Fundamentos de Ingeniería del Software

PRUEBAS
Vicente García Díaz garciavicente@uniovi.es

Vicente García Díaz César Fernández Acebal Juan Manuel Cueva Lovelle Escuela de Ingeniería Informática
Universidad de Oviedo Curso 2010-2011

Algunos problemas famosos
2


 


F-16 (1986) Therac-25 (1985-1987) Misil Patriot (1991) Ariadne 5 (1996) Mars Climate Orbiter (1999) Multidata Software (2001)

Ubicación general
3

  

Son necesarias ¿Por qué hacer pruebas? Desarrollos en cascada o iterativos…
Revisión

Análisis

Diseño

Codificación

Pruebas

Inicio operación

  

Pruebas vs otras etapas de desarrollo Software más complejo y crítico Costes ocasionados por los fallos muy altos

1/3

Conceptos básicos
4

defecto error fallo

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

, el

 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

2/3

Conceptos básicos
5

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

3/3

Conceptos básicos
6

Caso de prueba
 Es un escenario concreto de una prueba:
 Identificador  Componente a probar  Condiciones de entrada

 Datos de entrada
 Salida esperada
Id 1 2 3 Condiciones de entrada La base de datos está cargada La base de datos está cargada La base de datos está cargada Entrada 1 1,5 0,3 Salida esperada 1,323 1,984 0,396

 ¿Cuántos casos de prueba son suficientes?  Modelos

Objetivos de las pruebas
7

Verificar y validar el software Descubrir defectos no detectados con anterioridad Encontrar defectos con poco esfuerzo y tiempo

Encontrar defectos con una alta probabilidad

Características de las pruebas
8

  


 


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

Lo que deberían y no deberían hacer
9

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

Falsos mitos sobre pruebas
10

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

Esquema básico del proceso
11

Planificar

Plan de pruebas

Diseñar

Casos de prueba

Ejecutar

Información del proyecto

Resultados

Desarrollo

Depurar

Fallos encontrados

Evaluar

Resultados esperados Informes

Analizar

[Piattini et al., 96]

Planificación de la prueba
12

          

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

Diseño de la prueba
13

 

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

Depuración del software
14

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

Espacio conceptual
15 Prueba

Caso de prueba
*

*

1..n

Componente

Corrección
*

Controlador

Resguardo
* * * *

Fallo

Estado erróneo

*

*

Defecto

[Bruegge and Dutoit, 04]

Taxonomía de gestión de defectos
16

Manejo de defectos

Evitación de defectos Gestión de la configuración Revisión

Detección de defectos

Tolerancia a defectos Transacciones atómicas Manejo de excepciones

Metodología

Pruebas

Depuración

Pruebas unitarias

Pruebas de integración

...

[Bruegge and Dutoit, 04]

Estándares relacionados con pruebas
17

     


    

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

Tipos principales de pruebas
18

desarrollador

cliente

usuario

Pruebas unitarias Pruebas de integración Pruebas de sistema

Pruebas de usabilidad

Pruebas de implantación Pruebas alfa y beta Pruebas de aceptación

TÉCNICAS DE PRUEBAS

20

Pruebas de caja negra
Principales preocupaciones
Funcionalidad Entradas Salidas entrada funcionalidad salida

1/7

Criterios de cobertura
Particiones / Clases de equivalencia
 

21

Modelos (criterios) Consiste en reducir el número de casos de prueba:

¿Cómo?

Dividiéndolos en conjuntos de datos equivalentes

Dos fases
1.

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

2/7

Criterios de cobertura
Particiones de equivalencia

22

1- Identificar clases de equivalencia
 Habrá que crear una tabla enumerando cada clase

Especificación de entrada

Clases de equivalencia válidas

Clases de equivalencia no válidas

3/7

Criterios de cobertura
Particiones de equivalencia

23

1- Identificar clases de equivalencia
 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”

4/7

Criterios de cobertura
Particiones de equivalencia

24

1- Identificar clases de equivalencia
 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

5/7

Criterios de cobertura
Particiones de equivalencia

25

1- Identificar clases de equivalencia

 ¿Y las entradas múltiples?
 Hay que realizar el producto cartesiano

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

6/7

Criterios de cobertura
Particiones de equivalencia

26

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…

7/7

Criterios de cobertura
Particiones de equivalencia

27

2- Identificar casos de prueba
 Habrá que crear una tabla con los casos de prueba

Caso de prueba

Clases de equivalencia cubiertas

Resultado

1/3

Criterios de cobertura
Particiones de equivalencia. Ejemplo

28

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

2/3

Criterios de cobertura
Particiones de equivalencia. Ejemplo
Especificación de entrada Entre 2 y 10 caracteres Letras, dígitos y guiones bajos Clases de equivalencia válidas 1- 2 <= car <= 10 4- identificadores formados por letras, dígitos y guiones 6- el primer carácter tiene que ser una letra 8- el identificador no puede ser una palabra reservada del lenguaje 10- identificador válido Clases de equivalencia no válidas 2- car < 2 3- car > 10 5- un identificador con caracteres que no sean letras, dígitos o guiones 7- el primer carácter no es una letra 9- el identificador es una de las palabras reservadas del lenguaje 11- referenciar a un identificador intercambiando alguna letra mayúsculas / minúsculas

29

Empieza por letra

No utilizar palabras reservadas

Sensible a mayúsculas

3/3

Especificación de entrada

Criterios de cobert.
Particiones de equivalencia. Ejemplo
30

Entre 2 y 10 caracteres Letras, dígitos y guiones bajos

Clases de equivalencia válidas 1- 2 <= car <= 10 4- identificadores formados por letras, dígitos y guiones 6- el primer carácter tiene que ser una letra 8- el identificador no puede ser una palabra reservada del lenguaje 10- identificador válido

Empieza por letra

Clases de equivalencia no válidas 2- car < 2 3- car > 10 5- un identificador con caracteres que no sean letras, dígitos o guiones 7- el primer carácter no es una letra 9- el identificador es una de las palabras reservadas del lenguaje 11- referenciar a un identificador intercambiando alguna letra mayúsculas / minúsculas

No utilizar palabras reservadas

Sensible a mayúsculas

Caso de prueba (identificador) Estado-1 A Identificadorlargo dinero€ 1dinero String ESTADO-1

Clases de equivalencia cubiertas 1, 4, 6, 8, 10 2 3 5 7 9 11

Resultado El identificador es aceptado por el sistema Aparece un mensaje de error Aparece un mensaje de error Aparece un mensaje de error Aparece un mensaje de error Aparece un mensaje de error Aparece un mensaje de error

1/2

Criterios de cobertura
Análisis de valores límite

31

¿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

2/2

Criterios de cobertura
Análisis de valores límite

32

¿Cómo diseñar los casos de prueba?
Criterio para obtener casos de prueba - Caso para el valor numérico - Caso para el valor justo por encima - Caso para el valor justo por debajo - 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 - Caso para el primer elemento de la estructura - Caso para el último elemento de la estructura

Especificación para ENTRADA o SALIDA Valor numérico único

Rango de valores numéricos

Estructuras de datos con elementos

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

Especificación de entrada Entre 2 y 10 caracteres Letras, dígitos y guiones bajos

Clases de equivalencia válidas 1- 2 <= car <= 10 4- identificadores formados por letras, dígitos y guiones 6- el primer carácter tiene que ser una letra 8- el identificador no puede ser una palabra reservada del lenguaje 10- identificador válido

Empieza por letra

Clases de equivalencia no válidas 2- car < 2 3- car > 10 5- un identificador con caracteres que no sean letras, dígitos o guiones 7- el primer carácter no es una letra 9- el identificador es una de las palabras reservadas del lenguaje 11- referenciar a un identificador intercambiando alguna letra mayúsculas / minúsculas

Especificación de entrada (un rango de valores)

No utilizar palabras reservadas

Sensible a mayúsculas

Caso de prueba (identificador) Identifi10 K2 Identific10 K

Valor límite estudiado 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

Resultado El identificador es aceptado por el sistema El identificador es aceptado por el sistema Aparece un mensaje de error Aparece un mensaje de error

1/3

Criterios de cobertura
Grafo Causa – Efecto

34

Sirve para explorar combinaciones en los valores de entrada Transforma el lenguaje natural a lenguaje formal
 Entradas  causas  Salidas  efectos

c
Si c  e

e

c
Si !c  e

e

c1 c2 OR

e

c1 c2 AND

e

2/3

Criterios de cobertura
Grafo Causa – Efecto

35

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

3/3

Criterios de cobertura
Grafo Causa – Efecto

36

Ejemplo
 Tabla de decisión
Cuidado, es un OR
Causas 1 La tarjeta es válida 2 Clave correcta 3 Sobrepasa el nº máximo 4 Hay dinero disponible Efectos 50 Sale el dinero 51 Rechaza la tarjeta 52 Pregunta otra clave 53 Rechaza operac. Regla 1 NO Regla 1 NO SI NO NO Regla 2 SI SI SI Regla 2 SI NO NO NO Regla 3 SI NO NO Regla 3 NO NO SI NO Regla 4 SI NO Regla 4 NO NO NO SI

 Casos de prueba
 Una por cada columna

1/6

Criterios de cobertura
Matrices ortogonales
 

37

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

2/6

Criterios de cobertura
Matrices ortogonales

38

Proceso
1. 2. 3. 4. 5.

Identificar las variables Determinar el nº de opciones de cada variable Encontrar una matriz ortogonal adecuada Adaptar el problema a la matriz ortogonal 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

3/6

Criterios de cobertura
Matrices ortogonales

39

1- Identificar las variables
 Navegadores, 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

4/6

Criterios de cobertura
Matrices ortogonales

40

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

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

5/6

Criterios de cobertura
Matrices ortogonales

41

4- Adaptar el problema a la matriz


1 2 3 4 5 6 7 8 9

5- Crear casos de prueba
1 1 1 1 2 2 2 3 3 3 2 1 2 3 1 2 3 1 2 3 3 1 2 3 2 3 1 3 1 2 4 1 2 3 3 1 2 2 3 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: 1 Windows Vista 2 Windows 7 3 Linux

1 2 3 4 5 6 7 8 9

Navegador IE 8 IE 8 IE 8 Firefox 3.6 Firefox 3.6 Firefox 3.6 Google Chrome Google Chrome Google Chrome

Plugin Real Player Media Player Ninguno Real Player Media Player Ninguno Real Player Media Player Ninguno

Servidor IIS Apache JBoss Apache JBoss IIS JBoss IIS Apache

SO Windows Vista Windows 7 Linux Linux Windows Vista Windows 7 Windows 7 Linux Windows Vista

6/6

Criterios de cobertura
Matrices ortogonales

42

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 medida que aumentan los factores, la ganancia es mucho mayor…

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

Criterios de cobertura
Enfoque 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…

44

Pruebas de caja blanca
Principales preocupaciones
Ramificaciones del código Manejo de recursos del sistema entrada Manejo de errores Trabajo como se espera -Caja negra y caja blanca salida

Análisis de la cobertura de código
45

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

Criterios de cobertura
Sentencias
46

 Ejemplos de cobertura
 

ajuste(1, 10, 0) ajuste(1, 11, 15)

Criterios de cobertura
Decisiones
47

Decisiones vs Sentencias

decisión IF (1) IF (1) IF (2) IF (2) IF (3) IF (3)

edad <30 <30

¿trabaja? FALSE FALSE * FALSE

¿hijos? TRUE FALSE FALSE TRUE

>60 y <70 <=60 o >=70

caso de prueba 1- (20, FALSE, TRUE) 2- (20, FALSE, FALSE) 2- (20, FALSE, FALSE) 3- (40, FALSE, TRUE) 4- (65, FALSE, TRUE) 5- (70, FALSE, FALSE)

¿cumple? SI NO SI NO SI NO

Criterios de cobertura
Condiciones
48

Condiciones vs Decisiones
Condiciones vs Sentencias

decisión IF (1) IF (1) IF (2) IF (2) IF (3) IF (3) IF (3) IF (3)

edad ¿trabaja? ¿hijos? caso de prueba <30 TRUE FALSE 1- (20, TRUE, FALSE) >=30 FALSE TRUE 2- (40, FALSE, TRUE) TRUE FALSE 1- (20, TRUE, FALSE) FALSE TRUE 2- (40, FALSE, TRUE) >60 3- (65, FALSE, FALSE) <70 3- (65, FALSE, FALSE) <=60 1- (20, TRUE, FALSE) >=70 4- (70, FALSE, FALSE)

Criterios de cobertura
Decisiones / condiciones
49

decisión IF (1) IF (1) IF (2) IF (2) IF (3) IF (3) IF (3) IF (3)

edad ¿trabaja? ¿hijos? <30 FALSE TRUE >=30 TRUE FALSE TRUE FALSE FALSE TRUE >60 <70 <=60 >=70

caso de prueba 1- (20, FALSE, TRUE) 2- (40, TRUE, FALSE) 2- (40, TRUE, FALSE) 3- (40, FALSE, TRUE) 4- (65, FALSE, FALSE) 4- (65, FALSE, FALSE) 2- (40, TRUE, FALSE) 5- (70, FALSE, FALSE)

¿cumple? SI NO SI NO SI SI NO NO

Criterios de cobertura
Condiciones múltiples
50

decisión IF (1) IF (1) IF (1) IF (1) IF (1) IF (1) IF (1) IF (1) IF (2) IF (2) IF (2) IF (2) IF (3) IF (3) IF (3) IF (3)

edad <30 <30 <30 <30 >=30 >=30 >=30 >=30

¿trabaja? TRUE TRUE FALSE FALSE TRUE TRUE FALSE FALSE TRUE TRUE FALSE FALSE

¿hijos? TRUE FALSE TRUE FALSE TRUE FALSE TRUE FALSE TRUE FALSE TRUE FALSE

>60 y < 70 >60 y >= 70 <= 60 y <70 <= 60 y >= 70

caso de prueba 1- (20, TRUE, TRUE) 2- (20, TRUE, FALSE) 3- (20, FALSE, TRUE) 4- (20, FALSE, FALSE) 5- (65, TRUE, TRUE) 6- (65, TRUE, FALSE) 7- (70, FALSE, TRUE) 8- (50, FALSE, FALSE) 5- (65, TRUE, TRUE) 6- (65, TRUE, FALSE) 7- (70, FALSE, TRUE) 8- (50, FALSE, FALSE) 6- (65, TRUE, FALSE) 7- (70, FALSE, TRUE) 8- (50, FALSE, FALSE) no hay opción

1/12

Criterios de cobertura
Caminos
 

51

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

2/12

Criterios de cobertura
Caminos

52

Fases para realizar el criterio
1. 2. 3.

Identificar nodos
Dibujar grafo Calcular la complejidad ciclomática
Cuantifica la complejidad lógica

4.

Determinar el conjunto de caminos linealmente independientes Crear casos de prueba

5.

3/12

Criterios de cobertura
Caminos

53

Nodos. Sentencias
de código agrupadas

1- Identificar nodos
 ¿Cuántos nodos?

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

3 4

1 2 6 9 10 11 12 5 8

7

4/12

Criterios de cobertura
Caminos

54

2- Dibujar grafo
IF-ELSE
false

Aristas. Líneas que unen dos nodos
Regiones. Áreas delimitadas por aristas y nodos

true

secuencia

5/12

Criterios de cobertura
Caminos

55

2- Dibujar grafo
DO-WHILE

WHILE

true

false

true

false

6/12

Criterios de cobertura
Caminos

56

2- Dibujar grafo
IF múltiple

SWITCH

m
false low medium true true

high

n
false

7/12

Criterios de cobertura
Caminos

57

2- Dibujar grafo

1 2 3
false

6 8

4
5

7
false

9
false

10
true

11

12

8/12

Criterios de cobertura
Caminos

58

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 de 1 a 10 de 11 a 20 de 21 a 50 50 o más Evaluación del riesgo sin riesgo riesgo moderado alto riesgo muy alto riesgo

9/12

Criterios de cobertura
Caminos

59

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
R1 R2 R7 R3 R4 R5

R8

R6

Número de pruebas a realizar

10/12

Criterios de cobertura
Caminos

60

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

11/12

Criterios de cobertura
Caminos

61

4- Determinar el conjunto de caminos independientes
1  2  3  4  5  12 1  2  6  7  9  12 1  2  3  6  7  9  12

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

1  2  3  4  6  7  9  12
1  2  6  8  9  12 1  2  6  7  8  9  12 1  2  6  7  9  10  12

1  2  6  7  9  10  11  12

12/12

Criterios de cobertura
Caminos

1.

62

5- Crear casos de prueba
1  2  3  4  5  12 Camino 1  beca(20, FALSE, TRUE) 1  2  6  7  9  12 Camino 2  beca(40, FALSE, TRUE) 1  2  3  6  7  9  12 Camino 3  no es posible 1  2  3  4  6  7  9  12 Camino 4  no es posible 1  2  6  8  9  12 Camino 5  beca(40, TRUE, TRUE) 1  2  6  7  8  9  12 Camino 6  beca(40, FALSE, FALSE) 1  2  6  7  9  10  12 Camino 7  beca(100, FALSE, TRUE) 1  2  6  7  9  10  11  12 Camino 8  beca(65, FALSE, TRUE)

2.

3.

4.

5.

6.

7.

8.

1/4

Criterios de cobertura
Bucles

63

Los bucles son clave en la mayoría de los algoritmos Requieren un tratamiento especial Instrucciones típicas
 For  While

 Do

While

2/4

Criterios de cobertura
Bucles

64

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

3/4

Criterios de cobertura
Bucles

65

Bucles anidados
 Reglas
 Comenzar en el bucle más interno
 

Realizar pruebas de bucle simple Bucles externos  valores mínimos Realizar pruebas de bucle simple Bucles externos  valores mínimos Bucles internos  valores típicos

 Ir al siguiente nivel
  

4/4

Criterios de cobertura
Bucles

66

Bucles concatenados
 Reglas
 Si son independientes

Igual que bucles simples

 Si no son independientes

Igual que bucles anidados

¿Bucles no estructurados?

Otros criterios de cobertura
67

Métodos Hilos

Relacionales
Arrays

Criterios de cobertura
Basados en el flujo de datos
68

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?

1/6

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

69

Posibles combinaciones entre pares
Símbolos ˜d du dk ˜u ud uk ˜k ku kd dd uu kk d˜ u˜ k˜ Qué ocurre Definir directamente Definir – Usar Definir – Eliminar Usar directamente Usar – Definir Usar – Eliminar Eliminar directamente Eliminar – Usar Eliminar – Definir Definir – Definir Usar – Usar Eliminar – Eliminar Definir y no más Usar y no más Eliminar y no más Válido o no válido No hay problema No hay problema Problema potencial Problema potencial No hay problema. Se usa y luego se redefine No hay problema Problema potencial Problema potencial No hay problema Problema potencial. Se define dos veces seguidas No hay problema Problema potencial Problema potencial No hay problema No hay problema

Entornos de desarrollo

2/6

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

70

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

3/6

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

71

4/6

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

72

5/6

Criterios de cobertura
Basados en el flujo de datos. Análisis estático
Símbolos dk ˜u ˜k ku dd kk d˜ Qué ocurre Definir – Eliminar Usar directamente Eliminar directamente Eliminar – Usar Definir – Definir Eliminar – Eliminar Definir y no más Válido o no válido Problema potencial Problema potencial Problema potencial Problema potencial Problema potencial Problema potencial Problema potencial

73

Símbolos dd

Pasos 1-2-3

Conclusión Sospechoso

6/6

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

74

Símbolos dk ˜u ˜k ku dd kk d˜

Qué ocurre Definir – Eliminar Usar directamente Eliminar directamente Eliminar – Usar Definir – Definir Eliminar – Eliminar Definir y no más

Válido o no válido Problema potencial Problema potencial Problema potencial Problema potencial Problema potencial Problema potencial Problema potencial

1/3

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

75

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) ACU+P  All-du paths (ADUP)

Caminos ADUP AU APU+C

ACU

AD

APU
Decisiones Sentencias

2/3

Criterios de cobertura
Basados en el flujo de datos. Análisis dinámico
Estrategia AD Variable Bill 1-2-10 3-4-5-6 6-7 8-10 9-10 1-2-3-4-5-6-7 3-4-5-6-7 6-7 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)+ 8-10 9-10 (ACU) 3-4-5-6 6-7 6-7-8 8-10 3-4-5-9 (APU) + (ACU)+ (AU)

76

APU

ACU

APU+C

ACU+P AU

ADUP

3/3

Criterios de cobertura
Basados en el flujo de datos. Análisis dinámico
Estrategia AD APU Variable Usage 0-1-2 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 (APU) (ACU) 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 (APU) + (ACU)+ (AU)

77

ACU APU+C ACU+P AU

ADUP

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

Criterios de cobertura
Conjetura 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

79

Pruebas de caja gris
Principales preocupaciones
Registros Información saliente Residuos entrada salida

TIPOS DE PRUEBAS

Pruebas progresivas y regresivas
81

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

Objetivo

Probar un módulo software de manera independiente Caja blanca Caja negra

Técnica
 

Software para realizar este tipo de pruebas

JUnit, NUnit, …
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

Un módulo
 


Pruebas unitarias
Algunos problemas que pueden detectar…
83

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

9.

Precedencia aritmética incorrecta Cálculos incorrectos Flujos de control no adecuados Inicializaciones incorrectas Falta de precisión Representación incorrecta de una expresión Interfaces de entrada / salida Estructuras de datos incorrectas Tratamiento de errores equivocado

Pruebas de integración
84

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ón
Algunos problemas que pueden detectar…
85

1. 2. 3. 4. 5.

6.
7. 8. 9. 10.

Problemas de configuración Problemas en métodos Llamadas a métodos equivocados Fallos en los parámetros Mal uso de bases de datos y de ficheros Fallos en la integridad de los datos Fallos con polimorfismo Problemas de memoria Conflictos entre componentes Mal uso de los recursos (memoria, disco, …)

1/2

Pruebas de integración
Estrategia incremental ascendente
Módulo principal 1

86

2

3

7 4 5

8 11

9
6 10 12

Módulos de bajo nivel

2/2

Pruebas de integración
Estrategia incremental ascendente

87

1

2

3

Controlador 1

Controlador 2

Controlador 3

7 4 5 9 6 10

8 11 12

Pruebas de integración
Estrategia incremental descendente
88

1
Resguardo 1 Resguardo 2

2

3

7
4 5

8
11

9
6 10 12

Pruebas de integración
Integració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 sistema
90

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

1/6

Pruebas de sistema
Diferentes 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

2/6

Pruebas de sistema
Diferentes pruebas

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?

3/6

Pruebas de sistema
Diferentes pruebas

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

4/6

Pruebas de sistema
Diferentes pruebas

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

5/6

Pruebas de sistema
Diferentes pruebas

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

6/6

Pruebas de sistema
Diferentes pruebas

96

Disponibilidad / Servicio

Comprobar que las condiciones de disponibilidad son las adecuadas Identificar las condiciones máximas en las que el software fallará en procesarlas dentro de un periodo de tiempo determinado Probar que una aplicación funciona después de traducirla a otra ¿cultura?

Estrés

Localización

Otros tipos de prueba de sistema

 

Homologación Interoperabilidad Solidez

Pruebas de implantación
97

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ón
98

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

Objetivo

Encontrar problemas en las interfaces de usuario Caja negra

Técnica

 

Suelen realizarse muy pronto en el ciclo de desarrollo Aspectos a tener en cuenta
   

Accesibilidad Calidad de respuesta Eficiencia Comprensibilidad Exactitud Tiempo Recuerdo Respuesta emocional

Métricas

  

Pruebas Alfa y Beta
100

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

JUnit
102

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

Casos de prueba
103

Es la unidad mínima de trabajo de JUnit Extiende junit.framework.TestCase
  

public void 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 4
104

A partir de JUnit 4 se soportan anotaciones
 

No hace falta extender ninguna clase No hace falta poner nombres fijos a los métodos

Anotaciones
105

Permiten probar cualquier clase (POJO, Plain Old Java Object)
Parámetros Ninguno Ninguno Ninguno Ninguno Un String opcional Ninguno Una Class Empleo Método que se ejecuta después de cada método de prueba Método que se ejecuta después de todos los métodos @Test y de todos los @After Método que se ejecuta antes de cada método de prueba Método que se ejecuta antes de todos los métodos @Test y de todos los @Before Método para temporalmente decirle a JUnit que ignore un método de prueba Método que devuelve una colección de objetos. Éstos a su vez son pasados al constructor Método que sirve para especificar cambios respecto a qué tipo de ejecución se llevará a cabo Método que sirve para especificar, mediante una anotación, los TestCases que se van a probar en una agrupación de prueba (TestSuite) 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

Anotación
@After @AfterClass @Before @BeforeClass @Ignore @Parameters @RunWith

@SuiteClasses

Un array de Class

@Test

expected (opcional) timeout (opcional)

Garantías de orden

Asserts
106

Un Assert es una Afirmación que hace alguien
Para qué sirve Valida si x es null Valida si x no es null Valida si x es true Valida si x es false Valida si x e y son iguales. Utiliza el método de Java equals(Object obj1, Object obj2) Valida si x e y son iguales. Utiliza el operador == Valida si x e y no son iguales. Utiliza el operador == Falla un test de manera programática

Afirmación
assertNull(Object x) assertNotNull(Object x) assertTrue(boolean x) assertFalse(boolean x) assertEquals(Object x, Object y) assertSame(Object x, Object y) assertNotSame(Object x, Object y) fail()

 

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

Botón Derecho  Run As  JUnit Test

Conjuntos de pruebas (SuiteCase)
108  

Es una colección de casos de prueba (TestCase) Sirve para clasificarlos

EasyMock
109

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
Crear Grabar Reproducir Verificar

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 objetos Mock
110

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

.atLeastOnce() .times(int min, int max) .anyTimes()

Métodos que lanzan excepciones

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

Preparación para reproducir Reproducciones

Validación

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

CodeCover
113

http://www.codecover.org/

Cobertura de código
aplicación Java en Eclipse

aspecto de la aplicación en funcionamiento

114

Uso de la herramienta
1- activar CodeCover 2- seleccionar las clases a estudiar

3- ejecutar la aplicación con CodeCover

Varias formas de trabajo

Métricas de CodeCover
115

1.

2.
3. 4.

5.
6.

Statement Coverage Branch Coverage Term Coverage Loop Coverage Question mark operator (?) Coverage Synchronized Coverage

1/3

Informes generados
116

2/3

Informes generados
117

3/3

Informes generados
118

JMeter
119

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 Thread groups Timers Listeners Target Web Page

Elementos
   

Otras herramientas
120

     


     

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ácticos
121

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ácticos
122 

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ácticos
123


 

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ácticos
124 

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ía
125

Sign up to vote on this title
UsefulNot useful