|
Métodos de Prueba de Programas Por J. F. Díaz (jfdiaz98@hotmail.com) Lic. en Ciencias de la Computación La calidad de los datos de prueba es más importante que la cantidad. Regla de Programación Las pruebas son de gran importancia en la garantía del software. En la Fase de Prueba de los programas, muchas corridas de muestra que hacen los mismos cálculos en casos idénticos no brindan una prueba más eficaz que una sola corrida. Es posible que queden otros casos que nunca fueron probados antes, aún tras numerosas corridas de prueba. En programas pequeños la verificación de todas sus posibles alternativas del flujo de control es relativamente fácil, pero en programas mayores o de gran complejidad es imposible efectuar pruebas exhaustivas. Sin embargo, una selección cuidadosa de los datos de prueba puede darnos mucha confianza en el desempeño que tengan esos programas. Esto, aunado a un determinado mecanismo de comprobación de errores, puede producir software más confiable. Los objetivos principales de la realización de una prueba son:
Los Métodos de Prueba de Software tienen el objetivo de diseñar pruebas que descubran diferentes tipos de errores con menor tiempo y esfuerzo. A continuación se presentan los Mecanismos de Prueba de Software más conocidos. Método de la Caja Negra A la mayor parte de los usuarios de programas extensos no les interesa los detalles de su funcionamiento; lo único que desean es conseguir respuestas. Es decir, desean tratar el programa como una caja negra a la cual le introducen datos de entrada y obtienen de ella los datos de salida que esperan. De ahí el nombre de este método. De manera análoga, los datos de prueba se escogerán atendiendo a las especificaciones del problema, sin importar los detalles internos del programa, a fin de verificar que éste corra bien. A continuación se citan los criterios mínimos que deben guiarnos al escoger los datos de prueba de nuestros programas:
Método de la Caja de Cristal (o Caja Blanca) El segundo enfoque en la selección de los datos de prueba inicia con la observación de que un programa difícilmente puede considerarse como probado por completo si su código contiene partes que nunca han sido ejecutadas. En el Método de la Caja de Cristal, se analiza la estructura lógica del programa y, para cada alternativa que pueda presentarse, los datos de prueba ideados conducirán a ella. Así pues, se procura escoger los que verifiquen cada posibilidad en las estructuras de selección múltiple, las cláusulas de cada proposición if, cada alternativa de cada instrucción case (switch) y la condición de terminación de cada ciclo. En el caso de un programa extenso, este método es sin duda impráctico, pero en un módulo pequeño constituye un excelente medio de pruebas y depuración. En un programa bien diseñado, cada módulo incluirá unos pocos ciclos y opciones. De ahí que basten algunos casos de prueba bien seleccionados para probar cada módulo por separado. En una prueba que se vale del Método de la Caja de Cristal, se tornan patentes las ventajas de un diseño de programa modular. Examinemos un ejemplo típico de un proyecto que engloba 50 subprogramas, cada uno de los cuales incluye 5 casos o alternativas diferentes. Si quisiésemos probar todo el programa como uno, necesitaríamos 550 casos de prueba. Pero si escogemos casos de prueba para probar cada módulo por separado, eso nos da un total de 5x50=250 casos de prueba. De ahí que un problema de tamaño imposible haya sido reducido a otro que, en un programa grande, es un tamaño bastante modesto. Antes de concluir que la prueba con el Método de la Caja de Cristal siempre es el más adecuado, conviene señalar que en la práctica suele ser más eficaz para descubrir errores. Quizá ello se debe, entre otras cosas, a que los errores más sutiles a menudo ocurren no dentro de un subprograma, sino en la interfaz de los subprogramas, al no entenderse bien las condiciones y normas precisas del intercambio de información entre los subprogramas. Por tanto, un buen criterio de prueba para proyectos extensos consiste en aplicar el Método de la Caja de Cristal a cada módulo pequeño conforme se escriba; luego se usan esos datos empleados en esas pruebas en la verificación de las secciones más amplias del programa una vez terminadas. Método de la Caja de Pandora Este método constituye un enfoque que lamentablemente se usa mucho, incluso en el mundo del software comercial. Consiste en abstenerse de realizar pruebas luego de depurar bastante bien un proyecto; se deja al usuario que lo ensaye y acepte. Sobra decir que el resultado es una bomba de tiempo que casi siempre explota en la cara de los usuarios.- Ir al inicio de este artículo | Versión imprimible |
Lecturas Relacionadas Técnicas de Prueba de Programas La Importancia de la Prueba del Software Tres Preguntas Acerca de Cada Error Que Encuentres Escribimos software pésimo... ¡y con bugs! Las Fases de la Programación 
|
