Caja Blanca
Páginas: 9 (2118 palabras)
Publicado: 20 de septiembre de 2011
CAJA BLANCA
La prueba de caja blanca del software se basa en el minucioso examen de los detalles procedimentales. Se comprueban los caminos lógicos del software proponiendo casos de prueba que ejerciten conjuntos específicos de condiciones y/o bucles. Se puede examinar el «estado del programa» en varios puntos para determinar si el estado real coincide con el esperado o mencionado.
“Caminológicos es cualquier ruta del programa que ingresas por lo menos un nuevo conjunto de instrucciones de procesamiento o una nueva condición”
Las pruebas de caia blanca son diseñadas después de que exista un diseño de componente (o código fuente). El detalle de la lógica del programa debe estar disponible. A primera vista parecería que una prueba de caja blanca muy profunda nos lleva a tener«programas cien por cien correctos». Todo lo que tenemos que hacer es definir todos los caminos lógicos, desarrollar casos de prueba que los ejerciten y evaluar los resultados, es decir, generar casos de prueba que ejerciten exhaustivamente la lógica del programa. Desgraciadamente, la prueba exhaustiva presenta ciertos problemas logísticos. Incluso para pequeños programas, el número de caminos lógicosposibles puede ser enorme. Por ejemplo, considere un programa de 100 líneas de código en lenguaje C.
Después de la declaración de algunos datos básicos, el programa contiene dos bucles que se ejecutan de 1 a 20 veces cada uno, dependiendo de las condiciones especificadas en la entrada. Dentro del bucle interior, se necesitan cuatro construcciones if-then else. ¡Existen aproximadamente loi4caminos posibles que se pueden ejecutar en este programa!
La prueba de caja blanca, denominada a veces prueba de caja de cristal es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para obtener los casos de prueba. Mediante los métodos de prueba de caja blanca, el ingeniero del software puede obtener casos de prueba que
(1) garanticen que seejercita por lo menos una vez todos los caminos independientes de cada módulo;
(2) ejerciten todas las decisiones lógicas en sus vertientes verdadera y falsa;
(3) ejecuten todos los bucles en sus límites y con sus límites operacionales;
(4) ejerciten las estructuras internas de datos para asegurar su validez.
En este momento, se puede plantear un pregunta razonable: ¿Por qué emplear tiempo yenergía preocupándose de (y probando) las minuciosidades lógicas cuando podríamos emplear mejor el esfuerzo asegurando que se han alcanzado los requisitos del programa? O, dicho de otra forma, ¿por qué no empleamos todas nuestras energías en la prueba de caja negra? La respuesta se encuentra en la naturaleza misma de los defectos del software. Por ejemplo
* Los errores lógicos y lassuposiciones incorrectas son inversamente proporcionales a la probabilidad de que se ejecute un camino del programa. Los errores tienden a introducirse en nuestro trabajo cuando diseñamos e implementamos funciones, condiciones o controles que se encuentran fuera de lo normal. El procedimiento habitual tiende a hacerse más comprensible (y bien examinado), 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 normal. 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 sólo se descubren cuando comienza laprueba del camino.
* Los errores tipográficos son aleatorios. Cuando se traduce un programa a código fuente en 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 sin detectar hasta que comience la prueba. Es igual de probable que haya un error tipográfico en...
La prueba de caja blanca del software se basa en el minucioso examen de los detalles procedimentales. Se comprueban los caminos lógicos del software proponiendo casos de prueba que ejerciten conjuntos específicos de condiciones y/o bucles. Se puede examinar el «estado del programa» en varios puntos para determinar si el estado real coincide con el esperado o mencionado.
“Caminológicos es cualquier ruta del programa que ingresas por lo menos un nuevo conjunto de instrucciones de procesamiento o una nueva condición”
Las pruebas de caia blanca son diseñadas después de que exista un diseño de componente (o código fuente). El detalle de la lógica del programa debe estar disponible. A primera vista parecería que una prueba de caja blanca muy profunda nos lleva a tener«programas cien por cien correctos». Todo lo que tenemos que hacer es definir todos los caminos lógicos, desarrollar casos de prueba que los ejerciten y evaluar los resultados, es decir, generar casos de prueba que ejerciten exhaustivamente la lógica del programa. Desgraciadamente, la prueba exhaustiva presenta ciertos problemas logísticos. Incluso para pequeños programas, el número de caminos lógicosposibles puede ser enorme. Por ejemplo, considere un programa de 100 líneas de código en lenguaje C.
Después de la declaración de algunos datos básicos, el programa contiene dos bucles que se ejecutan de 1 a 20 veces cada uno, dependiendo de las condiciones especificadas en la entrada. Dentro del bucle interior, se necesitan cuatro construcciones if-then else. ¡Existen aproximadamente loi4caminos posibles que se pueden ejecutar en este programa!
La prueba de caja blanca, denominada a veces prueba de caja de cristal es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para obtener los casos de prueba. Mediante los métodos de prueba de caja blanca, el ingeniero del software puede obtener casos de prueba que
(1) garanticen que seejercita por lo menos una vez todos los caminos independientes de cada módulo;
(2) ejerciten todas las decisiones lógicas en sus vertientes verdadera y falsa;
(3) ejecuten todos los bucles en sus límites y con sus límites operacionales;
(4) ejerciten las estructuras internas de datos para asegurar su validez.
En este momento, se puede plantear un pregunta razonable: ¿Por qué emplear tiempo yenergía preocupándose de (y probando) las minuciosidades lógicas cuando podríamos emplear mejor el esfuerzo asegurando que se han alcanzado los requisitos del programa? O, dicho de otra forma, ¿por qué no empleamos todas nuestras energías en la prueba de caja negra? La respuesta se encuentra en la naturaleza misma de los defectos del software. Por ejemplo
* Los errores lógicos y lassuposiciones incorrectas son inversamente proporcionales a la probabilidad de que se ejecute un camino del programa. Los errores tienden a introducirse en nuestro trabajo cuando diseñamos e implementamos funciones, condiciones o controles que se encuentran fuera de lo normal. El procedimiento habitual tiende a hacerse más comprensible (y bien examinado), 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 normal. 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 sólo se descubren cuando comienza laprueba del camino.
* Los errores tipográficos son aleatorios. Cuando se traduce un programa a código fuente en 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 sin detectar hasta que comience la prueba. Es igual de probable que haya un error tipográfico en...
Leer documento completo
Regístrate para leer el documento completo.