Este documento describe los métodos de prueba de software. Explica que la prueba de software es un proceso para encontrar errores ejecutando un programa. Describe diferentes tipos de pruebas como pruebas de caja blanca, pruebas de caja negra y pruebas aleatorias. También explica principios clave como probar diferentes caminos y condiciones, y generar casos de prueba para datos válidos e inválidos. El objetivo final de la prueba de software es encontrar errores para mejorar la calidad del programa.

1. METODOS DE PRUEBA
DEL SOFTWARE

2. Introducción
¿Qué es probar software?
Algunas definiciones incorrectas:
• Probar es demostrar que no hay errores
presentes en un programa.
• El propósito de probar es mostrar que el
programa realiza correctamente las funciones
esperadas.
La definición Correcta
• Probar es el proceso ejecución de un programa
con el fin de encontrar errores.
¿Por qué Probar Software?

3. Pruebas del Software
Otras Definiciones
•
•
•
•
•
•
•
Verificar.
Validar.
Pruebas.
Caso de Prueba.
Defecto.
Fallo.
Error.

4. Relación entre error, defecto y fallo

5. Objetivos de la Prueba.
 La prueba es el proceso de ejecución de un
programa con la intención 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.

6. Principios de las pruebas
 A todas las pruebas se les debería poder
hacer un seguimiento hasta los requisitos
del cliente.
 Las pruebas deberían planificarse mucho
antes de que empiecen.
 Las pruebas deberían empezar por “lo
pequeño” y progresar hacia “lo grande”.

7. Principios de las pruebas
 No son posibles las pruebas exhaustivas.
 Para ser más eficaces (pruebas con la más
alta probabilidad de encontrar errores), las
pruebas deberían ser realizadas por un
equipo independiente.

8. Principios de las pruebas
 Se debe inspeccionar a conciencia el
resultado de cada prueba para, así, poder
descubrir posibles síntomas 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 válidos y
esperados como no válidos e inesperados.

9. 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 .

10. 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.

11. Facilidad de Prueba







Operatividad
Observabilidad
Controlabilidad
Capacidad de descomposición
Simplicidad
Estabilidad
Facilidad de comprensión

12. 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.

13. El proceso de Prueba
 La depuración (localización y corrección de
defectos).
 El análisis de la estadística de errores.

14. Ciclo completo de las Pruebas

15. Enfoque de Diseño de Casos de
Prueba
 Enfoque estructural o de caja blanca.
 Enfoque funcional o de caja negra.
 Enfoque Aleatorio.

16. 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.

17. 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)

18. Grafo de Flujo de las Estructuras Básicas de
programa
X
X
X
Secuencia



Si x Entonces…
(If x Then … Else…)
Hacer … hasta x
(Do … Until x)
Repetir
Mientras x Hacer …
(While x Do … )
Separar todas las condiciones
Agrupar sentencias ‘simples’ en bloques
Numerar todos los bloques y tambien las
condiciones

19. Grafo de Flujo de un programa
(Pseudocodigo)
Abrir Archivos;
Leer archivo ventas, al final indicar no mas registros
Limpiar linea de impresión
1
WHILE (Haya registros ventas) DO
2
Total Nacional = 0
Total Extranjero = 0
WHILE
(haya reg. ventas)
3
y
(mismo producto) DO
4
IF (Nacional) THEN
5
Sumar venta Nacional a Total Nacional
ELSE
6
Sumar venta extranjero a total extranjero
a12
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
7
8
9
10
11

20. 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.

21. 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.

22. 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.

23. ¿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.

24. Ejemplo de calculo de V (G)
1
a1
a2
a3
2
a4
3
Región 1
a5
a6
a8
5
a9
a7
4
Región 2
Región 3
a10
a11
7
a13
Región 5
6
a12
Región 4
9
10
11
 a) V (G) =14-11+2=5
a14
 b) V (G) = 5 Regiones
Cerradas.
8
 c) V (G) = 4+1= 5
Condiciones

25. 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.

26. 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.

27. 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.

28. Prueba de bucles
Tipos de pruebas:
• Bucles simples.
• Bucles Anidados.
• Bucles Concatenados.
• Bucles no estructurados.

29. 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.

30. 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.

31. Métodos 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
relaciónes esperadas”

32. Partición equivalente
Pasos para identificar clases de equivalencia.
1. Identificación de las condiciones de entrada
del programa.
2. Identificar las clases de equivalencia:
a) Datos válidos.
b) Datos no válidos.

33. Partición equivalente
Pasos para identificar casos de prueba.
1. Asignar un número único para cada clase de
equivalencia.
2. Escribir casos de pruebas para todas las
clases válidas.
3. Escribir casos de pruebas para todas las
clases no válidas.

34. Ejemplo de clases de equivalencia
Aplicación bancaria en la que el operador debe proporcionar un código,
un nombre y una operación.
Condición de
Entrada
Código de Área
# de 3 dígitos que no
empieza con 0 ni 1:
Nombre
Para identificar la
operación
Clases Válidas
Clases Inválidas
1) 200≤ código ≤ 999
2) Código < 200.
3) Código > 999.
4) No es número.
5) Seis caracteres.
6) Menos de 6
caracteres.
7) Más de 6 caracteres.
8) “Cheque”
9) “Depósito”
Orden
Una de las Siguientes 10) “Pago factura”
11)“Retiro de fondos”
12) Ninguna orden
válida

35. Análisis de valores limite
Las reglas para identificar las clases son:
1. Si una condición de entrada especifica un rango que
deben generar casos para los extremos.
2. 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
3. Usar la regla 1 para la condición de salida.
4. Usar la regla 2 para cada condición de salida.

36. 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.

37. 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.

38. 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.

39. BIBLIOGRAFIA
 Fairley R. Ingeniería de Software.
 Pressman, R.S. Ingeniería del Software. Un
enfoque práctico.