6.3 CASOS DE PRUEBA CAJA BLANCA

6.3 CASOS DE PRUEBA
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 bucles
6.3.1 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.
6.3.1 PRUEBA DE LA RUTA BASICA
Recordar:
Diagrama de Flujo
y
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
6.3.1 PRUEBA DE LA RUTA BASICA
1
11
Ruta 1:
Ruta 2:
Ruta 3:
Ruta 4:
2,3
6
4,5
R2
7
R1
9
Rutas independientes:
1-11
1-2-3-4-5-10-1-11
1-2-3-6-8-9-10-1-11
1-2-3-6-7-9-10-1-11
R3
8
Genera ruta cada vez que se
pasa por una arista nueva
10
R4
6.3.1 PRUEBA DE LA RUTA BASICA
1
11
2,3
6
4,5
1. Número de regiones
R2
7
R1
9
La complejidad ciclomática
se basa en la teoría
gráfica y se calcula de
tres maneras:
R3
8
4
10
R4
6.3.1 PRUEBA DE LA RUTA BASICA
1
11
2,3
6
4,5
V(G) = E – N + 2
R2
7
R1
9
2. Complejidad ciclomática
es igual a número de
aristas, menos el número
de nodos más 2
R3
8
V(G) = 11 – 9 + 2 = 4
10
R4
6.3.1 PRUEBA DE LA RUTA BASICA
1
11
2,3
6
V(G) = P + 1
4,5
R2
7
R1
9
R3
8
3. Complejidad ciclomática
es igual al número de
nodos predicado más uno
10
R4
V(G) = 3 + 1 = 4
6.3.1 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
2. Complejidad ciclomática es igual a número de
aristas, menos el número de nodos más
V(G) = E – N + 2
3. Complejidad ciclomática es igual al número de
nodos predicado más uno
V(G) = P + 1
6.3.1 PRUEBA DE LA RUTA BASICA
1
11
2,3
6
-
4,5
R2
7
R1
R3
8
Recordar se puede utilizar
las matrices y si se les da
peso a cada nodo esto
nos ayuda a conocer :
-
9
10
R4
-
Probabilidad de ejecución
de un enlace
Tiempo de procesamiento
al recorrer un enlace
Memoria al recorrer un
enlace
Recursos al recorrer un
enlace
6.3.2 PRUEBA DE CONDICION
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.
6.3.3 PRUEBA DE FLUJO 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 definicion de x
USO( I ) = x | instrucción I contiene un uso de x
Objetivo: probar todas las DEF y USO de I
6.3.4 PRUEBA DE BUCLES
Técnica de prueba de caja blanca que se concentra
exclusivamente en la validez de la construcción de
bucles.
Tipos de bucles: simple, anidado, concatenado, no
estructurado.
6.3.4 PRUEBA DE BUCLES
Bucles simples:
omitir por completo el bucle
solo un paso por el bucle
dos pasos por el bucle
m pasos por el bucle ( m < n )
n=1 , n , n+1 pasos por el bucle
( n es num máximo pasos permitidos )
6.3.4 PRUEBA DE BUCLES
Bucles anidados:
iniciar el bucle mas interno
asignar a todo bucle los valores mínimos
validar el mas interno con valores mínimos en externos
agregar pruebas con valores fuera de rango
analizar de la misma manera hacia afuera
6.3.4 PRUEBA DE BUCLES
Bucles concatenados:
igual que los simples
Bucles no estructurados:
se recomienda rediseñar los bucles
6.3 CASOS DE PRUEBA
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
• Preubas de transacción
• Pruebas de comunicación de red
Prueba de documentación
6.3.5 PRUEBA BASADA 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.
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.
6.3.6 PRUEBA BASADA
EN ESCENARIOS
Esta complementa la anterior, ya que la de fallas soslaya
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.
Ejemplo: mandar imprimir documento ( con última
corrección ? )
6.3.7 PRUEBA DE 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 de base de datos: probar la exactitud e integridad
de los datos, examinar transacciones, asegurar que se
almacena, actualiza y recuperan los datos.
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.
6.3.7 PRUEBA DE DOCUMENTACION
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.