ingeniería en informática facultad de informática …siul02.si.ehu.es/~alfredo/iso/tema3.pdf ·...
TRANSCRIPT
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
1
INGENIERÍA del SOFTWARECurso 2006/07
Ingeniería en InformáticaFacultad de Informática
UPV/EHU
Departamento de Lenguajes y Sistemas Informáticos
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
2
Tema 3. Evaluación / Pruebas del Software
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
3
Í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 descubrirdefectos en el software?
• Estudio de técnicas de diseño de casos de prueba: cajanegra 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 planificadosque obtienen una construcción correcta del software?
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
4
Introducción. Objetivos de una prueba
• La prueba es un proceso de ejecución con la intención de descubrir errores.
• Un buen caso de prueba es aquel que tiene una probabilidad muy alta de descubrir un nuevo error.
• Un caso de prueba no debe ser redundante.• Debe ser el mejor de un conjunto de pruebas de propósito
similar.• No debe ser ni muy sencillo ni excesivamente complejo: es mejor
realizar cada prueba de forma separada si se quiere probar diferentes casos.
• Una prueba tiene éxito si descubre un nuevo error• Lo que no hace una prueba…
Una prueba no asegura la ausencia de defectos, sólo puede demostrar que existen errores en el software.
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
5
Introducción. Principios de las pruebas
• Se debe hacer un seguimiento hasta ver si se cumplen los requisitos del cliente.
• Las pruebas deberán planificarse mucho antes de que empiecen.
• El principio de Pareto es aplicable a la prueba del software.– El 80% de los errores está en el 20% de los módulos.– Hay que identificar esos módulos y probarlos muy bien
• Empezar por lo pequeño y progresar hacia lo grande.• No son posibles las pruebas exhaustivas.• Son más eficientes las pruebas dirigidas por un equipo
independiente.
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
6
Caso de prueba
• Es un conjunto de entradas de prueba, condiciones de ejecución y resultados esperados
• Tiene un objetivo concreto (probar algo)
Ejemplo: CASO de PRUEBA CP1 para CASO de USO “Entrada Sistema”
ENTRADA: usuario “hacker” password “kaixo”
CONDICIONES DE EJECUCIÓN: no existe en la tabla CUENTA(usuario,pass,intentos) la tupla<“hacker”, “kaixo”,x> pero sí una tupla <“hacker”,“hola”,x>
RESULTADO ESPERADO: no deja entrar y cambia la tupla a <“hacker”,“hola”,x+1>
Objetivo del caso de prueba: comprobar que no deja entrar a un usuario existente con un password equivocado.
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
7
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
NOTA: se necesitarán otros métodos como comprobarUsuario,aniadirUsuarioque pueden pertenecer a la lógica del negocio o no (en este caso se considera que no)
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
9
¿Cómo escribir componentes de prueba?
• Se puede escribir “ad hoc”– Por cada caso de prueba, se escribe el
código correspondiente en el componente (cambiaría el código)
– Se escribe el código del componente de tal manera que recorra en una BD los casos de prueba y los ejecute.
• Cada vez que se añada un caso de prueba, simplemente se añade en la BD, pero el código del componente no cambiaría
• Se pueden usar entornos de trabajo disponibles para pruebas– Ejemplo: JUnit para Java
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
10
Diseño de casos de prueba.
• Definir los casos de prueba que tengan la mayor
probabilidad de encontrar el mayor número de errores
con la mínima cantidad de esfuerzo y tiempo.
– Pruebas de caja blanca
• Encontrar casos de prueba “viendo” el código
interno
– Pruebas de caja negra
• Encontrar casos de prueba “viendo” los
requisitos funcionales
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
11
Pruebas de Caja Blanca: “viendo” el código interno
• Aseguran que la operación interna del programa se ajusta a las especificaciones y que todos los componentes internos se han probado adecuadamente.– Usa la estructura de control para obtener los casos de prueba.
– Intentan garantizar que todos los caminos de ejecución del programa quedan probados.
• Pruebas de estructura de control:
– Del camino básico: Diseñar un caso de prueba por cada camino indpte
– De condición: Diseñar casos de prueba para que todas las condiciones
del programa se evalúen a cierto/falso
– De bucles: Diseñar casos de prueba para que se intente ejecutar un
bucle 0,1,…,n-1,n y n+1 veces (siendo n el número máximo)
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
12
Ejemplo: EsPrimo
El método Esprimo.esPrimopuede ser llamado
con un array de Strings
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
13
Ejemplo: casos de prueba de caja blanca para EsPrimo
ENTRADAOBJETIVO A PROBAR
-Probar todos los caminos
-Probar todas las condiciones
-Probar bucles
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
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)
package PruebasConJUnit;
public class ComponentePruebaEsPrimo {// Un método por cada caso de pruebapublic 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...}
java junit.swingui.TestRunner PruebasConJUnit.ComponentePruebaEsPrimo
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
16
Pruebas de Caja Negra
• Se centra en los requisitos funcionales del software.
• Permite obtener un conjunto de condiciones de entrada que ejerciten completamente los requisitos funcionales del programa.
• No es una alternativa a la prueba de caja blanca. – Complementan a las pruebas de caja blancaMejor diseñar los casos de prueba usando los dos tipos de técnicas
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
17
Prueba de Caja Negra
• Prueba de los valores límite– Los errores suelen situarse en los límites.– Si la entrada se encuentra en el rango a..b
entonces hay que probar con los valores a -1, a, a + 1, b - 1, b y b + 1
– Si la entrada es un conjunto de valores entonces hay que probar con los valores max-1, max, max+1, min-1, min y min+1
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
18
Ejemplo: casos de prueba de caja negra para EsPrimo
ENTRADAOBJETIVO A PROBAR
-Valores límite
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
19
Prueba de Caja Negra
• Prueba de la partición equivalente– Método de prueba de caja negra que divide el dominio de
entrada de un programa en un conjunto de clases de datos de los que se pueden derivar casos de prueba
– Si la entrada es un código formado por 2 partes, la primera un prefijo opcional de 3 dígitos, que empiece por 9 y la contraseña que sea una cadena de hasta 6 caracteres que empiece necesariamente por una letra y que puede contener letras, dígitos y el símbolo $
⇒ Se pueden diseñar casos de prueba, cada uno de los cuales representa a un conjunto de casos de prueba
prefijo contraseña
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
20
Prueba de Caja Negra• prefijo puede ser
– “ ” representa a entrada en blanco– “743” representa a número <900– “935” representa a número entre 900 y 999– “1983” representa a número >999– “8pW” representa a cadena que contiene carácter no dígito
• contraseña puede ser– “ ” representa a entrada en blanco– “4a2cd$” representa a cadena que empieza por dígito y que sólo
contiene letras, dígitos y $– “4a;2c$” representa a cadena que empieza por dígito y que
contiene algún carácter no letra, dígito o $– “$ab4$b” representa a cadena que no empieza por dígito y
que sólo contiene letras, dígitos y $– “b$$;a5” representa a cadena que no empieza por dígito y que
contiene algún carácter no letra, dígito o $
prefijo contraseña
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
21
Ejemplo: casos de prueba de caja negra para EsPrimo
Los siguientes casos de prueba (que ya estaban) también salen aplicando el criterio “partición equivalente”
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
22
Pruebas en entornos y aplicaciones especializadas
• Pruebas de interfaces gráficas de usuario– Pruebas sobre ventanas.– Pruebas sobre menús y uso del
ratón.– Pruebas de entrada de datos.
• Pruebas de documentación y de ayuda.
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
23
Ejemplo: casos de prueba de negra para EsPrimo
-Al cerrar (minimizar,..) la ventana se cierra (minimiza,…)
-Al pulsar el botón, aparece en el campo de texto el resultado
-Buscar ayuda de cómo utilizar la interfaz
Ejemplos de CASOS de PRUEBA
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
24
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.
Ejercicio
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
25
Ejercicio: Escribir componente de prueba, que pruebe el siguiente CP
Caso de prueba CP2Entrada: usuario “correcto” password “acertado”Condiciones de ejecución: en la tabla existe ese usuario con ese password y con 1 intento fallido anterior (número inferior a 3)Resultado esperado: dar paso y el número de intentos en la tabla USUARIO(cuenta,passord,numIntentos) para “correcto” es 0
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
26
Pruebas en el proceso unificado
• Objetivos: Planificar // Diseñar e implementar // Realizar las pruebas
Requisitos
Diseño
Implementación
Prueba
Análisis
ite r.# 1
ite r.# 2
ite r.# n
ite r.#n+ 1
ite r.# n+2
iter.#m
ite r.#m +1
Inicio Elaboración Construcción Transición
Iteraciones:
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
27
Modelo de pruebas
X X
Modelo de pruebas Sistema de pruebas
Caso de prueba Procedimientode prueba
Componentede prueba
1
* * *
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
• Actividad: realizar prueba de unidad– Probar componentes implementados como
unidades individuales– prueba de especificación (de caja negra)
que verifica el comportamiento observable externamente
– prueba de estructura (de caja blanca) que verifica la implementación interna
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
30Actividades del flujo de trabajo de 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.
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
31
Actividades del FT de Prueba
• Actividad: implementar prueba– Automatizar los procedimientos de prueba, creando componentes
de prueba, si es posible.
• Actividad: realizar pruebas de integración– Realizar las pruebas, comparar con los resultados esperados e
informar de los defectos
• Actividad: realizar prueba de sistema– Se comienzan después de las de integración y se realizan de
manera análoga (realizar, comparar e informar)
• Actividad: evaluar prueba– Se comparan los resultados de las pruebas con los objetivos
esbozados en el plan de prueba. Hay que preparar métricas que permitan determinar el nivel de calidad del software y la cantidad de pruebas a realizar.
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
32
Prueba de unidad de EsPrimo
Casos deprueba
Componente Pruebade Esprimo
EsPrimoRESULTADO
CodPr NUM SalidaEsper SalReal ResPrueba1 0 no positivo2 1 primo3 2 primo4 3 primo5 4 no primo6 23 primo7 -4 no positivo8 78298234 no primo9 -123412341234123 no positivo10 “patata” no positivo11 782.98234 no primo
NUM
Tabla PRU_UNIDAD_ESPRIMO
El Componente Prueba de Esprimo recorre la tabla PRU_UNIDAD_ESPRIMO y llama al módulo Esprimocon el valor de entrada NUM. El resultado obtenido lo escribe en SalReal y si es igual al valor de SalidaEsperdeja OK en ResPrueba, en caso contrario deja ERROR
no positivoprimo
no primo
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
33
Prueba de unidad de EsPrimoComponente Prueba
de EsPrimoAlgoritmo: ComponentePruebaEsPrimoResSQL := ejecutarBD(“Select CodPr, NUM, SalidaEsper
from PRU_UNIDAD_ESPRIMO”)mientras no fin (ResSQL) hacer
<CP,N,SE> := siguiente(ResSQL)ResEsPrimo := EsPrimo(N)si ResEsPrimo = SE entonces Prueba := “OK”sino Prueba := “ERROR”ejecutarBD(“Update PRU_UNIDAD_ESPRIMO
Set ResPrueba = %Prueba,SalReal = %ResEsPrimo
where CodPr= %CP”)
CodPr NUM SalidaEsper SalReal ResPruebaTabla PRU_UNIDAD_ESPRIMO
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
34
EsPrimo
SiguientePrimoAlgoritmo: SiguientePrimoEntrada: num (entero)Salida: entero
si num <= 0 entonces devolver 1
si no sig := num + 1mientras EsPrimo(sig) ≠ “primo” hacer
sig := sig + 1fin mientrasdevolver sig
finsi
Prueba de unidad de SiguientePrimo
0 1
1 2
2 3
4 5
18 19
17 19
patata no número
17.356 19
....
Tabla PRU_UNIDAD_SIGUIENTEPRIMO
PROBLEMA: si hay errores, ¿cómo saber a qué módulo corresponden?
SiguientePrimo o EsPrimo
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
35
EsPrimo
SiguientePrimo
Prueba de integración ascendente de SiguientePrimo y EsPrimo
ORDEN EN EL QUE SE HACEN LAS PRUEBAS:1º ) Prueba de Unidad de EsPrimo2º ) Prueba de Unidad de SiguientePrimo donde se supone que el módulo EsPrimo ya no contiene errores(en este caso coincide con la prueba de integración de ambos)
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
36
EsPrimo
SiguientePrimo
Prueba de integración descendente de SiguientePrimo y EsPrimo(o cómo probar SiguientePrimo si EsPrimo no está disponible)
ORDEN EN EL QUE SE HACEN LAS PRUEBAS:1º ) Prueba de Unidad de SiguientePrimo usando un Resguardo de Esprimo2º ) Prueba de Unidad de EsPrimo3º ) Prueba de integración de SiguientePrimo con EsPrimo
Resguardo deEsPrimo
SiguientePrimo
SE PRUEBA ASÍ
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
37
Prueba de integración descendente de SiguientePrimo y EsPrimo(o cómo probar SiguientePrimo si EsPrimo no está disponible)
Resguardo deEsPrimo
SiguientePrimoAlgoritmo: SiguientePrimoEntrada: num (entero)Salida: entero
si num <= 0 entonces devolver 1
si no sig := num + 1mientras EsPrimo(sig) ≠ “primo” hacer
sig := sig + 1fin mientrasdevolver sig
finsiCodPr NUM SalidaEsper SalReal ResPrueba
Tabla PRU_UNIDAD_ESPRIMO
SE LLAMA AL Resguardo de EsPrimo
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
38
Prueba de unidad de SiguientePrimo
Resguardode EsPrimoAlgoritmo: ResguardoEsPrimo
Entrada: numEnt (entero)Salida: String (“primo”, “no primo”, “no positivo”)ResSQL := ejecutarBD(“Select SalidaEsper
from PRU_UNIDAD_ESPRIMOwhere NUM = %numEnt”)
si fin (ResSQL) entonces devolver “no primo”sino <SE> := siguiente(ResSQL)
devolver SEfin si
CodPr NUM SalidaEsper SalReal ResPrueba1 0 no positivo2 1 primo3 2 primo4 3 primo.....................................................................
Tabla PRU_UNIDAD_ESPRIMO
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
39
Creación de un resguardo
Resguardode EsPrimoAlgoritmo: ResguardoEsPrimo
Entrada: numEnt (entero)Salida: String (“primo”, “no primo”, “no positivo”)ResSQL := ejecutarBD(“Select SalidaEsper
from PRU_UNIDAD_ESPRIMOwhere NUM = %numEnt”)
si fin (ResSQL) entonces devolver “no primo”sino <SE> := siguiente(ResSQL)
devolver SEfin si
CodPr NUM SalidaEsper SalReal ResPrueba1 0 no positivo2 1 primo3 2 primo4 3 primo.....................................................................
Tabla PRU_UNIDAD_ESPRIMO
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
40
Creación de un resguardo
Resguardode 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; }}
CodPr NUM SalidaEsper SalReal ResPrueba1 0 no positivo2 1 primo3 2 primo4 3 primo.....................................................................
Tabla PRU_UNIDAD_ESPRIMO
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
41
Bibliografía
• Ingeniería del Software. Un enfoquepráctico (5ª edición)– Roger S. Pressman– Editorial Mc. Graw Hill, 2001– Capítulos 17 y 18
• El proceso unificado de desarrollo de software– Jacobson, Booch, Rumbaugh– Editorial Addison Wesley, 1999– Capítulo 11
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
42
Ejercicio: Escribir componente de prueba, que pruebe el siguiente CP
Caso de prueba CP2Entrada: usuario “correcto” password “acertado”Condiciones de ejecución: en la tabla existe ese usuario con ese password y con 1 intento fallido anterior (número inferior a 3)Resultado esperado: dar paso y el número de intentos en la tabla USUARIO(cuenta,passord,numIntentos) para “correcto” es 0
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
43
Solución
public class ComponentePruebaEntrSistema {InterfaceLogicaNegocio ln; OperacionesParaPruebas lp;public static void main(String[] args) {
// Obtener lógica negocio y operaciones para pruebas
// CP2: usuario y passwords correctos, nº intentos no superadolp.aniadirUsuario(“correcto”,“acertado”,1); boolean b = ln.hacerLogin(“correcto”,“acertado”);if (!b) System.out.println(“Error CP2: No permite entrada”);else {int j = lp.comprobarUsuario(“correcto”,“acertado”);
// Dev. Nº intentosif (j!=0) System.out.println(“Error CP2: No puesto a 0.”);else System.out.println(“CP2 correcto”);}
}
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
44
Caso de prueba CP3Entrada: usuario “correcto” password “acertado”Condiciones de ejecución: en la tabla existe ese usuario con ese password y con 4 intentos fallidos (número superior a 3)Resultado esperado: no dar paso y el número de intentos en la tabla USUARIO(cuenta,passord,numIntentos) para “correcto” es 5
Ejercicio: Escribir componente de prueba, que pruebe el siguiente CP
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
45
Solución
public class ComponentePruebaEntrSistema {InterfaceLogicaNegocio ln; OperacionesParaPruebas lp;public static void main(String[] args) {
// Obtener lógica negocio y operaciones para pruebas
// CP3: usuario y passwords correctos, nº intentos superadolp.aniadirUsuario(“correcto”,“acertado”,4); boolean b = ln.hacerLogin(“correcto”,“acertado”);if (b) System.out.println(“Error CP3: Permite entrada”);else {int j = lp.comprobarUsuario(“correcto”,“acertado”);
// Dev. Nº intentosif (j!=5) System.out.println(“Error CP3: No incrementa.”);else System.out.println(“CP3 correcto”);}
}
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
46
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.
Ejercicio
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
47
Solución al ejercicioCaso 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 equivalente1) 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 ejercicioCaso de prueba de caja negra basado en los valores límite1) Entrada: usuario “pepita” password: “malPassw” Salida: no obtener paso
intentar otra vez: usuario “pepita” password: “malPassw” Salida: no obtener pasointentar 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 pasointentar otra vez: usuario “pepita” password: “malPassw” Salida: no obtener pasointentar 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 pasointentar otra vez: usuario “pepito” password: “malPassw” => no obtener pasointentar 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 pasointentar 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
Caso de prueba de interfaz gráfica de usuario:1) Entrada: usuario “pepita” password: “malPassw” Salida: comprobar passw. NO visible2) 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
50
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
51
Solución al ejercicioCaso 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 equivalente1) 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ímite1) Entrada: usuario “pepita” password: “malPassw” Salida: no obtener paso
intentar otra vez: usuario “pepita” password: “malPassw” Salida: no obtener pasointentar 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 pasointentar otra vez: usuario “pepita” password: “malPassw” Salida: no obtener pasointentar 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 pasointentar otra vez: usuario “pepito” password: “malPassw” => no obtener pasointentar 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 pasointentar 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 visible2) 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 ejercicioCaso 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 equivalente1) 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 ejercicioCaso de prueba de caja negra basado en los valores límite1) Entrada: usuario “pepita” password: “malPassw” Salida: no obtener paso
intentar otra vez: usuario “pepita” password: “malPassw” Salida: no obtener pasointentar 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 pasointentar otra vez: usuario “pepita” password: “malPassw” Salida: no obtener pasointentar 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 pasointentar otra vez: usuario “pepito” password: “malPassw” => no obtener pasointentar 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 pasointentar 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
Caso de prueba de interfaz gráfica de usuario:1) Entrada: usuario “pepita” password: “malPassw” Salida: comprobar passw. NO visible2) 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
55
Ejercicio Esprimo (camino básico)num<= 0
primo:=truei:=2 devolver “no positivo”
i<= num-1num resto i = 0
i:=i+1
primo:=falseprimo
devolver “primo” devolver “no primo”
FIN
1
23
4
5
67
89
10
1-3-10
1-2-4-7-8-10
1-2-4-7-9-10
1-2-4-5-6-7-9-10
1-2-4-5-6-7-8-10
1-2-4-5-4-5-4-7-9-10
V(G) = 5
1-2-4-5-4-5-4-5-7-9-10
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
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
57Algoritmo 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)
• CP 5) Entrada: 23 Salida: “no primo”para i de 2 a num - 1 hacer
si num resto i = 0 entonces (para que NO entre)
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
58
Prueba del camino básico
Construcciones estructurales en forma de grafo de flujo:
Secuencia Condición IF Bucle (While) Bucle (Hasta) Sentencia case
NODO: representa condición o sentencia procedimentalARISTA: representa flujo de control
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
59
Prueba de bucles
Buclessimples
Buclesanidados
Bucles concatenados
Bucles noestructurados
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
60
Prueba de bucles
• Prueba de bucles simples– Diseñar casos de prueba para que se ejecute el bucle: 0, 1, 2,
m, n-1, n y n+1 veces (siendo n el nº máximo de veces que se puede ejecutar el bucle y m<n)
• Prueba de bucles anidados– Si cada bucle se probara como bucle simple aumentaría mucho
el número de casos de prueba– Probar el bucle más interno como un bucle simple (0, 1, 2, m, n-
1, n y n+1 veces) entrando en todos los bucles externos el número mínimo de veces (1)
– Ir hacia fuera probando cada bucle externo como un bucle simple y dejando que sus bucles internos se ejecuten m veces (valor típico) y que sus bucles externos se ejecuten 1 vez (valor mínimo)
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
61
Prueba de bucles
• Prueba de bucles concatenados– En este caso puede ocurrir que el segundo bucle
se ejecute un número de veces que depende del primero.
– Si son bucles independientes entonces se prueban como dos bucles simples, y si no lo son, entonces se prueban como bucles anidados
• Prueba de bucles no estructurados– En este caso, merece la pena transformar el
código de entrada usando bucles estructurados y hacer las pruebas correspondientes
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
62
Prueba de bucles• Por supuesto, no hay por qué considerar el
siguiente bucle como no estructurado:
• Se puede probar para que se ejecute 0, 1, 2, m, n-1, n y n+1 combinando las 2 condiciones de salida (cond1 y cond2)
repetiracción1si cond1 entonces saliracción2
hasta cond2
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
63
Prueba de Caja Negra
• Tipos de errores que se encuentran:– Funciones incorrectas o ausentes.– Errores de interfaz.– Errores de estructuras de datos o en
accesos a bases de datos externas.– Errores de rendimiento.– Errores de inicialización o de terminación.
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
64Ejemplo: Algoritmo EsprimoAlgoritmo: EsprimoEntrada: num (entero)Salida: String (“no positivo”, “primo”, “no primo”)
si num <= 0 entonces devolver “no positivo”
si no primo := truepara i de 2 a num - 1 hacer
si num resto i = 0 entonces primo := falsesalir del bucle
fin sifin parasi primo entonces devolver “primo”si no devolver “no primo”fin si
fin si
DISEÑAR CASOS DE PRUEBA DE CAJA BLANCA
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
65
Ejemplo: Algoritmo Esprimo
Esprimoentero“es primo”
“no primo”
“no positivo”
DISEÑAR CASOS DE PRUEBA DE CAJA NEGRA
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
66
Ejemplo: Algoritmo Esprimo
DISEÑAR CASOS DE PRUEBA DE LA INTERFAZ
Y DE LA DOCUMENTACIÓN
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
67
Ejercicio: Tomar en Préstamo la Copia de un Libro
DISEÑAR LOS CASOS DE PRUEBA DE ESTE CASO DE USO
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
68
Introducción
• Las pruebas del software son un elemento crítico
para la garantía de calidad del software y representa
una revisión final de las especificaciones, del diseño
y de la codificación.
• Las pruebas de software son siempre necesarias.
• En algunos casos ocupan hasta un 40% del tiempo
de un proyecto informático.
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
69
Estrategias de prueba de Software
CU
DR
S
I
VST
Prueba de unidad
Prueba de validaciónPrueba del sistema
Ingeniería del sistema
RequisitosDiseñoCodificación
Prueba de integración
¿Cómo integrar las técnicas de diseño de casos de prueba enuna 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
70
Prueba de unidad
• Centra el proceso en el módulo.
• Se prueban los caminos de control
importantes para descubrir errores dentro del
límite del módulo.
• Está orientado a pruebas de caja blanca.
• Puede realizarse paralelamente en varios
módulos.
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
71
Prueba de unidad
Casos deprueba
InterfazCondiciones límiteCaminos independientesCaminos de manejo de errores
Módulo
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
72
Prueba de unidad
Casos deprueba
InterfazCondiciones límiteCaminos independientesCaminos de manejo de errores
Controlador
Módulo que se va a probar
Resguardo Resguardo
RESULTADOS
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
73
Prueba de integración
Integración descendente
M1
M2
M7
M4
M6
M3
M8
M5
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
74
Prueba de integración
Resguardo A Resguardo B Resguardo C Resguardo D
Mostrar unmensaje de traza
Mostrar elparámetropasado
Devolver unvalor de unatabla (o archivoexterno)
Hacer una búsqueda en una tabla de unparámetro de entrada y devolver elparámetro asociado
= Dirección del flujo de datos
Resguardos
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
75
Prueba de integración
Integración ascendente
Mc
Ma
D3D1 D2
Mb
Grupo 2
Grupo 3Grupo 1
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
76
Prueba de integración
Controlador A Controlador B Controlador C Controlador D
Invocar al subordinado
Enviar elparámetrode una tabla(o archivoexterno)
Mostrarparámetro
Una combinaciónde los controladoresB y C
= Dirección del flujo de datos
Controladores
Y AB
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
77
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
• Se lleva a cabo cuando se ha terminado la prueba de Integración: el software está ensamblado y se han eliminado todos los errores de interfaz.
• La validación se consigue cuando el software funciona según las expectativas del usuario.
• Generalmente son pruebas de caja negra.
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
79
Prueba del sistema
• Realizado el software debe integrarse en el sistema. Estas pruebas sirven para verificar que se han integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas.
• Tipos de pruebas:– prueba de recuperación– prueba de seguridad– prueba de resistencia– prueba de rendimiento
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
80
Depuración de errores
Casos de prueba
Depuración
Ejecución de casos
Resultados
Causasidentificadas
Correcciones
Pruebas de regresión
Pruebasadicionales Causas
sospechadas
La depuración es el proceso que elimina el error