Prueba de Programas | aprender-libre.com

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. Si hablamos de programas que involucran vidas humanas (medicina, equipos nucleares, etc.) el costo de la fase de pruebas puede fácilmente superar el 80%.

Pese a su enorme impacto en el coste de desarrollo, es una fase que muchos programadores aún consideran clasificable como un arte y, por tanto, como difícilmente conceptualizable. Es muy difícil entrenar a los nuevos programadores que aprenderán mucho más de su experiencia que de lo que les cuenten en los cursos de programación.

¿Qué es probar?

Mientras que para un matemático probar es poco mas o menos demostrar la corrección de un programa, para un programador es básicamente convencerse de que el programa va bien, funciona correctamente, y tendrá éxito y aceptación cuando lo entregue a sus usuarios finales.

El IEEE se atreve con una definición:

Es el proceso de ejercitar o evaluar un sistema, manual o automáticamente, con el ánimo de verificar que satisface los requisitos especificados, o identificar discrepancias entre los resultados esperados y los que el programa devuelve.

La práctica nos convence, en cambio, de que hay que usar planteamientos más duros, del tipo:

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 lo que hay que hacerle a los programas.

La Prueba Exhaustiva es Imposible

La prueba ideal de un sistema sería ponerlo en todas las situaciones posibles, comprobar que se comporta bien en todas y cada una de ellas, y así estar seguros de 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.) cabe pensar que el número de pruebas posibles es finito. Esto deja de ser cierto en cuanto entran en juego bucles, en los que es fácil introducir condiciones para un funcionamiento sin fin. Aún en el irreal 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. Imagínese hacer esto con un compilador de cualquier lenguaje: ¡habría que escribir, compilar y ejecutar todos y cada uno de los programas que se pudieran escribir con dicho lenguaje!

Sobre esta premisa de imposibilidad de alcanzar la perfección, hay que buscar formas humanamente abordables y económicamente aceptables de conseguir un nivel de confianza alto en lo que estamos entregando al usuario. Nótese que todo es muy relativo y resbaladizo en este área.

Organización

Hay multitud de conceptos (y palabras clave) asociadas a las tareas de prueba.

Clasificarlas difícil, pues no son 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 decisiones
- de bucles
- CAJA NEGRA

Cobertura de requisitos
- INTEGRACIÓN
- ACEPTACIÓN

La prueba de unidades se plantea a pequeña escala, y consiste en ir probando 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 estática (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 unos pocos 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 de base.

El planteamiento descendente tiene la ventaja de estar pensado en términos de la funcionalidad global; pero también tiene el inconveniente de que para cada prueba hay que “inventarse” algo sencillo (pero fiable) que simule el papel de los módulos inferiores, que aún no están disponibles.

El planteamiento ascendente evita tener que escribirse módulos ficticios, pues vamos construyendo pirámides más y más altas con lo que vamos teniendo. Su desventaja es que se centra más en el desarrollo que en las expectativas finales del cliente.

Estas clasificaciones no son las únicas posibles. Por ejemplo, en sistemas con mucha interacción con el usuario es frecuente codificar sólo las partes de cada módulo que hacen falta para una cierta funcionalidad. Una vez probada, se añade otra funcionalidad y así hasta el final.

Esto da lugar a un planteamiento más “vertical” de las pruebas. A veces se conoce como “codificación incremental”.

Aunque hay casos para todos los gustos, parece que lo más habitual es un plan ascendente, por el ahorro de codificación que supone.

Por último, las pruebas de aceptación son las que se plantea el cliente final, que decide qué pruebas va a aplicarle al producto antes de darlo por bueno y pagarlo.