Está en la página 1de 80

1

INGENIERÍA del SOFTWARE


Curso 2006/07

Ingeniería en Informática
Facultad 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 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

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,aniadirUsuario


que 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.esPrimo
puede 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

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

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 blanca
Mejor 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

OBJETIVO A PROBAR
ENTRADA
-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 $
prefijo contraseña
⇒ Se pueden diseñar casos de prueba, cada uno de los
cuales representa a un conjunto de casos de prueba

A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU


20

Prueba de Caja Negra


• prefijo puede ser prefijo contraseña
– “ ” 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 $
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

Ejemplos de -Al cerrar (minimizar,..) la ventana se cierra (minimiza,…)


CASOS de -Al pulsar el botón, aparece en el campo de texto el resultado
PRUEBA -Buscar ayuda de cómo utilizar la interfaz
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
Ejercicio 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.

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 CP2
Entrada: 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


Inicio Elaboración Construcción Transición

Requisitos

Análisis

Diseño

Implementación

Prueba

ite r. ite r. ite r. ite r. ite r. ite r. ite r.


Iteraciones: #1 #2 #n # n+ 1 # n+2 #m #m +1

• Objetivos: Planificar // Diseñar e implementar


// Realizar las pruebas
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
27

Modelo de pruebas

Modelo de pruebas Sistema 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

• 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


Actividades del flujo de trabajo de
30

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

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

Prueba de unidad de EsPrimo


Componente Prueba
Algoritmo: ComponentePruebaEsPrimo de EsPrimo
ResSQL := 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”)
Tabla PRU_UNIDAD_ESPRIMO
CodPr NUM SalidaEsper SalReal ResPrueba
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
34
Prueba de unidad de SiguientePrimo
Algoritmo: SiguientePrimo
Entrada: num (entero) SiguientePrimo
Salida: entero

si num <= 0 entonces


devolver 1
si no sig := num + 1 EsPrimo
mientras EsPrimo(sig) ≠ “primo” hacer
sig := sig + 1 0 1
1 2
fin mientras
2 3
devolver sig
4 5
finsi Tabla
18 19
PRU_UNIDAD_SIGUIENTEPRIMO
17 19
PROBLEMA: si hay errores, patata no número

¿cómo saber a qué módulo corresponden? 17.356 19

SiguientePrimo o EsPrimo ....


A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
35

Prueba de integración ascendente


de SiguientePrimo y EsPrimo

SiguientePrimo

EsPrimo

ORDEN EN EL QUE SE HACEN LAS PRUEBAS:


1º ) Prueba de Unidad de EsPrimo
2º ) 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

Prueba de integración descendente


de SiguientePrimo y EsPrimo
(o cómo probar SiguientePrimo si EsPrimo no está disponible)

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

Prueba de integración descendente


de SiguientePrimo y EsPrimo
(o cómo probar SiguientePrimo si EsPrimo no está disponible)

Algoritmo: SiguientePrimo
Entrada: num (entero) SiguientePrimo
Salida: entero

si num <= 0 entonces


devolver 1 Resguardo de
si no sig := num + 1 EsPrimo
mientras EsPrimo(sig) ≠ “primo” hacer
sig := sig + 1
SE LLAMA AL
fin mientras
Resguardo de EsPrimo
devolver sig
finsi Tabla PRU_UNIDAD_ESPRIMO
CodPr NUM SalidaEsper SalReal ResPrueba
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
38

Prueba de unidad de SiguientePrimo


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
39

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; }}

CodPr NUM SalidaEsper SalReal ResPrueba


1 0 no positivo
2 1 primo
3 2 primo
4 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 enfoque


prá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 CP2
Entrada: 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 superado


lp.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º intentos
if (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
Ejercicio: Escribir componente de
prueba, que pruebe el siguiente CP
Caso de prueba CP3
Entrada: 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

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 superado


lp.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º intentos
if (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


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

A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU


47

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

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


50

A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU


51

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

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


55

Ejercicio Esprimo (camino básico)


num<= 0 1
1-3-10
3
primo:=true
1-2-4-7-8-10 2 devolver “no positivo”
i:=2
1-2-4-7-9-10
4
1-2-4-5-6-7-9-10 i<= num-1
1-2-4-5-6-7-8-10 num resto i = 0 5
i:=i+1
1-2-4-5-4-5-4-7-9-10 6
7 primo:=false
1-2-4-5-4-5-4-5-7-9-10 primo

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)

• 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 procedimental


ARISTA: representa flujo de control
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
59

Prueba de bucles

Bucles Bucles Bucles


simples anidados concatenados
Bucles no
estructurados
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:

repetir
acción1
si cond1 entonces salir
acción2
hasta cond2

• 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)
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


Ejemplo: Algoritmo Esprimo 64

Algoritmo: Esprimo
Entrada: num (entero)
Salida: String (“no positivo”, “primo”, “no primo”)

si num <= 0 entonces


devolver “no positivo”
si no primo := true
para i de 2 a num - 1 hacer
si num resto i = 0 entonces
primo := false DISEÑAR CASOS
salir del bucle DE PRUEBA DE
fin si CAJA BLANCA
fin para
si primo entonces devolver “primo”
si no devolver “no primo”
fin si
fin si
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
65

Ejemplo: Algoritmo Esprimo

“es primo”
entero Esprimo
“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


¿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?
Ingeniería del sistema S

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

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

Interfaz
Módulo
Condiciones límite
Caminos independientes
Caminos de manejo de errores

Casos de
prueba

A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU


72

Prueba de unidad

Interfaz
Condiciones límite
Caminos independientes
Controlador
Caminos de manejo de errores

Módulo que
se va a probar

Casos de Resguardo Resguardo


prueba

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

A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU


74

Prueba de integración

Resguardos

Resguardo A Resguardo B Resguardo C Resguardo D

Mostrar un Mostrar el Devolver un Hacer una


mensaje de parámetro valor de una búsqueda en
traza pasado tabla (o archivo una tabla de un
externo) parámetro de
entrada y
devolver el
parámetro
= Dirección del flujo de datos
asociado
A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU
75

Prueba de integración

Integración Mc
ascendente
Ma Mb

D1 D2 D3

Grupo 3
Grupo 1

Grupo 2

A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU


76

Prueba de integración

Controladores

Controlador A Controlador B Controlador C Controlador D

Y B
A

Invocar al Enviar el Mostrar Una combinación


subordinado parámetro parámetro de los controladores
de una tabla ByC
(o archivo
externo)

= Dirección del flujo de datos


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

La depuración es el proceso que elimina el error

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