Modelos de prueba

Fundamentos de Ingeniería del Software

Capítulo 5. Prueba del software

“Bubbles don’t crash”
Bertrand Meyer

Prueba del software. Estructura
1. 2. 3. 4. 5. 6. Objetivos de la prueba Importancia de la prueba Principios de la prueba El proceso de prueba Métodos de diseño de casos de prueba Enfoque estructural Prueba del camino básico Notación de grafo de flujo Complejidad ciclomáticaDerivación de los casos de prueba Prueba de bucles Enfoque funcional Particiones o clases de equivalencia Análisis de Valores Límite (AVL) 8. 9. Prueba de interfaces gráficas de usuario Estrategias de prueba del software Relación entre productos de desarrollo y niveles de prueba Organización para la prueba del software Prueba de unidad Prueba de integración Integración incremental descendenteIntegración incremental ascendente Módulos críticos Prueba de aceptación

7.

Prueba del software. Bibliografía
(Piattini et al. 04) Capítulo 11 (Piattini et al. 96) Capítulo 12 (Pressman 06) Aptdo. 5.5.2, capítulos 13 y 14 (Pressman 02) Capítulos 17 y 18
(MAP 95) Ministerio de Administraciones Públicas. Guía de Técnicas de Métrica y Guía de Referencia. v.2.1. 1995

1. Objetivos de la pruebaObjetivos de las pruebas

⇒ ¿Labor destructiva y rutinaria?
(Myers 79)(Pressman 06):

1. La prueba es el proceso de ejecución de un programa con la intención de descubrir un error. 2. Un buen caso de prueba es aquel que tiene una alta probabilidad de descubrir un error no encontrado hasta entonces. 3. Una prueba tiene éxito si descubre un error no detectado hasta entonces. Actividad de V&V(Validación y Verificación) Implica la ejecución del código En otras actividades de V&V el código no se ejecuta:
revisiones (como walkthroughs) y pruebas formales

Objetivos de la prueba (II)
No sólo se prueba el código: tb. documentación y ayuda. La prueba no puede asegurar la ausencia de defectos: sólo puede demostrar que existen defectos en el software.

Índice de la fiabilidad delsoftware:
⇒ se comporta de acuerdo a las especificaciones funcionales y no funcionales.

2. Importancia de la prueba
No es una actividad secundaria:
Típicamente 30-40% del esfuerzo de desarrollo En aplicaciones críticas (p.ej. control de vuelo, reactores nucleares), ¡de 3 a 5 veces más que el resto de pasos juntos de la ingeniería del software! El coste aproximado de los errores del software (bugs)para la economía americana es el equivalente al 0,6% de su PIB, unos 60.000 millones de dólares (NIST, National Institute of Standards and Technology, 2002)
⇒ más de 1/3 podría evitarse si la prueba se efectuara mejor

3. Principios de la prueba
(Davis 95, Myers 79) (Pressman 06)
No son posibles las pruebas exhaustivas. Las pruebas deberían planificarse antes de que empiecen. No debenrealizarse planes de prueba suponiendo que prácticamente no hay defectos en los programas y, por tanto, dedicando pocos recursos a las pruebas. Se deben evitar los casos de prueba no documentados ni diseñados con cuidado. A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos de los clientes (trazabilidad). El principio de Pareto es aplicable a la prueba del software (“dondehay un defecto, hay otros”). Las pruebas deberían empezar por “lo pequeño” y progresar hacia “lo grande”. Para ser más efectivas, las pruebas deberían ser conducidas por un equipo independiente.

4. El proceso de prueba
Planear pruebas
Información sobre el proyecto Plan de pruebas

Diseñar pruebas

Configuración de pruebas (casos y procedimientos)

Ejecutar pruebas
ResultadosInformación sobre el software (ERS, diseño, etc.)

Configuración del software revisada Resultados esperados

DESARROLLO Depuración
Acciones preventivas (formación, mejora de procesos, etc.) Errores: histórico e informes de pruebas

Evaluar pruebas

Estadísticas de errores

(Piattini et al. 04)

Predicción de fiabilidad

Análisis de errores

5. Métodos de diseño de casos de prueba...