3.3 TECNICAS DE PRUEBA

MODULO III

Ingeniería de Software INF - 163

Resumen preparado por Miguel Cotaña 07/11/2012 1

Operatividad;

Observabilidad;

Controlabilidad;

Capacidad para

descomponer;

Simplicidad;

Estabilidad;

Facilidad de comprensión.

Características de facilidad de prueba

2

Kaner, Nguyen sugieren:

atributos para una buena prueba:

Tiene una elevada probabilidad

de encontrar un error;

No es redundante;

Debe ser la mejor de su clase;

No debe ser ni muy simple ni

demasiado compleja. 3

Pruebas de Caja Negra

4

Se concentran en

los requisitos

funcionales del Sw.

Se llevan a cabo sobre la interfaz del software, obviando el comportamiento interno y la estructura del prog.

Caja Negra

5

La prueba de la caja negra también es conocida como prueba de especificación o pruebas de comportamiento, puesto que examina si el sistema genera los resultados esperados, si cumple con los requerimientos que posee.

6

Con la realización de esta prueba se busca demostrar que las funciones del sistema son operativas, que las entradas se aceptan de forma adecuada y que se produce un resultado correcto.

7

Basados en grafo: Entender los objetos que se modelan en el software y las relaciones que conectan a estos objetos:

Se crea un grafo de objetos importantes y sus relaciones.

Se diseña una serie de pruebas que cubran el grafo, que se ejerciten todos los objetos y sus relaciones para descubrir errores;

Métodos de Prueba de Caja Negra

8

Partición equivalente: divide el campo de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba.

Una clase de equivalencia representa un conjunto de estados válidos o no válidos para condiciones de entrada.

9

Condición de

Entrada Clases Válidas

Clases

Inválidas

Código de Área

# de 3 dígitos que no

empieza con 0 ni 1:

1) 200≤ código ≤ 999

2) Código < 200.

3) Código > 999.

4) No es número.

Nombre

Para identificar la

operación

5) Seis caracteres.

6) Menos de 6

caracteres.

7) Más de 6 caracteres.

Orden

Una de las

Siguientes

8) “Cheque”

9) “Depósito”

10) “Pago factura”

11)“Retiro de fondos”

12) Ninguna orden

válida

10

Análisis de valores límite: los errores tienden a darse más en los límites del campo de entrada que en el centro. El AVL, completa a la partición equivalente. En lugar de seleccionar cualquier elemento de una clase de equivalencia, el AVL lleva a la elección de casos de prueba en los extremos.

11

Prueba de tabla ortogonal: hay aplicaciones donde el nro. de parámetros de entrada es pequeño y los valores de cada uno de los parámetros está delimitado. Cuando estos números son muy pequeños, es posible considerar cada permutación de entrada y comprobar exhaustivamente.

12

Adivinando el error: dado un programa “X”, se conjetura, por la intuición y la experiencia, ciertos tipos probables de errores y se escriben casos de prueba para exponer esos errores. Por ejemplo, la presencia del valor 0 en la entrada de un programa es una situación con tendencia a error.

13

Arquitectura Cliente/servidor:

Pruebas de servidor; Pruebas de base de datos Pruebas de transaccion Pruebas de comunicación de red

De sistemas de tiempo real.

14

Prueba de validación y verificación: Asegurar que el sistema se ajusta a los requisitos del usuario y cumple correctamente con una función especifica.

Prueba de seguridad: Verificar los mecanismos de protección incorporados en el sistema, de accesos no permitidos;

15

Prueba de Documentación y Ayuda: Los errores en la documentación pueden ser destructivos para la aceptación del sistema como los errores en los datos y el código fuente.

Pruebas de Caja Blanca

16

Se basa en un

examen cercano al

detalle

procedimental. Se

prueban las rutas

lógicas y la

colaboración entre

componentes.

Caja Blanca

17

Es un método de diseño, que el

IS podrá derivar los casos de

prueba que:

1. Garanticen que todas las

rutas independientes dentro

del módulo se han ejercitado

por lo menos una vez;

18

2. Ejerciten los lados V y F de

todas las decisiones lógicas;

3. Ejecuten todos los bucles en

sus límites y dentro de sus

límites operacionales;

4. Ejerciten estructuras de datos

internos para asegurar su

validez.

Es una técnica de caja blanca,

que permite que el diseñador de

casos de prueba obtenga una

medida de complejidad lógica de

un diseño procedimental y que

use esta medida como guía para

definir un conjunto básico de

rutas de ejecución.

Prueba de la Ruta Básica

19

20

Previamente, para

representación del

flujo de control

(gráfica de flujo) se

utiliza una notación.

Se describe la

estructura de control,

mediante DF. Luego

se mapea.

2

1

3

6 4

5 7 8

9 10

11

• If (….)

si T, si F

• Switch (….)

cada ‘case’ + `default’

• Cobertura de bucles

for; 3 pruebas: 0 veces, 1 vez, n>1 veces;

repeat; 2 pruebas: 1 vez, n>1 veces;

while; 3 pruebas: 0 veces, 1 vez, n>1 veces;

21

Una ruta independiente es

cualquier ruta del programa que

ingresa por lo menos un nuevo

conjunto de instrucciones de

procesamiento o una nueva

condición (debe recorrer por lo

menos una arista que no se haya

recorrido antes).

Rutas independientes del programa

22

¿Cómo se sabe cuántas rutas

buscar?

A través de la complejidad

ciclomática que es una métrica

de software que proporciona una

medida cuantitativa de la

complejidad lógica de un

programa. 23

El valor calculado, define el

número de rutas en el conjunto

básico de un programa, y

proporciona un límite superior para

el número de pruebas que deben

aplicarse para asegurar que todas

las instrucciones se hayan

ejecutado por lo menos una vez. 24

Se basa en la teoría gráfica:

1.Número de regiones;

2.V(G)=E-N+2;

3.V(G), de una gráfica de

flujo G, también se define

como: V(G)=P+1

(P número de nodos predicado)

Complejidad Ciclomática

25

1.Utilizando el diseño o el código

como base se dibuja la gráfica

de flujo correspondiente;

2.Determinar V(G);

3.Determinar un conjunto básico

de rutas linealmente

independientes;

4.Preparar casos de prueba.

Pasos para derivar el conjunto básico

26

Se aplica a un diseño

procedimiental o al código fuente

Como ejemplo, se tiene el

procedimiento que calcula el

promedio de <=100 números

que están entre los valores

límite; también calcula la suma y

el total de números válidos.

Derivación de Casos de Prueba

27

28

PROCEDIMIENTO promedio:

INTERFACE RETURNS promedio, t.entrada, t.valido;

INTERFACE ACCEPTS valor, minimo, maximo;

TYPE valor {1:100} IS SCALAR ARRAY;

TYPE promedio, t.entrada, t.valido;

minimo, maximo, suma IS SCALAR;

TYPE i IS INTEGER;

i = 1;

t.entrada = t.valido = 0;

suma = 0;

DO WHILE valor[i]<>-999 AND t.entrada<100

incrementar t.entrada en 1;

IF valor[i]>=minimo AND valor[1] <=maximo

THEN incrementar t.valido en 1;

suma = s suma + valor[1]

ELSE omitir

ENDIF

incrementar i en 1;

ENDDO

IF t.valido > 0

THEN promedio = suma/t.valido;

ELSE promedio = -999

ENDIF

END promedio

29

1

2

3

4

5

6

7 8

9

10

11

a12

Abrir Archivos;

Leer archivo ventas, al final indicar no mas registros

Limpiar linea de impresión

WHILE (Haya registros ventas) DO

Total Nacional = 0

Total Extranjero = 0

WHILE (haya reg. ventas) (mismo producto) y

IF (Nacional) THEN

Sumar venta Nacional a Total Nacional

ELSE

Sumar venta extranjero a total extranjero

END IF

Leer Archivo ventas, al final indicar no mas registros

END WHILE

Escribir línea de listado

Limpiar área de impresión

END WHILE

Cerrar Archivos

DO

30

Import java.io.*;

Public class Maximo {

public static void main (String args[]) throws IOException {

BufferedReader entrada = new BufferedReader (new InputStreamReader(System.in));

Int x,y,z,max;

System.out.println(“Introduce x,y,z: ”);

x = Integer.parseInt (entrada.readLine());

y = Integer.parseInt (entrada.readLine());

z = Integer.parseInt (entrada.readLine());

if (x>y && x>z)

max = x;

else

if (z>y)

max = z;

else

max = y;

System.out.println (“El máximo es ”+ max);

}

}

31

Es necesario probar un sistema OO en diferentes niveles para descubrir errores que podrían ocurrir a medida que las clases colaboran entre sí y los subsistemas se comunican entre las capas de la arquitectura.

Métodos de pruebas OO

32

Los métodos de prueba de caja blanca, pueden aplicarse a las operaciones definidas para una clase.

Las técnicas de flujo de datos o de prueba de la ruta básica o de bucle ayudan a asegurar que se han probado todas las instrucciones de una operación.

33

Los métodos de prueba de caja negra son tan apropiados para los sistemas OO como para los sistemas convencionales.

Los casos de uso proporcionan información útil para el diseño de pruebas de caja negra y basadas en el estado.