pruebas en la ingeniería del software

PRUEBAS

Fundamentos de Ingeniería del Software

Vicente García DíazCésar Fernández AcebalJuan Manuel Cueva LovelleEscuela de Ingeniería InformáticaUniversidad de OviedoCurso 2010-2011

[email protected]

Vicente García Díaz

mailto:[email protected]

Algunos problemas famosos

F-16 (1986)

Therac-25 (1985-1987)

Misil Patriot (1991)

Ariadne 5 (1996)

Mars Climate Orbiter (1999)

Multidata Software (2001)

2

Ubicación general

Son necesarias

¿Por qué hacer pruebas?

Desarrollos en cascada o iterativos…

Pruebas vs otras etapas de desarrollo

Software más complejo y crítico

Costes ocasionados por los fallos muy altos

Análisis Diseño Codificación Pruebas

3

Inicio operación

Revisión

Conceptos básicos

Un del programador ocasiona un , el cual produce un Error es una acción humana equivocada

Defecto es una definición incorrecta en un software

Fallo es la incapacidad de un sistema para realizar las funciones especificadas en los requisitos

No es lo mismo verificar que validar Verificar es determinar si se está construyendo un

producto correctamente

Validar es determinar si se está construyendo el producto correcto

4

1/3errordefecto

fallo

Conceptos básicos

Prueba Es un proceso crítico en el que un software o uno de sus

componentes se ejecuta en circunstancias previamente planificadas con el objetivo básico de encontrar errores

Los resultados se observan, se guardan y se evalúan

Ciclo de prueba Es una actividad compuesta: Formar una idea de los resultados aceptables para

determinados valores de entrada

Se ejecuta el software dándole los valores determinados en unas condiciones específicas

Se observan los resultados

Se comparan los resultados con la idea inicial

5

2/3

Id Condiciones de entrada Entrada Salida esperada

1 La base de datos está cargada 1 1,323

2 La base de datos está cargada 1,5 1,984

3 La base de datos está cargada 0,3 0,396

Conceptos básicos

Caso de prueba Es un escenario concreto de una prueba: Identificador

Componente a probar

Condiciones de entrada

Datos de entrada

Salida esperada

¿Cuántos casos de prueba son suficientes?

Modelos

6

3/3

Objetivos de las pruebas

Verificar y validar el software

Descubrir defectos no detectados con anterioridad

Encontrar defectos con poco esfuerzo y tiempo

Encontrar defectos con una alta probabilidad

7

Características de las pruebas8

Son siempre necesarias y críticas

Pueden llegar a ocupar incluso el 30-40 % del tiempo

Suelen suponer un coste del 30-50 % de un software confiable

El principio de Pareto es aplicable

Son críticas para garantizar la calidad del software

Sólo pueden demostrar la existencia de defectos

No pueden ser completas

Pueden planificarse con mucha antelación

Son más efectivas si las dirige un equipo independiente

Deberían: Probar si el software no hace lo que debe hacer

Probar si el software hace lo que no debe hacer

Realizarse de forma independiente respecto a otras

Estar muy bien documentadas

No deberían: Ser redundantes

Ser demasiado complejas

Dar por supuesto que un software no tendrá defectos

9

Lo que deberían y no deberían hacer

Falsos mitos sobre pruebas

Los desarrolladores de un módulo no deberían probar dicho módulo

El software no debería estar expuesto a personas que puedan utilizarlo de forma mal intencionada

Las personas que realizan las pruebas únicamente trabajan en la etapa de pruebas

10

Esquema básico del proceso

Informes

11

Planificar

[Piattini et al., 96]

Diseñar Ejecutar

EvaluarDepurar

Analizar

Desarrollo

Resultados esperados

Fallos encontrados

Plan de pruebas Casos de prueba

Información del proyecto Resultados

Planificación de la prueba

Identificación Enfoque Informe de incidencias Criterio de suspensión Productos a entregar Tareas a realizar Necesidades ambientales Responsabilidades Personal necesario Calendario Riesgos

12

Diseño de la prueba

Criterios utilizados para obtener los casos de prueba

Casos de prueba organizados Unidad, Integración, Sistema, …

Resultado esperado

Requisitos que se están probando

Datos de prueba

Criterios de terminación Un nº de defectos por unidad de tiempo de la prueba inferior a un valor

determinado

Un nº de defectos esperado

Un % de cobertura determinado

Fin de tiempo o recursos

Se ejecutaron todas las pruebas

13

Depuración del software

Lo que se hace cuando un caso de prueba tiene éxito

Fases de la depuración

Localizar el defecto

Corregir el defecto

Técnicas más utilizadas para localizar el defecto

Fuerza bruta

Rastreo hacia atrás

Eliminación de causas

14

Espacio conceptual

Caso de prueba

Prueba

Fallo Estado erróneo Defecto

Corrección

Resguardo

Controlador

Componente

15

[Bruegge and Dutoit, 04]

* 1..n

*

*

*

*

****

Taxonomía de gestión de defectos

Manejo de defectos

Evitación dedefectos

Detección dedefectos

Tolerancia adefectos

Revisión

Gestión de laconfiguración

MetodologíaTransacciones

atómicasManejo de

excepciones

...Pruebas deintegración

Pruebas unitarias

Pruebas Depuración

[Bruegge and Dutoit, 04]

16

Estándares relacionados con pruebas

IEEE 730 asegurar la calidad del software

IEEE 829 documentación de las pruebas

IEEE 830 especificaciones de los requisitos de sistemas

IEEE 1008 pruebas unitarias

IEEE 1012 verificación y validación del software

IEEE 1028 inspecciones en software

IEEE 1044 clasificación de las anomalías software

IEEE 1061 métricas sobre calidad del software

IEEE 12207 proceso del ciclo de vida del software y de los datos

BS 7925-1 vocabulario de términos utilizados en las pruebas

BS 7925-2 pruebas de componentes software

ISO/IEC 29119 todo el ciclo de pruebas. Pretende sustituir a otros como IEEE 829, IEEE 1008, BS 7925-1, BS 7925-2

17

Tipos principales de pruebas18 usuarioclientedesarrollador

Pruebas de usabilidadPruebas unitarias

Pruebas de integración

Pruebas de sistema

Pruebas de implantación

Pruebas de aceptación

Pruebas alfa y beta

TÉCNICAS DE PRUEBAS

Principales preocupacionesFuncionalidad

Entradas

Salidas

Pruebas de caja negra20

funcionalidadentrada salida

Criterios de coberturaParticiones / Clases de equivalencia

Modelos (criterios)

Consiste en reducir el número de casos de prueba: ¿Cómo? Dividiéndolos en conjuntos de datos equivalentes

Dos fases1. Identificar clases de equivalencia Es un conjunto de datos de entrada equivalentes

Clases de equivalencia válidas valores esperados

Clases de equivalencia no válidas valores no esperados

Se obtienen de las especificaciones de entrada

2. Identificar casos de prueba

21

1/7

Criterios de cobertura Particiones de equivalencia

1- Identificar clases de equivalencia

Habrá que crear una tabla enumerando cada clase

22

2/7

Especificación de entrada Clases de equivalencia válidas

Clases de equivalencia no válidas



Un valor numérico único

Ejemplo: El año tiene que ser 2005 Válida: 2005

No válida 1: “año < 2005”

No válida 2: “año > 2005”

Rango de valores numéricos

Ejemplo: Una cadena de texto tiene entre 10 y 15 letras

Válida: “entre 10 y 15 letras”

No válida 1: “< 10 letras”

No válida 2: “> 15 letras”

23

3/7



Un valor único no numérico

Ejemplo: El color tiene que ser rojo Válida: “color rojo”

No válida: “otro color”

Conjunto de valores

Ejemplo: La profesión puede ser camionero, piloto o albañil Válida: “profesión camionero, piloto o albañil”

No válida: “otra profesión”

Sin embargo, si el programa los tratara de forma diferente…

Habría que crear una clase válida por cada profesión

24

4/7



¿Y las entradas múltiples?

Hay que realizar el producto cartesiano

25

5/7

[http://www.uv.mx/jfernandez/]


2- Identificar casos de prueba Pasos: Cubrir absolutamente todas las clases de equivalencia

Para las clases de equivalencia válidas

Un caso de prueba tantas clases de equivalencia como sea posible

Para las clases de equivalencia no válidas

Un caso de prueba una clase de equivalencia

Ejemplo: números de teléfono

Dos clases de equivalencia no válidas: “El número móvil no empieza por +34”

“Después del código del país no hay 9 cifras”

Si se cubrieran con un mismo caso de prueba el usuario podría introducir como entrada: -40 677 00 00 00 000000

Podrían enmascararse errores no controlados…

26

6/7


2- Identificar casos de prueba

Habrá que crear una tabla con los casos de prueba

27

7/7

Caso de prueba Clases de equivalencia cubiertas

Resultado

Criterios de cobertura Particiones de equivalencia. Ejemplo

La idea es crear pruebas de caja negra para el reconocimiento de identificadores de un lenguaje de programación

Especificación de entrada:

Los identificadores tienen entre 2 y 10 caracteres

El lenguaje distingue entre minúsculas y mayúsculas

Se podrán utilizar letras, dígitos y guiones bajos

Todos los identificadores tienen que empezar por una letra

No se pueden utilizar palabras reservadas del lenguaje como identificadores

28

1/3

Criterios de cobertura Particiones de equivalencia. Ejemplo

29

2/3



Entre 2 y 10 caracteres 1- 2 <= car <= 10 2- car < 2 3- car > 10

Letras, dígitos y guiones bajos

4- identificadores formados por letras, dígitos y guiones

5- un identificador con caracteres que no sean letras, dígitos o guiones

Empieza por letra 6- el primer carácter tiene que ser una letra

7- el primer carácter no es una letra

No utilizar palabras reservadas

8- el identificador no puede ser una palabra reservada del lenguaje

9- el identificador es una de las palabras reservadas del lenguaje

Sensible a mayúsculas 10- identificador válido 11- referenciar a un identificador intercambiando alguna letra mayúsculas / minúsculas

Criterios de cobert.Particiones de equivalencia. Ejemplo

30

3/3

Caso de prueba (identificador)

Clases de equivalencia cubiertas

Resultado

Estado-1 1, 4, 6, 8, 10 El identificador es aceptado por el sistema

A 2 Aparece un mensaje de error

Identificadorlargo 3 Aparece un mensaje de error

dinero€ 5 Aparece un mensaje de error

1dinero 7 Aparece un mensaje de error

String 9 Aparece un mensaje de error

ESTADO-1 11 Aparece un mensaje de error













Criterios de cobertura Análisis de valores límite

¿Qué son los valores límite?

Son aquellos que están en los márgenes de las clases de equivalencia

Los casos de prueba que exploran los valores límites producen mejores resultados

Entonces hay que:

Seleccionar casos de prueba en los extremos

Fijarse también en las especificaciones de salida

31

1/2

Criterios de cobertura Análisis de valores límite

¿Cómo diseñar los casos de prueba?

32

2/2

Especificación para ENTRADA o SALIDA Criterio para obtener casos de prueba

Valor numérico único - Caso para el valor numérico - Caso para el valor justo por encima - Caso para el valor justo por debajo

Rango de valores numéricos - Caso para el valor máximo del rango - Caso para el valor mínimo del rango - Caso para el valor justo por encima - Caso para el valor justo por debajo

Estructuras de datos con elementos - Caso para el primer elemento de la estructura

- Caso para el último elemento de la estructura













Criterios de cobert.Análisis de valores límite. Ejemplo

33

Caso de prueba (identificador)

Valor límite estudiado Resultado

Identifi10 Caso para el valor máximo del rango

El identificador es aceptado por el sistema

K2 Caso para el valor mínimo del rango

El identificador es aceptado por el sistema

Identific10 Caso para el valor justo por encima

Aparece un mensaje de error

K Caso para el valor justo por debajo

Aparece un mensaje de error

Especificación de entrada (un rango de valores)

Criterios de cobertura Grafo Causa – Efecto

Sirve para explorar combinaciones en los valores de entrada

Transforma el lenguaje natural a lenguaje formal

Entradas causas

Salidas efectos

34

1/3

c e c e c1 e

c2

OR

c1 e

c2

AND

Si c e Si !c e


Ejemplo “Se quiere sacar dinero de un cajero”

Causas (condiciones a cumplir) 1- La tarjeta es válida

2- La clave de usuario es correcta

3- Se pasa el nº máximo

4- Hay dinero disponible

Efectos 50- Sale el dinero

51- Rechaza la tarjeta

52- Pregunta otra clave

53- Rechaza la operación

35

2/3

Causas Regla 1 Regla 2 Regla 3 Regla 4

1 La tarjeta es válida NO SI SI -

2 Clave correcta - SI NO -

3 Sobrepasa el nº máximo - - NO SI

4 Hay dinero disponible - SI - NO


Ejemplo

Tabla de decisión

Casos de prueba

Una por cada columna

3/3

Efectos Regla 1 Regla 2 Regla 3 Regla 4

50 Sale el dinero NO SI NO NO

51 Rechaza la tarjeta SI NO NO NO

52 Pregunta otra clave NO NO SI NO

53 Rechaza operac. NO NO NO SI

Cuidado, es un OR

36

Criterios de cobertura Matrices ortogonales

Selecciona un subconjunto de casos de prueba

¿Cuándo se debe utilizar?

Cuando hay demasiados casos de prueba

Cuando no hay tiempo

¿Qué son?

Matrices en las que si se selecciona 2 columnas cualesquiera, en dichas columnas estarán todas las combinaciones posibles de pares, sin repetirse ninguna

Estudios empíricos

37

1/6


Proceso1. Identificar las variables

2. Determinar el nº de opciones de cada variable

3. Encontrar una matriz ortogonal adecuada

4. Adaptar el problema a la matriz ortogonal

5. Crear casos de prueba

Ejemplo [www.parquesoft.com, GSQA-TecnicasPruebasFuncionales.ppt]“Un sitio Web debe operar correctamente con diferentes navegadores, usando diferentes plugins, sobre diferentes sistemas operativos en el cliente y utilizando diferentes servidores de aplicaciones”

Navegadores: IE 8, Firefox 3.6, Google Chrome

Plugins: Real Player, Media Player, ninguno

Servidores de aplicaciones: IIS, Apache, JBoss

Sistemas operativos: Windows Vista, Windows 7, Linux

Combinaciones: 3 x 3 x 3 x 3 = 81

38

2/6


1- Identificar las variablesNavegadores, plugins, servidores de aplicaciones y

sistemas operativos

2- Determinar el nº de opciones de cada variable

Navegadores 3

Plugins 3

Servidores de aplicaciones 3

Sistemas operativos 3

Combinaciones totales 3 x 3 x 3 x 3 = 81

39

3/6


3- Encontrar una matriz ortogonal adecuada

Nº de variables 4 4 columnas

Nº de posibilidades de cada columna 3

L9(34) Sólo hay que contemplar 9 posibilidades

40

4/6

1 2 3 4

1 1 1 1 1 2 1 2 2 2 3 1 3 3 3 4 2 1 2 3 5 2 2 3 1 6 2 3 1 2 7 3 1 3 2 8 3 2 1 3 9 3 3 2 1


4- Adaptar el problema a la matriz

5- Crear casos de prueba

41

5/6

Navegador Plugin Servidor SO

1 IE 8 Real Player IIS Windows Vista 2 IE 8 Media Player Apache Windows 7 3 IE 8 Ninguno JBoss Linux 4 Firefox 3.6 Real Player Apache Linux 5 Firefox 3.6 Media Player JBoss Windows Vista 6 Firefox 3.6 Ninguno IIS Windows 7 7 Google Chrome Real Player JBoss Windows 7 8 Google Chrome Media Player IIS Linux 9 Google Chrome Ninguno Apache Windows Vista

1 2 3 4

1 1 1 1 1 2 1 2 2 2 3 1 3 3 3 4 2 1 2 3 5 2 2 3 1 6 2 3 1 2 7 3 1 3 2 8 3 2 1 3 9 3 3 2 1

Navegadores

1 IE 8

2 Firefox 3.6

3 Google Chrome

Plugins:

1 Real Player

2 Media Player

3 Ninguno.

Servidores de aplicaciones:

1 IIS

2 Apache

3 JBoss

Sistemas operativos:

1Windows Vista

2Windows 7

3 Linux


No todas las combinaciones dadas por la matriz tienen que ser válidas

Otros ejemplos de matrices ortogonales

L4(23) En lugar de 8 pruebas, se hacen 4

L8(2441) En lugar de 64, se hacen 8

L18(3661) En lugar de 4374, se hacen 18

A veces no existe una matriz perfecta, pero se puede seleccionar una un poco más grande

42

6/6

A medida que aumentan los factores, la ganancia es mucho mayor…

Criterios de coberturaEnfoque aleatorio

43

Utilizado generalmente cuando no hay más tiempo

Se simula la entrada de datos

Se pueden utilizar modelos estadísticos

Es menos eficiente que las pruebas directas pero… Hay que considerar el tiempo que supone hacer un

generador aleatorio de entradas al programa y el tiempo que supone hacer las pruebas no aleatorias

Una vez desarrollado el generador aleatorio, la máquina puede hacer pruebas todo el día…

Principales preocupacionesRamificaciones del código

Manejo de recursos del sistema

Manejo de errores

Trabajo como se espera

-Caja negra y caja blanca

Pruebas de caja blanca44

entrada salida

Análisis de la cobertura de código

Es el proceso de:

Encontrar fragmentos del software no ejecutados

Crear casos de prueba adicionales

Determinar un valor cuantitativo de la cobertura

NO es necesario cubrir siempre todo el código

NO mide la calidad del producto software

45

Criterios de coberturaSentencias

Ejemplos de cobertura ajuste(1, 10, 0)

ajuste(1, 11, 15)

46

decisión edad ¿trabaja? ¿hijos? caso de prueba ¿cumple?

IF (1) <30 FALSE TRUE 1- (20, FALSE, TRUE) SI

IF (1) <30 FALSE FALSE 2- (20, FALSE, FALSE) NO

IF (2) * FALSE 2- (20, FALSE, FALSE) SI

IF (2) FALSE TRUE 3- (40, FALSE, TRUE) NO

IF (3) >60 y <70 4- (65, FALSE, TRUE) SI

IF (3) <=60 o >=70 5- (70, FALSE, FALSE) NO

Criterios de coberturaDecisiones

47

Decisiones vs Sentencias

decisión edad ¿trabaja? ¿hijos? caso de prueba

IF (1) <30 TRUE FALSE 1- (20, TRUE, FALSE)

IF (1) >=30 FALSE TRUE 2- (40, FALSE, TRUE)

IF (2) TRUE FALSE 1- (20, TRUE, FALSE)

IF (2) FALSE TRUE 2- (40, FALSE, TRUE)

IF (3) >60 3- (65, FALSE, FALSE)

IF (3) <70 3- (65, FALSE, FALSE)

IF (3) <=60 1- (20, TRUE, FALSE)

IF (3) >=70 4- (70, FALSE, FALSE)

Criterios de coberturaCondiciones

48

Condiciones vs Decisiones

Condiciones vs Sentencias

decisión edad ¿trabaja? ¿hijos? caso de prueba ¿cumple?

IF (1) <30 FALSE TRUE 1- (20, FALSE, TRUE) SI

IF (1) >=30 TRUE FALSE 2- (40, TRUE, FALSE) NO

IF (2) TRUE FALSE 2- (40, TRUE, FALSE) SI

IF (2) FALSE TRUE 3- (40, FALSE, TRUE) NO

IF (3) >60 4- (65, FALSE, FALSE) SI

IF (3) <70 4- (65, FALSE, FALSE) SI

IF (3) <=60 2- (40, TRUE, FALSE) NO

IF (3) >=70 5- (70, FALSE, FALSE) NO

Criterios de coberturaDecisiones / condiciones

49

decisión edad ¿trabaja? ¿hijos? caso de prueba

IF (1) <30 TRUE TRUE 1- (20, TRUE, TRUE)

IF (1) <30 TRUE FALSE 2- (20, TRUE, FALSE)

IF (1) <30 FALSE TRUE 3- (20, FALSE, TRUE)

IF (1) <30 FALSE FALSE 4- (20, FALSE, FALSE)

IF (1) >=30 TRUE TRUE 5- (65, TRUE, TRUE)

IF (1) >=30 TRUE FALSE 6- (65, TRUE, FALSE)

IF (1) >=30 FALSE TRUE 7- (70, FALSE, TRUE)

IF (1) >=30 FALSE FALSE 8- (50, FALSE, FALSE)

IF (2) TRUE TRUE 5- (65, TRUE, TRUE)

IF (2) TRUE FALSE 6- (65, TRUE, FALSE)

IF (2) FALSE TRUE 7- (70, FALSE, TRUE)

IF (2) FALSE FALSE 8- (50, FALSE, FALSE)

IF (3) >60 y < 70 6- (65, TRUE, FALSE)

IF (3) >60 y >= 70 7- (70, FALSE, TRUE)

IF (3) <= 60 y <70 8- (50, FALSE, FALSE)

IF (3) <= 60 y >= 70 no hay opción

Criterios de coberturaCondiciones múltiples

50

Criterios de coberturaCaminos

Un criterio muy utilizado

Camino Secuencia de pasos, desde el inicial hasta la final

Camino de prueba Camino que atraviesa como máximo una vez el

interior de cada bucle que encuentra a su paso*

Camino linealmente independiente Camino de prueba que introduce por lo menos un

nuevo paso respecto a otros Si el procedimiento lo dibujáramos como una grafo, se

correspondería con dibujar una nueva arista que no haya sido recorrida anteriormente por otro camino

1/12

51


Fases para realizar el criterio1. Identificar nodos

2. Dibujar grafo

3. Calcular la complejidad ciclomática Cuantifica la complejidad lógica

4. Determinar el conjunto de caminos linealmente independientes

5. Crear casos de prueba

2/12

52


53

Nodos. Sentencias de código agrupadas

Nodos predicado. Nodos surgidos de cada condición de una decisión

1- Identificar nodos

¿Cuántos nodos?

3/12

1

2

3

45

67

8

910

11

12


2- Dibujar grafo

4/12

54

IF-ELSE

truefalse

secuencia

Aristas. Líneas que unen dos nodos

Regiones. Áreas delimitadas por aristas y nodos


2- Dibujar grafo

5/12

55

WHILE DO-WHILE

true

false

truefalse


2- Dibujar grafo

6/12

56

SWITCH

m

n

IF múltiple

low

truemediumhigh

truefalse

false


2- Dibujar grafo 1

8

9

7

6

5

4

3

2

11

10

12

false

false

false

true

57

7/12


3- Calcular la complejidad ciclomática

V(G) = A – N + 2

A Nº de aristas del grafo

N Nº de nodos del grafo

V(G) = R

R Nº de regiones cerradas del grafo

V(G) = C + 1

C Nº de nodos de condición

Complejidad ciclomática Evaluación del riesgo

de 1 a 10 sin riesgo

de 11 a 20 riesgo moderado

de 21 a 50 alto riesgo

50 o más muy alto riesgo

58

8/12


3- Calcular la complejidad ciclomática

V(G) = A – N + 2 = 18 – 12 + 2 = 8

V(G) = R = 7 + la región externa = 8

V(G) = C + 1 = 7 + 1 = 8

Número de pruebas a realizar

59

9/12

R1

R2R3

R4

R5R6

R7

R8


4- Determinar el conjunto de caminos independientes

Heurísticos

Elegir un camino principal (el más corto hasta el final)

Identificar un segundo camino

Añadiendo alguna arista nueva

…pero tratando que sea el camino en el que menos se añaden

Seguir identificando caminos hasta que no haya más posibilidades

60

10/12


4- Determinar el conjunto de caminos independientes

1. 1 2 3 4 5 12

2. 1 2 6 7 9 12

3. 1 2 3 6 7 9 12

4. 1 2 3 4 6 7 9 12

5. 1 2 6 8 9 12

6. 1 2 6 7 8 9 12

7. 1 2 6 7 9 10 12

8. 1 2 6 7 9 10 11 12

61

11/12


5- Crear casos de prueba1. 1 2 3 4 5 12

Camino 1 beca(20, FALSE, TRUE)

2. 1 2 6 7 9 12


3. 1 2 3 6 7 9 12

Camino 3 no es posible

4. 1 2 3 4 6 7 9 12

Camino 4 no es posible

5. 1 2 6 8 9 12

Camino 5 beca(40, TRUE, TRUE)

6. 1 2 6 7 8 9 12

Camino 6 beca(40, FALSE, FALSE)

7. 1 2 6 7 9 10 12


8. 1 2 6 7 9 10 11 12


12/12

62

Criterios de coberturaBucles

Los bucles son clave en la mayoría de los algoritmos

Requieren un tratamiento especial

Instrucciones típicas For

While

Do While

63

1/4


Bucles simples

Reglas

No ejecutar el bucle ninguna vez

Ejecutarlo una vez

Ejecutarlo dos veces

Ejecutarlo m veces, con m < n

Ejecutarlo n-1, n y n+1 veces

64

2/4


Bucles anidados

Reglas

Comenzar en el bucle más interno Realizar pruebas de bucle simple

Bucles externos valores mínimos

Ir al siguiente nivel Realizar pruebas de bucle simple

Bucles externos valores mínimos

Bucles internos valores típicos

65

3/4


Bucles concatenados

Reglas

Si son independientes Igual que bucles simples

Si no son independientes

Igual que bucles anidados

66

4/4

¿Bucles no estructurados?

Otros criterios de cobertura

Métodos

Hilos

Relacionales

Arrays

67

Criterios de coberturaBasados en el flujo de datos

Los programas son algo más que flujos de control También tienen datos

Categorías de datos d defined, created, initialized k killed, undefined, released u used c used in a calculation p used in a predicate

Tipos de prueba Estática* Identifica anomalías Dinámica Ejecuta el código, similar a las pruebas de

flujo de control ¿Por qué no es suficiente con la versión estática?

68

Símbolos Qué ocurre Válido o no válido

˜d Definir directamente No hay problema

du Definir – Usar No hay problema

dk Definir – Eliminar Problema potencial

˜u Usar directamente Problema potencial

ud Usar – Definir No hay problema. Se usa y luego se redefine

uk Usar – Eliminar No hay problema

˜k Eliminar directamente Problema potencial

ku Eliminar – Usar Problema potencial

kd Eliminar – Definir No hay problema

dd Definir – Definir Problema potencial. Se define dos veces seguidas

uu Usar – Usar No hay problema

kk Eliminar – Eliminar Problema potencial

d˜ Definir y no más Problema potencial

u˜ Usar y no más No hay problema

k˜ Eliminar y no más No hay problema

Criterios de coberturaBasados en el flujo de datos. Análisis estático

Posibles combinaciones entre pares

Entornos de desarrollo

69

1/6


70

2/6

[ftp.ncsu.edu/pub/tech/2006/TR-2006-22.pdf /]


71

3/6


72

4/6


73

5/6






dd Definir – Definir Problema potencial



Símbolos Pasos Conclusión

dd 1-2-3 Sospechoso






dd Definir – Definir Problema potencial




74

6/6

Criterios de coberturaBasados en el flujo de datos. Análisis dinámico

Estrategias (criterios de cobertura) All-definition (AD) All-p-uses (APU) All-c-uses (ACU) All-p-uses / Some-c-uses (APU+C) All-c-uses / Some-p-uses (ACU+P) All-uses (AU) All-du paths (ADUP)

75

1/3

Caminos

ADUP

AU

ACU+P

ACU

APU+C

APUAD

Decisiones

Sentencias


76

2/3

Estrategia Variable Bill

AD 1-2-10 3-4-5-6 6-7 8-10 9-10

APU 1-2-3-4-5-6-7 3-4-5-6-7 6-7

ACU 1-2-10 3-4-5-6 3-4-5-9 3-4-10 6-7-8 6-7-10 8-10 9-10

APU+C (APU)+ 8-10 9-10

ACU+P (ACU)

AU 3-4-5-6 6-7 6-7-8 8-10 3-4-5-9

ADUP (APU) + (ACU)+ (AU)


77

3/3

Estrategia Variable Usage

AD 0-1-2

APU 0-1-2 0-1-2-3-4 0-1-2-3-4-5

ACU 0-1-2-3-4-5-6 0-1-2-3-4-5-9

APU+C (APU)

ACU+P (ACU)

AU 0-1-2 0-1-2-3-4 0-1-2-3-4-5 0-1-2-3-4-5-6 0-1-2-3-4-5-9

ADUP (APU) + (ACU)+ (AU)

…y ahora sólo faltaría hacer un caso de prueba para cada camino

Criterios de coberturaConjetura de errores

78

Diferencia respecto a los anteriores criterios Ponerse en la “piel” del desarrollador y del usuario 1- Crear una lista con errores comunes Cálculos Manejo de colecciones de datos Manejo de ficheros Permisos de los usuarios Usabilidad Interfaces para otros sistemas Uniones y comparaciones de datos Búsquedas de datos

2- Crear los casos de prueba

Principales preocupacionesRegistros

Información saliente

Residuos

Pruebas de caja gris79

entrada salida

TIPOS DE PRUEBAS

Pruebas progresivas y regresivas81

Pruebas progresivas

Realización de pruebas para tratar de encontrar errores en partes nuevas de un software

Pruebas regresivas

Repetición selectiva de pruebas para estudiar efectos adversos cuando se introducen cambios

Probabilidad de introducir errores 50-80%

Pruebas unitarias82

Objetivo Probar un módulo software de manera independiente

Técnica Caja blanca Caja negra

Software para realizar este tipo de pruebas JUnit, NUnit, …

Un módulo Es un bloque básico de construcción Tiene una función independiente Puede ser probado por separado No suele tener más de 500 líneas de código

Pruebas unitariasAlgunos problemas que pueden detectar…

83

1. Precedencia aritmética incorrecta

2. Cálculos incorrectos

3. Flujos de control no adecuados

4. Inicializaciones incorrectas

5. Falta de precisión

6. Representación incorrecta de una expresión

7. Interfaces de entrada / salida

8. Estructuras de datos incorrectas

9. Tratamiento de errores equivocado

Pruebas de integración84

Objetivo

Verificar el correcto ensamblaje de los módulos

Asegurando que interactúan correctamente

Regresión

Técnica

Caja negra

Estrategias principales

No incremental

Incremental

Pruebas de integraciónAlgunos problemas que pueden detectar…

85

1. Problemas de configuración2. Problemas en métodos3. Llamadas a métodos equivocados4. Fallos en los parámetros5. Mal uso de bases de datos y de ficheros6. Fallos en la integridad de los datos7. Fallos con polimorfismo8. Problemas de memoria9. Conflictos entre componentes10. Mal uso de los recursos (memoria, disco, …)

Pruebas de integraciónEstrategia incremental ascendente

86

4

6

5

7 8

9

11

1210

2 3

1

1/2

Módulo principal

Módulos de bajo nivel

Pruebas de integraciónEstrategia incremental ascendente

87

4

6

5

7 8

9

11

1210

Controlador 1

2 3

1

Controlador 2 Controlador 3

2/2

Pruebas de integraciónEstrategia incremental descendente

88

4

6

5

7 8

9

11

1210

2 3

1

Resguardo 1 Resguardo 2

Pruebas de integraciónIntegración ascendente VS integración descendente

89

Ventaja de la integración descendente Se prueba primero el módulo principal

Ventaja de la integración ascendente No se necesitan resguardos Los resguardos son más complejos que los controladores

Integración mixta

Pruebas de sistema90

Objetivo Comprobar la integración del sistema visto desde el

punto de vista global

Técnica Caja negra

Idealmente las hace un equipo

independiente

Se basan en la especificación de

requisitos

Pruebas de sistemaDiferentes pruebas

91

Funcionales Consiste en probar al sistema como un todo

Se utiliza el software ya integrado

Se basan principalmente en los casos de uso

Generación de los casos de prueba Se toma un caso de uso por su camino típico y se generan los

casos de prueba para pasarlo Lo mismo para otros caminos alternativos exitosos

Lo mismo para los caminos que terminen en fracaso

Se crean otros casos de prueba para situaciones imprevistas Ausencia de algún recurso

Imposibilidad de acceder a recursos

Equivocaciones de los usuarios

Situaciones de medio ambiente

1/6


92

Funcionales Ejemplo de caso de uso para guiar las pruebas funcionales

“Un usuario introduce su identificador y su clave y podría entrar en el sistema”

Mejor así:

“Un usuario introduce su identificador y su clave y entra en el sistema. Si el usuario no es el correcto, aparecerá un mensaje advirtiendo que el usuario no está en el sistema. Si el usuario es correcto pero la clave no es correcta, aparecerá un mensaje indicando que la clave no es correcta”.

¿Cuántos casos de prueba podrían realizarse con este caso de uso?

2/6


93

Humo

Comprobar si el software funciona de manera preliminar y directa

Carga

Observar el comportamiento bajo una cantidad de peticiones esperada

Seguridad

Asegurar que la aplicación es segura de acuerdo con sus necesidades

3/6


94

Rendimiento Asegurar que el software cumple con los requisitos de

rendimiento de acuerdo con las especificaciones

Recursos Asegurar que el software no utiliza más recursos de

los requeridos (por ejemplo memoria RAM, procesador, disco duro, etc.)

Configuración Comprobar que el software funciona correctamente

con otras configuraciones software / hardware

4/6


95

Compatibilidad Asegurar que los requisitos de compatibilidad hacia

atrás se cumplen y si los métodos de actualización funcionan

Instalación Determinar si la instalación y desinstalación del

software funciona correctamente en todos los casos

Recuperación Determinar si el software cumple con los requisitos de

recuperación ante fallos inesperados

5/6


96

Disponibilidad / Servicio Comprobar que las condiciones de disponibilidad son las

adecuadas

Estrés Identificar las condiciones máximas en las que el software

fallará en procesarlas dentro de un periodo de tiempo determinado

Localización Probar que una aplicación funciona después de traducirla a otra

¿cultura?

Otros tipos de prueba de sistema Homologación Interoperabilidad Solidez

6/6

Pruebas de implantación97

Objetivo

Comprobar la correcta instalación en el entorno objetivo

Técnica

Caja negra

Aspectos a tener en cuenta

Recuperación

Seguridad

Rendimiento

Comunicaciones

Pruebas de aceptación98

Objetivo Validar que un sistema cumple con lo esperado

Permitir que el cliente acepte el sistema desde todos los puntos de vista

contrato

Técnica Caja negra

Lo ideal es que el cliente sea quien aporta los casos de prueba

Recomendable hacerlas en el entorno objetivo

Pruebas de usabilidad99

Objetivo Encontrar problemas en las interfaces de usuario

Técnica Caja negra

Suelen realizarse muy pronto en el ciclo de desarrollo

Aspectos a tener en cuenta Accesibilidad

Calidad de respuesta

Eficiencia

Comprensibilidad

Métricas Exactitud

Tiempo

Recuerdo

Respuesta emocional

Pruebas Alfa y Beta100

Se emplean cuando el software no se realiza para un cliente determinado

Alfa Personas que adoptan el rol de usuario final Pertenecen a la organización que desarrolló el software

Beta Subconjunto seleccionado (o no) de los usuarios reales No pertenecen a la organización

La motivación es importante ¿Regresivas o progresivas? Alfa vs Beta ¿Qué problema tienen las pruebas Beta?

HERRAMIENTAS

JUnit102

http://www.junit.org/

Es el estándar de facto para pruebas unitarias

También hay NUnit, CppUnit, PyUnit, …

Muy extendidas

Eclipse, Netbeans, …

Ciclo de vida

Preparar Ejecutar Evaluar Limpiar

http://www.jmock.org/

Casos de prueba103

Es la unidad mínima de trabajo de JUnit

Extiende junit.framework.TestCase publicvoid testNAME()

public void setUp()

public void tearDown()

CONSEJO: Poner las pruebas en una carpeta diferente a la del código pero en el mismo paquete que la clase a probar. Así se podrá acceder a métodos y atributos protected

Casos de prueba a partir de JUnit 4104

A partir de JUnit 4 se soportan anotaciones No hace falta extender ninguna clase

No hace falta poner nombres fijos a los métodos

Anotación Parámetros Empleo @After Ninguno Método que se ejecuta después de cada método

de prueba @AfterClass Ninguno Método que se ejecuta después de todos los

métodos @Test y de todos los @After @Before Ninguno Método que se ejecuta antes de cada método de

prueba @BeforeClass Ninguno Método que se ejecuta antes de todos los

métodos @Test y de todos los @Before @Ignore Un String opcional Método para temporalmente decirle a JUnit que

ignore un método de prueba @Parameters Ninguno Método que devuelve una colección de objetos.

Éstos a su vez son pasados al constructor @RunWith Una Class Método que sirve para especificar cambios

respecto a qué tipo de ejecución se llevará a cabo

@SuiteClasses Un array de Class Método que sirve para especificar, mediante una anotación, los TestCases que se van a probar

en una agrupación de prueba (TestSuite) @Test expected (opcional)

timeout (opcional)

Método de pruebas. expected sirve para

especificar una excepción esperada. timeout sirve para especificar el tiempo (en ms) máximo permitido de ejecución

Anotaciones105

Permiten probar cualquier clase (POJO, Plain Old Java Object)

Garantías de orden

Afirmación Para qué sirve assertNull(Object x) Valida si x es null assertNotNull(Object x) Valida si x no es null assertTrue(boolean x) Valida si x es true assertFalse(boolean x) Valida si x es false assertEquals(Object x, Object y) Valida si x e y son iguales. Utiliza el método de Java

equals(Object obj1, Object obj2) assertSame(Object x, Object y) Valida si x e y son iguales. Utiliza el operador == assertNotSame(Object x, Object y) Valida si x e y no son iguales. Utiliza el operador == fail() Falla un test de manera programática

Asserts106

Un Assert es una Afirmación que hace alguien

Si se valida la afirmación el método de test pasa la prueba

Con que sólo una de las afirmaciones no se cumpla el método de test NO pasa la prueba

Ejemplo de uso de Asserts107

Botón Derecho Run As JUnit Test

Conjuntos de pruebas (SuiteCase)108

Es una colección de casos de prueba (TestCase)

Sirve para clasificarlos

EasyMock109

http://easymock.org/

¿Qué es un Mock Object?

Es un objeto que sirve para emular el comportamiento de otro

¿Dónde viene bien?

Ciclo de vida

Tipos de objetos Mock

Regular si se espera y no se llama o si se llama sin esperarse

Nice si se espera y no se llama

Strict si se espera y no se llama o si se llama sin esperarse. Importa el orden

Crear Grabar Reproducir Verificar

http://easymock.org/

Crear objetos Mock110

Creación de objetos Mock directa

Los objetos Mock y su validación son independientes

EasyMock.createMock(myInterface.class)

EasyMock.createNiceMock(myInterface.class)

EasyMock.createStrictMock(myInterface.class)

Creación de objetos Mock mediante un control

Los objetos Mock están relacionados a través del control

Grabar el comportamiento en objetos Mock

111

Métodos que devuelven void

Métodos que no devuelven void

Métodos que lanzan excepciones

.atLeastOnce()

.times(int min, int max)

.anyTimes()

Reproducir y validar el comportamiento en objetos Mock

112

Falta, reproducir el comportamiento grabado y validar que todos los métodos se han llamado las veces oportunas

¿Qué pasa si..

Hacemos una llamada más al método sumar? Y al restar?

Si utilizamos createNiceMock y hacemos una llamada más al método sumar?

Si utilizamos createNiceMock y quitamos la llamada al método restar?

Si utilizamos createStrictMock?

Preparación para reproducir

Reproducciones

Validación

CodeCover113

http://www.codecover.org/

Cobertura de código

aplicación Java en Eclipse

aspecto de la aplicación en funcionamiento

http://www.codecover.org/

Uso de la herramienta

Varias formas de trabajo

1- activar CodeCover2- seleccionar las clases a estudiar

3- ejecutar la aplicación con CodeCover

114

Métricas de CodeCover

1. Statement Coverage

2. Branch Coverage

3. Term Coverage

4. Loop Coverage

5. Question mark operator (?) Coverage

6. Synchronized Coverage

115

Informes generados1/3

116


117


118

JMeter119

http://jakarta.apache.org/jmeter/

Pruebas de carga, de estrés, de rendimiento

Diferentes protocolos

Plan de Test

Se pueden ir añadiendo elementos de forma jerárquica

Elementos

Thread groups

Timers

Listeners

Target Web Page

http://jakarta.apache.org/jmeter/

Otras herramientas120

xUnit (NUnit, CUnit, CppUnit, PHPUnit, PyUnit, SUnit)

DbUnit, HttpUnit, EJB3Unit, JUnitPerf, NoUnit

TestNG, Cactus

SilkTest, Selenium, Fitnesse, Fest

JCrasher, Eclat, Symstra, TestGen4J

JTest, CodePro

JDepend, CheckStyle

Cobertura, Jester, Emma, Jumble, Clover

jMock, jMockit

Dumbster

Findbugs, JLint

JProfiler

JBench

Casos prácticos121

Clases de equivalencia y valores límite. Se ha creado un subsistema que comprueba si un identificador es correcto. Un identificador tiene las siguientes características:

Entre 4 y 20 caracteres

Letras válidas (a-z, A-Z)

Dígitos válidos (2-8)

Caracteres especiales válidos: % y –

Como mínimo tendrá 2 letras (mínimo 1 en mayúsculas), 1 carácter especial y 1 dígito

El primer y el último carácter son letras

No emplea las palabras reservadas del lenguaje

Se pide crear casos de prueba adecuados para el sistema.

Matrices ortogonales. Se ha creado un software que admite como entrada 4 parámetros (PAR1, PAR2, PAR3, y PAR4). El software se ejecuta de la siguiente forma: >> run.exe PAR1 PAR2 PAR3 PAR4. PAR1 puede tener como valores “a” “b” o “c”, PAR2 puede tener como valores “c”, “d” o “f”, PAR3 puede tener como valores “g”, “h”, “i”, y PAR4 puede tener como valores “j”, “k”, o simplemente estar vacio. Se pide crear casos de prueba adecuados para el sistema.

Casos prácticos122

Grafo causa - efecto. Se ha creado un software que admite como entrada un único parámetro (PAR1). El software se ejecuta de la siguiente forma: >> run.exe PAR1. PAR1 es un identificador de un libro que está formado por lo siguiente:

Un primer bloque, que es una C (de comedia), una A (de acción), o una T (de técnico)

Un segundo bloque, es un número del 0 al 99999, referenciando al libro

Ejemplos: C239, A0, T9911

Si el identificador es correcto, entonces se muestra el libro. Si el primer bloque no es correcto, entonces se muestra un mensaje indicando que el código no ha sido correcto. Si el segundo bloque no es correcto, entonces se muestra un mensaje indicando que el número no ha sido correcto

Se pide crear casos de prueba adecuados para el sistema

Casos prácticos123

En función del código anterior, crear casos de prueba para lo siguiente:

Cobertura de caminos

Cobertura de sentencias, decisiones, condiciones, decisiones-condiciones, condiciones múltiple

Cobertura del flujo de datos

Casos prácticos124

En función del código, crear casos de prueba para lo siguiente:

Cobertura de caminos

Cobertura de sentencias, decisiones, condiciones, decisiones-condiciones, condiciones múltiple

Cobertura del flujo de datos

Bibliografía125

pruebas en la ingeniería del software

Documents