Presentaci

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.