Casos de Prueba
Caja Blanca y Caja Negra
CAJA BLANCA
Tipos de Prueba:
Prueba de la Ruta Básica
Pruebas de la estructura de control
Prueba de condición
Prueba del flujo de datos
Prueba de ciclos
PRUEBA DE LA RUTA BASICA
Técnica de prueba de caja blanca que propuso
Tom McCabe.
Permite conocer una medida de la complejidad
lógica de un diseño procedural y usar esta
medida como guía para definir un conjunto
básico de rutas de ejecución.
Estas garantizan que se ejecute cada
instrucción del programa por lo menos una
vez durante la prueba.
PRUEBA DE LA RUTA BASICA
Recordar:
Diagrama de Flujo
Gráfica de Flujo
Componentes de la gráfica de flujo:
Aristas : enlaces
Nodos : instrucción procedural
Nodo predicado : nodo del que emanan dos aristas
(if)
Región : área que se limitan por aristas y nodos
PRUEBA DE LA RUTA BASICA
Rutas independientes:
Ruta 1: 1-11
Ruta 2: 1-2-3-4-5-10-1-11
Ruta 3: 1-2-3-6-8-9-10-1-11
Ruta 4: 1-2-3-6-7-9-10-1-11
Genera ruta cada vez que
se pasa por una arista
nueva
PRUEBA DE LA RUTA BASICA
La complejidad ciclomática
se basa en la teoría gráfica y
se calcula de tres maneras:
1. Número de regiones:
4
PRUEBA DE LA RUTA BASICA
2. Complejidad ciclomática es
igual a número de aristas,
menos el número de nodos
más 2
V(G) = E –N + 2
V(G) = 11 –9 + 2 =
4
PRUEBA DE LA RUTA BASICA
3. Complejidad ciclomática
es igual al número de
nodos predicado más
uno
V(G) = P + 1
V(G) = 3 + 1 =
4
PRUEBA DE LA RUTA BASICA
Recordar se puede utilizar
las matrices y si se les da
peso a cada nodo esto nos
ayuda a conocer :
Probabilidad de ejecución de
un enlace
Tiempo de procesamiento al
recorrer un enlace
Memoria al recorrer un enlace
Recursos al recorrer un enlace
PRUEBA DE CONDICIÓN
Método que ejercita las condiciones lógicas
contenidas en un módulo del programa.
Una condición simple es una variable booleana o una
expresión relacional.
Esta prueba se concentra en la prueba de cada
condición del programa para asegurar que no
contiene errores.
Expresión1 <operador relacional> Expresión2
Objetivo: probar todos los casos de la relación.
PRUEBA DE USO DE DATOS
Método que selecciona rutas de prueba de acuerdo con
las ubicaciones de las definiciones y usos de las variables
del programa.
Asume que cada instrucción se le asigna un numero de
instrucción y ninguna función modifica sus parámetros o
variables globales.
Probar las DEF( I ) y las USO( I )
Donde:
DEF( I ) = x | instrucción I contiene una definición de x
USO( I ) = x | instrucción I contiene un uso de x
Objetivo: probar todas las DEF y USO de I
PRUEBA DE CICLOS
Técnica de prueba de caja blanca que se concentra
exclusivamente en la validez de la construcción de
bucles.
Tipos: simple, anidado, concatenado, no estructurado.
PRUEBA DE CICLOS
Ciclos simples:
Omitir por completo el ciclo
Solo un paso por él
Dos pasos por él
m pasos por él ( m < n )
n=1 , n , n+1 pasos por él
( n es número máximo de pasos permitidos )
PRUEBA DE CICLOS
Ciclos anidados:
iniciar el ciclo más interno
asignar a todo ciclo los valores mínimos
validar el más interno con valores mínimos en
externos
agregar pruebas con valores fuera de rango
analizar de la misma manera hacia afuera
PRUEBA DE CICLOS
Ciclos concatenados:
igual que los simples
Ciclos no estructurados:
se recomienda rediseñarlos
CAJA NEGRA
Tipos de Prueba:
Prueba basada en fallas
Prueba basada en escenarios
Prueba de arquitectura cliente/servidor
Pruebas de servidor
Pruebas de base de datos
Pruebas de transacción
Pruebas de comunicación de red
Prueba de documentación
PRUEBAS BASADAS EN FALLAS
Diseñar pruebas que tengan altas
probabilidades de descubrir posibles fallas.
La prueba de integración busca fallas en
llamadas a operación o en conexiones entre
mensajes.
PRUEBAS BASADAS EN FALLAS
Tres tipos de fallas se pueden encontrar:
resultado inesperado,
operación incorrecta / mensaje empleado,
invocación incorrecta.
La prueba de integración busca encontrar
errores en el objeto cliente, no en el
servidor.
PRUEBA BASADA EN ESCENARIOS
Esta complementa la anterior, ya que la de
fallas conlleva dos tipos de errores:
a) Especificaciones incorrectas: el producto no hace
lo que el cliente quiere.
b) Interacciones entre subsistemas: ocurren cuando el
comportamiento de un subsistema causa fallas del
otro subsistema.
Este tipo de prueba se enfoca en lo que hace
el usuario no el producto.
PRUEBA ARQUITECTURA
CLIENTE/SERVIDOR
Prueba de servidor: probar las funciones
de coordinación y manejo de datos del
servidor. Desempeño del servidor
(tiempo de respuesta y procesamiento
total de los datos).
PRUEBA ARQUITECTURA
CLIENTE/SERVIDOR
Prueba de base de datos: probar la
exactitud e integridad de los datos,
examinar transacciones, asegurar que se
almacena, actualiza y recuperan los datos.
PRUEBA ARQUITECTURA
CLIENTE/SERVIDOR
Pruebas de comunicación de red:
verificar comunicación entre los nodos, el
paso de mensajes, transacciones y trafico
de la red se realice sin errores.
PRUEBA DE DOCUMENTACIÓN
Es importante para la aceptación del programa.
Revisar la guía de usuario o funciones de ayuda
en línea.
Prueba de documentación es en dos fases:
1.Revisar e inspeccionar: examinar la claridad
editorial del documento.
2.Prueba en vivo: usar la documentación junto con el
programa real.