Tema Evaluación / Pruebas del Software

(1)

DISEÑO DE SISTEMAS DE

INFORMACIÓN

Tema

Evaluación / Pruebas del Software

(2)

2

Tema 3.

Evaluación / Pruebas del Software

(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?

(4)

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

.

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

(6)

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.

(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>

(8)

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)

(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

Héctor Cuadra, [email protected]

(10)

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

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

(12)

12

Ejemplo: EsPrimo

El método

Esprimo.esPrimo

puede ser llamado

con un array de

Strings

(13)

Ejemplo: casos de prueba de caja

blanca para EsPrimo

ENTRADA

OBJETIVO A PROBAR

-

Probar todos los caminos

-

Probar todas las condiciones

(14)

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”);} ...}

(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... }

(16)

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

(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

(18)

18

Ejemplo: casos de prueba de caja

negra para EsPrimo

ENTRADA

OBJETIVO A PROBAR

-

Valores límite

(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

(20)

(21)

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 $

(22)

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”

(23)

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.

(24)

23

Ejemplo: casos de prueba de

negra para EsPrimo

Ejemplos de

CASOS de

PRUEBA

-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

(25)

Ejercicio

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.

(26)

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

(27)

Pruebas en el proceso unificado

Inicio Elaboración Construcción Transición

Requisitos Análisis Diseño Implementación Prueba

Iteraciones:

ite r.# 1 ite r. # 2 ite r. # n ite r. # n + 1 ite r. # n + 2 ite r. # m ite r. # m + 1

• Objetivos: Planificar // Diseñar e implementar

// Realizar las pruebas

(28)

27

Modelo de pruebas

1 Modelo de pruebas

_{Sistema de pruebas}

*

_{* *}

X

_X

Caso de prueba

_{Procedimiento}

de prueba

Componente

de prueba

(29)

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.

(30)

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

(31)

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

(32)

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.

(33)

Prueba de unidad de EsPrimo

Componente Prueba

de Esprimo

Casos de

prueba

RESULTADO NUM no positivo primo no primo

EsPrimo

CodPr NUM SalidaEsper SalReal ResPrueba

1 0 no positivo 2 1 primo 3 2 primo 4 3 primo 5 4 no primo 6 23 primo 7 -4 no positivo 8 78298234 no primo 9 -123412341234123 no positivo 10 “patata” no positivo 11 782.98234 no primo El Componente Prueba de Esprimo recorre la tabla PRU_UNIDAD_ESPRIMO y llama al módulo Esprimo con el valor de entrada

NUM. El resultado obtenido lo escribe en SalReal y si es igual al valor de SalidaEsper deja OK en ResPrueba, en caso contrario deja ERROR

(34)

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

(35)

Prueba de unidad de SiguientePrimo

Algoritmo: SiguientePrimo

Entrada: num (entero)

Salida: entero

si num <= 0 entonces

devolver 1

si no sig := num + 1

mientras EsPrimo(sig)

≠

“primo” hacer

SiguientePrimo

EsPrimo

finsi

sig := sig + 1

fin mientras

devolver sig

Tabla PRU_UNIDAD_SIGUIENTEPRIMO

PROBLEMA: si hay errores,

0 1 1 2 2 3 4 5 18 19 17 19 patata no número

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

SiguientePrimo o EsPrimo

17.356 19 ....

(36)

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)

(37)

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

(38)

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)

Salida: entero

si num <= 0 entonces

devolver 1

si no sig := num + 1

mientras EsPrimo(sig)

≠

“primo” hacer

sig := sig + 1

SiguientePrimo

Resguardo de

EsPrimo

fin mientras

devolver sig

SE LLAMA AL

Resguardo de EsPrimo

finsi

_{Tabla PRU_UNIDAD_ESPRIMO}

(39)

Prueba de unidad de SiguientePrimo

Algoritmo: ResguardoEsPrimo

Entrada: numEnt (entero)

Resguardo

de EsPrimo

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

fin si

1 0 no positivo 2 1 primo 3 2 primo 4 3 primo ... Tabla PRU_UNIDAD_ESPRIMO

(40)

39

Creación de un resguardo

Algoritmo: ResguardoEsPrimo

Entrada: numEnt (entero)

Resguardo

de EsPrimo

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

fin si

(41)

Creación de un resguardo

package resguardo;

public class Esprimo {

Resguardo

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

(42)

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

(43)

Ejercicio: Escribir componente de

prueba, que pruebe el siguiente CP

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

(44)

43

Solución

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

(45)

Ejercicio: Escribir componente de

prueba, que pruebe el siguiente CP

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

(46)

45

Solución

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

(47)

Ejercicio

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.

(48)

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)

(49)

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)

intentar otra vez: usuario “pepita” password: “malPassw” Salida: no obtener paso intentar otra vez: usuario “pepita” password: “e445dr”

Salida: obtener paso // Intenta 3 veces

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”

(suponiendo usuario “pepita” válido y password “e445dr” válido)

(50)

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

(51)

(52)

51

Solución al ejercicio

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)

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”

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”

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

(53)

Solución al ejercicio

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)

(54)

53

Solución al ejercicio

intentar otra vez: usuario “pepita” password: “malPassw” Salida: no obtener paso intentar otra vez: usuario “pepita” password: “e445dr”

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”

(55)

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

(56)

55

Ejercicio Esprimo (camino básico)

1-3-10

num<= 0

1 primo:=true

3 1-2-4-7-8-10

1-2-4-7-9-10

1-2-4-5-6-7-9-10

2 i:=2

4 i<= num-1

devolver “no positivo”

1-2-4-5-6-7-8-10

1-2-4-5-4-5-4-7-9-10

num resto i = 0

5

i:=i+1

6 1-2-4-5-4-5-4-5-7-9-10

primo

7 primo:=false

V(G) = 5

devolver “primo”

9 FIN

8 devolver “no primo”

(57)

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: -4 Salida: “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

(58)

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)

(59)

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

(60)

59

Prueba de bucles

Bucles simples Bucles anidados Bucles concatenados Bucles no estructurados

(61)

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)

(62)

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

(63)

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)

(64)

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.

(65)

Ejemplo: Algoritmo Esprimo

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

salir del bucle

fin si

fin para

si primo entonces devolver “primo”

si no devolver “no primo”

fin si

DISEÑAR CASOS

DE PRUEBA DE

CAJA BLANCA

fin si

(66)

65

Ejemplo: Algoritmo Esprimo

entero

Esprimo

“es primo”

“no primo”

“no positivo”

DISEÑAR CASOS DE PRUEBA DE CAJA NEGRA

(67)

Ejemplo: Algoritmo Esprimo

DISEÑAR CASOS DE PRUEBA DE LA INTERFAZ

Y DE LA DOCUMENTACIÓN

(68)

67

Ejercicio: Tomar en Préstamo la

Copia de un Libro

DISEÑAR LOS CASOS DE PRUEBA DE ESTE CASO DE USO

(69)

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.

(70)

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

I

V

ST

Prueba de unidad

Prueba de integración

Prueba de validación

Prueba del sistema

(71)

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

.

(72)

71

Prueba de unidad

Interfaz

Condiciones límite

Caminos independientes

Caminos de manejo de errores

Módulo

Casos de

prueba

(73)

Prueba de unidad

Interfaz

Condiciones límite

Caminos independientes

Caminos de manejo de errores

Controlador

Módulo que

se va a probar

Casos de

prueba

Resguardo Resguardo

RESULTADOS

(74)

73

Prueba de integración

Integración

descendente

M1

M2 M3 M4

M5 M6 M7

M8

(75)

Prueba de integración

Resguardos

Resguardo A Resguardo B Resguardo C Resguardo D Mostrar un mensaje de traza Mostrar el parámetro pasado Devolver un valor de una tabla (o archivo externo) Hacer una búsqueda en una tabla de un parámetro de entrada y devolver el parámetro = Dirección del flujo de datos

(76)

75

Prueba de integración

Integración

_Mc

ascendente

Ma Mb

D1 D2

_D3

Grupo 1 Grupo 3 Grupo 2

(77)

Prueba de integración

Controladores

Controlador A Controlador B Controlador C Controlador D

Y _A B Invocar al subordinado Enviar el parámetro de una tabla (o archivo externo) Mostrar parámetro Una combinación de los controladores B y C

= Dirección del flujo de datos

(78)

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

.

(79)

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.

(80)

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

(81)

Depuración de errores

La depuración es el proceso que elimina el error

Ejecución de casos Casos de prueba Pruebas adicionales Causas sospechadas Resultados Pruebas de regresión Correcciones

Causas

identificadas