Semana 4 Diseño de casos de prueba Automatización de Pruebas DISEÑO DE CASOS DE PRUEBA Los casos de prueba o Test Case son un conjunto de condiciones o variables bajo las cuáles el analista (Tester) determinará si el requisito de una aplicación es parcial o completamente satisfactorio. Se pueden realizar muchos casos de prueba para determinar que un requisito es completamente satisfactorio. Con el propósito de comprobar que todos los requisitos de una aplicación son revisados, debe haber al menos: Un caso de prueba para cada requisito. Si un requisito tiene requisitos secundarios, en ese caso, cada requisito secundario deberá tener por lo menos un caso de prueba. Se recomiendan el crear por lo menos dos casos de prueba para cada requisito. Uno de ellos debe realizar la prueba positiva de los requisitos y el otro debe realizar la prueba negativa. Lo que caracteriza un escrito formal de caso de prueba es que hay una ENTRADA conocida, un valor ESPERADA y una SALIDA obtenida, los cuales son formulados antes de que se ejecute la prueba. Bajo circunstancias especiales, podría haber la necesidad de ejecutar la prueba, producir resultados, y luego evaluar si los resultados se pueden considerar como "correctos" o incorrectos. Esto sucede a menudo en la determinación del número del rendimiento de productos nuevos. La primera prueba se toma como línea base para los subsecuentes ciclos de pruebas/lanzamiento del producto. Los casos de prueba escritos, incluyen una descripción de la funcionalidad que se probará, la cuál es tomada ya sea de los requisitos o de los casos de uso, o de lo que se supone que un campo de texto debe recibir. A lo largo del desarrollo del software nos encontraremos con diferentes pruebas que requieren el diseño de casos de prueba para su fin en específico. Casos de Prueba para realizar las pruebas de Unidad Cualquier programa puede ser probado bajo 2 esquemas diferentes: 1) Conociendo la función del producto (programa), es decir solo hay que demostrar que esa función anda bien. Este caso se realiza sobre las interfaces graficas y se lo denomina prueba de caja negra. Semana 4 Diseño de casos de prueba Automatización de Pruebas 2) Demostrar que la operación interna: Esta prueba se desarrolla en base a los caminos lógicos del modulo, se denomina PRUEBA DE CAJA BLANCA. Es la prueba que mejor nos deja ver a detalles de un programa. PRUEBAS DE CAJA BLANCA: Debe Garantizar: 1) Que se ejecutan al menos de una vez todos los caminos independientes de cada modulo. 2) Que se prueben todas las decisiones lógicas en sus ramas verdaderas y falsas. 3) Ejecutar todos los bucles o ciclos con los límites que se les haya definido. 4) Ejecutar las estructuras internas de datos para asegurar su validez. Métodos o herramientas de Caja Blanca Prueba del camino básico: Pasar el diagrama lógico a un grafo de flujo. Utiliza el grafo de flujo -> distintos módulos Componentes del Grafo de Flujo: Arista: Representa flujo de control Nodo: representa un conjunto de sentencias. Región: Área limitada por aristas y nodos Se considera como un área + lo que esta fuera del grafos (otra región). Complejidad Ciclomática: Es aquella medida cuantitativa que nos define la complejidad de un programa, y lo que mide es el número de caminos independientes que tiene el programa (cuando hablamos de caminos independientes nos referimos a cualquier camino que introduzca un nuevo conjunto de sentencias o un conjunto de decisiones, expresado en el grafos por un nodo). La complejidad ciclomática da un limite superior que define la cantidad de pruebas que tendríamos que hacer para asegurar que cada línea/sentencia se ejecute al menos una vez. Prueba de Bucles A - Eventualmente puede tener una repetición de ciclos B - Tiene un tope “n” que dice la cantidad máxima de veces que se puede repetir. Pruebas que hay que hacer: Semana 4 Diseño de casos de prueba Automatización de Pruebas 1º) Saltar por sobre el bucle. 2º) Pasar una sola vez por el bucle. 3º) Pasar 2 veces por el bucle. 4º) Pasar m veces (siendo m < n). 5º) Pasar n-1 veces. 6º) Pasar n veces. 7º) Pasar n+1 veces. Si se trata de un bucle anidado: La técnica es empezar primero por el bucle más interior dejando al resto en sus valores mínimos, probar al bucle interior como si fuera un bucle simple, avanzar hacia fuera manteniendo los bucles que siguen siendo exteriores en sus valores mínimos y a los interiores ponerlos en valores típicos. Si se trata de bucles concatenados: Si son independientes usamos para cada uno la técnica del bucle simple y si no son independientes, o sea si hay alguna relación, usan la técnica de bucles anidados. Otro Caso, Bucles no estructurados: En este caso rediseñar el software (borrar y empezar de cero) PRUEBAS DE CAJA NEGRA Son complementarias a las de caja blanca. Pero en la práctica se hace normalmente solo la prueba de caja negra. Errores habituales que se encuentran con pruebas de caja negra: *Funciones inexistentes o incorrectas. *Errores de interfase. *Errores de iniciación, comienzo o finalización. *Errores de rendimiento. Semana 4 Diseño de casos de prueba Automatización de Pruebas Planteamos 2 técnicas: 1)- Análisis de Valores Límites: Pressman dice que no hay una identificación clara de los valores límite, que suele haber más errores en los valores límites que en los típicos. Cuando hablamos de Valores Limites lo que decimos es que elegimos casos de prueba en los límites o bordes de la clase que estamos probando. (Ej.: Si una condición de entrada o salida exige un rango entre B y R, se realizan los casos de prueba para los valores B y R, y además a los valores que están por encima de ellos, es decir A y S). 2)- Partición Equivalencia: Es una técnica de simplificación de pruebas. Hay que dividir el dominio de entrada de un programa en clases de datos que tengan algo en común, de ahí derivan clases de prueba y por lo tanto también derivan clases de errores, de esta forma no hay necesidad de ejecutar muchas pruebas para encontrar errores genéricos. Para lograr esta se evalúan las clases de equivalencias posibles para una condición de entrada. Clases de equivalencias: Son los conjuntos de estados (válidos o no) para las condiciones de entrada. Condiciones de entrada: Valor numérico, rango de valores, condición booleana (si o no). Si una condición de entrada especifica un rango, se propone definir una clase de equivalencia valida y 2 inválidas. Si una condición de entrada especifica un número, un valor, se define una clase de equivalencia igual al caso anterior, (1 valida y 2 inválidas). Si una condición de entrada especifica un miembro de un conjunto, se define una condición valida y una invalida. Si es booleana, se define una clase de equivalencia igual al caso anterior (1 valida y 1 inválida).