Tecnicas De Construccion De Pruebas

INTRODUCCIÓN

Podemos decir que las pruebas presentan una interesante anomalía para el ingeniero del software. Durante las fases anteriores de definición y de desarrollo, el ingeniero intenta construir el software partiendo de un concepto abstracto y llegando a una implementación tangible. A continuación, llegan las pruebas. El ingeniero crea una serie de casos de prueba que intentan «demoler»el software construido. De hecho, las pruebas son uno de los pasos de la ingeniería del software que se puede ver (por lo menos, psicológicamente) como destructivo en lugar de constructivo.
Los ingenieros del software son, por naturaleza, personas constructivas. Las pruebas requieren que se descarten ideas preconcebidas sobre la «corrección» del software que se acaba de desarrollar y se superecualquier conflicto de intereses que aparezcan cuando se descubran errores.










1. Técnicas de construcción de pruebas orientadas al control de flujo de datos.
Las pruebas del software son un elemento crítico para la garantía de calidad del software y representa una revisión final de las especificaciones, del diseño y de la codificación. La creciente percepción delsoftware como un elemento del sistema y la importancia de los costos asociados a un fallo del propio sistema, están motivando la creación de pruebas minuciosas y bien planificadas
Prueba:
Proceso de ejecutar software con el propósito de probar su funcionalidad y exactitud; se realiza para detectar defectos o estimar la confiabilidad.
Las pruebas deben planificarse mucho antes de que empiecen. Laplanificación de las pruebas puede empezar tan pronto como esté completo el modelo de requisitos. La definición detallada de los casos de prueba puede empezar tan pronto como el modelo de diseño se ha consolidado. Por tanto, se pueden planificar y diseñar todas las pruebas antes de generar ningún código.
El principio de Pareto es aplicable a la prueba del software. Dicho de manera sencilla, elprincipio de Pareto implica que al 80 por 100 de todos los errores descubiertos durante las pruebas se les puede hacer un seguimiento hasta un 20 por 100 de todos los módulos del programa. El problema, por supuesto, es aislar estos módulos sospechosos y probarlos concienzudamente. Las pruebas deberían empezar por lo pequeño y progresar hacia lo grande. Las primeras pruebas planeadas y ejecutadas secentran generalmente en módulos individuales del programa. A medida que avanzan las pruebas, desplazan su punto de mira en un intento de encontrar errores en grupos integrados de módulos y finalmente en el sistema entero.
No son posibles las pruebas exhaustivas. El número de permutaciones de caminos para incluso un programa de tamaño moderado es excepcionalmente grande. Por este motivo, esimposible ejecutar todas las combinaciones de caminos durante las pruebas. Es posible, sin embargo, cubrir adecuadamente la lógica del programa y asegurarse de que se han aplicado todas las condiciones en el diseño a nivel de componente.

Para ser más eficaces, las pruebas deberían ser realizadas por un equipo independiente.
Existen dos tipos diferentes de prueba, que se utilizan en las diferentes etapasde desarrollo del software:
A. Las pruebas de defectos:
Pretenden encontrar las inconsistencias entre un programa y su especificación. Estas inconsistencias se deben habitualmente a los fallos o defectos en el código del programa. Las pruebas se diseñan para revelar la presencia de defectos en el sistema, más que para evaluar su capacidad operacional.

B. Las pruebas estadísticas:
Seutilizan para probar el desempeño y la fiabilidad del programa y comprobar como trabaja bajo condiciones operacionales. Las pruebas se diseñan para reflejar las entradas de los usuarios y su frecuencia. Después de llevar a cabo las pruebas, se puede hacer una estimación de la fiabilidad operacional del sistema contando el número de caídas observadas en el sistema. La capacidad del programa se valora...