10.- Flujo de Pruebas Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA

1. 10.- Flujo de Pruebas Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA

2. Contenidos • Introducción • Error • Pasos • Verificación & Validación • Métodos de pruebas • Tipos de pruebas • Actividades de pruebas

3. Introducción • Se verifica el resultado de la implementación probando cada “build” -internos e intermedios- y la release. • Objetivos: • Planear las pruebas requeridas en cada iteración, incluyendo pruebas de integración y de sistema. • Integración: para cada “build”, estilo caja blanca. • Sistema: al final de cada iteración. Comportamiento observable externamente. • Diseñar e implementar las pruebas, creando casos de prueba, procedimientos de prueba (cómo hacerlos) y creando componentes de prueba ejecutables para automatizar las pruebas. • Realizar las pruebas y manejar sistemáticamente los resultados de las mismas.

4. Error • Un error software existe cuando el software no hace lo que el usuario espera que haga, acordado previamente en la especificación de requisitos.

5. Pasos • Los ing. de pruebas realizan el plan de pruebas para cada iteración (esfuerzo de pruebas a realizar). • Describen los casos de prueba y los procedimientos de prueba a realizar. • Si procede, los ing. de componentes crean los componentes de prueba para automatizar las pruebas. • Los probadores de sistema e integración prueban cada build y anotan los defectos encontrados. • Los resultados se pasan a los ing.de pruebas para que evalúen los resultados de las pruebas y a otros flujos como diseño e implementación para subsanar los defectos.

6. Verificación & Validación • Verificación: • ¿Se ha construido el sistema correctamente? • Validación: • ¿se ha construido el sistema correcto?

7. Métodos de pruebas (I): caja blanca • Comportamiento interno y estructura del programa. • Se ejecutan todas las sentencias al menos una vez • Se navega por todos los caminos independientes • Realista: es imposible. • Técnicas: • Prueba de interfaz • Análisis del flujo de datos a través de las interfaces. • Prueba de estructuras de datos locales • Prueba del camino básico • Definición de un conjunto básico de caminos de ejecución usando una medida calculada previamente de la complejidad lógica del módulo (complejidad ciclomática). • Prueba de condiciones límite • Validar la construcción de los bucles.

8. Métodos de pruebas (y II): caja negra • Considera el SW como una caja negra sin tener en cuenta los detalles. • Los datos de entrada han de generar una salida en concordancia con las especificaciones. • Técnicas: • Partición de equivalencia • División de la entrada de un programa en clases de datos de las que se pueden derivar casos de prueba para reducirlos. • Análisis de valores límite • Probar los límites de cada clase de equivalencia.

9. Tipos de pruebas (I): unitarias • Prueba de cada módulo o clase del programa de manera que cumpla unitariamente el caso de uso que implementa. • Realizada por el ingeniero de desarrollo del caso de uso. • Ventajas: • Error más localizado. • Se pueden probar varios módulos simultaneamente. • Método empleado: caja blanca. • En algunos casos se pueden crear módulos sencillos de prueba para probar módulos con alta cohesión.

10. Tipos de pruebas (II): de integración • Integración de módulos en subsistemas. • Método: caja negra -blanca a veces-. • Tipos: • No incremental (BIG BANG): todo a la vez :( • Incremental.

11. Tipos de pruebas (III): de validación • Comprobación de que se cumplen todos los requisitos. • Dos partes: • Validación por parte del usuario. • Utilidad, facilidad de uso y ergonomía de la GUI. • Tipos: • Pruebas Alfa: realizadas por los desarrolladores en el entorno de usuario. • Pruebas Beta: realizadas por el usuario.

12. Tipos de pruebas (IV): de sistemas • Se prueba el sistema integrado en su entorno (HW & SW). • Consta de pruebas de: • interfaces externas • volumen • funcionamiento • recuperación • seguridad • resistencia • rendimiento/comportamiento • fiabilidad • documentación

13. Tipos de pruebas (y V): de aceptación • Último paso antes de la entrega formal del SW al cliente. • Se realiza normalmente en el entorno del usuario.

14. Actividades de Pruebas • Planear las pruebas. • Diseñar pruebas. • Implementar pruebas. • Realizar pruebas de integración. • Evaluar pruebas.

15. Actividad: Planear las pruebas • Objetivos: • Describir una estrategia de pruebas (p.e. cuantos casos de prueba serán automatizados, con qué técnicas, etc.) • Estimar los recursos precisos. • Planificar el esfuerzo. • Las entradas son los casos de uso, el modelo de diseño, etc.

16. Actividad: Diseñar pruebas (I) • Objetivos: • Identificar y describir los casos de prueba para cada build. • Identificar y estructurar los procedimientos de prueba especificando como realizar los casos de prueba. • Pruebas de integración: • Chequear que las interacciones reales entre objetos son las especificadas en las realizaciones de los casos de uso. • Pruebas de sistemas: • Probar casos de uso bajo diferentes condiciones (de hardware, de carga, de número de actores, con diferentes tamaños de base de datos) y combinaciones.

17. Actividad: Diseñar pruebas (y II) • Pruebas de regresión: • Algunos casos de prueba de previas builds podrán usarse en la actual para asegurar que las cosas que funcionaban en la build anterior lo siguen haciendo. • A veces los casos de prueba no podrán ser reutilizados directamente. • A la hora de diseñar procedimientos de prueba, deben tratar de reutilizarse lo más posible (por ejemplo especificando un único procedimiento para partes comunes de varios casos de uso).

18. Actividad: Implementar pruebas • Crear componentes de prueba que puedan automatizar los procesos de prueba (p.e generadores de carga).

19. Actividad: Realizar pruebas de integración • Si existe algún fallo en la batería de pruebas realizada, es necesario notificarlo a los ingenieros de componentes cuyos componentes no están funcionando, y a los ingenieros de pruebas para que puedan evaluar el resultado global de las pruebas.

20. Actividad: Evaluar pruebas • El objetivo es evaluar el esfuerzo de pruebas durante la iteración. • Básicamente se usan dos métricas: • Completitud de las pruebas: % de los casos de prueba que se han ejecutado y % del código que se ha probado. • Fiabilidad: se basa en analizar los defectos descubiertos y las tendencias que puedan extraerse de ellos (p.e una parte que falla demasiadas veces, o una tendencia general a que se produzcan situaciones anómalas bajo ciertas situaciones de carga).

21. Ejemplo

22. Bibliografía • Software Development on Internet Time. M. A. Cusumano, D. B. Yoffie. IEEE Computer, Oct. 1999. • Evaluating the Effectiveness of Independent Verification and Validation. J. D. Arthur, M. K. Gröner, K. J. Hayhurst, C. M. Holloway. IEEE Computer, Oct. 1999. • When to test less. T. Menzies, B. Cukic., IEEE Software, Sept-Oct. 2000 • Improvisation in small software organizations. T. Dyba. IEEE Software, Sept-Oct. 2000. • Knowledge-based software architectures: acquisition, specification and verification. J.J.P.Tsai, A.Liu, E.Juan, A. Sahay. IEEE Transactions on Knowledge and Data Engineering. Jan-Feb. 1999. • The Role of Independent Verification and Validation in Maintaining a Safety Critical Evolutionary Software in a Complex Environment: The NASA Space Shuttle Program. M. V. Zelkowitz, I. Rus. IEEE International Conference on Software Maintenance (ICSM ‘01). • Software Verification and Validation. An overview. D. R. Wallace, R. U. Fujii. IEEE Software, May 1989.