PRUEBAS

Fundamentos de Ingeniera del Software

Vicente Garca Daz
Csar Fernndez Acebal
Juan Manuel Cueva Lovelle
Escuela de Ingeniera Informtica
Universidad de Oviedo
Curso 2010-2011
garciavicente@uniovi.es
Vicente Garca Daz
Algunos problemas famosos
F-16 (1986)
Therac-25 (1985-1987)
Misil Patriot (1991)
Ariadne 5 (1996)
Mars Climate Orbiter (1999)
Multidata Software (2001)
2
Ubicacin general
Son necesarias
Por qu hacer pruebas?
Desarrollos en cascada o iterativos
Pruebas vs otras etapas de desarrollo
Software ms complejo y crtico
Costes ocasionados por los fallos muy altos
Anlisis Diseo Codificacin Pruebas
3
Inicio
operacin
Revisin
Conceptos bsicos
Un del programador ocasiona un , el
cual produce un
Error es una accin humana equivocada
Defecto es una definicin 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/3
error
defecto
fallo
Conceptos bsicos
Prueba
Es un proceso crtico en el que un software o uno de sus
componentes se ejecuta en circunstancias previamente
planificadas con el objetivo bsico de encontrar errores
Los resultados se observan, se guardan y se evalan
Ciclo de prueba
Es una actividad compuesta:
Formar una idea de los resultados aceptables para
determinados valores de entrada
Se ejecuta el software dndole los valores determinados en
unas condiciones especficas
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 bsicos
Caso de prueba
Es un escenario concreto de una prueba:
Identificador
Componente a probar
Condiciones de entrada
Datos de entrada
Salida esperada
Cuntos 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
Caractersticas de las pruebas
8
Son siempre necesarias y crticas
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 crticas para garantizar la calidad del software
Slo pueden demostrar la existencia de defectos
No pueden ser completas
Pueden planificarse con mucha antelacin
Son ms efectivas si las dirige un equipo
independiente
Deberan:
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 deberan:
Ser redundantes
Ser demasiado complejas
Dar por supuesto que un software no tendr defectos
9
Lo que deberan y no deberan hacer
Falsos mitos sobre pruebas
Los desarrolladores de un mdulo no deberan
probar dicho mdulo
El software no debera 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 bsico del proceso
Informes
11
Planificar
[Piattini et al., 96]
Disear Ejecutar
Evaluar Depurar
Analizar
Desarrollo
Resultados esperados
Fallos encontrados
Plan de pruebas Casos de prueba
Informacin del proyecto
Resultados
Planificacin de la prueba
Identificacin
Enfoque
Informe de incidencias
Criterio de suspensin
Productos a entregar
Tareas a realizar
Necesidades ambientales
Responsabilidades
Personal necesario
Calendario
Riesgos
12
Diseo de la prueba
Criterios utilizados para obtener los casos de prueba
Casos de prueba organizados
Unidad, Integracin, Sistema,
Resultado esperado
Requisitos que se estn probando
Datos de prueba
Criterios de terminacin
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
Depuracin del software
Lo que se hace cuando un caso de prueba tiene xito
Fases de la depuracin
Localizar el defecto
Corregir el defecto
Tcnicas ms utilizadas para localizar el defecto
Fuerza bruta
Rastreo hacia atrs
Eliminacin de causas
14
Espacio conceptual
Caso de prueba
Prueba
Fallo Estado errneo Defecto
Correccin
Resguardo
Controlador
Componente
15
[Bruegge and Dutoit, 04]
* 1..n
*
*
*
*
* * * *
Taxonoma de gestin de defectos
Manejo de
defectos
Evitacin de
defectos
Deteccin de
defectos
Tolerancia a
defectos
Revisin
Gestin de la
configuracin
Metodologa
Transacciones
atmicas
Manejo de
excepciones
...
Pruebas de
integracin
Pruebas
unitarias
Pruebas Depuracin
[Bruegge and Dutoit, 04]
16
Estndares relacionados con pruebas
IEEE 730 asegurar la calidad del software
IEEE 829 documentacin de las pruebas
IEEE 830 especificaciones de los requisitos de sistemas
IEEE 1008 pruebas unitarias
IEEE 1012 verificacin y validacin del software
IEEE 1028 inspecciones en software
IEEE 1044 clasificacin de las anomalas software
IEEE 1061 mtricas sobre calidad del software
IEEE 12207 proceso del ciclo de vida del software y de los datos
BS 7925-1 vocabulario de trminos 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 pruebas
18
usuario cliente desarrollador
Pruebas de usabilidad
Pruebas unitarias
Pruebas de integracin
Pruebas de sistema
Pruebas de implantacin
Pruebas de aceptacin
Pruebas alfa y beta
TCNICAS DE PRUEBAS
Principales preocupaciones
Funcionalidad
Entradas
Salidas
Pruebas de caja negra
20
funcionalidad
entrada salida
Criterios de cobertura
Particiones / Clases de equivalencia
Modelos (criterios)
Consiste en reducir el nmero de casos de prueba:
Cmo?
Dividindolos en conjuntos de datos equivalentes
Dos fases
1. Identificar clases de equivalencia
Es un conjunto de datos de entrada equivalentes
Clases de equivalencia vlidas valores esperados
Clases de equivalencia no vlidas 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
Especificacin de entrada Clases de equivalencia
vlidas
Clases de equivalencia no
vlidas






Criterios de cobertura
Particiones de equivalencia
1- Identificar clases de equivalencia
Un valor numrico nico
Ejemplo: El ao tiene que ser 2005
Vlida: 2005
No vlida 1: ao < 2005
No vlida 2: ao > 2005
Rango de valores numricos
Ejemplo: Una cadena de texto tiene entre 10 y 15 letras
Vlida: entre 10 y 15 letras
No vlida 1: < 10 letras
No vlida 2: > 15 letras
23
3/7
Criterios de cobertura
Particiones de equivalencia
1- Identificar clases de equivalencia
Un valor nico no numrico
Ejemplo: El color tiene que ser rojo
Vlida: color rojo
No vlida: otro color
Conjunto de valores
Ejemplo: La profesin puede ser camionero, piloto o albail
Vlida: profesin camionero, piloto o albail
No vlida: otra profesin
Sin embargo, si el programa los tratara de forma diferente
Habra que crear una clase vlida por cada profesin
24
4/7
Criterios de cobertura
Particiones de equivalencia
1- Identificar clases de equivalencia
Y las entradas mltiples?
Hay que realizar el producto cartesiano
25
5/7
[http://www.uv.mx/jfernandez/]
Criterios de cobertura
Particiones de equivalencia
2- Identificar casos de prueba
Pasos:
Cubrir absolutamente todas las clases de equivalencia
Para las clases de equivalencia vlidas
Un caso de prueba tantas clases de equivalencia como sea
posible
Para las clases de equivalencia no vlidas
Un caso de prueba una clase de equivalencia
Ejemplo: nmeros de telfono
Dos clases de equivalencia no vlidas:
El nmero mvil no empieza por +34
Despus del cdigo del pas no hay 9 cifras
Si se cubrieran con un mismo caso de prueba el usuario podra
introducir como entrada:
-40 677 00 00 00 000000
Podran enmascararse errores no controlados
26
6/7
Criterios de cobertura
Particiones de equivalencia
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
programacin
Especificacin de entrada:
Los identificadores tienen entre 2 y 10 caracteres
El lenguaje distingue entre minsculas y maysculas
Se podrn utilizar letras, dgitos 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
Especificacin de entrada Clases de equivalencia
vlidas
Clases de equivalencia no
vlidas
Entre 2 y 10 caracteres 1- 2 <= car <= 10 2- car < 2
3- car > 10
Letras, dgitos y guiones
bajos
4- identificadores
formados por letras,
dgitos y guiones
5- un identificador con
caracteres que no
sean letras, dgitos o
guiones
Empieza por letra 6- el primer carcter
tiene que ser una
letra
7- el primer carcter 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 maysculas 10- identificador vlido 11- referenciar a un
identificador
intercambiando
alguna letra
maysculas /
minsculas

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

Especificacin de entrada Clases de equivalencia
vlidas
Clases de equivalencia no
vlidas
Entre 2 y 10 caracteres 1- 2 <= car <= 10 2- car < 2
3- car > 10
Letras, dgitos y guiones
bajos
4- identificadores
formados por letras,
dgitos y guiones
5- un identificador con
caracteres que no
sean letras, dgitos o
guiones
Empieza por letra 6- el primer carcter
tiene que ser una
letra
7- el primer carcter 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 maysculas 10- identificador vlido 11- referenciar a un
identificador
intercambiando
alguna letra
maysculas /
minsculas

Criterios de cobertura
Anlisis de valores lmite
Qu son los valores lmite?
Son aquellos que estn en los mrgenes de las clases
de equivalencia
Los casos de prueba que exploran los valores
lmites producen mejores resultados
Entonces hay que:
Seleccionar casos de prueba en los extremos
Fijarse tambin en las especificaciones de salida
31
1/2
Criterios de cobertura
Anlisis de valores lmite
Cmo disear los casos de prueba?
32
2/2
Especificacin para ENTRADA o SALIDA Criterio para obtener casos de prueba
Valor numrico nico - Caso para el valor numrico
- Caso para el valor justo por encima
- Caso para el valor justo por debajo
Rango de valores numricos - Caso para el valor mximo del rango
- Caso para el valor mnimo 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

Especificacin de entrada Clases de equivalencia
vlidas
Clases de equivalencia no
vlidas
Entre 2 y 10 caracteres 1- 2 <= car <= 10 2- car < 2
3- car > 10
Letras, dgitos y guiones
bajos
4- identificadores
formados por letras,
dgitos y guiones
5- un identificador con
caracteres que no
sean letras, dgitos o
guiones
Empieza por letra 6- el primer carcter
tiene que ser una
letra
7- el primer carcter 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 maysculas 10- identificador vlido 11- referenciar a un
identificador
intercambiando
alguna letra
maysculas /
minsculas

Criterios de cobert.
Anlisis de valores lmite. Ejemplo
33
Caso de prueba
(identificador)
Valor lmite estudiado Resultado
Identifi10 Caso para el valor mximo del
rango
El identificador es aceptado
por el sistema
K2 Caso para el valor mnimo 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

Especificacin 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
Criterios de cobertura
Grafo Causa Efecto
Ejemplo
Se quiere sacar dinero de un cajero
Causas (condiciones a cumplir)
1- La tarjeta es vlida
2- La clave de usuario es correcta
3- Se pasa el n mximo
4- Hay dinero disponible
Efectos
50- Sale el dinero
51- Rechaza la tarjeta
52- Pregunta otra clave
53- Rechaza la operacin
35
2/3
Causas Regla 1 Regla 2 Regla 3 Regla 4
1 La tarjeta es vlida NO SI SI -
2 Clave correcta - SI NO -
3 Sobrepasa el n mximo - - NO SI
4 Hay dinero disponible - SI - NO

Criterios de cobertura
Grafo Causa Efecto
Ejemplo
Tabla de decisin
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
Cundo 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 estarn todas las
combinaciones posibles de pares, sin repetirse
ninguna
Estudios empricos
37
1/6
Criterios de cobertura
Matrices ortogonales
Proceso
1. 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
Criterios de cobertura
Matrices ortogonales
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
39
3/6
Criterios de cobertura
Matrices ortogonales
3- Encontrar una matriz ortogonal adecuada
N de variables 4 4 columnas
N de posibilidades de cada columna 3
L
9
(3
4
) Slo 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

Criterios de cobertura
Matrices ortogonales
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
1IE 8
2Firefox 3.6
3Google Chrome
Plugins:
1Real Player
2Media Player
3Ninguno.
Servidores de aplicaciones:
1IIS
2Apache
3JBoss
Sistemas operativos:
1Windows Vista
2Windows 7
3Linux
Criterios de cobertura
Matrices ortogonales
No todas las combinaciones dadas por la matriz tienen
que ser vlidas
Otros ejemplos de matrices ortogonales
L
4
(2
3
) En lugar de 8 pruebas, se hacen 4
L
8
(2
4
4
1
) En lugar de 64, se hacen 8
L
18
(3
6
6
1
) En lugar de 4374, se hacen 18
A veces no existe una matriz perfecta, pero se puede
seleccionar una un poco ms grande
42
6/6
A medida que aumentan los factores, la ganancia es mucho mayor
Criterios de cobertura
Enfoque aleatorio
43
Utilizado generalmente cuando no hay ms
tiempo
Se simula la entrada de datos
Se pueden utilizar modelos estadsticos
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
mquina puede hacer pruebas todo el da
Principales preocupaciones
Ramificaciones del cdigo
Manejo de recursos del sistema
Manejo de errores
Trabajo como se espera
-Caja negra y caja blanca
Pruebas de caja blanca
44
entrada salida
Anlisis de la cobertura de cdigo
Es el proceso de:
Encontrar fragmentos del software no ejecutados
Crear casos de prueba adicionales
Determinar un valor cuantitativo de la cobertura
NOes necesario cubrir siempre todo el cdigo
NOmide la calidad del producto software
45
Criterios de cobertura
Sentencias
Ejemplos de cobertura
ajuste(1, 10, 0)
ajuste(1, 11, 15)
46
decisin 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 cobertura
Decisiones
47
Decisiones vs Sentencias
decisin 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 cobertura
Condiciones
48
Condiciones vs Decisiones
Condiciones vs Sentencias
decisin 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 cobertura
Decisiones / condiciones
49
decisin 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 opcin
Criterios de cobertura
Condiciones mltiples
50
Criterios de cobertura
Caminos
Un criterio muy utilizado
Camino
Secuencia de pasos, desde el inicial hasta la final
Camino de prueba
Camino que atraviesa como mximo 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 dibujramos como una grafo, se
correspondera con dibujar una nueva arista que no haya sido
recorrida anteriormente por otro camino
1/12
51
Criterios de cobertura
Caminos
Fases para realizar el criterio
1. Identificar nodos
2. Dibujar grafo
3. Calcular la complejidad ciclomtica
Cuantifica la complejidad lgica
4. Determinar el conjunto de caminos linealmente
independientes
5. Crear casos de prueba
2/12
52
Criterios de cobertura
Caminos
53
Nodos. Sentencias
de cdigo agrupadas
Nodos predicado.
Nodos surgidos de
cada condicin de
una decisin
1- Identificar nodos
Cuntos nodos?
3/12
1
2
3
4
5
6
7
8
9
10
11
12
Criterios de cobertura
Caminos
2- Dibujar grafo
4/12
54
IF-ELSE
true
false
secuencia
Aristas. Lneas que
unen dos nodos
Regiones. reas
delimitadas por
aristas y nodos
Criterios de cobertura
Caminos
2- Dibujar grafo
5/12
55
WHILE DO-WHILE
true
false
true
false
Criterios de cobertura
Caminos
2- Dibujar grafo
6/12
56
SWITCH
m
n
IF mltiple
low
true
medium
high
true false
false
Criterios de cobertura
Caminos
2- Dibujar grafo
1
8
9
7
6
5
4
3
2
11
10
12
false
false
false
true
57
7/12
Criterios de cobertura
Caminos
3- Calcular la complejidad ciclomtica
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 condicin
Complejidad ciclomtica Evaluacin del riesgo
de 1 a 10 sin riesgo
de 11 a 20 riesgo moderado
de 21 a 50 alto riesgo
50 o ms muy alto riesgo
58
8/12
Criterios de cobertura
Caminos
3- Calcular la complejidad ciclomtica
V(G) = A N + 2 = 18 12 + 2 = 8
V(G) = R = 7 + la regin externa = 8
V(G) = C + 1 = 7 + 1 = 8
Nmero de pruebas a realizar
59
9/12
R1
R2
R3
R4
R5
R6
R7
R8
Criterios de cobertura
Caminos
4- Determinar el conjunto de caminos
independientes
Heursticos
Elegir un camino principal (el ms corto hasta el final)
Identificar un segundo camino
Aadiendo alguna arista nueva
pero tratando que sea el camino en el que menos se aaden
Seguir identificando caminos hasta que no haya ms
posibilidades
60
10/12
Criterios de cobertura
Caminos
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
Criterios de cobertura
Caminos
5- Crear casos de prueba
1. 1 2 3 4 5 12
Camino 1 beca(20, FALSE, TRUE)
2. 1 2 6 7 9 12
Camino 2 beca(40, FALSE, TRUE)
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
Camino 7 beca(100, FALSE, TRUE)
8. 1 2 6 7 9 10 11 12
Camino 8 beca(65, FALSE, TRUE)
12/12
62
Criterios de cobertura
Bucles
Los bucles son clave en la mayora de los
algoritmos
Requieren un tratamiento especial
Instrucciones tpicas
For
While
Do While
63
1/4
Criterios de cobertura
Bucles
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
Criterios de cobertura
Bucles
Bucles anidados
Reglas
Comenzar en el bucle ms interno
Realizar pruebas de bucle simple
Bucles externos valores mnimos
Ir al siguiente nivel
Realizar pruebas de bucle simple
Bucles externos valores mnimos
Bucles internos valores tpicos
65
3/4
Criterios de cobertura
Bucles
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
Mtodos
Hilos
Relacionales
Arrays
67
Criterios de cobertura
Basados en el flujo de datos
Los programas son algo ms que flujos de control
Tambin tienen datos
Categoras 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
Esttica* Identifica anomalas
Dinmica Ejecuta el cdigo, similar a las pruebas de
flujo de control
Por qu no es suficiente con la versin esttica?
68
Smbolos Qu ocurre Vlido o no vlido
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 ms Problema potencial
u Usar y no ms No hay problema
k Eliminar y no ms No hay problema

Criterios de cobertura
Basados en el flujo de datos. Anlisis esttico
Posibles combinaciones entre pares
Entornos de desarrollo
69
1/6
Criterios de cobertura
Basados en el flujo de datos. Anlisis esttico
70
2/6
[ftp.ncsu.edu/pub/tech/2006/TR-2006-22.pdf /]
Criterios de cobertura
Basados en el flujo de datos. Anlisis esttico
71
3/6
Criterios de cobertura
Basados en el flujo de datos. Anlisis esttico
72
4/6
Criterios de cobertura
Basados en el flujo de datos. Anlisis esttico
73
5/6
Smbolos Qu ocurre Vlido o no vlido
dk Definir Eliminar Problema potencial
u Usar directamente Problema potencial
k Eliminar directamente Problema potencial
ku Eliminar Usar Problema potencial
dd Definir Definir Problema potencial
kk Eliminar Eliminar Problema potencial
d Definir y no ms Problema potencial

Smbolos Pasos Conclusin
dd 1-2-3 Sospechoso

Smbolos Qu ocurre Vlido o no vlido
dk Definir Eliminar Problema potencial
u Usar directamente Problema potencial
k Eliminar directamente Problema potencial
ku Eliminar Usar Problema potencial
dd Definir Definir Problema potencial
kk Eliminar Eliminar Problema potencial
d Definir y no ms Problema potencial

Criterios de cobertura
Basados en el flujo de datos. Anlisis esttico
74
6/6
Criterios de cobertura
Basados en el flujo de datos. Anlisis dinmico
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
APU AD
Decisiones
Sentencias
Criterios de cobertura
Basados en el flujo de datos. Anlisis dinmico
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)

Criterios de cobertura
Basados en el flujo de datos. Anlisis dinmico
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 slo faltara 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
Clculos
Manejo de colecciones de datos
Manejo de ficheros
Permisos de los usuarios
Usabilidad
Interfaces para otros sistemas
Uniones y comparaciones de datos
Bsquedas de datos
2- Crear los casos de prueba
Principales preocupaciones
Registros
Informacin saliente
Residuos
Pruebas de caja gris
79
entrada salida
TIPOS DE PRUEBAS
Pruebas progresivas y regresivas
81
Pruebas progresivas
Realizacin de pruebas para tratar de encontrar
errores en partes nuevas de un software
Pruebas regresivas
Repeticin selectiva de pruebas para estudiar
efectos adversos cuando se introducen cambios
Probabilidad de introducir errores 50-80%
Pruebas unitarias
82
Objetivo
Probar un mdulo software de manera independiente
Tcnica
Caja blanca
Caja negra
Software para realizar este tipo de pruebas
JUnit, NUnit,
Un mdulo
Es un bloque bsico de construccin
Tiene una funcin independiente
Puede ser probado por separado
No suele tener ms de 500 lneas de cdigo
Pruebas unitarias
Algunos problemas que pueden detectar
83
1. Precedencia aritmtica incorrecta
2. Clculos incorrectos
3. Flujos de control no adecuados
4. Inicializaciones incorrectas
5. Falta de precisin
6. Representacin incorrecta de una expresin
7. Interfaces de entrada / salida
8. Estructuras de datos incorrectas
9. Tratamiento de errores equivocado
Pruebas de integracin
84
Objetivo
Verificar el correcto ensamblaje de los mdulos
Asegurando que interactan correctamente
Regresin
Tcnica
Caja negra
Estrategias principales
No incremental
Incremental
Pruebas de integracin
Algunos problemas que pueden detectar
85
1. Problemas de configuracin
2. Problemas en mtodos
3. Llamadas a mtodos equivocados
4. Fallos en los parmetros
5. Mal uso de bases de datos y de ficheros
6. Fallos en la integridad de los datos
7. Fallos con polimorfismo
8. Problemas de memoria
9. Conflictos entre componentes
10. Mal uso de los recursos (memoria, disco, )
Pruebas de integracin
Estrategia incremental ascendente
86
4
6
5
7 8
9
11
12
10
2 3
1
1/2
Mdulo principal
Mdulos de bajo nivel
Pruebas de integracin
Estrategia incremental ascendente
87
4
6
5
7 8
9
11
12
10
Controlador 1
2 3
1
Controlador 2 Controlador 3
2/2
Pruebas de integracin
Estrategia incremental descendente
88
4
6
5
7 8
9
11
12
10
2 3
1
Resguardo 1 Resguardo 2
Pruebas de integracin
Integracin ascendente VS integracin descendente
89
Ventaja de la integracin descendente
Se prueba primero el mdulo principal
Ventaja de la integracin ascendente
No se necesitan resguardos
Los resguardos son ms complejos que los controladores
Integracin mixta
Pruebas de sistema
90
Objetivo
Comprobar la integracin del sistema visto desde el
punto de vista global
Tcnica
Caja negra
Idealmente las hace un equipo
independiente
Se basan en la especificacin de
requisitos
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
Generacin de los casos de prueba
Se toma un caso de uso por su camino tpico 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 algn recurso
Imposibilidad de acceder a recursos
Equivocaciones de los usuarios
Situaciones de medio ambiente
1/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 podra 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.
Cuntos casos de prueba podran realizarse con este caso
de uso?
2/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 aplicacin es segura de acuerdo con
sus necesidades
3/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 ms recursos de
los requeridos (por ejemplo memoria RAM,
procesador, disco duro, etc.)
Configuracin
Comprobar que el software funciona correctamente
con otras configuraciones software / hardware
4/6
Pruebas de sistema
Diferentes pruebas
95
Compatibilidad
Asegurar que los requisitos de compatibilidad hacia
atrs se cumplen y si los mtodos de actualizacin
funcionan
Instalacin
Determinar si la instalacin y desinstalacin del
software funciona correctamente en todos los casos
Recuperacin
Determinar si el software cumple con los requisitos de
recuperacin ante fallos inesperados
5/6
Pruebas de sistema
Diferentes pruebas
96
Disponibilidad / Servicio
Comprobar que las condiciones de disponibilidad son las
adecuadas
Estrs
Identificar las condiciones mximas en las que el software
fallar en procesarlas dentro de un periodo de tiempo
determinado
Localizacin
Probar que una aplicacin funciona despus de traducirla a otra
cultura?
Otros tipos de prueba de sistema
Homologacin
Interoperabilidad
Solidez
6/6
Pruebas de implantacin
97
Objetivo
Comprobar la correcta instalacin en el entorno
objetivo
Tcnica
Caja negra
Aspectos a tener en cuenta
Recuperacin
Seguridad
Rendimiento
Comunicaciones
Pruebas de aceptacin
98
Objetivo
Validar que un sistema cumple con lo esperado
Permitir que el cliente acepte el sistema
desde todos los puntos de vista
contrato
Tcnica
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
Tcnica
Caja negra
Suelen realizarse muy pronto en el ciclo de desarrollo
Aspectos a tener en cuenta
Accesibilidad
Calidad de respuesta
Eficiencia
Comprensibilidad
Mtricas
Exactitud
Tiempo
Recuerdo
Respuesta emocional
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 organizacin que desarroll el software
Beta
Subconjunto seleccionado (o no) de los usuarios reales
No pertenecen a la organizacin
La motivacin es importante
Regresivas o progresivas?
Alfa vs Beta
Qu problema tienen las pruebas Beta?
HERRAMIENTAS
JUnit
102
http://www.junit.org/
Es el estndar de facto para pruebas unitarias
Tambin hay NUnit, CppUnit, PyUnit,
Muy extendidas
Eclipse, Netbeans,
Ciclo de vida
Preparar Ejecutar Evaluar Limpiar
Casos de prueba
103
Es la unidad mnima 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
cdigo pero en el mismo paquete
que la clase a probar. As se
podr acceder a mtodos 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 mtodos
Anotacin Parmetros Empleo
@After
Ninguno Mtodo que se ejecuta despus de cada mtodo
de prueba
@AfterClass
Ninguno Mtodo que se ejecuta despus de todos los
mtodos @Test y de todos los @After
@Before
Ninguno Mtodo que se ejecuta antes de cada mtodo de
prueba
@BeforeClass
Ninguno Mtodo que se ejecuta antes de todos los
mtodos @Test y de todos los @Before
@Ignore
Un String opcional Mtodo para temporalmente decirle a JUnit que
ignore un mtodo de prueba
@Parameters
Ninguno Mtodo que devuelve una coleccin de objetos.
stos a su vez son pasados al constructor
@RunWith
Una Class Mtodo que sirve para especificar cambios
respecto a qu tipo de ejecucin se llevar a
cabo
@SuiteClasses
Un array de Class Mtodo que sirve para especificar, mediante una
anotacin, los TestCases que se van a probar
en una agrupacin de prueba (TestSuite)
@Test
expected (opcional)
timeout (opcional)
Mtodo de pruebas. expected sirve para
especificar una excepcin esperada. timeout
sirve para especificar el tiempo (en ms) mximo
permitido de ejecucin

Anotaciones
105
Permiten probar cualquier clase (POJO, Plain Old Java Object)
Garantas de orden
Afirmacin 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 mtodo 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 programtica

Asserts
106
Un Assert es una Afirmacin que hace alguien
Si se valida la afirmacin el mtodo de test pasa la prueba
Con que slo una de las afirmaciones no se cumpla el
mtodo de test NO pasa la prueba
Ejemplo de uso de Asserts
107
Botn Derecho Run As JUnit Test
Conjuntos de pruebas (SuiteCase)
108
Es una coleccin 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
Dnde 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
Crear objetos Mock
110
Creacin de objetos Mock directa
Los objetos Mock y su validacin son independientes
EasyMock.createMock(myInterface.class)
EasyMock.createNiceMock(myInterface.class)
EasyMock.createStrictMock(myInterface.class)
Creacin de objetos Mock mediante un control
Los objetos Mock estn relacionados a travs del control
Grabar el comportamiento en objetos Mock
111
Mtodos que devuelven void
Mtodos que no devuelven void
Mtodos 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 mtodos
se han llamado las veces oportunas
Qu pasa si..
Hacemos una llamada ms al mtodo sumar? Y al restar?
Si utilizamos createNiceMocky hacemos una llamada ms al mtodo sumar?
Si utilizamos createNiceMock y quitamos la llamada al mtodo restar?
Si utilizamos createStrictMock?
Preparacin para reproducir
Reproducciones
Validacin
CodeCover
113
http://www.codecover.org/
Cobertura de cdigo
aplicacin Java en Eclipse
aspecto de la aplicacin en
funcionamiento
Uso de la herramienta
Varias formas de trabajo
1- activar CodeCover
2- seleccionar las clases a
estudiar
3- ejecutar la aplicacin con CodeCover
114
Mtricas de CodeCover
1. Statement Coverage
2. BranchCoverage
3. TermCoverage
4. LoopCoverage
5. Question mark operator (?) Coverage
6. SynchronizedCoverage
115
Informes generados
1/3
116
Informes generados
2/3
117
Informes generados
3/3
118
JMeter
119
http://jakarta.apache.org/jmeter/
Pruebas de carga, de estrs, de rendimiento
Diferentes protocolos
Plan de Test
Se pueden ir aadiendo elementos de forma jerrquica
Elementos
Thread groups
Timers
Listeners
Target Web Page
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 prcticos
121
Clases de equivalencia y valores lmite. Se ha creado un subsistema que
comprueba si un identificador es correcto. Un identificador tiene las
siguientes caractersticas:
Entre 4 y 20 caracteres
Letras vlidas (a-z, A-Z)
Dgitos vlidos (2-8)
Caracteres especiales vlidos: % y
Como mnimo tendr 2 letras (mnimo 1 en maysculas), 1 carcter especial y 1 dgito
El primer y el ltimo carcter 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 parmetros (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 prcticos
122
Grafo causa - efecto. Se ha creado un software que admite como
entrada un nico parmetro (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 accin), o una T (de
tcnico)
Un segundo bloque, es un nmero 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 cdigo no ha sido correcto. Si el segundo bloque no es correcto,
entonces se muestra un mensaje indicando que el nmero no ha sido
correcto
Se pide crear casos de prueba adecuados para el sistema
Casos prcticos
123
En funcin del cdigo anterior, crear casos de prueba para lo siguiente:
Cobertura de caminos
Cobertura de sentencias, decisiones, condiciones, decisiones-condiciones,
condiciones mltiple
Cobertura del flujo de datos
Casos prcticos
124
En funcin del cdigo, crear
casos de prueba para lo
siguiente:
Cobertura de caminos
Cobertura de sentencias,
decisiones, condiciones,
decisiones-condiciones,
condiciones mltiple
Cobertura del flujo de datos
Bibliografa
125