LA PRUEBA DEL SOFTWARE

1. LA PRUEBA DEL SOFTWARE Objetivo: Descubrir errores en el software Es necesario crear buenos casos de prueba (aquél que tiene una alta probabilidad de mostrar errores aún no descubiertos) Una prueba tiene éxito si descubre un error no detectado hasta entonces.

2. Principios de la prueba • A todas las pruebas se les debería hacer un seguimiento hasta los requisitos del cliente. • Las pruebas deberían planificarse mucho antes de que empiecen. • El principio de Pareto es aplicable a la prueba de software. (El 80% de los errores descubiertos con las pruebas surgen de hacerle seguimiento sólo al 20% de todos los módulos del programa). El problema es aislar esos módulos sospechosos y probarlos concienzudamente.

3. Principios de la prueba • Las pruebas empiezan por lo pequeño y progresan hasta lo grande. • No son posibles las pruebas exhaustivas. • Para ser más efectivas, las pruebas deberían ser conducidas por un equipo independiente.

4. Enfoques de Prueba PRODUCTO puede probarse 1. PRUEBAS DE CAJA NEGRA Conociendo la función para la que fue diseñado, se hacen pruebas que demuestren que cada función es operativa y al mismo tiempo se buscan errorres en cada una. Pruebas sobre la interfaz del software 2. PRUEBAS DE CAJA BLANCA Conociendo el funcionamiento del producto, se desarrollan pruebas que aseguren “que todas las piezas encajan”, que la operación interna se ajusta a las especificaciones y que todos los componentes internos se han comprobado adecuadamente. Examen minucioso de detalles procedimentales

5. Pruebas de Caja Blanca Casos de prueba que: • Garanticen que se ejercitan por lo menos una vez TODOS los caminos, independientemente de cada módulo. • Ejerciten todas las decisiones lógicas por sus vertientes Cierto y Falso. • Ejecuten todos los ciclos en sus límites y límites operacionales. • Ejerciten las estructuras internas de datos para asegurar su validez.

6. Pruebas de Caja Negra Permiten obtener conjuntos de condiciones de entrada que ejecuten todos los requisitos funcionales de un programa. Las pruebas de caja negra NO son una alternativa a las técnicas de prueba de caja blanca. Es un enfoque complementario. Las pruebas de caja negra intentan hallar errores tales como:

7. Pruebas de Caja Negra • Funciones incorrectas o ausentes. • Errores de interfaz. • Errores en estructuras de datos o en accesos a BD externas. • Errores de rendimiento. • Errores de inicialización y de terminación.

8. Otras Pruebas • Pruebas de GUI (Interfaces Gráficas de Usuario). • Pruebas de Arquitectura Cliente/Servidor. • Pruebas de Documentación y Ayudas.

9. Tipo de Pruebas Pruebas Unitarias • Hacen uso intensivo de técnicas de prueba de caja blanca. • Se prueba la interfaz del módulo (Primero que todo, si no funciona, NO seguir. Verificar que la información llega y sale de manera correcta). • Estructuras de datos locales (datos se conservan íntegros durante la ejecución).

10. Tipo de Pruebas Pruebas Unitarias • Condiciones límites. (Caminos de control para asegurar que se ejecutan al menos una vez; luego se prueban todos los caminos de manejo de errores). • Validez Funcional.

11. Tipo de Pruebas Pruebas de integración • Usa fundamentalmente técnicas de caja negra. • Algunas veces usa técnicas de prueba de caja blanca para asegurar que se cubren los principales caminos de control.

12. Tipo de Pruebas Pruebas de Alto Nivel Sirven para comprobar si se cumplen los criterios de validación. Prueba de Validación Se usa para verificar si se cumplen todos los requerimientos funcionales, de comportamiento y de rendimiento.

13. Tipo de Pruebas Prueba del Sistema Operando en condiciones reales. • Pruebas de recuperación • Pruebas de seguridad • Pruebas de resistencia (pruebas en situaciones anormales) • Pruebas de rendimiento

14. Especificación de la Prueba • Ámbito de la Prueba. (Características, funcionamiento, rendimiento y diseño interno que se van a probar). Se delimita el esfuerzo de la prueba, se describen los criterios de terminación de cada fase de prueba. • Plan de Prueba Describe la estrategia general para la integración. Se divide en fases y construcciones que tratan características funcionales y de comportamiento del software.

15. Especificación de la Prueba • Procedimiento de Prueba • Orden de integración (propósito y módulos a probar). • Pruebas Unitarias (descripción prueba módulo n). • Entorno de la prueba (herramientas o técnicas específicas). • Datos de los casos de prueba. • Resultados esperados.

16. Especificación de la Prueba • Resultados de prueba obtenidos. • Referencias. • Apéndices.

17. Pruebas Alfa y Beta Para descubrir errores que pareciera que sólo el usuario puede descubrir. • Prueba Alfa Se hace en el lugar de desarrollo y con un cliente que la realiza. El desarrollador es un observador del usuario y registra errores y problemas de uso. • Pruebas Beta La hacen los usuario finales. Se hacen después de haber acogido las pruebas del sistema y las pruebas alfa.