Principios de las pruebas
No deben hacerse planes de prueba suponiendo que, prácticamente, no hay defectos en los programas, y dedicando pocos recursos a las pruebas.
La experiencia indica que donde hay un defecto hay otros.
Las pruebas son una tarea creativa como el desarrollo de software.
Facilidad de Prueba
Operatividad
Observabilidad
Controlabilidad
Capacidad de descomposición
Simplicidad
Estabilidad
Facilidad de comprensión
Bondad de una Prueba
Debe tener una alta probabilidad de encontrar un error.
No debe ser redundante.
Debe ser la mejor de todas las posibles.
No debe ser ni demasiado sencilla ni demasiado compleja.
El proceso de Prueba
La depuración (localización y corrección de defectos).
El análisis de la estadística de errores.
Ciclo completo de las Pruebas
Enfoque de Diseño de Casos de Prueba
Enfoque estructural o de caja blanca.
Enfoque funcional o de caja negra.
Enfoque Aleatorio.
Pruebas de Caja Blanca
Garanticen que se ejercita por lo menos una vez todos los caminos independientes de cada módulo.
Ejerciten todas las decisiones lógicas en sus vertientes verdadera y falsa.
Ejecuten todos los bucles en sus límites y con sus límites operacionales.
Ejerciten las estructuras internas de datos para asegurar su validez.
Criterios de Cobertura lógica
Cobertura de Sentencias.
Cobertura de decisiones.
Cobertura de Condiciones.
Criterios de decisión/Condición.
Criterio de Condición Múltiple.
Criterio de Cobertura de Caminos (impracticable)
Menos Riguroso
(Mas Barato)
Más Riguroso
(Más Caros)
Grafo de Flujo de las Estructuras Básicas de programa
Separar todas las condiciones
Agrupar sentencias ‘simples’ en bloques
Numerar todos los bloques y tambien las condiciones
(Gp:) X
(Gp:) X
(Gp:) X
Secuencia
Si x Entonces…
(If x Then … Else…)
Hacer … hasta x
(Do … Until x)
Repetir
Mientras x Hacer …
(While x Do … )
Grafo de Flujo de un programa (Pseudocodigo)
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
Variantes de Prueba de Caja Blanca
a) Prueba del Camino Básico.
b) Prueba de Condición.
c) Prueba de Flujo de Datos.
d) Prueba de Bucles.
Prueba del camino Básico
Complejidad Ciclomatica(La complejidad de McCabe V (G))
La métrica de McCabe ha sido muy popular en el diseño de pruebas.
Es un indicador del número de caminos independientes que existen en un grafo.
Formas de Calcular la Complejidad Ciclomática V(G)
V (G) = a – n + 2
V (G) = r
V (G) = c + 1
Donde
a : # de arcos o aristas del grafo.
n : # de nodos.
r : # de regiones cerradas del grafo.
c : # de nodos de condición.
¿Qué es lo que se logra con la complejidad ciclomática?
V (G) marca el límite mínimo de casos de prueba para un programa.
Cuando V (G) >10 la probabilidad de defectos en el módulo o programa crece mucho entonces quizás sea interesante dividir el módulo.
Ejemplo de calculo de V (G)
a) V (G) =14-11+2=5
b) V (G) = 5 Regiones
Cerradas.
c) V (G) = 4+1= 5
Condiciones
(Gp:) 1
(Gp:) 2
(Gp:) 3
(Gp:) 4
(Gp:) 5
(Gp:) 6
(Gp:) 7
(Gp:) 8
(Gp:) 9
(Gp:) 10
(Gp:) 11
(Gp:) a1
(Gp:) a2
(Gp:) a3
(Gp:) a4
(Gp:) a5
(Gp:) a6
(Gp:) a7
(Gp:) a8
(Gp:) a9
(Gp:) a10
(Gp:) a11
(Gp:) a12
(Gp:) a13
(Gp:) a14
(Gp:) Región 1
(Gp:) Región 2
(Gp:) Región 3
(Gp:) Región 4
(Gp:) Región 5
Prueba de Condición
Ventajas
La cobertura de la prueba de una condición es sencilla.
La cobertura de la prueba de las condiciones de un programa da una orientación para generar pruebas adicionales del programa.
Estrategias de prueba de Condiciones
Prueba de Ramificaciones.
Prueba de Dominio.
E1< operador-relacional>E2
Se necesitan 2n (n>0) pruebas como máximo
para encontrar errores.
Prueba de flujo de datos
Esta técnica selecciona caminos de un programa de acuerdo a las definiciones y uso de las variables.
El enfoque de prueba de flujo de datos es efectivo para la protección contra errores.
Prueba de bucles
Tipos de pruebas:
Bucles simples.
Bucles Anidados.
Bucles Concatenados.
Bucles no estructurados.
Pruebas de Caja Negra.
Intenta encontrar errores de las siguientes categorías:
Funciones Incorrectas o Ausentes.
Errores de Interfaz.
Errores en estructuras de datos o acceso a bases de datos externas.
Errores de rendimiento.
Errores de inicialización y terminación.
Pruebas de Caja Negra.
Variantes de pruebas de caja negra.
a) Métodos de prueba basados en grafos.
b) Partición Equivalente.
c) Análisis de valores límite.
d) Prueba de Comparación.
e) Conjetura de Errores.
Métodos de prueba basados en grafos
Pasos a seguir para una prueba de caja
Negra:
Entender los objetos que se van a modelar y las relaciones que conectan a estos.
Definir una serie de pruebas que verifique que “todos los objetos tienen entre ellos la relaciónes esperadas”
Partición equivalente
Pasos para identificar clases de equivalencia.
Identificación de las condiciones de entrada del programa.
Identificar las clases de equivalencia:
Datos válidos.
Datos no válidos.
Partición equivalente
Pasos para identificar casos de prueba.
Asignar un número único para cada clase de equivalencia.
Escribir casos de pruebas para todas las clases válidas.
Escribir casos de pruebas para todas las clases no válidas.
Ejemplo de clases de equivalenciaAplicación bancaria en la que el operador debe proporcionar un código, un nombre y una operación.
Análisis de valores limite
Las reglas para identificar las clases son:
Si una condición de entrada especifica un rango que deben generar casos para los extremos.
Si la condición de entrada especifica un número finito y consecutivo de valores, escribir casos para los números máximo, mínimo, uno más del máximo y uno menos del mínimo de valores
Usar la regla 1 para la condición de salida.
Usar la regla 2 para cada condición de salida.
Prueba de Comparación
Se desarrollan versiones independientes de una aplicación con las mismas especificaciones.
Probar todas las versiones con los mismos datos de prueba.
Luego se ejecutan las versiones en paralelo y se hace una comparación en tiempo real de los resultados.
Conjetura de Errores
Enumerar una lista de equivocaciones que pueden cometer los desarrolladores.
Generar casos de prueba en base a dicha lista.
La generación de casos se obtiene en base a la intuición o la experiencia.
Pruebas Aleatorias
Se simula los posibles datos de entrada en la secuencia y frecuencia que pueden aparecer en la practica.
Si el proceso de generación se ha realizado correctamente, se crearán eventualmente todas las posibles entradas del programa en todas las posibles combinaciones y permutaciones.
Baja probabilidad de encontrar errores.
BIBLIOGRAFIA
Fairley R. Ingeniería de Software.
Pressman, R.S. Ingeniería del Software. Un enfoque práctico.
 Página anterior | Volver al principio del trabajo | Página siguiente  |