Está en la página 1de 6

Clase 12: Diseo de casos de prueba 1.- Pruebas de caja blanca 1.1- Prueba del camino bsico 1.

2- Prueba de condiciones 1.3- Prueba de bucles 2.- Pruebas de caja negra 2.1- Particin equivalente 2.2- Anlisis de valores lmite 3.- Pruebas de integracin 4.- Pruebas de validacin. Alfa y beta. 5.- Ejercicio Recordando el objetivo de la prueba, debemos disear pruebas que tengan la mayor probabilidad de encontrar el mayor nmero de errores con la mnima cantidad de esfuerzo y tiempo. Las pruebas de caja negra se refieren a las pruebas que se llevan a cabo sobre la interfaz del software. O sea, pretenden demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce una salida correcta, as como que la integridad de la informacin externa se mantiene. Una prueba de caja negra examina algunos aspectos del modelo fundamental del sistema sin tener mucho en cuenta la estructura lgica interna del software. Las pruebas de caja blanca se basan en el minucioso examen de los detalles procedimentales. Se comprueban los caminos lgicos del software proponiendo casos de prueba que ejerciten conjuntos especficos de condiciones y/o bucles. A primera vista parecera que una prueba de caja blanca muy profunda nos llevara a tener "programas 100 por ciento correctos", pero desgraciadamente, la prueba exhaustiva presenta ciertos problemas logsticos. Incluso para pequeos programas, el nmero de caminos lgicos posibles resulta ser enorme, con lo que no se pueden probar estos caminos en un tiempo razonable. Por qu no gastamos, entonces, todas nuestras energas en las pruebas de caja negra? La respuesta se encuentra en la naturaleza misma de los defectos del software. A menudo creemos que un camino lgico tiene pocas posibilidades de ejecutarse cuando de hecho, se puede ejecutar muchas veces. Los errores de escritura son en su mayora descubiertos por los mecanismos de comprobacin de sintaxis, pero otros permanecern indetectados hasta que comience la prueba, siendo igual de probable que exista un error tipogrfico en un oscuro camino lgico que en un camino principal. La prueba de la caja negra, sin tener en cuenta cmo sea de completa, puede pasar por alto los tipos de errores que acabamos de sealar.

1.1- Prueba del camino bsico. El mtodo del camino bsico, propuesto por Tom McCabe, 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 derivados del conjunto bsico garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia de programa. Cualquier representacin del diseo procedimental se puede traducir a un grafo de flujo. La complejidad ciclomtica de este grafo (como se defini en la clase anterior) define el nmero de caminos independientes del conjunto bsico de un programa y nos da un lmite superior para el nmero de pruebas que se deben realizar para asegurar que se ejecuta cada sentencia al menos una vez. Un camino independiente es cualquier camino del programa que introduce por lo menos un nuevo conjunto de sentencias de procesamiento o una nueva condicin. En trminos del grafo de flujo, un camino independiente se debe mover por lo menos por una arista que no haya sido recorrida anteriormente a la definicin de un camino. La complejidad se puede calcular de tres formas: 1.- El numero de regiones del grafo de flujo 2.- Aristas - Nodos + 2 3.-Nodos predicado + 1 (un nodo predicado es el que representa una condicional if o case, es decir, que de l salen varios caminos) El valor de V(G) nos da el nmero de caminos linealmente independientes de la estructura de control del programa. Entonces se preparan los casos de prueba que forzarn la ejecucin de cada camino del conjunto bsico. Ejemplo: Diseemos un algoritmo que sea capaz de procesar una situacin de overflow cuando un conjunto de N pilas comparten un rea de memoria comn de M localizaciones enumeradas de L0 a Lm. L0 L1 L2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LM Entradas al programa: N - Cantidad de pilas b(j), t(j) J = 1, ..., N i - Pila donde se va a efectuar una insercin Si t(i) > b(i+1) ocurre overflow. Tres casos son posibles: 1.- Existe espacio a la izquierda? Se decrementa j desde i hasta 1 hasta encontrar que t(j) <= b(j+1). Si se encuentra, se corren a la izquierda una

posicin todas las pilas desde la j+1 hasta la pila i. Posteriormente se procede a ejecutar la insercin abandonada. 2.- Si no existe espacio a la izquierda existe a la derecha? Se incremente j desde i hasta M hasta encontrar que t(j) <= b(j+1). Si es as, se corren todas las pilas 1 posicin a la derecha desde la i+1 hasta la j. Efectuar la insercin abandonada. 3.- Si no existe espacio a la derecha ni a la izquierda, el overflow no tiene solucin. Caminos: 129 134579 1346879 13469 Los casos de prueba deben explotar los caminos anteriores. 1.2- Prueba de condiciones. La prueba de condiciones es un mtodo de diseo de casos de prueba que ejercita las condiciones lgicas contenidas en el mdulo de un programa. Se basa en el criterio de que si un conjunto de pruebas de un programa P es efectivo para detectar errores en las condiciones que se encuentran en P, es probable que el conjunto de pruebas sea tambin efctivo para detectar otros errores en el programa P. Para una expresin relacional de la forma: E1 <operador relacional> E2 se requieren tres pruebas: el valor de E1 mayor, menor o igual que el de E2. La prueba que haga el valor de E1 mayor o menor que el de E2 debe hacer que la diferencia entre estos dos valores sea lo ms pequea posible. Si la expresin es de la forma B1 & B2 donde B1 y B2 son variables lgicas, esta se cubre para B1 verdadero y B2 falso, B1 falso y B2 verdadero y ambos B1 y B2 verdadero. Ver en el libro de Pressman pgs. 642 a 643 ejemplos de expresiones complejas que incluyen expresiones lgicas y de comparacin. 1.3- Prueba de bucles Los bucles son la piedra angular de la mayora de los algoritmos implementados en software. La prueba de bucles es una tcnica de prueba de caja blanca que centra su punto de atencin en la validez de las construcciones de bucles.

A) Bucles simples: Se les debe aplicar el siguiente conjunto de pruebas, donde n es el nmero mximo de pasos permitidos para el bucle: 1. Pasar por alto 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 < n 5. Hacer n-1, n y n+1 pasos por el bucle B) Bucles anidados 1. Comenzar por el bucle ms interior. Establecer los dems bucles en sus valores mnimos. 2. Llevar a cabo las pruebas de bucles simples para el bucle ms interior, mientras se mantienen los parmetros de iteracin (p. Ej. Contadores de bucles) de los bucles externos en sus valores mnimos. Aadir otras pruebas para valores fuera de rango o excludos. 3. Progresar hacia fuera, llevando a cabos pruebas para el siguiente bucle, pero manteniendo todos los bucles externos en sus valores mnimos y los dems bucles anidados en sus valores "tpicos". 4. Continuar hasta que se hayan probado todos los bucles. C) Bucles concatenados: Se pueden probar mediante el enfoque anteriormente definido para los bucles simples, mientras cada uno de los bucles sea independiente del resto (si el contador del bucle 1 se usa como valor inicial del bucle 2 entonces los bucles no son independientes) D) Bucles no estructurados: Esta clase de bucles se deben redisear para que se ajusten a las construcciones de la programacin estructurada. 2.- Pruebas de caja negra 2.1- Particin Equivalente La particin equivalente es un mtodo de prueba de caja negra que divide el campo de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba.. Un caso de prueba ideal descubre de forma inmediata una clase de errores, que de otro modo requeriran la ejecucin de muchos casos antes de detectar el error genrico. La particin equivalente se dirige a la definicin de casos de prueba que descubran clases de errores, reduciendo as el nmero de casos de prueba que hay que desarrollar. El diseo de casos de prueba para la particin equivalente se basa en una evaluacin de las clases de equivalencia para una condicin de entrada. Una clase de equivalencia representa un conjunto de estados vlidos o invlidos para condiciones de entrada. 1. Si una condicin de entrada especifica un rango, se define una clase de equivalencia vlida y dos invlidas 2. Si una condicin de entrada requiere un valor especfico, se define una clase de equivalencia vlida y dos invlidas. 3. Si una condicin de entrada especifica un miembro de un conjunto, se

define una clase de equivalencia vlida y una invlida. 4. Si una condicin de entrada es lgica, se define una clase vlida y una invlida. Como ejemplo, consideremos los datos contenidos en una aplicacin de automatizacin bancaria. Este software acepta datos en la siguiente forma: Cdigo de rea: En blanco un nmero de 3 dgitos Prefijo: Nmero de 3 dgitos que no comience por 0 1 Sufijo: Nmero de 4 dgitos Contrasea: Vvalor alfanumrico de 6 dgitos Ordenes: "Comprobar", "Depositar","Pagar factura", etc. Las condiciones de entrada relacionadas con cada elemento de la aplicacin bancaria se pueden especificar como: Cdigo de rea: Condicin de entrada lgica - el cdigo de rea puede estar o no presente Condicin de entrada rango - valores definidos entre 200 y 999 Prefijo: Condicin de entrada rango - valor especificado > 200 Sufijo: Condicin de entrada valor- longitud de 4 dgitos Contrasea: Condicin de entrada lgica - la palabra clave puede estar o no presente Condicin de entrada valor - cadena de seis caracteres Orden: Condicin de entrada conjunto, contenida en las rdenes listadas anteriormente. Los casos de prueba se seleccionan de manera que se ejercite el mayor nmero de atributos de cada clase de equivalencia a la vez. 2.2 - Anlisis de valores lmite (AVL) Esta tcnica complementa a la de particin equivalente. En lugar de seleccionar cualquier elemento de una clase de equivalencia, el AVL lleva a la eleccin de casos de prueba "en los bordes" de la clase. En lugar de centrarse solamente en las condiciones de entrada, el AVL deriva casos de prueba tambin para el campo de salida. 1. Si una condicin de entrada especifica un rango delimitado por los valores a y b, se deben disear casos de prueba para los valores a y b y para valores justo por debajo y justo por encima de a y b, respectivamente. 2. Si una condicin de entrada especifica un nmero de valores, se deben desarrollar casos de prueba que ejerciten los valores mximo y mnimo. Tambin se deben probar los valores justo por debajo del mximo y del mnimo. 3. Aplicar las directrices 1 y 2 a las condiciones de salida. Por ej. supongamos que se requiere una tabla como salida deun programa, entonces se deben disear casos de prueba que creen un informe de salida que produzca el mximo ( y el mnimo) nmero permitido de entradas en la tabla. 4. Si las estructuras de datos internas tienen lmites preestablecidos ( p. Ej.

Un arreglo de 100 entradas) hay que asegurarse de disear un caso de prueba que ejercite la estructura de datos en sus lmites. 3.- Pruebas de integracin. La prueba de integracin se realiza posteriormente a las pruebas de unidad y su foco de atencin es el diseo y la construccin de la arquitectura del software. Despus de la integracin viene la validacin y por ltimo la prueba del sistema, sta ltima consiste en probar el software junto con los otros elementos de la empresa o entidad, como la gente, departamentos, la base de datos, etc. Las pruebas de integracin pueden ser descendentes o ascendentes o en sandwich, pero estas tienen sentido con ese nombre en los sistemas hechos en lenguajes estructurados, en los que el diagrama de la estructura de mdulos del sistema permite definir un tipo dado de integracin. En los orientados a objeto, otra vez cobra importancia el concepto de caso de uso, pues ste gua a la prueba en cuanto a los requisitos que deben satisfacer un determinado nmero de clases de programacin que tienen que interactuar entre s gobernadas por alguna clase de control del caso de uso. 4.- Pruebas de validacin La validacin se logra cuando el software funciona de acuerdo a las expectativas del cliente. La validacin seconsigue mediante una serie de pruebas de la caja negra que demuestran la conformidad con los requisitos. Si aparecen deficiencias, hay que negociar con el cliente un mtodo para resolverlas. La prueba alfa es conducida por un cliente en el lugar de desarrollo. Se usa el software de manera natural, con el encargado de desarrollo "mirando por encima del hombro" del usuario" y registrando errores y problemas de uso. Las pruebas alfa se llevan a cabo en un entrono controlado. La prueba beta se lleva a cabo en uno o ms lugares de clientes por los usuarios finales del software. A diferencia de la prueba alfa, el encargado de desarrollo, normalmente, no est presente. La prueba beta es una aplicacin "en vivo" del software en un entrono que no puede ser controlado por el equipo de desarrollo. El cliente registra todos los problemas (reales o imaginarios) que encuentra y los informa a intervalos regulares. Como resultado, el equipo de desarrollo lleva a cabo modificaciones y as prepara una versin del producto para toda la base de clientes.