View
21
Download
0
Category
Preview:
Citation preview
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.
Recommended