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

10.- Flujo de Pruebas10.- Flujo de PruebasJusto N. Hidalgo SanzJusto N. Hidalgo Sanz

DEPARTAMENTO DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA INFORMÁTICAINFORMÁTICA

Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)

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 Verificació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.

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

Documents

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