Upload
vicente-garcia-diaz
View
6.121
Download
6
Embed Size (px)
DESCRIPTION
Presentación sobre Pruebas en la ingeniería del software para la asignatura de Fundamentos de ingeniería del software de la Escuela de Ingeniería Informática de Oviedo
Citation preview
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
Vicente García Díaz
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
Criterios de cobertura Particiones de equivalencia
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”
23
3/7
Criterios de cobertura Particiones de equivalencia
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
24
4/7
Criterios de cobertura Particiones de equivalencia
1- Identificar clases de equivalencia
¿Y las entradas múltiples?
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 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
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 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
Especificación de entrada Clases de equivalencia válidas
Clases de equivalencia no válidas
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
Especificación de entrada Clases de equivalencia válidas
Clases de equivalencia no válidas
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 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
Especificación de entrada Clases de equivalencia válidas
Clases de equivalencia no válidas
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.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
Criterios de cobertura Grafo Causa – Efecto
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
Criterios de cobertura Grafo Causa – Efecto
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
Criterios de cobertura Matrices ortogonales
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
Criterios de cobertura Matrices ortogonales
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
Criterios de cobertura Matrices ortogonales
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
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
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
Criterios de cobertura Matrices ortogonales
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
Criterios de coberturaCaminos
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
Criterios de coberturaCaminos
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
Criterios de coberturaCaminos
2- Dibujar grafo
4/12
54
IF-ELSE
truefalse
secuencia
Aristas. Líneas que unen dos nodos
Regiones. Áreas delimitadas por aristas y nodos
Criterios de coberturaCaminos
2- Dibujar grafo
5/12
55
WHILE DO-WHILE
true
false
truefalse
Criterios de coberturaCaminos
2- Dibujar grafo
6/12
56
SWITCH
m
n
IF múltiple
low
truemediumhigh
truefalse
false
Criterios de coberturaCaminos
2- Dibujar grafo 1
8
9
7
6
5
4
3
2
11
10
12
false
false
false
true
57
7/12
Criterios de coberturaCaminos
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
Criterios de coberturaCaminos
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
Criterios de coberturaCaminos
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
Criterios de coberturaCaminos
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 coberturaCaminos
5- Crear casos de prueba1. 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 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
Criterios de coberturaBucles
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 coberturaBucles
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
Criterios de coberturaBucles
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
Criterios de coberturaBasados en el flujo de datos. Análisis estático
70
2/6
[ftp.ncsu.edu/pub/tech/2006/TR-2006-22.pdf /]
Criterios de coberturaBasados en el flujo de datos. Análisis estático
71
3/6
Criterios de coberturaBasados en el flujo de datos. Análisis estático
72
4/6
Criterios de coberturaBasados en el flujo de datos. Análisis estático
73
5/6
Símbolos Qué ocurre Válido o no válido
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 más Problema potencial
Símbolos Pasos Conclusión
dd 1-2-3 Sospechoso
Símbolos Qué ocurre Válido o no válido
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 más Problema potencial
Criterios de coberturaBasados en el flujo de datos. Análisis estático
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
Criterios de coberturaBasados en el flujo de datos. Análisis dinámico
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 coberturaBasados en el flujo de datos. Análisis dinámico
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
Pruebas de sistemaDiferentes 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?
2/6
Pruebas de sistemaDiferentes 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
3/6
Pruebas de sistemaDiferentes 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
4/6
Pruebas de sistemaDiferentes 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
5/6
Pruebas de sistemaDiferentes pruebas
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
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
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
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
Informes generados2/3
117
Informes generados3/3
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
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