1. METODOS DE PRUEBAMETODOS DE PRUEBA
DEL SOFTWAREDEL SOFTWARE

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

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

4. Relación entre error, defecto y falloRelación entre error, defecto y fallo

5. Objetivos de la Prueba.Objetivos de la Prueba.
 La prueba es el proceso de ejecución de unLa prueba es el proceso de ejecución de un
programa con la intención de descubrir unprograma con la intención de descubrir un
error.error.
 Un buen caso de prueba es aquel que tieneUn buen caso de prueba es aquel que tiene
una alta probabilidad de mostrar un error nouna alta probabilidad de mostrar un error no
descubierto hasta entonces.descubierto hasta entonces.
 Una prueba tiene éxito si descubre un errorUna prueba tiene éxito si descubre un error
no detectado hasta entonces.no detectado hasta entonces.

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

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

8. Principios de las pruebasPrincipios de las pruebas
 Se debe inspeccionar a conciencia elSe debe inspeccionar a conciencia el
resultado de cada prueba para, así, poderresultado de cada prueba para, así, poder
descubrir posibles síntomas de defectos.descubrir posibles síntomas de defectos.
 Cada caso de prueba debe definir elCada caso de prueba debe definir el
resultado de salida esperado.resultado de salida esperado.
 Al generar casos de prueba, se debenAl generar casos de prueba, se deben
incluir tanto datos de entrada válidos yincluir tanto datos de entrada válidos y
esperados como no válidos e inesperados.esperados como no válidos e inesperados.

9. Principios de las pruebasPrincipios de las pruebas
 Las pruebas deben centrarse en dosLas pruebas deben centrarse en dos
objetivos (es habitual olvidar el segundo)objetivos (es habitual olvidar el segundo)
• Probar si el software no hace lo que debe hacerProbar si el software no hace lo que debe hacer
• Probar si el software hace lo que no debeProbar si el software hace lo que no debe
hacer, es decir si provoca efectos secundarioshacer, es decir si provoca efectos secundarios
 Se deben evitar los casos desechablesSe deben evitar los casos desechables..

10. Principios de las pruebasPrincipios de las pruebas
 No deben hacerse planes de pruebaNo deben hacerse planes de prueba
suponiendo que, prácticamente, no haysuponiendo que, prácticamente, no hay
defectos en los programas, y dedicandodefectos en los programas, y dedicando
pocos recursos a las pruebas.pocos recursos a las pruebas.
 La experiencia indica que donde hay unLa experiencia indica que donde hay un
defecto hay otros.defecto hay otros.
 Las pruebas son una tarea creativa como elLas pruebas son una tarea creativa como el
desarrollo de software.desarrollo de software.

11. Facilidad de PruebaFacilidad de Prueba
 OperatividadOperatividad
 ObservabilidadObservabilidad
 ControlabilidadControlabilidad
 Capacidad de descomposiciónCapacidad de descomposición
 SimplicidadSimplicidad
 EstabilidadEstabilidad
 Facilidad de comprensiónFacilidad de comprensión

12. Bondad de una PruebaBondad de una Prueba
 Debe tener una alta probabilidad deDebe tener una alta probabilidad de
encontrar un error.encontrar un error.
 No debe ser redundante.No debe ser redundante.
 Debe ser la mejor de todas las posibles.Debe ser la mejor de todas las posibles.
 No debe ser ni demasiado sencilla niNo debe ser ni demasiado sencilla ni
demasiado compleja.demasiado compleja.

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

14. Ciclo completo de las PruebasCiclo completo de las Pruebas

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

16. Pruebas de Caja BlancaPruebas de Caja Blanca
 Garanticen que se ejercita por lo menosGaranticen que se ejercita por lo menos
una vez todos los caminos independientesuna vez todos los caminos independientes
de cada módulo.de cada módulo.
 Ejerciten todas las decisiones lógicas enEjerciten todas las decisiones lógicas en
sus vertientes verdadera y falsa.sus vertientes verdadera y falsa.
 Ejecuten todos los bucles en sus límites yEjecuten todos los bucles en sus límites y
con sus límites operacionales.con sus límites operacionales.
 Ejerciten las estructuras internas de datosEjerciten las estructuras internas de datos
para asegurar su validez.para asegurar su validez.

17. Criterios de Cobertura lógicaCriterios de Cobertura lógica
 Cobertura de Sentencias.Cobertura de Sentencias.
 Cobertura de decisiones.Cobertura de decisiones.
 Cobertura de Condiciones.Cobertura de Condiciones.
 Criterios de decisión/Condición.Criterios de decisión/Condición.
 Criterio de Condición Múltiple.Criterio de Condición Múltiple.
 Criterio de Cobertura de CaminosCriterio de Cobertura de Caminos
(impracticable)(impracticable)
Menos Riguroso
(Mas Barato)
Más Riguroso
(Más Caros)

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

19. Grafo de Flujo de un programaGrafo de Flujo de un programa
(Pseudocodigo)(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

20. Variantes de Prueba de Caja BlancaVariantes de Prueba de Caja Blanca
 a) Prueba del Camino Básico.a) Prueba del Camino Básico.
 b) Prueba de Condición.b) Prueba de Condición.
 c) Prueba de Flujo de Datos.c) Prueba de Flujo de Datos.
 d) Prueba de Bucles.d) Prueba de Bucles.

21. Prueba del camino BásicoPrueba del camino Básico
 Complejidad Ciclomatica(La complejidad deComplejidad Ciclomatica(La complejidad de
McCabe V (G))McCabe V (G))
– La métrica de McCabe ha sido muy popular enLa métrica de McCabe ha sido muy popular en
el diseño de pruebas.el diseño de pruebas.
– Es un indicador del número de caminosEs un indicador del número de caminos
independientes que existen en un grafo.independientes que existen en un grafo.

22. Formas de Calcular la ComplejidadFormas de Calcular la Complejidad
Ciclomática V(G)Ciclomática V(G)
 V (G) = a – n + 2V (G) = a – n + 2
 V (G) = rV (G) = r
 V (G) = c + 1V (G) = c + 1
DondeDonde
– a : # de arcos o aristas del grafo.a : # de arcos o aristas del grafo.
– n : # de nodos.n : # de nodos.
– r : # de regiones cerradas del grafo.r : # de regiones cerradas del grafo.
– c : # de nodos de condición.c : # de nodos de condición.

23. ¿¿Qué es lo que se logra con laQué es lo que se logra con la
complejidad ciclomática?complejidad ciclomática?
 V (G) marca el límite mínimo de casos deV (G) marca el límite mínimo de casos de
prueba para un programa.prueba para un programa.
 Cuando V (G) >10 la probabilidad deCuando V (G) >10 la probabilidad de
defectos en el módulo o programa crecedefectos en el módulo o programa crece
mucho entonces quizás sea interesantemucho entonces quizás sea interesante
dividir el módulo.dividir el módulo.

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

25. Prueba de CondiciónPrueba de Condición
 VentajasVentajas
• La cobertura de la prueba de una condición esLa cobertura de la prueba de una condición es
sencilla.sencilla.
• La cobertura de la prueba de las condiciones deLa cobertura de la prueba de las condiciones de
un programa da una orientación para generarun programa da una orientación para generar
pruebas adicionales del programa.pruebas adicionales del programa.

26. Estrategias de prueba deEstrategias de prueba de
CondicionesCondiciones
 Prueba de Ramificaciones.Prueba de Ramificaciones.
 Prueba de Dominio.Prueba de Dominio.
EE11<operador-relacional>E<operador-relacional>E22
Se necesitan 2Se necesitan 2nn
(n>0) pruebas como máximo(n>0) pruebas como máximo
para encontrar errores.para encontrar errores.

27. Prueba de flujo de datosPrueba de flujo de datos
 Esta técnica selecciona caminos de unEsta técnica selecciona caminos de un
programa de acuerdo a las definiciones yprograma de acuerdo a las definiciones y
uso de las variables.uso de las variables.
 El enfoque de prueba de flujo de datos esEl enfoque de prueba de flujo de datos es
efectivo para la protección contra errores.efectivo para la protección contra errores.

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

29. Pruebas de Caja Negra.Pruebas de Caja Negra.
 Intenta encontrar errores de las siguientesIntenta encontrar errores de las siguientes
categorías:categorías:
• Funciones Incorrectas o Ausentes.Funciones Incorrectas o Ausentes.
• Errores de Interfaz.Errores de Interfaz.
• Errores en estructuras de datos o acceso aErrores en estructuras de datos o acceso a
bases de datos externas.bases de datos externas.
• Errores de rendimiento.Errores de rendimiento.
• Errores de inicialización y terminación.Errores de inicialización y terminación.

30. Pruebas de Caja Negra.Pruebas de Caja Negra.
Variantes de pruebas de caja negra.Variantes de pruebas de caja negra.
• a) Métodos de prueba basados en grafos.a) Métodos de prueba basados en grafos.
• b) Partición Equivalente.b) Partición Equivalente.
• c) Análisis de valores límite.c) Análisis de valores límite.
• d) Prueba de Comparación.d) Prueba de Comparación.
• e) Conjetura de Errores.e) Conjetura de Errores.

31. Métodos de prueba basados enMétodos de prueba basados en
grafosgrafos
Pasos a seguir para una prueba de cajaPasos a seguir para una prueba de caja
Negra:Negra:
1.1. Entender los objetos que se van a modelar yEntender los objetos que se van a modelar y
las relaciones que conectan a estos.las relaciones que conectan a estos.
2.2. Definir una serie de pruebas que verifique queDefinir una serie de pruebas que verifique que
“todos los objetos tienen entre ellos la“todos los objetos tienen entre ellos la
relaciónes esperadas”relaciónes esperadas”

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

33. Partición equivalentePartición equivalente
Pasos para identificar casos de prueba.Pasos para identificar casos de prueba.
1.1. Asignar un número único para cada clase deAsignar un número único para cada clase de
equivalencia.equivalencia.
2.2. Escribir casos de pruebas para todas lasEscribir casos de pruebas para todas las
clases válidas.clases válidas.
3.3. Escribir casos de pruebas para todas lasEscribir casos de pruebas para todas las
clases no válidas.clases no válidas.

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

35. Análisis de valores limiteAnálisis de valores limite
Las reglas para identificar las clases son:Las reglas para identificar las clases son:
1.1. Si una condición de entrada especifica un rango queSi una condición de entrada especifica un rango que
deben generar casos para los extremos.deben generar casos para los extremos.
2.2. Si la condición de entrada especifica un número finitoSi la condición de entrada especifica un número finito
y consecutivo de valores, escribir casos para losy consecutivo de valores, escribir casos para los
números máximo, mínimo, uno más del máximo y unonúmeros máximo, mínimo, uno más del máximo y uno
menos del mínimo de valoresmenos del mínimo de valores
3.3. Usar la regla 1 para la condición de salida.Usar la regla 1 para la condición de salida.
4.4. Usar la regla 2 para cada condición de salida.Usar la regla 2 para cada condición de salida.

36. Prueba de ComparaciónPrueba de Comparación
 Se desarrollan versiones independientes deSe desarrollan versiones independientes de
una aplicación con las mismasuna aplicación con las mismas
especificaciones.especificaciones.
 Probar todas las versiones con los mismosProbar todas las versiones con los mismos
datos de prueba.datos de prueba.
 Luego se ejecutan las versiones en paraleloLuego se ejecutan las versiones en paralelo
y se hace una comparación en tiempo realy se hace una comparación en tiempo real
de los resultados.de los resultados.

37. Conjetura de ErroresConjetura de Errores
 Enumerar una lista de equivocaciones queEnumerar una lista de equivocaciones que
pueden cometer los desarrolladores.pueden cometer los desarrolladores.
 Generar casos de prueba en base a dichaGenerar casos de prueba en base a dicha
lista.lista.
 La generación de casos se obtiene en baseLa generación de casos se obtiene en base
a la intuición o la experiencia.a la intuición o la experiencia.

38. Pruebas AleatoriasPruebas Aleatorias
 Se simula los posibles datos de entrada enSe simula los posibles datos de entrada en
la secuencia y frecuencia que puedenla secuencia y frecuencia que pueden
aparecer en la practica.aparecer en la practica.
 Si el proceso de generación se ha realizadoSi el proceso de generación se ha realizado
correctamente, se crearán eventualmentecorrectamente, se crearán eventualmente
todas las posibles entradas del programatodas las posibles entradas del programa
en todas las posibles combinaciones yen todas las posibles combinaciones y
permutaciones.permutaciones.
 Baja probabilidad de encontrar errores.Baja probabilidad de encontrar errores.

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