Fundamentos de las pruebas de Software

 

Prueba de aplicaciones Convencionales

Las pruebas requieren que el desarrollador deseche nociones preconcebidas sobre lo “correcto” del software recién desarrollado y luego trabajen duro para diseñar casos de prueba a fin de “romper” el software.

Técnicas para el diseño de casos de prueba de software para aplicaciones convencionales. Este diseño se enfoca en un conjunto de técnicas para la creación de casos de prueba que satisfacen los objetivos de prueba globales y las estrategias de pruebas.

Fundamentos de las pruebas del software

La meta de probar es encontrar errores, y una buena prueba es aquella que tiene una alta probabilidad de encontrar uno. Por tanto, un sistema basado en computadora o un producto debe diseñarse e implementarse teniendo en mente la “comprobabilidad”. Al mismo tiempo, las pruebas en sí mismas deben mostrar un conjunto de características que logren la meta de encontrar la mayor cantidad de errores con el mínimo esfuerzo.

Comprobabilidad - definición de comprobabilidad: “La comprobabilidad del software significa simplemente saber con cuánta facilidad puede probarse [un programa de cómputo].” Las siguientes características conducen a software comprobable:

·         Operatividad. “Mientras mejor funcione, más eficientemente puede probarse.” Si un sistema se diseña e implementa teniendo como objetivo la calidad, relativamente pocos errores bloquearán la ejecución de las pruebas, lo que permitirá avanzar en ellas sin interrupciones.

·         Observabilidad. “Lo que ve es lo que prueba.” Las entradas proporcionadas como parte de las pruebas producen distintas salidas. Los estados del sistema y las variables son visibles o consultables durante la ejecución. La salida incorrecta se identifica con facilidad. Los errores internos se detectan y se reportan de manera automática. El código fuente es accesible.

·         Controlabilidad. “Mientras mejor pueda controlar el software, más podrá automatizar y optimizar las pruebas.” Todas las salidas posibles pueden generarse a través de alguna combinación de entradas, y los formatos de entrada/salida (E/S) son consistentes y estructurados. Todo código es ejecutable a través de alguna combinación de entradas. El ingeniero de pruebas puede controlar directamente los estados del software, del hardware y las variables. Las pruebas pueden especificarse, automatizarse y reproducirse convenientemente.

·         Descomponibilidad. “Al controlar el ámbito de las pruebas, es posible aislar más rápida mente los problemas y realizar pruebas nuevas y más inteligentes.” El sistema de software se construye a partir de módulos independientes que pueden probarse de manera independiente.

·         Simplicidad. “Mientras haya menos que probar, más rápidamente se le puede probar.” El programa debe mostrar:

o   simplicidad funcional (por ejemplo, el conjunto característico es el mínimo necesario para satisfacer los requerimientos).

o   simplicidad estructural (la arquitectura es modular para limitar la propagación de fallos).

o   simplicidad de código (se adopta un estándar de codificación para facilitar la inspección y el mantenimiento).

·         Estabilidad. “Mientras menos cambios, menos perturbaciones para probar.” Los cambios al software son raros, se controlan cuando ocurren y no invalidan las pruebas existentes. El software se recupera bien de los fallos.

·         Comprensibilidad. “Mientras más información se tenga, se probará con más inteligencia.” El diseño arquitectónico y las dependencias entre componentes internos, externos y compartidos son bien comprendidos. La documentación técnica es accesible al instante, está bien organizada, es específica, detallada y precisa. Los cambios al diseño son comunicados a los examinadores.

Características de la prueba

Una buena prueba tiene una alta probabilidad de encontrar un error. Para lograr esta meta, el examinador debe comprender el software e intentar desarrollar una imagen mental de cómo puede fallar. De manera ideal, se prueban las clases de fallas.

Una buena prueba no es redundante. El tiempo y los recursos de la prueba son limitados. No se trata de realizar una prueba que tenga el mismo propósito que otra. Cada una debe tener un propósito diferente (incluso si es sutilmente diferente).

Una buena prueba debe ser “la mejor de la camada”. En un grupo de pruebas que tengan una intención similar, las limitaciones de tiempo y recursos pueden mitigar la ejecución de sólo un subconjunto de dichas pruebas. En tales casos, debe usarse la prueba que tenga la mayor probabilidad de descubrir toda una clase de errores.

Una buena prueba no debe ser demasiado simple o compleja. Aunque en ocasiones es posible combinar una serie de pruebas en un caso de prueba, los efectos colaterales posibles asociados con este enfoque pueden enmascarar errores. En general, cada prueba debe ejecutarse por separado.