Software
Páginas: 3 (586 palabras)
Publicado: 25 de febrero de 2013
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 deprueba.
Mediante los métodos de prueba de caja blanca, el ingeniero del software puede obtener casos de prueba que (1) garanticen que se ejercita por lo menos una vez todos los caminosindependientes 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; y (4) ejerciten lasestructuras internas de datos para asegurar su validez.
En este momento, se puede plantear un pregunta razonable: ¿Por qué emplear tiempo y energía preocupándose de (y probando) las minuciosidadesló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 cajanegra? La respuesta se encuentra en la naturaleza misma de los defectos del software (por ejemplo, (JON 81):
Los errores lógicos y las suposiciones incorrectas son inversamente proporcionales a laprobabilidad 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 fuerade 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 uncamino 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 nuestrassuposiciones 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 la prueba del camino.
Los errores tipográficos son...
Mediante los métodos de prueba de caja blanca, el ingeniero del software puede obtener casos de prueba que (1) garanticen que se ejercita por lo menos una vez todos los caminosindependientes 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; y (4) ejerciten lasestructuras internas de datos para asegurar su validez.
En este momento, se puede plantear un pregunta razonable: ¿Por qué emplear tiempo y energía preocupándose de (y probando) las minuciosidadesló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 cajanegra? La respuesta se encuentra en la naturaleza misma de los defectos del software (por ejemplo, (JON 81):
Los errores lógicos y las suposiciones incorrectas son inversamente proporcionales a laprobabilidad 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 fuerade 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 uncamino 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 nuestrassuposiciones 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 la prueba del camino.
Los errores tipográficos son...
Leer documento completo
Regístrate para leer el documento completo.