SEMINARIO DE APLICACIONES DE SOFTWARE

LEON VELAZQUEZ, RAFAEL

Pgina 1 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE

LEON VELAZQUEZ, RAFAEL

Existen 2 formas de desarrollar un diseo de software: Una es hacerla tan simple que obviamente no hay deficiencias, y la otra es que sea tan complicada que no existan deficiencias obvias. El primer mtodo es mucho ms difcil C.A.R. Hoare

Pgina 2 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE

LEON VELAZQUEZ, RAFAEL

INDICE
Justificacin. ________________________________________________________________________ 1 Tcnicas de prueba de software. _____________________________________________________ Objetivos de las pruebas. ___________________________________________________________ Diseo de caja de prueba. __________________________________________________________ Pruebas del camino bsico. _________________________________________________________ Notacin de grafos de flujo. _________________________________________________________ Complejidad ciclomticas. __________________________________________________________ Obtencin de casos de prueba. ______________________________________________________ Matrices de grafo. _________________________________________________________________ Prueba de la estructura de control. ____________________________________________________ Prueba de condicin. ______________________________________________________________ Prueba de flujo de datos. ___________________________________________________________ Prueba de bucles. _________________________________________________________________ Prueba de caja negra. _____________________________________________________________ Mtodos de prueba basados en grafos. ________________________________________________ Participacin equivalente. ___________________________________________________________ Anlisis de limites de valores. ________________________________________________________ Prueba de comparacin. ____________________________________________________________ Prueba de tabla ortogonal. __________________________________________________________ Prueba de entornos especializados, arquitecturas y aplicaciones. ___________________________ Prueba de interfaces graficas de usuarios. _____________________________________________ Prueba de arquitectura cliente servidor. ________________________________________________ Prueba de documentacin y facilidad de ayuda. _________________________________________ Prueba de sistemas de tiempo real. ___________________________________________________ Estrategia de pruebas de software. ___________________________________________________ Verificacin y validacin. ___________________________________________________________ Organizacin para la pruebas del software. _____________________________________________ Una estrategia de prueba de software. _________________________________________________ Criterio para completar la prueba. ____________________________________________________ Consideraciones sobre la prueba de unidad. ____________________________________________ Procedimiento para completar la prueba. _______________________________________________ Prueba de Integracin. _____________________________________________________________ Integracin descendente. ___________________________________________________________ Integracin ascendente. ____________________________________________________________ Prueba de regresin. ______________________________________________________________ Prueba de humo. _________________________________________________________________ Prueba de validacin. _____________________________________________________________ Criterios para la prueba. ____________________________________________________________
Pgina 3 de 27

5 6 6 6 7 8 8 9 10 12 12 13 13 14 15 15 16 16 16 17 17 17 18 18 18 19 19 20 20 20 21 21 21 22 22 23 23 23

SEMINARIO DE APLICACIONES DE SOFTWARE

LEON VELAZQUEZ, RAFAEL

24 24 24 24 24 24 25 25 25 25

Revisin de la configuracin. ________________________________________________________ Pruebas alfa. ____________________________________________________________________ Prueba beta. _____________________________________________________________________ 9 Prueba del sistema. _______________________________________________________________ Prueba de recuperacin. ___________________________________________________________ Prueba de seguridad. _____________________________________________________________ Prueba de resistencia. _____________________________________________________________ Prueba de rendimiento. ____________________________________________________________

10 Prueba de la depuracin. ___________________________________________________________ Proceso de depuracin. ____________________________________________________________

Pgina 4 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE

LEON VELAZQUEZ, RAFAEL

JUSTIFICACION En el sistema de control cyber se encuentran diferentes errores dentro de los cuales podemos resaltar como lo que son: La mala informacin que se maneja entre empleados de turno ya que estos sin duda alguna se lleva cada uno sus excedentes y tambin el desajuste de productos en ventas del da: Primero Se le maneja para cada turno uno cierto nmero de hojas las cuales sin que el empleado sepa el administrador deber llevar un control de estas dentro de un inventario y al final se sepa cuantas se usaron y cuantas se fueron a la basura para as saber cuntas impresiones son las que en realidad se estn contemplando o las que estn faltando por contemplar. Segundo Un problemas ms dentro del sistema es la falta del conocer, el tiempo de uso en cada uno de los equipos ya que esto llevara a conocer la realidad del tiempo dentro del cual los equipos estn en funcionamiento, para as saber porque hay excedentes y faltantes de dentro del recibo de luz desde un tiempo a la fecha.

Propuestas para corregir los problemas dentro de los sistemas cyber: Crear cuentas de acceso para todos y cada uno de los usuarios que maneje el sistema cyber. Implementar un mdulo dentro de cada uno de los equipos clientes que detecte l envi de impresiones al servidor y este tenga el control de todas las maquinas clientes para que al final del da sepa con certeza cuantas impresiones hubo al da independientemente del nmero de hojas que se le asignen al turno en curso y as obtener un mejor control. Crear un mtodo con el cual el equipo mande una bandera indicando las horas de trabajo y uso de este as saber el tiempo dentro del cual se estuvo usando para as saber por qu hay excedentes en el recibo de luz si segn el equipo estuvo apagado. Estas implementaciones se llevaran a cabo y el empleado estar enterado, lo que no sabr es como acceder a esa informacin ya que esta estar restringida dependiendo el acceso de seguridad que tenga cada uno de estos en sus cuentas. Conocer con certeza el control al da de cmo funciona el sistema mejorara al sistema hacindolo ms confiable para el propietario.

Pgina 5 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE 1. Tcnicas de Prueba de Software

LEON VELAZQUEZ, RAFAEL

Dentro de lo que es el desarrollo del sistema del software se realizaran unas series de pruebas las cuales son un elemento crtico para la garanta de la calidad del software. Fundamentos de la prueba de software La idea es crear casos de prueba los cuales intentaran validar al software desarrollado y as conocer los puntos de vulnerabilidad y corregirlos para hacer de este un mejor sistema. Objetivos de la pruebas Verificar la integracin adecuada de los componentes. Verificar que todos los requisitos se han implementado correctamente. Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software al cliente. Una prueba tiene xito si descubre un error no detectado hasta entonces.

Disear pruebas que sistemticamente saquen a la luz errores, hacindolo con la menor cantidad de tiempo y esfuerzo.

Diseo de caja de prueba. Es un proceso que se enfocara sobre la lgica interna del software y las funciones externas para la aplicacin. Es el proceso de ejecutar un programa con la intencin de descubrir un error. Disear tcnicas que proporcionen directrices sistemticas para pruebas de caja. 1) Comprobar la lgica interna y las interfaces de todo componente del software 2) Comprobar los dominios de entrada y salida del programa para descubrir errores en su funcin, comportamiento y desempeo. Realizando este proceso se podr obtener un 99% de confiabilidad en la aplicacin. Las prueba de este tipo examinan algn aspecto funcional de un sistema que tiene poca relacin con la estructura interna del software, y se prueban rutas lgicas del software y la colaboracin entre componentes, al proporcionar casos de prueba que ejerciten conjuntos especficos de condiciones, bucles o ambos.

Prueba de caja blanca: Permiten examinar la estructura interna del programa. Se disean casos de prueba para examinar la lgica del programa. Es un mtodo de diseo de casos de prueba que usa la

Pgina 6 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE

LEON VELAZQUEZ, RAFAEL

estructura de control del diseo procedimental para derivar casos de prueba que garanticen que: Se ejercitan todos los caminos independientes de cada mdulo. Se ejercitan todas las decisiones lgicas. Se ejecutan todos los bucles. Se ejecutan las estructuras de datos internas. Prueba de caja negra: Las pruebas se llevan a cabo sobre la interfaz del software, y es completamente indiferente el comportamiento interno y la estructura del programa. Los casos de prueba de la caja negra pretende demostrar que: Las funciones del software son operativas. La entrada se acepta de forma adecuada. Se produce una salida correcta, y La integridad de la informacin externa se mantiene. Se derivan conjuntos de condiciones de entrada que ejerciten completamente todos los requerimientos funcionales del programa. La prueba de la caja negra intenta encontrar errores de las siguientes categoras: Funciones incorrectas o ausentes. Errores de interfaz. Errores en estructuras de datos o en accesos a bases de datos externas. Errores de rendimiento. Errores de inicializacin y de terminacin. Los casos de prueba deben satisfacer los siguientes criterios: Reducir, en un coeficiente que es mayor que uno, el nmero de casos de prueba adicionales. Que digan algo sobre la presencia o ausencia de clases de errores.

2. Pruebas del camino bsico. El mtodo del camino bsico, propuesto por Tom McCabe, permite al diseador de casos de prueba obtener una medida de la complejidad lgica de un diseo procedimental y usar esa medida como gua para la definicin de un conjunto bsico de caminos de ejecucin. Los casos de prueba derivados del conjunto bsico garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia de programa.

Pgina 7 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE Notacin de grafos de flujo.

LEON VELAZQUEZ, RAFAEL

Cualquier representacin del diseo procedimental se puede traducir a un grafo de flujo. La complejidad ciclomtica de este grafo, define el nmero de caminos independientes del conjunto bsico de un programa y nos da un lmite superior para el nmero de pruebas que se deben realizar para asegurar que se ejecuta cada sentencia al menos una vez. Un camino independiente es cualquier camino del programa que introduce por lo menos un nuevo conjunto de sentencias de procesamiento o una nueva condicin. En trminos del grafo de flujo, un camino independiente se debe mover por lo menos por una arista que no haya sido recorrida anteriormente a la definicin de un camino. Representacin del flujo de control lgico con la siguiente notacin:

Complejidad ciclomticas. La complejidad ciclomtica se basa en el recuento del nmero de caminos lgicos individuales contenidos en un programa. La complejidad se puede calcular de tres formas: 1.- El nmero de regiones del grafo de flujo 2.- Aristas - Nodos + 2 3.-Nodos predicado + 1 (un nodo predicado es el que representa una condicional if o case, es decir, que de l salen varios caminos)

Pgina 8 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE

LEON VELAZQUEZ, RAFAEL

El valor de V(G) nos da el nmero de caminos linealmente independientes de la estructura de control del programa. Entonces se preparan los casos de prueba que forzarn la ejecucin de cada camino del conjunto bsico. A partir del valor de la complejidad ciclomtica obtenemos el nmero de caminos independientes, que nos dan un valor lmite para el nmero de pruebas que tenemos que disear. Obtencin de casos de prueba. El mtodo de prueba de camino bsico se puede aplicar a un diseo procedimental detallado o a un cdigo fuente. 1. 2. 3. 4. Dibujar el grafo correspondiente Determinar la complejidad. Determinar un conjunto bsico de caminos linealmente independientes Preparar casos de prueba que forzarn a la ejecucin de cada camino bsico.

A un cuando las propuestas para automatizar y sistematizar el proceso de obtencin de casos de prueba del sistema se pueden obtener a partir de los requisitos funcionales.

Pgina 9 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE

LEON VELAZQUEZ, RAFAEL

Proponiendo el hacer especial hincapi en algunos aspectos concretos como son: 1. El obtener un conjunto completo de pruebas del sistema que permitan garantizar que el sistema software cumple con la especificacin funcional dada, lo cual permite asegurar su calidad. 2. Partir de los requisitos funcionales del sistema y hacer especial hincapi a comenzar a desarrollar los casos de prueba del sistema en cuanto se dispongan los requisitos funcionales. 3. Usar el anlisis de los caminos posibles, bien mediante la descripcin textual de los pasos del escenario o caso de uso o mediante diagramas de estado. 4. Los requisitos funcionales no tienen que cumplir de principio ningn requisito formal. A partir de una breve descripcin en lenguaje corriente ya se puede comenzar a trabajar. 5. La derivacin de pruebas del sistema a partir de los requisitos funcionales se realiza de manera automtica y sistemtica. 6. La aplicacin de estas propuestas a los requisitos funcionales ayuda a validarlos, comprobando si son correctos y completos en las primeras fases de desarrollo.

Matrices de grafo. La prueba del camino bsico es una tcnica que se puede automatizar mediante la estructura de datos denominada Matriz de Grafo. Matriz de Grafo: Matriz Cuadrada. Tamao = N de nodos del grafo de flujo. Filas y columnas corresponden a nodos. Las entradas de la matriz corresponden a aristas (conexiones entre nodos). Peso de enlace: Nos da informacin adicional sobre el flujo de control. Se aade a cada entrada de la matriz. En su forma ms sencilla toma dos valores: 1: Si existe conexin. 0: Si no existe conexin. Gracias a los pesos de enlace se pueden derivar propiedades ms interesantes:
Pgina 10 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE

LEON VELAZQUEZ, RAFAEL

La probabilidad de que un enlace (arista) sea ejecutado El tiempo de procesamiento asociado al recorrido de un enlace La memoria requerida durante el recorrido de un enlace Los recursos requeridos durante el recorrido de un enlace Modulo para cuentas de acceso a usuarios
Nodo A Vrtices

A B C D E

CUENTAS DE ACCESO A USUARIOS PEDIR DATOS AL USUARIO (USER, PASS) COMPARAR DATOS SI SON CORRECTOS ENTRAR SI SON FALSOS VOLVER A PEDIR DATOS CONTINUAR AL SIGUIENTE MODULO

Matriz de grafo. A B C D E A 0 0 0 1 0 B C 1 0 0 1 0 0 0 0 0 0 Matriz de conexiones D 0 1 0 0 0 E 0 0 1 0 0

Lista de adyacencia
A B

E Pgina 11 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE Lista Arcos

A AB

LEON VELAZQUEZ, RAFAEL

BC

BD

CE

DA

3. Prueba de la estructura de control. Las estructuras de control o construcciones de control controlan la secuencia o flujo de ejecucin de las sentencias.

Prueba de condicin. Este Mtodo de diseo de casos de prueba, ejercita las condiciones lgicas contenidas en el mdulo de un sistema. Esta prueba asegurara en que cada condicin del sistema no contenga errores. Dentro de esta prueba se deber verificar la expresin relacional que adquiere la forma: E1<operador relacional>E2 donde E1 y E2 son expresiones aritmticas < operador relacional > puede ser<,<=,=,>,>=, Verificando que el sistema cumpla reglas como son: Si una condicin compuesta est formada por dos o ms condiciones simples, operadores lgicos o parntesis. Los operadores lgicos permitidos en una condicin compuesta incluyan OR(|), AND(&), NOT.

Pgina 12 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE

LEON VELAZQUEZ, RAFAEL

Y para esta prueba los errores de una condicin que podran encontrarse y corregir son: Error en operador lgico Error en variable lgica Error en parntesis lgico Error en operador relacional Error en expresin aritmtica

Prueba de flujo de datos. Este mtodo seleccionara caminos de prueba del sistema de acuerdo con la ubicacin de las definiciones y los usos de las variables del sistema. Las estrategias de prueba de flujo de datos son tiles para seleccionar caminos de prueba del sistema que contenga sentencias como if o bucles anidados. La prueba de flujo de datos ser efectiva para la proteccin contra errores Prueba de bucles. En este mtodo los bucles son la piedra angular de la inmensa mayora de los algoritmos implementados en el sistema, por lo que se les prestara una atencin especial a la hora de realizar la prueba del sistema. La prueba de bucles es una tcnica de prueba de caja blanca que se centra en la validez de las construcciones de los bucles. Se pueden definir cuatro tipos de bucles diferentes: Bucles simples Bucles concatenados Bucles anidados Bucles no estructurados

Pgina 13 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE Bucles simples

LEON VELAZQUEZ, RAFAEL

En el sistema a los bucles simples (de n iteraciones) se les tiene que aplicar el conjunto de pruebas siguientes: Saltar el bucle Pasar slo una vez por el bucle Pasar dos veces por el bucle Hacer m pasos del bucle con m < n Hacer n-1, n y n+1 pasos por el bucle Bucles anidados Si en el sistema extendisemos el conjunto de pruebas de los bucles simples a los bucles anidados, el nmero de pruebas crecera geomtricamente, por lo que Beizer sugiere el siguiente conjunto de pruebas para bucles anidados: Comenzar con el bucle ms interno, estableciendo los dems bucles a los valores mnimos Llevar a cabo las pruebas de bucles simples para el bucle ms interno, conservando los valores de iteracin de los bucles ms externos a los valores mnimos Progresar hacia fuera en el siguiente bucle ms externo, y manteniendo los bucles ms externos a sus valores mnimos Continuar hasta que se hayan probado todos los bucles Bucles concatenados En el sistema se probaran los bucles concatenados mediante las tcnicas de prueba para bucles simples, considerndolos como bucles independientes. Bucles no estructurados Dentro del sistema se redisearan estos bucles para que se ajusten a las construcciones de la programacin estructurada.

4. Prueba de caja negra. En el sistema se corrern pruebas de caja negra que se llevaran a cabo sobre la interfaz grfica de este, obviando el comportamiento interno y la estructura del sistema. Los casos de prueba de la caja negra demostraran que: Las funciones del software son operativas La entrada se acepta de forma correcta Se produce una salida correcta
Pgina 14 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE La integridad de la informacin externa se mantiene

LEON VELAZQUEZ, RAFAEL

Esta prueba de caja negra pretende encontrar estos tipos de errores en el sistema: Funciones incorrectas o ausentes Errores en la interfaz Errores en estructuras de datos o en accesos a bases de datos externas Errores de rendimiento Errores de inicializacin y de terminacin Mtodos de prueba basados en grafos. En este mtodo se debe entender los objetos (objetos de datos, objetos de programa tales como mdulos o colecciones de sentencias del lenguaje de programacin) que se modelaran en el software y las relaciones que conectan a estos objetos. Una vez que se ha llevado a cabo esto, el siguiente paso es definir una serie de pruebas que verifiquen que todos los objetos tienen entre ellos las relaciones esperadas. Los pasos a seguir para una prueba de caja Negra en el sistema sern: Entender los objetos que se van a modelar y las relaciones que conectan a estos (grafos). Definir una serie de pruebas que verifique que todos los objetos tienen entre ellos la relaciones esperadas

Participacin equivalente. Con este mtodo de prueba de caja negra dividiremos el dominio de entrada de un programa en clases de datos, a partir de las cuales se derivaran los casos de prueba. Cada una de estas clases de equivalencia representa a un conjunto de estados vlidos o invlidos para las condiciones como son: Condiciones externas Clases de equivalencia vlidas Clases de equivalencia invlidas En el sistema se seguirn las siguientes directrices para identificar errores y as mismo corregirlos. Si una condicin de entrada especifica un rango de valores (p.e, entre 1 y 999), se define una CEV (1 <= valor <= 999) y dos CEI (valor < 1 y valor > 999) Si una CE requiere un valor especfico (p.e., el primer carcter tiene que ser una letra), se define una CEV (una letra) y una CEI (no es una letra)

Pgina 15 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE

LEON VELAZQUEZ, RAFAEL

Si una CE especifica un conjunto de valores de entrada, se define una CEV para cada uno de los valores vlidos, y una CEI (p.e., CEV para "Moto", "Coche" y "Camin", y CEI para "Bicicleta") Si una condicin de entrada especifica el nmero de valores (p.e., una casa puede tener uno o dos propietarios), identificar una CEV y dos CEI (0 propietarios y 3 propietarios)

Anlisis de lmites de valores. Dentro de esta prueba las reglas para identificar las clases son: Si una condicin de entrada especifica un rango que deben generar casos para los extremos. Si la condicin de entrada especifica un nmero finito y consecutivo de valores, escribir casos para los nmeros mximo, mnimo, uno ms del mximo y uno menos del mnimo de valores Usar la regla 1 para la condicin de salida. Usar la regla 2 para cada condicin de salida.

Prueba de comparacin. En el sistema se desarrollaran versiones independientes de una aplicacin con las mismas especificaciones. Se probaran todas las versiones con los mismos datos de prueba. Se ejecutaran las versiones en paralelo y se har una comparacin en tiempo real de los resultados. Prueba de tabla ortogonal. En el sistema se encontraran aplicaciones donde el nmero de parmetros de entrada es pequeo y los valores de cada uno de los parmetros estn claramente delimitados. Cuando estos nmeros son muy pequeos (por ejemplo, 3 parmetros de entrada tomando 3 valores diferentes), es posible considerar cada permutacin de entrada y comprobar exhaustivamente el proceso del dominio de entrada. En cualquier caso, cuando el nmero de valores de entrada crece y el nmero de valores diferentes para cada elemento de dato se incrementa, la prueba exhaustiva se hace impracticable. La prueba de la tabla ortogonal la aplicaremos a problemas en que el dominio de entrada es relativamente pequeo pero demasiado grande para posibilitar pruebas exhaustivas. El
Pgina 16 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE

LEON VELAZQUEZ, RAFAEL

mtodo de prueba de la tabla ortogonal es particularmente til para encontrar errores asociados con fallos localizados en una categora de error asociada con defectos de la lgica dentro de un componente del sistema. La prueba de tabla ortogonal permitir proporcionar una buena cobertura de pruebas con bastantes menos casos de prueba que en la estrategia exhaustiva. As la prueba: Detectara y aislara todos los fallos de modalidad simple. Un fallo de modalidad simple es un problema que afecta a un solo parmetro. Detectara todos los fallos de modalidad doble. Si existe un problema donde estn afectados dos parmetros que intervienen conjuntamente, se llama fallo de modalidad doble Fallos multimodales. Las tablas ortogonales [del tipo indicado] pueden asegurar la deteccin nicamente de fallos de modalidad simple o doble.

5. Prueba de entornos especializados, arquitecturas y aplicaciones.

Prueba de interfaces graficas de usuarios. Para este tipo de mtodo se enfocara en probar si la interfaz grfica del sistema es amigable y cumple con los requerimientos establecidos por el usuario. As mismo se comprobara la entrada de los datos para su posterior visualizacin de resultados. En esta tcnica se tomaran en cuenta dos aspectos importantes para la comprobacin de la interfaz grfica: * Pruebas sobre ventanas. * Pruebas de entrada de datos. Ya que estas han crecido en su complejidad. Debido a que muchas de las GUI actuales tienen un aspecto y modo de uso muy similares de tal manera que podramos derivar una serie de pruebas estndar y herramientas para prueba GUI.

Prueba de arquitectura cliente servidor. La naturaleza distribuida, el desempeo relacionado con el proceso de transaccin, la posibilidad de varias plataformas de hardware, la complejidad de la comunicacin de red; son aspectos a considerar dentro del sistema realizando pruebas en:
Pgina 17 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE

LEON VELAZQUEZ, RAFAEL

Prueba de servidor: se probaran las funciones de coordinacin y manejo de datos del servidor. Esto es el desempeo del servidor (tiempo de respuesta y procesamiento total de los datos). Prueba de base de datos: se probara la exactitud e integridad de los datos, examinando transacciones, para asegurar que se almacenen, actualicen y recuperen los datos. Pruebas de comunicacin de red: verificar que la comunicacin entre los nodos, el paso de mensajes, transacciones y el trfico de la red se realice sin errores.

Prueba de documentacin y facilidad de ayuda. En el sistema los errores de documentacin y ayuda al usuario son devastadores para la aceptacin de software, si no coinciden entre s. Es por esto que esta prueba es importante para la aceptacin del programa, ya que se revisara la gua de usuario o funciones de ayuda en lnea. Esta prueba de documentacin se har en dos fases: 1. Revisar e inspeccionar: examinar la claridad editorial del documento. 2. Prueba en vivo: usar la documentacin junto con el programa real.

Prueba de sistemas de tiempo real. En este mtodo se deber probar el manejo de eventos, la temporizacin de los datos y el paralelismo entre procesos que manejan los datos y as asegurar el correcto funcionamiento del sistema.

6. Estrategia de pruebas de software. Las estrategias de prueba de software se realizan para descubrir errores cometidos sin darse cuenta al realizar el diseo y construccin del sistema. En procesos de prueba eficaz que ayudan a descubrir los errores. En un conjunto de actividades que se planean con anticipacin y se realizan de manera sistemtica.

Verificacin y validacin. Verificacin: Estamos construyendo el producto correctamente?. El software debe ajustarse a su especificacin

Pgina 18 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE Validacin: Estamos construyendo el producto correcto?. El software debe hacer lo que el cliente realmente reclama.

LEON VELAZQUEZ, RAFAEL

Es el proceso de todo un ciclo vital: La Verificacin y Validacin deben aplicarse en cada etapa del software. Con dos objetivos primordiales El descubrimiento de defectos en el sistema; La evaluacin de si el sistema es til y utilizable en una situacin operacional o no. Estas pruebas deben establecer la confianza de que el software es adecuado al propsito, NO significa que est completamente libre de defectos. Sino que debe ser lo suficientemente bueno para su uso previsto y el tipo de uso determinar el grado de confianza que se necesita.

Organizacin para la pruebas del software. El desarrollo de software es una tarea constructiva, desde la especificacin de requisitos hasta la documentacin del sistema. Al comenzar estas pruebas se tratar de romper lo que ha construido el ingeniero de software El ingeniero de software trata de ser indulgente con el producto El responsable de desarrollo no debe participar en el proceso de prueba El software debe ponerse a salvo de extraos que lo prueben sin misericordia Quienes aplican pruebas slo deben participar en el proyecto cuando se vaya a darse los primeros pasos de esas pruebas El responsable El desarrollador del componente SIEMPRE ser el responsable de probar los componentes del programa y asegurar que cada uno realice la funcin o muestre el comportamiento para el que se dise En muchos casos, el desarrollador aplicara la prueba de integracin El grupo independiente Trabajara junto con el desarrollador para hacer pruebas exhaustivas El desarrollador debe estar disponible para corregir los errores que se descubran Participara en el anlisis y diseo del sistema

Pgina 19 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE Una estrategia de prueba de software.

LEON VELAZQUEZ, RAFAEL

Se realiza con pruebas efectivas en donde un equipo de software debe efectuar revisiones tcnicas formales y efectivas. Tales pruebas comienza al nivel de componentes y trabajan hacia fuera, hacia la integracin de los componentes. Con diferentes tcnicas de prueba que son apropiadas en diferentes momentos. Estas pruebas las dirigir el desarrollador del software y un grupo independiente de pruebas, tales pruebas y las depuraciones son actividades diferentes, pero la segunda se debe incluir en la estrategia de pruebas, con lo que deben de incluir pruebas de bajo nivel y de alto nivel

Criterio para completar la prueba. Nunca se terminara de aplicar la prueba La carga se desplaza al cliente Cada vez que se ejecuta el software se est probando Tal prueba se termina cuando se acaba el dinero o el tiempo, sugiriendo respuestas basadas en criterios estadsticos obtenidos a travs de modelos de confiabilidad del software.

Consideraciones sobre la prueba de unidad. Para esta prueba se realizara consideraciones como son: Verifica el componente o mdulo de software Se deber tomar como gua la descripcin del diseo al nivel de componentes Se concentrara en la lgica de procesamiento interno y en las estructuras de datos dentro de los lmites de un componente. Se limitara la complejidad de las pruebas.

Realizndose mediante: Interfaz Se probara para verificar que la informacin fluye apropiadamente hacia dentro y hacia fuera del mdulo Estructura de datos locales Se asegurara que los datos temporales mantienen la integridad durante todos los pasos de la ejecucin del algoritmo Rutas de ejecucin Se recorrern todos los caminos independientes para probar que todas las instrucciones se hayan ejecutado al menos una vez
Pgina 20 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE

LEON VELAZQUEZ, RAFAEL

Condiciones lmite Se asegura que el mdulo opera apropiadamente en los lmites establecidos para restringir el procesamiento Rutas de manejo de errores Se probaran todos los caminos que involucran a los errores

Procedimiento para completar la prueba. Para completar tal prueba se deber: Tomar como base la especificacin del mdulo. Con cada caso de prueba se debe relacionar con un conjunto de resultados esperados Desarrollar un software controlador o de resguardo.

Controlador: programa principal, acepta los datos de prueba y los pasa al componente. Resguardo: Reemplaza los mdulos subordinados al componente que habr de probarse, usando la interfaz del mdulo subordinado, realizando una mnima manipulacin de datos, proporcionando la verificacin de la entrada y devolviendo el control al mdulo de prueba. Simplificando el trabajo cuando el mdulo tiene cohesin elevada

7. Prueba de Integracin. Es una tcnica sistemtica para construir la arquitectura del software mientras, al mismo tiempo, se aplican las pruebas para descubrir errores asociados con la interfaz. Son prdidas de datos, mdulos con efectos adversos sobre otros, combinacin de funciones que no produzca el resultado deseado, imprecisin inaceptable, estructuras globales de datos, etc. Tal tcnica se construye y prueba en pequeos incrementos, en los cuales resulta ms fcil aislar y corregir errores. Integracin descendente. Este es un enfoque incremental para la construccin de la arquitectura del software. Los mdulos se integraran al descender por la jerarqua de control, empezando por el programa principal y los mdulos subordinados al principal, se incorporan en la estructura de dos maneras: Primero en profundidad Primero en anchura
Pgina 21 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE

LEON VELAZQUEZ, RAFAEL

El proceso se realiza desde el mdulo de control principal que se utiliza como controlador de prueba, sustituyendo los resguardos en todos los componentes directamente subordinados al mdulo de control principal. Dependiendo del enfoque (profundidad o anchura) se van reemplazando los resguardos subordinados, uno por uno, con los componentes reales. Estas pruebas se aplicaran cada vez que se integra un nuevo mdulo y al completar cada conjunto de pruebas, se reemplaza otro resguardo con el mdulo real, aplicando la prueba de regresin para asegurarse que no se han introducido nuevos errores.

Integracin ascendente. Esta integracin empieza con la construccin y prueba de mdulos atmicos, y se elimina la necesidad de resguardos. En la estrategia de integracin ascendente: Se combinan los mdulos de bajo nivel en grupos que realicen una subfuncin especfica del software Se escribe un controlador con el fin de coordinar la entrada y salida de los casos de prueba Se prueba el grupo Se eliminan los controladores y se combinan los grupos ascendiendo por la estructura del sistema

Prueba de regresin. Esta prueba consiste en ejecutar nuevamente el mismo subconjunto de pruebas que ya se ha aplicado para asegurarse de que los cambios no han propagado efectos colaterales adversos Ejecutndose manualmente un subconjunto de todos los casos de prueba o se usan herramientas de captura, reproduccin. Con una muestra representativa de pruebas que ejercern todas las funciones del software Con pruebas adicionales que se concentran en las funciones del software que probablemente el cambio afectara y pruebas que se concentran en los componentes del software que han cambiado.

Pgina 22 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE Prueba de humo.

LEON VELAZQUEZ, RAFAEL

Este es un enfoque de prueba de integracin. Marca el ritmo en proyectos en los cuales el tiempo es crtico, lo que permite que el equipo de software evale su proyecto con frecuencia. En el procedimiento. Los componentes del software traducidos a cdigo se integran en una construccin (archivos de datos, libreras, mdulos reutilizables) Se disea una serie de pruebas para exponer errores que impedirn que la construccin realice apropiadamente su funcin. El objetivo es encontrar errores paralizantes que tengan la mayor probabilidad de retrasar el proyecto. La construccin se integra con otras construcciones y diariamente se aplica una prueba de humo a todo el producto. El enfoque de integracin puede ser ascendente o descendente. Con esta prueba se minimiza el riesgo en la integracin. Desde el principio se descubren incompatibilidades, mejorando la calidad del producto final. Tambin se pueden descubrir errores funcionales, arquitectnicos y al nivel de componentes. Simplificando el diagnstico y la correccin de errores o errores no descubiertos que se descubrirn en la siguiente construccin.

8. Prueba de validacin. Esta prueba comienza al culminar las pruebas de integracin, ya que en este nivel desaparece la distincin entre software convencional y software orientado a objetos, y en esta prueba se concentrara en las acciones visibles para el usuario y en la salida del sistema que ste puede reconocer. La especificacin de requisitos del software junto con la seccin criterios de aceptacin forman la base para establecer la estrategia de pruebas de validacin. Criterios para la prueba. Se realiza el criterio con el requisitos. objetivo de demostrar que las pruebas cumplen con los

Se desarrolla un plan Se establece la clase de pruebas que se ejecutarn Se definen los casos de prueba Se debe incluir todas las caractersticas funcionales, de comportamiento, de desempeo, de facilidad de uso y otros requisitos especificados Si se descubren desviaciones de la especificacin, se crea una lista y se negocia con el cliente un mtodo para resolver las deficiencias
Pgina 23 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE

LEON VELAZQUEZ, RAFAEL

Revisin de la configuracin. Esta se realiza con el objetivo de asegurar que todos los elementos de la configuracin del software se hayan desarrollado apropiadamente, que estn catalogados y tengan el detalle suficiente para reforzar la fase de soporte del ciclo de vida del software. Pruebas alfa. Esta prueba se llevara a cabo, por un cliente, en el lugar de desarrollo. Usando el software de forma natural con el desarrollador como observador del usuario y registrando los errores y problemas de uso. Las pruebas alfa se llevaran a cabo en un entorno controlado. Prueba beta. La realizacin de esta prueba se llevara a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. A diferencia de la prueba alfa, el desarrollador no est presente normalmente. As, la prueba beta es una aplicacin en vivo del software en un entorno que no puede ser controlado por el desarrollador. El cliente registra todos los problemas que encuentra durante la prueba beta e informa en intervalos regulares al desarrollador.

9.

Prueba del sistema.

Se probara el sistema de cmputo profundamente y as poder adelantarse a los posibles problemas de interfaz. Las pruebas trabajaran para verificar que se hayan integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas.

Prueba de recuperacin. Sera la prueba que obliga al software a fallar de varias maneras y a verificar que la recuperacin se realice apropiadamente. Si la recuperacin es automtica debe evaluarse que sean correctos la reinicializacin, mecanismos de respaldo del sistema y recuperacin de datos Si la recuperacin es manual, se debe evaluar el tiempo medio de reparacin para determinar si se encuentra dentro de lmites aceptables

Prueba de seguridad. Este tipo de prueba comprobara que los mecanismos de proteccin integrados en el sistema verificando que realmente lo protejan de irrupciones inapropiadas

Pgina 24 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE

LEON VELAZQUEZ, RAFAEL

Para as el papel del diseador del sistema es que el costo de la irrupcin sea mayor que el valor de la informacin que habr de obtenerse. Prueba de resistencia. Se ejecutara el sistema de tal manera que requiera una cantidad, una frecuencia o un volumen anormal de recursos. De lo que se tratara es de sobrecargar el sistema para realizar as una prueba de sensibilidad. Tratando de descubrir combinaciones de datos dentro de las clases de entrada vlidas que causen inestabilidad o procesamiento inadecuado. Prueba de rendimiento. Est prueba est diseada para probar el rendimiento del software en tiempo de ejecucin dentro del contexto de un sistema integrado que: Se aplicara en todos los niveles de prueba, desde prueba de unidad. Se requerir instrumentacin externa para medir el desempeo del sistema.

10. Prueba de la depuracin. Esta prueba de depuracin ocurre como consecuencia de una prueba realizada con xito. El propsito es eliminar los errores en el cdigo Esta depuracin siempre arrojara dos resultados Se encuentra y corrige la causa No se localiza la causa

Se requiere, a partir de la sospecha, disear uno o ms casos de prueba que ayuden a convalidar esa sospecha y avanzar hacia la correccin del error de manera iterativa

Proceso de depuracin. El proceso ser fuerza bruta, seguimiento hacia atrs y eliminacin de la causa Fuerza bruta Es el mtodo ms comn y menos eficiente en el que se aplica la filosofa Dejemos que la computadora encuentre el error Se hacen descargas de memoria, se invocan seales en tiempo de ejecucin, se carga el programa con instrucciones de salida

Pgina 25 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE Rastreo hacia atrs

LEON VELAZQUEZ, RAFAEL

Comienza en el sitio en donde se encuentra un sntoma, se recorre hacia atrs el cdigo fuente (manualmente) hasta hallar el sitio de la causa Funciona con programas pequeos

Eliminacin de la causa Se realiza por induccin o deduccin introduciendo el concepto de particin binaria. Se elaboran hiptesis de causas y se aprovechan los datos de los sntomas para probar o desechar hiptesis. Elaborando una lista de todas las causas posibles y aplicando pruebas para eliminar cada una de ellas.

Existiendo otro proceso el cual se llama: Depuracin automatizada En el cual las herramientas complementan los enfoques anteriores Los IDE capturan errores de sintaxis, variables indefinidas, caracteres faltantes sin compilacin. Estos cuentan con compiladores que soportan la depuracin, ayudas dinmicas para la depuracin, generadores automticos de casos de prueba, herramientas de correlacin de referencias cruzadas. Las herramientas NO son sustituto de la evaluacin cuidadosa basada en un modelo de diseo completo y un cdigo fuente claro.

Pgina 26 de 27

SEMINARIO DE APLICACIONES DE SOFTWARE

LEON VELAZQUEZ, RAFAEL

Antes de que el software pueda ser reutilizable primero debe ser utilizable Ralph Johnson

Pgina 27 de 27