Estrategias de prueba
 |
La estrategia de prueba tiene que especificar lo siguiente:
- la planificación de la prueba,
- el diseño de casos de prueba,
- la ejecución de pruebas,
- la evaluación de los resultados.
Como norma común, las pruebas suelen iniciarse en los niveles más básicos, los módulos, y se va ascendiendo a partir de ahí. En cada etapa se comprueba que la integración de los elementos sea correcta. Al hacerlo paso a paso, la localización de los errores es más fácil.
Si el proyecto es de grandes dimensiones, en este proceso intervienen tanto el encargado del desarrollo como un grupo independiente de pruebas.
Además de asegurar que el producto cumple correctamente las funciones que el cliente ha solicitado, hay que comprobar que los requisitos establecidos son los adecuados.
Los pasos que suelen darse en el proceso de prueba son los siguientes:
- Prueba de las funciones y los módulos: se utilizan pruebas de la caja blanca. Los casos de prueba examinarán la interfaz del módulo, las estructuras de datos locales, las condiciones límite, los caminos independientes y los caminos de manejo de errores.
- Pruebas de integración: se utilizan pruebas de la caja blanca y de la caja negra. Se comprueba que, aunque cada módulo funcione bien con otros, no distorsione ninguna función.
- La integración descendente empieza las pruebas desde el módulo de control principal, de los niveles más altos a los más básicos. En cada etapa se sustituyen los módulos de los niveles inferiores por resguardos, objetos con la misma interfaz del módulo que sustituyen pero mucho más simples.
- La integración ascendente sigue el camino contrario, desde los niveles más básicos hasta el nivel total del sistema. Las pruebas ascendentes son más sencillas porque no necesitan resguardos, sólo hay que diseñar conductores que generen entradas y salidas apropiadas para los casos de prueba. Sin embargo, hasta los últimos pasos, en los que se integran los módulos principales de control, no estaremos seguros de la corrección del diseño.
- Pruebas de validación: se utilizan pruebas de la caja negra para comprobar que las especificaciones de los requisitos del software se cumplen. También se comprueba que todas las fases están documentadas de manera correcta y que los elementos del sistema se han catalogado para permitir un mantenimiento sin problemas.
- Pruebas de aceptación: las lleva a cabo el usuario final, así que él mismo validará los requisitos. Existen dos tipos de pruebas de aceptación, que mencionamos a continuación:
Hay dos estrategias diferentes para llevar a cabo estas pruebas:
La ventaja de este método es que se descubren errores de diseño en etapas muy tempranas del proyecto y se pueden probar muy pronto las principales funciones de control.
Los inconvenientes más destacables residen en la dificultad para crear resguardos que simulen la actuación de los módulos y en la necesidad de crear, en muchos casos, situaciones artificiales que obliguen a los niveles superiores a mostrar resultados.
- Prueba alfa: el cliente prueba el software en el lugar donde se ha desarrollado y, por lo tanto, en un entorno controlado. El encargado del desarrollo toma nota de los problemas que surgen o pueden surgir y los corrige.
- Prueba beta: el cliente prueba el software en el lugar donde será utilizado. Los errores que encuentra se los comunica a la organización encargada del desarrollo, que los corregirá.
- Prueba del sistema: para finalizar, el software se integra en el resto del sistema (que podrá estar compuesto por hardware, usuarios, etc.). En estas pruebas participan los responsables del desarrollo de cada elemento del sistema.
- Pruebas de recuperación: tratan de evaluar si la recuperación en caso de fallo es apropiada, es decir, si la reinicialización, los mecanismos de recuperación del estado del sistema, la recuperación de datos y del rearranque son adecuados y, en caso de que la recuperación se efectúe de manera manual, el tiempo que este proceso conlleva.
- Pruebas de seguridad: tratan de asegurar que el sistema se encuentre protegido contra robos de claves de acceso, ataques con software, bloqueos del sistema, errores provocados por asaltos al sistema, etc.
- Pruebas de resistencia: intentan garantizar que el sistema tiene unos límites correctos de aguante, cuando se utilizan recursos en cantidad, frecuencia o volumen anormales.
- Pruebas de rendimiento: se relizan desde que empieza la implementación de las primeras funciones del software.
Las principales comprobaciones del sistema que se llevan a cabo son las siguientes:
