ESCUELA POLITCNICA DEL EJRCITO EXTENSIN LATACUNGA

Nombre: Fecha: Tema: Caja blanca

Alex Campaa G. 26-04-2012. Caja Blanca en Software

Tipo de pruebas de software que se realiza sobre las funciones internas de un mdulo. As como las pruebas de caja negra ejercitan los requisitos funcionales desde el exterior del mdulo, las de caja blanca estn dirigidas a las funciones internas. Entre las tcnicas usadas se encuentran; la cobertura de caminos (pruebas que hagan que se recorran todos los posibles caminos de ejecucin), pruebas sobre las expresiones lgicoaritmticas, pruebas de camino de datos (definicin-uso de variables), comprobacin de bucles (se verifican los bucles para 0,1 e interacciones, y luego para las interacciones mximas, mximas menos uno y ms uno). Las pruebas de caja blanca se llevan a cabo en primer lugar, sobre un mdulo concreto, para luego realizar las de caja negra sobre varios subsistemas (integracin). En los sistemas orientados a objetos, las pruebas de caja blanca pueden aplicarse a los mtodos de la clase, pero segn varias opiniones, ese esfuerzo debera dedicarse a otro tipo de pruebas ms especializadas (un argumento podra ser que los mtodos de una clase suelen ser menos complejos que los de una funcin de programacin estructurada). Dentro de las Pruebas de Caja Blanca encontramos las llamadas coberturas (sentencia, decisin, condicin y mltiple adems de los mencionados caminos ciclomticos propuestos por McCabe) Mtodos de prueba de caja blanca Algunos de los mtodos empleados en las pruebas de caja blanca son los siguientes: Prueba del camino bsico: es una tcnica propuesta inicialmente por Tom McCabe, la cual le permite al diseador de casos de prueba obtener una medida de la complejidad lgica de un diseo procedimental y usar esa medida como gua para la definicin de un conjunto bsico de caminos de ejecucin. Los casos de prueba obtenidos del conjunto bsico garantizarn que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa.

Algunos elementos y conceptos utilizados alrededor de ste mtodo son los siguientes: - Grafo de flujo o grafo del programa: representa el flujo de control lgico de un programa y se utiliza para trazar ms fcilmente las caminos de ste. (Cada nodo representa una o ms sentencias procedimentales y cada arista representa el flujo de control) - Complejidad ciclomtica: es una mtrica de software que proporciona una medicin cuantitativa de la complejidad lgica de un programa. Cuando se usa en el contexto de las pruebas, el clculo de la complejidad ciclmatica representa el nmero de caminos independientes del conjunto bsico de un programa. Esta medida ofrece al probador de software un lmite superior para el nmero de pruebas que debe realizar para garantizar que se ejecutan por lo menos una vez cada sentencia. - Camino independiente: cualquier camino del programa que introduce, por lo menos, un nuevo conjunto de sentencias de proceso o una nueva condicin. De forma general, los pasos que se debe seguir para la obtencin de los casos de prueba en este mtodo, son los siguientes: 1. Emplear el diseo o el cdigo para elaborar el grafo de flujo. 2. Determinar la complejidad ciclomtica del grafo de flujo. 3. Determinar un conjunto bsico de caminos linealmente independientes. 4. Preparar los casos de prueba que forzarn la ejecucin de cada camino del conjunto bsico. Prueba de la estructura de control: dentro de ste tipo de prueba se contempla el mtodo del camino bsico mencionado anteriormente pero adems existen otras pruebas asociadas que permiten ampliar la cobertura de la prueba y mejorar su calidad. Estas son: 1. Prueba de condicin: es un mtodo de diseo de casos de prueba que ejercita las condiciones lgicas contenidas en el mdulo de un programa. Algunos conceptos empleados alrededor de esta prueba son los siguientes: - Condicin simple: es una variable lgica o una expresin relacional ( E1 < operador relacional > E2). - Condicin compuesta: est formada por dos o ms condiciones simples, operadores lgicos y parntesis. En general los tipos de errores que se buscan en una prueba de condicin, son los siguientes: - Error en operador lgico(existencia de operadores lgicos incorrectos, desaparecidos, sobrantes). - Error en variable lgica. - Error en parntesis lgico.

- Error en operador relacional. - Error en expresin aritmtica. 2. Prueba del flujo de datos [Tai89]: selecciona caminos de prueba de un programa de acuerdo con la ubicacin de las definiciones y los usos de las variables del programa. 3. Prueba de bucles [Bei90a]: es una tcnica que se centra exclusivamente en la validez de las construcciones de bucles (bucles simples, anidados, concatenados y no estructurados). 3.1 Bucles simples. Se les aplica el siguiente conjunto de pruebas: - Pasar por alto totalmente el bucle. - Pasar una sola vez por el bucle. - Pasar dos veces por el bucle. - Hacer m pasos por el bucle con m < n (donde n es el nmero mximo de pasos permitidos por el bucle). -Hacer n - 1, n y n + 1 pasos por el bucle. 3.2 Bucles anidados. Si se empleara el mismo enfoque de prueba de bucles simples a los bucles anidados, el nmero de pruebas aumentara considerablemente por lo cual Beizer sugiere emplear el siguiente enfoque: - Comenzar por el bucle ms interior. Establecer o configurar los dems bucles con sus valores mnimos. - Llevar a cabo las pruebas de bucles simples para el bucle ms interior, mientras se mantienen los parmetros de iteracin de los bucles externos en sus valores mnimos. Aadir otras pruebas para valores fuera de rango o excluidos. - Progresar hacia fuera, llevando a cabo pruebas para el siguiente bucle, pero manteniendo todos los bucles externos en sus valores mnimos y los dems bucles anidados en sus valores tpicos. - Continuar hasta que se hayan probado todos los bucles. 3.3 Bucles concatenados. stos bucles se pueden probar utilizando el enfoque de bucles simples, siempre y cuando cada uno de los bucles sea independiente del resto de lo contrario se debe emplear el enfoque de bucles anidados. 3.4 Bucles no estructurados. Siempre que sea posible stos bucles deben redisearse.