Está en la página 1de 7

2012

Exposicin Ariosto F. Javier Morales Ramrez.

[PRUEBAS DE LA CAJA BLANCA]


Extensin Rutas independientes del programa

Pruebas de la caja blanca


La prueba de la caja blanca, en ocasiones llamada prueba de caja de cristal, es un mtodo de diseo que usa la estructura de control descrita como parte del diseo al nivel de componentes para derivar los casos de prueba. Al emplear los mtodos de prueba de caja blanca, el ingeniero de software podr derivar casos de prueba que: Garanticen que todos las rutas independientes dentro del mdulo se han ejercitado por lo menos una vez. Ejerciten los lados verdadero y falso de todas las decisiones lgicas. Ejecuten todos los bucles en sus lmites y dentro de sus lmites operacionales. Ejerciten estructuras de datos internos para asegurar su validez.

Tipos de Pruebas de la Caja Blanca

Tipos de Pruebas

Prueba de la Ruta Bsica


Pruebas de la estructura de control

Prueba de condicin Prueba del flujo de datos Prueba de bucles

Prueba de la ruta bsica 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 los 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) 2) 3) 4) Emplear el diseo o el cdigo para elaborar el grafo de flujo. Determinar la complejidad ciclomtica del grafo de flujo. Determinar un conjunto bsico de caminos linealmente independientes. Preparar los casos de prueba que forzarn la ejecucin de cada camino del conjunto bsico.

Pruebas de la estructura de control

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: 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: 1) Error en operador lgico (existencia de operadores lgicos incorrectos, desaparecidos, sobrantes). 2) Error en variable lgica.

3) Error en parntesis lgico. 4) Error en operador relacional. 5) Error en expresin aritmtica.

Prueba del flujo de datos: selecciona caminos de prueba de un programa de acuerdo con la ubicacin de las definiciones y los usos de las variables del programa. Prueba de bucles: es una tcnica que se centra exclusivamente en la validez de las construcciones de bucles (bucles simples, anidados, concatenados y no estructurados).

1) 2) 3) 4)

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). 5) Hacer n - 1, n y n + 1 pasos por el bucle.

1) 2)

3)

4)

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.

Bucles concatenados. Estos 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.

Bucles no estructurados. Siempre que sea posible estos bucles deben redisearse.

Rutas independientes del programa


Una ruta independiente es cualquier ruta del programa que ingresa por lo menos un nuevo conjunto de instrucciones del procesamiento o una nueva condicin. Cuando se explica desde el punto de vista de una grfica de flujo, una ruta independiente debe recorrer por lo menos una arista que no se haya recorrido antes. Por ejemplo, a continuacin se presenta un conjunto de rutas independientes en la grfica de flujo: Ruta 1: 1-11 Ruta2: 1-2-3-4-5-10-1-11 Ruta3: 1-2-3-6-8-9-10-1-11 Ruta4: 1-2-3-6-7-9-10-1-11 Obsrvese que cada camino ingresa una nueva arista. El camino 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11 No se considera una ruta independiente porque se trata simplemente de una combinacin de rutas ya especificadas y no recorre ninguna arista nueva.

Pero Cmo se sabe cuntas rutas buscar?, el clculo de la Complejidad ciclomtica es la respuesta. La Complejidad Ciclomtica es una mtrica del software que proporciona una medicin cuantitativa de la complejidad lgica de un programa. Es una de las mtricas de software de mayor aceptacin, ya que ha sido concebida para ser independiente del lenguaje. El resultado obtenido en el clculo de la complejidad ciclomtica define el nmero de caminos independientes dentro de un fragmento de cdigo y determina la cota superior del nmero de pruebas que se deben realizar para asegurar que se ejecuta cada sentencia al menos una vez. La medida resultante puede ser utilizada en el desarrollo, mantenimiento y reingeniera para estimar el riesgo, costo y estabilidad. Algunos estudios experimentales indican la existencia de

distintas relaciones entre la mtrica de McCabe y el nmero de errores existentes en el cdigo fuente, as como el tiempo requerido para encontrar y corregir esos errores.

Una vez calculada la complejidad ciclomtica de un fragmento de cdigo, se puede determinar el riesgo que supone utilizando los rangos definidos en la siguiente tabla:

Complejidad Ciclomtica 1-10 11-20 21-50 50

Evaluacin del Riesgo Programa Simple, sin mucho riesgo Ms complejo, riesgo moderado Complejo, Programa de alto riesgo Programa no testeable, Muy alto riesgo

A partir del anlisis de muchos proyectos McCabe encontr que un valor 10 es un lmite superior prctico para el tamao de un mdulo. Cuando la complejidad supera dicho valor se hace muy difcil probarlo, entenderlo y modificarlo. La limitacin deliberada de la complejidad en todas las fases del desarrollo ayuda a evitar los problemas asociados a proyectos de alta complejidad. El lmite propuesto por McCabe sin embargo es fuente de controversias. Algunas organizaciones han utilizado el valor 15 con bastante xito.

Clculo de la Complejidad Ciclomtica

Primero introducir una sencilla notacin para la representacin del flujo de control, denominada Grafos de Flujo de Control de un programa. M = Complejidad ciclomtica. E = Nmero de aristas del grafo. Una arista conecta dos vrtices si una sentencia puede ser ejecutada inmediatamente despus de la primera. N = Nmero de nodos del grafo correspondientes a sentencias del programa. P = Nmero de componentes conexos correspondientes a las diferentes subrutinas, funciones o mtodos. Definidos estos conceptos, la Complejidad Ciclomtica puede calcularse de la siguiente manera:

M=EN+P Una versin simplificada para el clculo de la Complejidad Ciclomtica es la siguiente: M = Nmero de condiciones + 1 Esta ltima frmula hay que retocarla si el cdigo a analizar presenta varios puntos de salida o "returns", pasando a ser: M = Nmero de condiciones + Nmero de retornos o salidas donde el nmero de salidas nunca descender de 1.