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.