Beruflich Dokumente
Kultur Dokumente
Ingeniería en Informática
Facultad de Informática
UPV/EHU
Departamento de Lenguajes
y Sistemas Informáticos
Tema 3.
Evaluación / Pruebas del Software
Índice
• Introducción
– Objetivos y principios de las pruebas
• Diseño de casos de prueba del software
– ¿Cuál debe ser el conjunto de casos de prueba
que tenga la mayor probabilidad de descubrir
defectos en el software?
• Estudio de técnicas de diseño de casos de prueba: caja
negra y caja blanca
• Las pruebas en el proceso unificado de
desarrollo de software
– ¿Cómo integrar las técnicas de diseño de casos
de prueba en una serie de pasos bien planificados
que obtienen una construcción correcta del
software?
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
4
Caso de prueba
• Es un conjunto de entradas de prueba,
condiciones de ejecución y resultados esperados
• Tiene un objetivo concreto (probar algo)
Procedimiento de prueba
• Pasos que hay que llevar a cabo para probar uno
(o varios) casos de prueba: ¿cómo probar el caso
de prueba y verificar si ha tenido éxito?
Ejemplo: Procedimiento de prueba para CP1
- Ejecutar la clase Presentacion
- Comprobar que en la BD “passwords.mdb”
existe la tupla <“hacker”,“hola”,x>
- Escribir “hacker”en la interfaz gráfica (en el
campo de texto etiquetado “Escribe nombre usuario”
- Escribir “kaixo”en la interfaz gráfica (en el campo de texto “Escribe password”)
- Pulsar botón “Acceder al sistema”
- Comprobar que no deja entrar al sistema y que en la BD la tupla ha cambiado a
<“hacker”,“hola”,x+1>
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
8
Componente de prueba
• Programa que automatiza la ejecución de uno (o varios) casos de prueba
• Una vez escrito, se puede probar muchas veces (cada vez que haya un
cambio en el código de una clase que pueda afectarle)
public class ComponentePruebaEntrSistema {
InterfaceLogicaNegocio ln; InterfaceOperacionesParaPruebas lp;
public static void main(String[] args) {
lp.aniadirUsuario(“hacker”,”hola”,3); // Crea usuario con pass y numInt.
boolean b = ln.hacerLogin(“hacker”,”kaixo”);
if (b) System.out.println(“Error CP1: Permite entrada”);
else { int j = lp.comprobarUsuario(“hacker”,”hola”); // Dev. Nº intentos
if (j!=4) System.out.println(“Error CP1: No incr.”);
else System.out.println(“CP1 correcto”);} // Fin caso prueba CP1
– Del camino básico: Diseñar un caso de prueba por cada camino indpte
Ejemplo: EsPrimo
El método
Esprimo.esPrimo
puede ser llamado
con un array de
Strings
OBJETIVO A PROBAR
ENTRADA
-Probar todos los caminos
-Probar todas las condiciones
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU -Probar bucles
14
Ejemplo: Componente de prueba
para EsPrimo
public class ComponentePruebaEsPrimo {
public static void main(String[] args) {
String[] s1 = new String[0];
try {boolean b1 = Esprimo.esPrimo(s1);
System.out.println(“CP1 incorrecto”);}
catch (ErrorFaltaParametro e)
{System.out.println(“CP1 correcto”);}
catch (Exception e) {System.out.println(“CP1 incorrecto”);}
String[] s2 = new String[2]; s2[0]=“xx”; s2[1]=“yy”;
try {boolean b1 = Esprimo.esPrimo(s2);
System.out.println(“CP2 incorrecto”);}
catch (ErrorSolo1Parametro e)
{System.out.println(“CP2 correcto”);}
catch (Exception e) {System.out.println(“CP2 incorrecto”);}
...}
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
15
Ejemplo: Componente de prueba
para EsPrimo (usando JUnit)
java junit.swingui.TestRunner PruebasConJUnit.ComponentePruebaEsPrimo
package PruebasConJUnit;
public class ComponentePruebaEsPrimo {
// Un método por cada caso de prueba
public void testPrimoSinPars() {
num = new String[0];
try {result= Esprimo.esPrimo(num);
assertTrue(false);}
catch (Exception e)
{assertTrue(e instanceof ErrorFaltaParametro);}
}
// RESTO DE CASOS DE PRUEBA...
}
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
16
OBJETIVO A PROBAR
ENTRADA
-Valores límite
Diseñar un caso de prueba de caja blanca, un caso de prueba de caja negra basado
en la partición equivalente, un caso de prueba de caja negra basado en los valores
límites y un caso de prueba de interfaz de usuario gráfica para el caso de uso
ENTRAR EN EL SISTEMA que se describe a continuación.
El flujo de eventos del caso de uso ENTRAR EN EL SISTEMA
-El usuario escribe su nombre y el password
-El sistema comprueba que existe una cuenta con ese nombre y password y, si es así, se le da
permiso para entrar en el sistema.
-Si existe el nombre de usuario pero el password es incorrecto permite reintroducir el
password hasta un máximo de tres veces.
Requisitos no funcionales del caso de uso ENTRAR EN EL SISTEMA
-El password no debe ser visible
-Los nombres de usuarios sólo pueden contener letras y como mínimo 5 letras.
Requisitos
Análisis
Diseño
Implementación
Prueba
Modelo de pruebas
* * *
X X
Caso de prueba Procedimiento Componente
de prueba de prueba
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
28
Modelo de pruebas
• Artefacto: caso de prueba
– Un caso de prueba especifica una forma de
probar el sistema, incluyendo la entrada y
salida con la que se ha de probar y las
condiciones bajo las que ha de probarse
• Artefacto: procedimiento de prueba
– Un procedimiento de prueba especifica cómo
realizar uno o varios casos de prueba
• Artefacto: componente de prueba
– Automatiza uno o varios procedimientos de
prueba o partes de ellos.
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
29
Actividad del flujo de trabajo de
Implementación
Prueba
• Actividad: planificar prueba
– Describir una estrategia de prueba, estimar los
requisitos y planificar el esfuerzo de la prueba
• Actividad: diseñar prueba
– identificar casos de prueba y procedimientos de
prueba
• diseñar casos de prueba de integración (para verificar que
los componentes interaccionan correctamente)
• diseñar la prueba del sistema (para verificar que el sistema
funciona correctamente como un todo)
• diseñar los casos de prueba de regresión
– Al añadir un nuevo módulo puede haber problemas con
módulos que antes iban bien. Las pruebas de regresión son un
conjunto de pruebas (ya realizadas antes) que aseguran que
los cambios no han dado lugar a cambios colaterales.
Componente Prueba
de Esprimo
no positivo
Casos de NUM primo
no primo
prueba
RESULTADO EsPrimo
CodPr NUM SalidaEsper SalReal ResPrueba
1 0 no positivo
2 1 primo El Componente Prueba de
3 2 primo Esprimo recorre la tabla
4 3 primo PRU_UNIDAD_ESPRIMO
5 4 no primo y llama al módulo Esprimo
6 23 primo con el valor de entrada
7 -4 no positivo NUM. El resultado obtenido
8 78298234 no primo lo escribe en SalReal y si es
9 -123412341234123 no positivo igual al valor de SalidaEsper
10 “patata” no positivo deja OK en ResPrueba, en
11 782.98234 no primo caso contrario deja ERROR
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU Tabla PRU_UNIDAD_ESPRIMO
33
SiguientePrimo
EsPrimo
SiguientePrimo SiguientePrimo
SE PRUEBA ASÍ
EsPrimo Resguardo de
EsPrimo
ORDEN EN EL QUE SE HACEN LAS PRUEBAS:
1º ) Prueba de Unidad de SiguientePrimo usando un Resguardo
de Esprimo
2º ) Prueba de Unidad de EsPrimo
3º ) Prueba de integración de SiguientePrimo con EsPrimo
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
37
Algoritmo: SiguientePrimo
Entrada: num (entero) SiguientePrimo
Salida: entero
Creación de un resguardo
Resguardo
Algoritmo: ResguardoEsPrimo de EsPrimo
Entrada: numEnt (entero)
Salida: String (“primo”, “no primo”, “no positivo”)
ResSQL := ejecutarBD(“Select SalidaEsper
from PRU_UNIDAD_ESPRIMO
where NUM = %numEnt”)
si fin (ResSQL) entonces devolver “no primo”
sino <SE> := siguiente(ResSQL)
devolver SE CodPr NUM SalidaEsper SalReal ResPrueba
fin si 1 0 no positivo
2 1 primo
3 2 primo
4 3 primo
.....................................................................
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU Tabla PRU_UNIDAD_ESPRIMO
40
Creación de un resguardo
Resguardo
de EsPrimo
package resguardo;
public class Esprimo {
public static boolean esPrimo(String args[]) throw …
if (args[0].equals(“0”)) throw new ErrorNoNumeroPositivo();
else if (args[0].equals(“1”)) return true;
else if (args[0].equals(“2”)) return true;
else if (args[0].equals(“3”)) return true;
...
return false; }}
Bibliografía
Solución
Solución
Diseñar un caso de prueba de caja blanca, un caso de prueba de caja negra basado
en la partición equivalente, un caso de prueba de caja negra basado en los valores
límites y un caso de prueba de interfaz de usuario gráfica para el caso de uso
ENTRAR EN EL SISTEMA que se describe a continuación.
El flujo de eventos del caso de uso ENTRAR EN EL SISTEMA
-El usuario escribe su nombre y el password
-El sistema comprueba que existe una cuenta con ese nombre y password y, si es así, se le da
permiso para entrar en el sistema.
-Si existe el nombre de usuario pero el password es incorrecto permite reintroducir el
password hasta un máximo de tres veces.
Requisitos no funcionales del caso de uso ENTRAR EN EL SISTEMA
-El password no debe ser visible
-Los nombres de usuarios sólo pueden contener letras y como mínimo 5 letras.
Solución al ejercicio
Caso de prueba de caja blanca:
No se puede ya que el código fuente no está accesible.
Caso de prueba de caja negra basado en la partición equivalente
1) Entrada: usuario “pepita” password: “e445dr” Salida: dar paso (usuario y
password válidos; suponiendo que se encuentran en la BD)
2) Entrada: usuario “pepita2” password “e445dr” Salida: no dar paso (usuario
no válido por contener caracteres “no letras” y más de 5)
3) Entrada: usuario “pepi” password “e445dr” Salida: no dar paso (usuario no
válido por contener menos de 5 letras)
4) Entrada: usuario “pep3” password “e445dr” Salida: no dar paso (usuario no
válido por contener menos de 5 letras, y algunas no ser letras)
5) Entrada: usuario “” password “e445dr” Salida: no dar paso (usuario “en
blanco”)
6) Entrada: usuario “3432432” password “e445dr” Salida: no dar paso
(usuario no válido por no contener ni una sola letra, aunque sí más de 5
caracteres)
7) Entrada: usuario “pepita” password: “” Salida: no dar paso (usuario válido
pero password no, suponiendo que se encuentra en la BD)
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
48
Solución al ejercicio
Caso de prueba de caja negra basado en los valores límite
1) Entrada: usuario “pepita” password: “malPassw” Salida: no obtener paso
intentar otra vez: usuario “pepita” password: “malPassw” Salida: no obtener paso
intentar otra vez: usuario “pepita” password: “malPassw”
Salida: no obtener paso y comprobar que se bloquea // Intenta 4 veces
(suponiendo usuario válido pero password incorrecto)
2) Entrada: usuario “pepita” password: “malPassw” Salida: no obtener paso
intentar otra vez: usuario “pepita” password: “malPassw” Salida: no obtener paso
intentar otra vez: usuario “pepita” password: “e445dr”
Salida: obtener paso // Intenta 3 veces
(suponiendo usuario válido pero password incorrecto)
3) Entrada: usuario “pepito” password: “malPassw” => no obtener paso
intentar otra vez: usuario “pepito” password: “malPassw” => no obtener paso
intentar otra vez: usuario “pepito” password: “malPassw”
Salida: no obtener paso pero comprobar que no se bloquea // Intenta 3 veces
(suponiendo tanto usuario como password incorrectos)
4) Entrada: usuario “pepita” password: “malPassw” => no obtener paso
intentar otra vez: usuario “pepita” password: “e445dr”
Salida: obtener paso // Intenta 2 veces
(suponiendo usuario “pepita” válido y password “e445dr” válido)
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
49
Solución al ejercicio
Solución al ejercicio
Caso de prueba de caja blanca:
No se puede ya que el código fuente no está accesible.
Caso de prueba de caja negra basado en la partición equivalente
1) Entrada: usuario “pepita” password: “e445dr” Salida: dar paso (usuario y password válidos; suponiendo que se encuentran en la BD)
2) Entrada: usuario “pepita2” password “e445dr” Salida: no dar paso (usuario no válido por contener caracteres “no letras” y más de 5)
3) Entrada: usuario “pepi” password “e445dr” Salida: no dar paso (usuario no válido por contener menos de 5 letras)
4) Entrada: usuario “pep3” password “e445dr” Salida: no dar paso (usuario no válido por contener menos de 5 letras, y algunas no ser letras)
5) Entrada: usuario “” password “e445dr” Salida: no dar paso (usuario “en blanco”)
6) Entrada: usuario “3432432” password “e445dr” Salida: no dar paso (usuario no válido por no contener ni una sola letra, aunque sí más de 5 caracteres)
7) Entrada: usuario “pepita” password: “” Salida: no dar paso (usuario válido pero password no, suponiendo que se encuentra en la BD)
Caso de prueba de caja negra basado en los valores límite
1) Entrada: usuario “pepita” password: “malPassw” Salida: no obtener paso
intentar otra vez: usuario “pepita” password: “malPassw” Salida: no obtener paso
intentar otra vez: usuario “pepita” password: “malPassw”
Salida: no obtener paso y comprobar que se bloquea // Intenta 4 veces
(suponiendo usuario válido pero password incorrecto)
2) Entrada: usuario “pepita” password: “malPassw” Salida: no obtener paso
intentar otra vez: usuario “pepita” password: “malPassw” Salida: no obtener paso
intentar otra vez: usuario “pepita” password: “e445dr”
Salida: obtener paso // Intenta 3 veces
(suponiendo usuario válido pero password incorrecto)
3) Entrada: usuario “pepito” password: “malPassw” => no obtener paso
intentar otra vez: usuario “pepito” password: “malPassw” => no obtener paso
intentar otra vez: usuario “pepito” password: “malPassw”
Salida: no obtener paso pero comprobar que no se bloquea // Intenta 3 veces
(suponiendo tanto usuario como password incorrectos)
4) Entrada: usuario “pepita” password: “malPassw” => no obtener paso
intentar otra vez: usuario “pepita” password: “e445dr”
Salida: obtener paso // Intenta 2 veces
(suponiendo usuario “pepita” válido y password “e445dr” válido)
Caso de prueba de interfaz gráfica de usuario:
1) Entrada: usuario “pepita” password: “malPassw” Salida: comprobar passw. NO visible
2) Entrada: pulsar botón “acceder al sistema” Salida: comprobar que “responde”
3) Entrada: pulsar icono “minimizar ventana” Salida: comprobar que se minimiza
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
52
Solución al ejercicio
Caso de prueba de caja blanca:
No se puede ya que el código fuente no está accesible.
Caso de prueba de caja negra basado en la partición equivalente
1) Entrada: usuario “pepita” password: “e445dr” Salida: dar paso (usuario y
password válidos; suponiendo que se encuentran en la BD)
2) Entrada: usuario “pepita2” password “e445dr” Salida: no dar paso (usuario
no válido por contener caracteres “no letras” y más de 5)
3) Entrada: usuario “pepi” password “e445dr” Salida: no dar paso (usuario no
válido por contener menos de 5 letras)
4) Entrada: usuario “pep3” password “e445dr” Salida: no dar paso (usuario no
válido por contener menos de 5 letras, y algunas no ser letras)
5) Entrada: usuario “” password “e445dr” Salida: no dar paso (usuario “en
blanco”)
6) Entrada: usuario “3432432” password “e445dr” Salida: no dar paso
(usuario no válido por no contener ni una sola letra, aunque sí más de 5
caracteres)
7) Entrada: usuario “pepita” password: “” Salida: no dar paso (usuario válido
pero password no, suponiendo que se encuentra en la BD)
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
53
Solución al ejercicio
Caso de prueba de caja negra basado en los valores límite
1) Entrada: usuario “pepita” password: “malPassw” Salida: no obtener paso
intentar otra vez: usuario “pepita” password: “malPassw” Salida: no obtener paso
intentar otra vez: usuario “pepita” password: “malPassw”
Salida: no obtener paso y comprobar que se bloquea // Intenta 4 veces
(suponiendo usuario válido pero password incorrecto)
2) Entrada: usuario “pepita” password: “malPassw” Salida: no obtener paso
intentar otra vez: usuario “pepita” password: “malPassw” Salida: no obtener paso
intentar otra vez: usuario “pepita” password: “e445dr”
Salida: obtener paso // Intenta 3 veces
(suponiendo usuario válido pero password incorrecto)
3) Entrada: usuario “pepito” password: “malPassw” => no obtener paso
intentar otra vez: usuario “pepito” password: “malPassw” => no obtener paso
intentar otra vez: usuario “pepito” password: “malPassw”
Salida: no obtener paso pero comprobar que no se bloquea // Intenta 3 veces
(suponiendo tanto usuario como password incorrectos)
4) Entrada: usuario “pepita” password: “malPassw” => no obtener paso
intentar otra vez: usuario “pepita” password: “e445dr”
Salida: obtener paso // Intenta 2 veces
(suponiendo usuario “pepita” válido y password “e445dr” válido)
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
54
Solución al ejercicio
9 8
devolver “primo” devolver “no primo”
V(G) = 5 FIN
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU 10
56
Algoritmo Esprimo
• CP 1) Entrada: 1 Salida: “primo”
• CP 2) Entrada: 2 Salida: “primo”
• CP 3) Entrada: 4 Salida “no primo”
– es el primer no primo
• CP 4) Entrada: 32342342342341234 Salida: “no
primo”
– número muy grande (mayor que el máximo entero)
• CP 5) Entrada: 0 Salida: “no positivo”
• CP 6) Entrada: -4Salida: “no positivo”
• CP 7:) Entrada: -123412341234123 Salida: “no
positivo”
• CP 8) Entrada: “patata” Salida: “no positivo”
• CP 9) Entrada: 782.98234 Salida: “no primo”
– debe tomar 782 como el número de entrada
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
57
Algoritmo Esprimo
• CP 1) Entrada: 0 Salida: “no positivo”
si num <= 0 entonces
devolver “no positivo”
• CP 2) Entrada: 2 Salida: “primo”
para i de 2 a num - 1 hacer (para que no entre)
si primo entonces devolver “primo” (que entre)
• CP 3) Entrada: 3 Salida: “primo”
para i de 2 a num - 1 hacer (ejecutar 1 vez)
• CP 4) Entrada: 4 Salida: “no primo”
para i de 2 a num - 1 hacer
si num resto i = 0 entonces (para que entre)
si no devolver “no primo” (para que entre)
Prueba de bucles
Prueba de bucles
Prueba de bucles
Prueba de bucles
• Por supuesto, no hay por qué considerar el
siguiente bucle como no estructurado:
repetir
acción1
si cond1 entonces salir
acción2
hasta cond2
Algoritmo: Esprimo
Entrada: num (entero)
Salida: String (“no positivo”, “primo”, “no primo”)
“es primo”
entero Esprimo
“no primo”
“no positivo”
Introducción
Requisitos R
Diseño D
Codificación C
U Prueba de unidad
Prueba de integración
I
V Prueba de validación
ST Prueba del sistema
Prueba de unidad
módulos.
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
71
Prueba de unidad
Interfaz
Módulo
Condiciones límite
Caminos independientes
Caminos de manejo de errores
Casos de
prueba
Prueba de unidad
Interfaz
Condiciones límite
Caminos independientes
Controlador
Caminos de manejo de errores
Módulo que
se va a probar
RESULTADOS
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
73
Prueba de integración
Integración
descendente
M1
M2 M3 M4
M5 M6 M7
M8
Prueba de integración
Resguardos
Prueba de integración
Integración Mc
ascendente
Ma Mb
D1 D2 D3
Grupo 3
Grupo 1
Grupo 2
Prueba de integración
Controladores
Y B
A
Prueba de integración
• Prueba de regresión:
– Al añadir un nuevo módulo el software
cambia y se establecen nuevos caminos
de flujo de datos, nueva E/S y nueva lógica
de control.
– Puede haber problemas con funciones que
antes iban bien.
– Se ejecutarán un conjunto de pruebas que
se han realizado anteriormente para
asegurarse que los cambios no han dado
lugar cambios colaterales.
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
78
Prueba de validación
Depuración de errores
Ejecución de casos
Pruebas
Casos de adicionales Causas Resultados
prueba sospechadas
Pruebas de regresión
Depuración
Correcciones Causas
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU identificadas