Diseño de casos de prueba

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).