1. Descripción y objetivos

Transcripción

1 Pruebas 1

2 1. Descripción y objetivos Las pruebas son prácticas a realizar en diversos momentos de la vida del sistema de información para verificar: El correcto funcionamiento de los componentes del sistema. El correcto ensamblaje entre los distintos componentes. El funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de información con los que se comunica. El funcionamiento correcto del sistema integrado de hardware y software en el entorno de operación. Que el sistema cumple con el funcionamiento esperado y permite al usuario de dicho sistema que determine su aceptación, desde el punto de vista de su funcionalidad y rendimiento. Que los cambios sobre un componente de un sistema de información, no introducen un comportamiento no deseado o errores adicionales en otros componentes no modificados. 2

3 1. Descripción y objetivos El diseño de casos de prueba para la verificación del software puede significar un esfuerzo considerable (cerca del 40% del tiempo total de desarrollo) Verificación y Validación Verificación: ió estamos construyendo el producto correctamente? Validación: estamos construyendo el producto correcto? Recursos: 3

4 2. Tipologías. Pruebas Unitarias. Pruebasb de Integración. Pruebas del Sistema. Pruebas de Implantación. Pruebas de Aceptación. Pruebas de Regresión. 4

5 2. Tipologías. Unitarias Las pruebas unitarias constituyen la prueba inicial de un sistema y las demás pruebas deben apoyarse sobre ellas. Tipologías: Enfoque estructural t o de caja blanca. Se verifica la estructura interna del componente con independencia de la funcionalidad establecida para el mismo. Por tanto, no se comprueba la corrección de los resultados si éstos se producen. Enfoque funcional o de caja negra. Se comprueba el correcto funcionamiento de los componentes del sistema de información, analizando las entradas y salidas y verificando que el resultado es el esperado. 5

6 2. Tipologías. Integración El objetivo de las pruebas de integración es verificar el correcto ensamblaje entre los distintos componentes una vez que han sido probados unitariamente con el fin de comprobar que interactúan correctamente a través de sus interfaces, tanto internas como externas, cubren la funcionalidad establecida y se ajustan a los requisitos no funcionales especificados en las verificaciones correspondientes. 6

7 2. Tipologías. Del Sistema. Las pruebas del sistema tienen como objetivo ejercitar profundamente el sistema comprobando la integración del sistema de información globalmente,, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de información con los que se comunica. 7

8 2. Tipologías. Del Sistema. Pruebas funcionales. Dirigidas a asegurar que el SI realiza correctamente todas las funciones que se han detallado en las especificaciones dadas por el usuario del sistema. Pruebas de comunicaciones. Determinan que las interfaces entre los componentes del sistema funcionan adecuadamente, tanto a través de dispositivos remotos, como locales. Asimismo, se han de probar las interfaces hombre/máquina. Pruebas de rendimiento. Determinar que los tiempos de respuesta están dentro de los intervalos establecidos en las especificaciones del sistema. Pruebas de volumen. Examinar el funcionamiento del sistema cuando está trabajando con grandes volúmenes de datos, simulando las cargas de trabajo esperadas. Pruebas de sobrecarga. Comprobar el funcionamiento del sistema en el umbral límite de los recursos, sometiéndole a cargas masivas. El objetivo es establecer los puntos extremos en los cuales el sistema empieza a operar por debajo de los requisitos establecidos. Pruebas de disponibilidad de datos. Consisten en demostrar que el sistema puede recuperarse ante fallos, tanto de equipo físico como lógico, sin comprometer la integridad de los datos. Pruebas de facilidad de uso. Consisten en comprobar la adaptabilidad del sistema a las necesidades de los usuarios, tanto para asegurar que se acomoda a su modo habitual de trabajo, como para determinar las facilidades que aporta al introducir datos en el sistema y obtener los resultados. Pruebas de operación. Consisten en comprobar la correcta implementación de los procedimientos de operación, incluyendo la planificación y control de trabajos, arranque y rearranque del sistema, etc. Pruebas de entorno. Verificar las interacciones i del sistema con otros sistemas dentro del mismo entorno. Pruebas de seguridad. Consisten en verificar los mecanismos de control de acceso al sistema para evitar alteraciones indebidas en los datos. 8

9 2. Tipologías. De Implantación. El objetivo es comprobar el funcionamiento correcto del sistema integrado de hardware y software en el entorno de operación, y permitir al usuario que, desde el punto de vista de operación, revise el sistema en base al cumplimiento de los requisitos no funcionales especificados. 9

10 2. Tipologías. De Aceptación. El objetivo de las pruebas de aceptación es validar que un sistema cumple con el funcionamiento esperado y permitir al usuario de dicho sistema que determine su aceptación,, desde el punto de vista de su funcionalidad y rendimiento. 10

11 2. Tipologías. De Regresión. El objetivo de las pruebas de regresión es eliminar el efecto onda, es decir, comprobar que los cambios sobre un componente de un sistema de información, no introducen un comportamiento no deseado o errores adicionales en otros componentes no modificados (Repeticióni ió de casos de prueba) 11

12 3. Pruebas de Caja Blanca Objetivo: Probar el funcionamiento de la estructura de control de las unidades de programación. Garantizan que se ejecutan una vez por lo menos todos los caminos independientes de cada módulo. Prueban todas las decisiones lógicas en sus vertientes verdadera d y falsa. Ejecutan todos los bucles. Ejecutan todas las estructuras internas. 12

13 3. Pruebas de Caja Blanca Pruebas Caja Blanca: Prueba del Camino Básico Prueba de la Estructura de Control. Prueba de condición Prueba de flujo de datos Prueba de bucles 13

14 3. Pruebas de Caja Blanca. Camino Básico Propuesta por Tom McCabe (1976) Objetivo: Definir un conjunto básico de caminos de ejecución. Pasos: A partir del diseño o del código fuente, dibujar el grafo de flujo asociado Se calcula la complejidad ciclomática del grafo Se determina un conjunto básico de caminos independientes Se preparan los casos de prueba que obliguen a la ejecución de cada camino del conjunto básico 14

15 3. Pruebas de Caja Blanca. Camino Básico Secuencia If Case While Until 15

16 3. Pruebas de Caja Blanca. Camino Básico Complejidad ciclomática de un grafo de flujo V(G) establece el número de caminos independientes Pueded calcularse l de tres formas alternativas: El número de regiones del grafo de flujo V(G) = A - N + 2, donde A es el número de aristas y N es el número de nodos V(G) = P + 1, donde P es el número de nodos predicado 16

17 3. Pruebas de Caja Blanca. Camino Básico 1 V(G) = , 3 6 4, 4, El grafo de la figura tiene cuatro regiones. 11 aristas - 9 nodos + 2 =4 9 3 nodos predicado + 1 =

18 3. Pruebas de Caja Blanca. Camino Básico Camino 1: 1-9 Camino 2: Camino 3: Camino 4:

19 3. Pruebas de Caja Blanca. Estructuras de Control Bucles anidados Bucles simples Bucles concatenados Bucles no estructurados 19

20 3. Pruebas de Caja Blanca. Estructuras de Control Prueba de Bucles. Objetivo: Validar las construcciones de bucles. Tipos: Simples. Aplicar, siendo n el número máximo de pasos permitidos: 1. Saltarse el bucle. 2. Ejecutarlo sólo una vez. 3. Pasar dos veces. 4. Hacer m pasadas, siendo m<n. 5. Hacer n-1 y n+1 pasos en el bucle. Concatenados 1.Comenzar por el bucle más interno. 2. Probarlo como un bucle simple. 3. Progresar hacia fuera, manteniendo los bucles internos en sus valores típicos. 4. Continuar hasta probarlos todos. Anidados Si el contador del primer bucle no se utiliza como valor inicial del segundo bucle, pueden probarse como bucles simples. Si no es así deberá aplicarse el enfoque de anidados. 20

21 4. Pruebas de Caja Negra. Las pruebas de caja negra se centran en los requisitos funcionales del software Comprobar que la funcionalidad del programa o sistema es completamente operativa. Que la entrada se acepta de forma adecuada d y la salida es correcta. Verificar que la integridad de la información interna se mantiene. Errores típicos encontrados: Funciones incorrectas o ausentes Errores de interfase Errores de estructura de datos o acceso a BD externas Errores de rendimiento Errores de inicialización y de terminación 21

22 4. Pruebas de Caja Negra. Algunas técnicas que se basan en la filosofía de la caja negra son: Partición Equivalente Análisis de Valores Límite Grafos de Causa-Efecto Pruebas de Comparación 22

23 4. Pruebas de Caja Negra. Partición Equivalente Método que divide el campo de entrada de un programa en clases de datos Una condición de entrada es un valor numérico específico, un rango de valores, un miembrodeunconjuntodevaloresológica Una clase de equivalencia i representa un conjunto de estados válidos y no válidos para una condición ió de entrada La prueba de partición equivalente se basa en evaluar las clases de equivalencia para una condición de entrada 23

24 4. Pruebas de Caja Negra. Partición equivalente. Condición de Entrada Tipo Clase Equivalencia Válida Clase Equivalencia No Válida Código banco Lógica (puede 1: En blanco 3: Un valor no numérico éi estar o no) Si está es Rango 2: 100<= Código banco <= 999 4: Código banco < 100 5: Código banco > 999 Código Rango 6: 0 <= Código sucursal <= 7: Código sucursal < 1000 sucursal : Código sucursal >= 9999 Nº Cuenta Valor 9: Cualquier número de cinco 10: Número de más de cinco dígitos dígitos 11: Número de menos de cinco dígitos Clave Valor 12: Cualquier cadena de caracteres alfanuméricos de 5 posiciones Orden Conjunto, con comportamiento distinto t 15: 16: Transferencia 17: Retroceso 13: Cadena de menos de 5 posiciones 14: Cadena de más de 5 posiciones i 18: Cadena distinta de blanco y de las válidas 24

25 4. Pruebas de Caja Negra. Valores límite La técnica de Análisis de Valores Límites selecciona casos de prueba que ejerciten los valores límite Complementa la prueba de partición i equivalente. En lugar de realizar la prueba con cualquier elemento de la partición equivalente, se escogen los valores en los bordes de la clase Se derivan tanto casos de prueba a partir de las condiciones i de entrada como con las de salida 25

26 26