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 CASOS DE PRUEBA6.3 CASOS DE PRUEBACAJA BLANCACAJA BLANCA

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 BASICA6.3.1 PRUEBA DE LA RUTA BASICA

Recordar:

Diagrama de Flujo y Gráfica de Flujo

Componentes de la gráfica de flujo:

Aristas : enlacesNodos : instrucción proceduralNodo predicado : nodo del que emanan dos aristas ( if )Región : área que se limitan por aristas y nodos



1

2,3

4,5

11

6

7 8

9 10

Rutas independientes:

Ruta 1: 1-11Ruta 2: 1-2-3-4-5-10-1-11Ruta 3: 1-2-3-6-8-9-10-1-11Ruta 4: 1-2-3-6-7-9-10-1-11

Genera ruta cada vez que se pasa por una arista nueva

R1R2

R3

R4


1

2,3

4,5

11

6

7 8

9 10

R1R2

R3

La complejidad ciclomática se basa en la teoría gráfica y se calcula de tres maneras:

1. Número de regiones

4

R4


1

2,3

4,5

11

6

7 8

9 10

R1R2

R3

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

R4


1

2,3

4,5

11

6

7 8

9 10

R1R2

R3

3. Complejidad ciclomática es igual al número de nodos predicado más uno

V(G) = P + 1

V(G) = 3 + 1 = 4

R4

La complejidad ciclomática se basa en la teoría gráfica y se calcula de tres maneras:

1. Número de regiones2. 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 unoV(G) = P + 1



1

2,3

4,5

11

6

7 8

9 10

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

R1R2

R3

R4

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.2 PRUEBA DE CONDICION6.3.2 PRUEBA DE CONDICION

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 xUSO( I ) = x | instrucción I contiene un uso de x

Objetivo: probar todas las DEF y USO de I

6.3.3 PRUEBA DE FLUJO DE DATOS6.3.3 PRUEBA DE FLUJO DE DATOS

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 BUCLES6.3.4 PRUEBA DE BUCLES

Bucles simples:omitir por completo el buclesolo un paso por el bucledos pasos por el buclem pasos por el bucle ( m < n )n=1 , n , n+1 pasos por el bucle

( n es num máximo pasos permitidos )


Bucles anidados:iniciar el bucle mas internoasignar a todo bucle los valores mínimosvalidar el mas interno con valores mínimos en externosagregar pruebas con valores fuera de rangoanalizar de la misma manera hacia afuera


Bucles concatenados:igual que los simples

Bucles no estructurados:se recomienda rediseñar los bucles


6.3 CASOS DE PRUEBA6.3 CASOS DE PRUEBACAJA NEGRACAJA 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

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.5 PRUEBA BASADA EN FALLAS6.3.5 PRUEBA BASADA EN FALLAS

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.6 PRUEBA BASADA 6.3.6 PRUEBA BASADA EN ESCENARIOSEN ESCENARIOS

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 ARQUITECTURA6.3.7 PRUEBA DE ARQUITECTURACLIENTE / SERVIDORCLIENTE / SERVIDOR

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.

6.3.7 PRUEBA DE DOCUMENTACION6.3.7 PRUEBA DE DOCUMENTACION

Casos de Prueba Caja Blanca

Documents

Transcript of Casos de Prueba Caja Blanca