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

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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).

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

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.

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).

Ejemplo

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.