Plan de pruebas

1. Introducción
Una de las últimas fases del ciclo de vida antes de entregar un programa para su explotación, es la fase de pruebas.
Una de las sorpresas con las que suelen encontrar los nuevos programadores es la enorme cantidad de tiempo y esfuerzo que requiere esta fase. Se estima que la mitad del esfuerzo de desarrollo de un programa (tanto en tiempo como en gastos) se va en esta fase. Sihablamos de programas que involucran vidas humanas (medicina, equipos nucleares, etc) el costo de la fase de pruebas puede fácilmente superar el 80%.
1.1. ¿Qué es probar?
Como parte que es de un proceso industrial, la fase de pruebas añade valor al producto que se maneja: todos los programas tienen errores y la fase de pruebas los descubre; ese es el valor que añade. El objetivo específico dela fase de pruebas es encontrar cuantos más errores, mejor.
Probar un programa es ejercitarlo con la peor intención a fin de encontrarle fallos.
Por poner un ejemplo duro, probar un programa es equivalente a la actividad de ciertos profesores para los que examinar a un alumno consiste en poner en evidencia todo lo que no sabe. Esto es penoso cuando se aplica a personas; pero es exactamente loque hay que hacerle a los programas.
1.2. La Prueba Exhaustiva es Imposible
La prueba ideal de un sistema sería exponerlo en todas las situaciones posibles, así encontraríamos hasta el último fallo. Indirectamente, garantizamos su respuesta ante cualquier caso que se le presente en la ejecución real.
Esto es imposible desde todos los puntos de vista: humano, económico e incluso matemático.Dado que todo es finito en programación (el número de líneas de código, el número de variables, el número de valores en un tipo, etc etc) cabe pensar que el número de pruebas posibles es finito. Esto deja de ser cierto en cuanto entran en juego ciclos, en los que es fácil introducir condiciones para un funcionamiento sin fin. Aún en el irrealista caso de que el número de posibilidades fuera finito,el número de combinaciones posibles es tan enorme que se hace imposible su identificación y ejecución a todos los efectos prácticos.
Probar un programa es someterle a todas las posible variaciones de los datos de entrada, tanto si son válidos como si no lo son.
1.3. Organización
Hay multitud de conceptos (y palabras clave) asociadas a las tareas de prueba. Clasificarlas es difícil, pues noson mutuamente disjuntas, sino muy entrelazadas. En lo que sigue intentaremos la siguiente estructura para la presentación:

Fases de prueba:
UNIDADES
Planteamientos:
CAJA BLANCA
Cobertura:
de segmentos
de ramas
de condición/decisión
de bucles
CAJA NEGRA
Cobertura de requisitos
INTEGRACIÓN
ACEPTACIÓN
La prueba de unidades se plantea a pequeña escala, y consiste en irprobando uno a uno los diferentes módulos que constituyen una aplicación.
Las pruebas de integración y de aceptación son pruebas a mayor escala, que puede llegar a dimensiones industriales cuando el número de módulos es muy elevado, o la funcionalidad que se espera del programa es muy compleja.
Las pruebas de integración se centran en probar la coherencia semántica entre los diferentes módulos,tanto de semántica estática (se importan los módulos adecuados; se llama correctamente a los procedimientos proporcionados por cada módulo), como de semántica dinámica (un módulo recibe de otro lo que esperaba). Normalmente estas pruebas se van realizando por etapas, englobando progresivamente más y más módulos en cada prueba.
Las pruebas de integración se pueden empezar en cuanto tenemos unospocos módulos, aunque no terminarán hasta disponer de la totalidad. En un diseño descendente (top-down) se empieza a probar por los módulos más generales; mientras que en un diseño ascendente se empieza a probar por los módulos de base.
El planteamiento descendente tiene la ventaja de estar siempre pensando en términos de la funcionalidad global; pero también tiene el inconveniente de que para...