Ejemplos de pruebas - Apuntes 3 PDF

Preview

Summary

pruebas de software...

Description

1

DISEÑO DE SISTEMAS DE INFORMACIÓN

Tema Evaluación / Pruebas del Software

Héctor Cuadra, [email protected]

2

Tema 3. Evaluación / Pruebas del Software

Héctor Cuadra, [email protected]

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? Héctor Cuadra, [email protected]

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. Héctor Cuadra, [email protected]

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. Héctor Cuadra, [email protected]

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 pero sí una tupla RESULTADO ESPERADO: no deja entrar y cambia la tupla a

Objetivo del caso de prueba: comprobar que no deja entrar a un usuario existente con un password equivocado. Héctor Cuadra, [email protected]

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

Héctor Cuadra, [email protected]

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) Héctor Cuadra, [email protected]

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

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 Héctor Cuadra, [email protected]

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) Héctor Cuadra, [email protected]

12

Ejemplo: EsPrimo

El método Esprimo.esPrimo puede ser llamado con un array de Strings

Héctor Cuadra, [email protected]

13

Ejemplo: casos de prueba de caja blanca para EsPrimo

ENTRADA

OBJETIVO A PROBAR -Probar todos los caminos -Probar todas las condiciones

Héctor Cuadra, [email protected]

-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”);} ...} Héctor Cuadra, [email protected]

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... } Héctor Cuadra, [email protected]

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 Héctor Cuadra, [email protected]

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

Héctor Cuadra, [email protected]

18

Ejemplo: casos de prueba de caja negra para EsPrimo

ENTRADA

Héctor Cuadra, [email protected]

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

Héctor Cuadra, [email protected]

20

Prueba de Caja Negra • prefijo puede ser – – – – –

“ ” “743” “935” “1983” “8pW”

prefijo

contraseña

representa a entrada en blanco representa a número 999 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 $

Héctor Cuadra, [email protected]

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”

Héctor Cuadra, [email protected]

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. Héctor Cuadra, [email protected]

23

Ejemplo: casos de prueba de negra para EsPrimo

Ejemplos de CASOS de PRUEBA Héctor Cuadra, [email protected]

-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

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.

Héctor Cuadra, [email protected]

24

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

Héctor Cuadra, [email protected]

26

Pruebas en el proceso unificado Inicio

Elaboración

Construcción

Transición

Requisitos

Análisis

Diseño

Implementación

Prueba

Iteraciones:

ite r.

ite r.

ite r.

ite r.

ite r.

ite r.

ite r.

#1

#2

#n

# n+ 1

# n+2

#m

#m+ 1

• Objetivos: Planificar // Diseñar e implementar // Realizar las pruebas

Héctor Cuadra, [email protected]

27

Modelo de pruebas

1 Modelo de pruebas

*

X Caso de prueba

Héctor Cuadra, [email protected]

Sistema de pruebas

*

*

X Procedimiento de prueba

Componente de prueba

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. Héctor Cuadra, [email protected]

Actividad del flujo de trabajo de Implementación

29

• 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

Héctor Cuadra, [email protected]

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. Héctor Cuadra, [email protected]

30

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. Héctor Cuadra, [email protected]

32

Prueba de unidad de EsPrimo Componente Prueba de Esprimo Casos de prueba

NUM RESULTADO

CodPr 1 2 3 4 5 6 7 8 9 10 11

no positivo primo no primo

EsPrimo

NUM SalidaEsper SalReal ResPrueba 0 no positivo El Componente Prueba de 1 primo Esprimo recorre la tabla 2 primo PRU_UNIDAD_ESPRIMO 3 primo y llama al módulo Esprimo 4 no primo con el valor de entrada 23 primo NUM. El resultado obtenido -4 no positivo lo escribe en SalReal y si es 78298234 no primo igual al valor de SalidaEsper -123412341234123 no positivo deja OK en ResPrueba, en “patata” no positivo caso contrario deja ERROR 782.98234 no primo

Héctor Cuadra, [email protected]

Tabla PRU_UNIDAD_ESPRIMO

33

Prueba de unidad de EsPrimo Componente Prueba de EsPrimo Algoritmo: ComponentePruebaEsPrimo ResSQL := ejecutarBD(“Select CodPr, NUM, SalidaEsper from PRU_UNIDAD_ESPRIMO”) mientras no fin (ResSQL) hacer := 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 Héctor Cuadra, [email protected]

NUM

SalidaEsper SalReal ResPrueba

Prueba de unidad de SiguientePrimo Algoritmo: SiguientePrimo Entrada: num (entero) Salida: entero

SiguientePrimo

si num 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) Héctor Cuadra, [email protected]

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 Héctor Cuadra, [email protected]

50

Héctor Cuadra, [email protected]

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