MTODOS DE PRUEBA

DEL SOFTWARE
Introduccin
Qu es probar software?
Algunas definiciones incorrectas:
Probar es demostrar que no hay errores
presentes en un programa.
El propsito de probar es mostrar que el
programa realiza correctamente las funciones
esperadas.
La definicin Correcta
Probar es el proceso ejecucin de un programa
con el fin de encontrar errores.
Por qu Probar Software?
Pruebas del Software
Otras Definiciones
Verificar.
Validar.
Pruebas.
Caso de Prueba.
Defecto.
Fallo.
Error.
Relacin entre error, defecto y fallo
Objetivos de la Prueba.
La prueba es el proceso de ejecucin de un
programa con la intencin de descubrir un
error.
Un buen caso de prueba es aquel que tiene
una alta probabilidad de mostrar un error no
descubierto hasta entonces.
Una prueba tiene xito si descubre un error
no detectado hasta entonces.
Principios de las pruebas
A todas las pruebas se les debera poder
hacer un seguimiento hasta los requisitos
del cliente.
Las pruebas deberan planificarse mucho
antes de que empiecen.
Las pruebas deberan empezar por lo
pequeo y progresar hacia lo grande.
Principios de las pruebas
No son posibles las pruebas exhaustivas.

Para ser ms eficaces (pruebas con la ms

alta probabilidad de encontrar errores), las
pruebas deberan ser realizadas por un
equipo independiente.
Principios de las pruebas
Se debe inspeccionar a conciencia el
resultado de cada prueba para, as, poder
descubrir posibles sntomas de defectos.
Cada caso de prueba debe definir el
resultado de salida esperado.
Al generar casos de prueba, se deben
incluir tanto datos de entrada vlidos y
esperados como no vlidos e inesperados.
Principios de las pruebas

Las pruebas deben centrarse en dos

objetivos (es habitual olvidar el segundo)
Probar si el software no hace lo que debe hacer
Probar si el software hace lo que no debe
hacer, es decir si provoca efectos secundarios
Se deben evitar los casos desechables .
Principios de las pruebas
No deben hacerse planes de prueba
suponiendo que, prcticamente, 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 descomposicin
Simplicidad
Estabilidad
Facilidad de comprensin
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 depuracin (localizacin y correccin de

defectos).

El anlisis de la estadstica de errores.

Ciclo completo de las Pruebas
Enfoque de Diseo 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 mdulo.
Ejerciten todas las decisiones lgicas en
sus vertientes verdadera y falsa.
Ejecuten todos los bucles en sus lmites y
con sus lmites operacionales.
Ejerciten las estructuras internas de datos
para asegurar su validez.
 Criterios de Cobertura lgica
Cobertura de Sentencias. Menos Riguroso
(Mas Barato)
Cobertura de decisiones.
Cobertura de Condiciones.
Criterios de decisin/Condicin.
Criterio de Condicin Mltiple.
Criterio de Cobertura de Caminos Ms Riguroso
(Ms Caros)
(impracticable)
 Grafo de Flujo de las Estructuras Bsicas de
programa
X X

Secuencia Si x Entonces Hacer hasta x Mientras x Hacer

(If x Then Else) (Do Until x) (While x Do )
Repetir
Separar todas las condiciones
Agrupar sentencias simples en bloques
Numerar todos los bloques y tambien las
condiciones
 Grafo de Flujo de un programa
(Pseudocodigo)
Abrir Archivos;
Leer archivo ventas, al final indicar no mas registros
Limpiar linea de impresin
1
WHILE (Haya registros ventas) DO 2
Total Nacional = 0
Total Extranjero = 0 3
WHILE (haya reg. ventas) y (mismo producto) DO
4
IF (Nacional) THEN

Sumar venta Nacional a Total Nacional 5

ELSE
Sumar venta extranjero a total extranjero 6
a12
END IF
Leer Archivo ventas, al final indicar no mas registros 7 8
END WHILE
9
Escribir lnea de listado
Limpiar rea de impresin 10
END WHILE
11
Cerrar Archivos
Variantes de Prueba de Caja Blanca
a) Prueba del Camino Bsico.

b) Prueba de Condicin.

c) Prueba de Flujo de Datos.

d) Prueba de Bucles.
Prueba del camino Bsico
Complejidad Ciclomatica(La complejidad de
McCabe V (G))

La mtrica de McCabe ha sido muy popular en

el diseo de pruebas.

Es un indicador del nmero de caminos

independientes que existen en un grafo.
 Formas de Calcular la Complejidad
Ciclomtica 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 condicin.
 Qu es lo que se logra con la
complejidad ciclomtica?

V (G) marca el lmite mnimo de casos de

prueba para un programa.

Cuando V (G) >10 la probabilidad de

defectos en el mdulo o programa crece
mucho entonces quizs sea interesante
dividir el mdulo.
 Ejemplo de calculo de V (G)
1
a1
a2 a3
2
a4
3 Regin 1
a) V (G) =14-11+2=5
a5
a6 a7
4
Regin 2 a8
5 Regin 3 b) V (G) = 5 Regiones
a9
a10

a11
6
a12
Cerradas.
Regin 4
7 8
a13
9
a14
c) V (G) = 4+1= 5
Regin 5
10 Condiciones
11
Prueba de Condicin
Ventajas

La cobertura de la prueba de una condicin es

sencilla.

La cobertura de la prueba de las condiciones de

un programa da una orientacin 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 mximo
para encontrar errores.
Prueba de flujo de datos
Esta tcnica 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 proteccin 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
categoras:
Funciones Incorrectas o Ausentes.
Errores de Interfaz.
Errores en estructuras de datos o acceso a
bases de datos externas.
Errores de rendimiento.
Errores de inicializacin y terminacin.
Pruebas de Caja Negra.
Variantes de pruebas de caja negra.

a) Mtodos de prueba basados en grafos.

b) Particin Equivalente.
c) Anlisis de valores lmite.
d) Prueba de Comparacin.
e) Conjetura de Errores.
 Mtodos de prueba basados en
grafos
Pasos a seguir para una prueba de caja
Negra:
1. Entender los objetos que se van a modelar y
las relaciones que conectan a estos.

2. Definir una serie de pruebas que verifique que

todos los objetos tienen entre ellos la
relacines esperadas
Particin equivalente
Pasos para identificar clases de equivalencia.

1. Identificacin de las condiciones de entrada

del programa.

2. Identificar las clases de equivalencia:

a) Datos vlidos.
b) Datos no vlidos.
Particin equivalente
Pasos para identificar casos de prueba.

1. Asignar un nmero nico para cada clase de

equivalencia.
2. Escribir casos de pruebas para todas las
clases vlidas.
3. Escribir casos de pruebas para todas las
clases no vlidas.
Ejemplo de clases de equivalencia
Aplicacin bancaria en la que el operador debe proporcionar un cdigo,
un nombre y una operacin.

Condicin de
Clases Vlidas Clases Invlidas
Entrada
Cdigo de rea 2) Cdigo < 200.
# de 3 dgitos que no 1) 200 cdigo 999 3) Cdigo > 999.
empieza con 0 ni 1: 4) No es nmero.
Nombre 6) Menos de 6
Para identificar la 5) Seis caracteres. caracteres.
operacin 7) Ms de 6 caracteres.
8) Cheque
Orden 9) Depsito 12) Ninguna orden
Una de las Siguientes 10) Pago factura vlida
11)Retiro de fondos
Anlisis de valores limite
Las reglas para identificar las clases son:

1. Si una condicin de entrada especifica un rango que

deben generar casos para los extremos.
2. Si la condicin de entrada especifica un nmero finito
y consecutivo de valores, escribir casos para los
nmeros mximo, mnimo, uno ms del mximo y uno
menos del mnimo de valores
3. Usar la regla 1 para la condicin de salida.
4. Usar la regla 2 para cada condicin de salida.
Prueba de Comparacin
Se desarrollan versiones independientes de
una aplicacin 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 comparacin 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 generacin de casos se obtiene en base
a la intuicin 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 generacin se ha realizado
correctamente, se crearn eventualmente
todas las posibles entradas del programa
en todas las posibles combinaciones y
permutaciones.
Baja probabilidad de encontrar errores.
 BIBLIOGRAFIA
Fairley R. Ingeniera de Software.

Pressman, R.S. Ingeniera del Software. Un

enfoque prctico.