Estrategias de prueba de software desde la perspectiva de un enfoque estratégico
1.
2.
3. Quien prueba el Software? Desarrollador Pruebas independientes Entiende el sistema pero probará “suavemente” y está guiado por la “entrega” Debe aprender acerca del sistema, pero intentará romperlo y está guiado por la calidad Si el Ing.Sw. no encuentra los errores ¡ El cliente si lo hará !...
4.
5. Estrategia de Pruebas Pruebas de Unidad Pruebas de Integración Pruebas de Validación Pruebas de Sistema Codigo Diseño Ing.de Sistema Requisitos
6. Estrategia de Prueba de Sw Orientadas a Objetos CLASE 1 Atributos Operaciones … Por último se prueba el sistema como un todo para asegurarse de que se descubran errores en los requisitos ...… Atributos Operaciones CLASE 2 Atributos Operaciones CLASE 3 + Pruebas … Pruebas de Regresión
7. Criterios para Completar la Prueba … Cada vez que el cliente o el usuario ejecutan el programa de computadora, este se esta probando. Cuando terminamos las pruebas ? “… Nunca se termina de aplicar una prueba”
8. Pruebas de Unidad Módulo a ser probado Casos de Prueba Resultados Ingeniero de Software
9. Pruebas de Unidad Interfase (flujo de informacion hacia adentro/afuera del programa) Estructuras locales de datos (datos locales mantíenen integridad durante la ejecucion del programa) Condiciones de límites (modulo opera ok en los limites establecidos p/restrigir procesamiento) Caminos independientes (asegurar que todos los caminos se ejecutan por lo menos una vez) Caminos de manejo de errores (los errores probables tienen buen tratamiento y finalizacion adecuada) Casos de prueba Módulo a ser probado
10.
11.
12. Ambiente de Pruebas de Unidad Módulo Resguardo Controlador Resultados Casos de Prueba Interfase Estructuras locales de datos Condiciones de límites Caminos independientes Caminos de manejo de errores Resguardo
13.
14.
15.
16. Integración de Arriba-Abajo El módulo mas alto es probado con resguardos A B C D E F G Los resguardos son reemplazados uno a la vez, “primero en profundidad” o “primero en anchura” A medida que nuevos módulos se integran, algunos sub-grupos de pruebas se realizan nuevamente
17. Integración de Abajo-Arriba A B C D E F G Grupo Los controladores son reemplazados una a la vez, “el mas profundo primero” Los módulos de trabajo están integrados y agrupados
18. Pruebas de Sandwich A B C D E F G Los módulos más altos son probados con resguardos Los módulos de trabajo están integrados y agrupados Grupo
19.
20.
21.
22. Pruebas de Alto Orden Prueba de Validación Prueba Alfa y Beta Pruebas de Sistema Otras pruebas especializadas
23.
24.
25.
26. Depuración: un proceso de diagnóstico Cuando un caso de prueba descubre un error, la depuración es la acción que lo elimina!!
27. El proceso de depuración Casos de prueba Resultados Depuración Sospechas de Causas Causas Identificadas Correcciones Pruebas de Regresión Pruebas Adicionales Ejecución de Casos
28. Esfuerzo de Depuración Tiempo requerido para diagnosticar el síntoma y determinar la causa Tiempo requerido para corregir el error y conducir pruebas de regresión
29. Síntomas y Causas Síntoma y causa pueden estar separados geográficamente El síntoma puede desaparecer cuando se arregla otro problema El sintoma podria deberse a un error humano dificil de localizar La causa puede deberse a un error de sistema o de compilador La causa puede deberse a supuestos que todos creen El síntoma puede ser intermitente Síntoma Causa
30. Consecuencias de los Errores Daño suave leve disturbios serio extremo catastrófico infeccioso Tipo de Bug Categorías de errores: errores de función, errores de sistema, errores de datos, errores de código, errores de diseño, de documentación, violaciones estándar, etc.
31. Técnicas de Depuración Fuerza bruta / pruebas Volver atrás Eliminación de Causa - Inducción o Deducción