PRUEBAS DE CAJA BLANCA

Mientras que las pruebas de caja negra suponen que no se sabe nada acerca del programa, las pruebas de caja blanca asumen que usted sabe todo acerca del programa. En este caso, el programa es como una casa de vidrio en la cual todo es visible.
Las pruebas de caja blanca son responsabilidad del programado4, quien sabe exactamente que sucede dentro del programa. Usted debe asegurare de que todas las instrucciones posibles y todas las situaciones posibles se hayan probado. ! Y esta no es una tarea simple!
La experiencia ayudara al programador a diseñar un buen plan de pruebas, pero algo que puede hacer desde el principio es adquirir el habito de escribir planes de prueba. Comenzara su plan de pruebas cuando este en la etapa de diseño. A medida que construya su diagrama de estructura, se preguntara a si mismo que situaciones necesita probar, especialmente las inusuales, y las anotara de inmediato, pues puede suceder que no las recuerde una hora mas tarde.
Cuando el programador escribe sus diagramas de flujo o pseudocódigo, debe revisarlos poniendo atención a los casos de prueba y tomar nota de los casos que necesita.
Al llegar el momento de construir sus casos de prueba, debe revisar sus notas y organizarlas en conjuntos lógicos. Excepto por programas tipo estudiante muy simples, un conjunto de datos de prueba no validara completamente un programa. Para proyectos de desarrollo a gran escala, tal vez sea necesario ejecutar 20, 30 o más casos de prueba. De nuevo, los anotara e incorporará a su plan de pruebas. Después de que se ha terminado el programa y este esta en producción, el programador necesitara nuevamente los planes de prueba cuando modifique el programa.

La prueba de la caja blanca es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para deribar los casos de prueba. Mediante los métodos de prueba de la caja blanca el ingeniero del software puede derivar casos de prueba que:

• Garanticen que se ejercitan al menos una vez todos los caminos independientes de cada módulo
• Se ejercitan todas las decisiones lógicas en sus caras verdaderas y falsas
• Se ejecutan todos los bucles en sus límites y con sus límites operacionales
• Se ejercitan las estructuras de datos internas para asegurar su validez.

En estas encrucijadas se puede exponer una pregunta razonable: ”¿Por qué gastar tiempo y energía probando y preocupándose de las minuciosidades lógicas cuando podríamos gastar mejor el esfuerzo asegurando que se han alcanzado los requerimientos del programa?”. La respuesta se encuentra en la naturaleza misma de los defectos del software.

• Los errores lógicos y las suposiciones incorrectas son inversamente proporcionales a la probabilidad de que se ejecute un camino del programa. Los errores tienden a producirse en nuestro trabajo cuando diseñamos o implementamos funciones, condiciones o controles que se encuentran fuera de los normal. El procedimiento habitual tiende a hacer más comprensible, mientras que el procesamiento de “casos especiales” tiende a caer en el caos.




• A menudo creemos que un camino lógico tiene pocas posibilidades de ejecutarse cuando, de hecho, se puede ejecutar de forma regular. El flujo lógico de un programa a veces no es nada intuitivo, lo que significa que nuestras suposiciones intuitivas sobre el flujo de control y los datos nos pueden llevar a tener errores de diseño que solo se descubren cuando comienza la prueba del camino.




• Los errores tipográficos son aleatorios. Cuando se traduce un programa a código fuente de un lenguaje de programación, es muy probable que se den algunos errores de escritura. Muchos serán descubiertos por los mecanismos de comprobación de sintaxis, pero otros permanecerán indetectados hasta que comience la prueba. Es igual de probable que haya un error tipográfico en un oscuro camino lógico que en un camino principal.

Cada una de estas razones nos da un argumento para llevar a cabo las pruebas de caja blanca. La prueba de caja negra, sin tener en cuenta como sea de completa, puede pasarse los tipos de errores que acabamos de señalar. Como estableció Beizer: “Los errores se esconden en los rincones y se aglomeran en los límites”. Es mucho más fácil de descubrirlos con la prueba de caja blanca.

Pruebas del Camino Básico.
La prueba del camino básico es una técnica de prueba de la caja blanca propuesta inicialmente por Tom McCabe. El método del camino básico permite al diseñador de casos de prueba derivar una medida de complejidad lógica de un diseño procedural y usar esa medida como guía para la definición de un conjunto básico de caminos de ejecución. Los casos de prueba derivados del conjunto básico garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa.

Notación de grafo de flujo
Antes de considerar el método del camino básico se debe introducir una sencilla notación para la representación del flujo de control, denominada grafo de flujo. El grafo de flujo representa el flujo de control lógico mediante la notación ilustrada en la figura 2.1. Cada construcción estructurada tiene un correspondiente símbolo en el grafo de flujo.

Para ilustrar el uso de un grafo de flujo, consideremos la representación del diseño procedural de la figura 2.2.

Fig 2.2

Aquí, se usa un diagrama de flujo para representar la estructura de control de un programa.
Cuando en un diseño procedural se encuentran condiciones compuestas, la generación del grafo de flujo se hace un poco mas complicada. Una condición compuesta se da cuando aparecen uno o mas operadores booleanos (OR, AND, NAND, NOR lógicos) en una sentencia condicional.

Prueba de Bucles
Los bucles son la piedra angular de la mayoría de los algoritmos implementados en software. Y por ello debemos prestarle normalmente un poco de atención cuando llevamos a cabo la prueba del software.
La prueba de bucles es una técnica de prueba de caja blanca que se centra exclusivamente en la validez de las construcciones de bucles. Se pueden definir cuatro clases diferentes de bucles: Bucles simples, Bucles concatenados, Bucles Anidados, y bucles no estructurado.
Además de un análisis del camino básico que aísle todos los caminos de un bucle, se recomienda un conjunto especial de pruebas adicionales para cada tipo de bucles. Estas pruebas buscan errores de inicialización, errores de indexación o de incremento y errores en los límites de los bucles.
Bucles Simples: A los bucles simples se les debe aplicar el siguiente conjunto de pruebas, donde n es el numero máximo de pasos permitidos por bucle.

1. Saltar totalmente el bucle.
2. Pasar una sola vez por el bucle.
3. Pasar dos veces por el bucle.
4. Hacer m pasos por el bucle con m

Bucles Anidados: Si extendiéramos el enfoque de prueba de los bucles simples a los bucles anidados, el numero de posibles pruebas crecería geométricamente a medida que aumenta el nivel de anidamiento. Esto nos llevaría a un numero impracticable de pruebas. Beizer sugiere un enfoque que ayuda a reducir el número de pruebas:

1. Comenzar en el bucle más interior. Disponer todos los demás bucles en sus valores mínimos.
2. Llevar a cabo las pruebas de bucles simples con el bucle mas interno mientras se mantiene los bucles exteriores con los valores mínimos para sus parámetros de iteración. Añadir otras pruebas para los valores fuera de rango o para valores excluidos.
3. Progresar hacia afuera, llevando a cabo las pruebas para el siguiente bicle, pero manteniendo todos los demás bucles exteriores en sus valores mínimos y los demás bucles anidados con valores “típicos”.
4. Continuar hasta que se hayan probado todos los bucles.

Bucles Concatenados: los bucle concatenados se pueden probar mediante el enfoque anteriormente definido para los bucles simple, mientras que cada uno de los bucles sea independiente del resto. Por ejemplo, si hay dos bucles concatenados y se usa el contador del bucle 1 como valor inicial del bucle 2, entonces los bucles no son independientes. Cuando los bucles no son independientes, se recomienda usar el enfoque aplicado para los bucles anidados.

Bucles No Estructurados: Siempre que sea posible, esta clase de bucles se deben rediseñar para que se ajuste a las construcciones de la programación estructurada.