Model-Driven Test

Design

DISEÑO DE PRUEBAS BASADO EN MODELOS

Estas transparencias están basadas en las desarrolladas por Ammann & Offutt como
acompañamiento de su libro Introduction to Software Testing (2nd Edition)
 2
Complejidad del testing de
Software

 Ningún otro campo de la ingeniería construye productos tan

complicados como el software.
 De hecho, el término corrección no tiene significado en otros
contextos.
 ¿Es un edificio correcto?
 ¿Es un coche correcto?
 ¿Es la red de metro correcta?

 Al igual que otros ingenieros, debemos abstraer para reducir

la complejidad.
 Este es el propósito principal del diseño de tests basado en
modelos.
 El modelo es una estructura abstracta.
 3
Fundamentos

Edsger Wybe Dijkstra Las pruebas de

(1930-2002)
programas se pueden
usar para mostrar la
presencia de errores,
¡pero nunca para
mostrar su ausencia!
 4
Testing & Debugging

 Testing: Evaluar software observando su ejecución.

 Test Failure: Ejecución de un test que da lugar a un
fallo en el software.
 Debugging: El proceso de encontrar un defecto
(fault) a la vista de un fallo (failure).
NO TODAS LAS ENTRADAS DAN LUGAR A QUE UN
DEFECTO PROVOQUE UN FALLO
 5
Falla y Modelo de Fallas (RIPR)

 Se deben dar cuatro condiciones para observar un

fallo.
1. Reachability (Accesibilidad): Lugar (o lugares) del
programa que contienen el defecto (falla) que debe
alcanzarse.
2. Infection (Infección): El estado del programa debe ser
incorrecto.
3. Propagation (Propagación): El estado infectado debe
causar que algún output o estado final del programa
sea incorrecto.
4. Reveal (Develar): El testeador debe observar (parte
de) la porción incorrecta del estado del programa
 6
RIPR Model

Test Estado final

Estado final del del programa
programa observado
alcanza
Fault Estado final
incorrecto

infecta
propaga revela
Estado
incorrecto Oráculos
del de los
programa tests
 7
Roles en testing

 Ingeniero de testing: Profesional al cargo de una o

más actividades de testing.
 Diseña los tests.
 Genera valores de entrada para los tests.
 Ejecuta los test scripts.
 Analiza los resultados.
 Informa de los resultados a desarrolladores y
managers.
 8
Roles en testing

 Manager de testing: Está al cargo de uno o más

ingenieros de testing.
 Marca las políticas de testing y sus procesos asociados.
 Interacciona con otros managers del proyecto.
 Niveles de testing Testing de Sistema: Testear la
funcionalidad completa del 9
tradicionales Sistema. Testing de aceptación:
¿Es el software aceptable
main Clase P para el usuario?

Test de Integración :
Testear como los módulos
Clase A interaccionan entre ellos. Clase B

metodo A1() metodo B1()

metodo A2() metodo B2()

Test de Unidad:
Testear cada método Test de Modulo: Testear
individualmente. cada clase, modulo,
componente.
 10

Niveles de testing POO

Testing Inter-metodos testing: Testear

pares de métodos de la misma clase

Testing Inter-clase:
Clase A Testear múltiples Clase B
clases juntas

metodo A1() metodo B1()

metodo A2() metodo B2()

Testing Intra-clases:
Testear una clase
mediante
secuencias de
llamadas.

Testing Intra - metodos: Testear

cada método individualmente.
 11
Criterios de cobertura

 Incluso los programas más pequeños tienen demasiadas

entradas para testearlos completamente.
private static double computeAverage (int A, int B, int C)
 En una máquina de 32-bits, cada variable tiene unos
4.000.000.000 valores posibles.
 Tenemos alrededor de 80.000.000.000.000.000.000.000.000.000
(80 trillones) de tests posibles!
 Esencialmente, podríamos asumir que el espacio de entradas
es infinito.
 12
Criterios de cobertura

 Los testers tienen que trabajar con espacios de

entradas inmensos con el objetivo de encontrar el
menor número de ellas que detecte la mayoría de
los problemas.
 Los criterios de cobertura nos dan formas
estructuradas y prácticas de buscar en el espacio
de inputs de forma que
 Dicho espacio se recorra a fondo.
 No se produzca demasiado solapamiento entre los
tests.
 13
Ventajas de los criterios de
cobertura

 Dan trazabilidad del paso de artefactos software a

tests
 Código, requisitos, modelos, …
 Hacen que regression testing sea más sencillo.
 Dan a los testeadores una “regla de parada”:
cuando finalizar testing.
 Existen herramientas muy potentes que los
implementan.
 14
Requisitos y criterios de test

 Criterio de test: Colección de reglas y un proceso

que define los requisitos de test. Por ejemplo,
 Cubrir cada línea de código.
 Cubrir cada requisito funcional.

 Requisitos de test: Cosas específicas que se

deberían satisfacer o ser cubiertas durante el
proceso de testing. Por ejemplo,
 Cada línea de código podría dar lugar a un requisito.
 Cada requisito funcional podría dar lugar a un
requisito.
 15
Requisitos y criterios de test

Los investigadores en testing han definido varios criterios

pero en realidad se pueden agrupar en cuatro tipos de
estructuras …

1. Dominio de las entradas. 3. Expresiones lógicas.

2. Grafos. 4. Descripciones sintácticas.
 16
Caja blanca vs. caja negra

 Testing de caja negra: Se generan tests a partir de

descripciones externas del software que pueden ser
especificaciones, requisitos u otros mecanismos de
diseño.
 Testing de caja blanca: Se generan tests a partir del
código del software, específicamente, a partir de
sus ramas, condiciones y líneas de código.
 Testing basado en modelos: Se generan tests a
partir de un modelo del software (ej. un diagrama
UML).

MDTD (Model-Driven Test Design) hace que estas distinciones sean menos
importantes.
La pregunta pasa a ser: ¿A partir de que nivel de abstracción generamos los tests?
 17
Model-Driven Test Design

 El diseño de tests es el proceso consistente en

diseñar valores de los inputs que testean de forma
efectiva el software.
 El diseño de tests es solo una de las diferentes
actividades que constituyen el testing de software.
Tiene dos características principales:
 Tiene una base más rigurosa (formalismos con base
matemática).
 Tiene un desafío técnico mayor.
 Pasamos a ver una clasificación de las diferentes
actividades relacionadas con el testing de software.
 18
Tipos de actividades en testing

 Testing se puede dividir en los siguientes cuatro

grandes grupos de actividades:
 Diseño de tests.  1.a) Basado en criterios.

 Automatización de tests.  1.b) Basados en factor humano.

 Ejecución de tests.
 Evaluación de tests.

 Cada tipo de actividad requiere diferentes

habilidades, conocimientos previos y formación.
 19
Tipos de actividades en testing

 Ninguna organización (responsable) que desarrolle

software utiliza al mismo personal para definir
requisitos, diseñar el sistema, implementarlo, realizar
la integración y controlar su configuración.
 Sin embargo,

¿Por qué las organizaciones que realizan testing

usan al mismo personal para las cuatro actividades?
 20
Diseño de tests—
(a) Basado en criterios

Diseñar valores de los tests para satisfacer criterios de

cobertura u otro objetivo.

 Probablemente, el trabajo más técnico en el área de testing.

 Requiere conocimientos de Matemática Discreta,
Programación, Testing.
 Utilizar personal poco calificado para diseñar tests es una MUY
mala idea: se generarán tests poco efectivos.
Diseño de tests 21
(b) Factor humano

Diseñar valores de los tests basándose en el conocimiento del dominio

del programa y el conocimiento de testing.

 Más difícil de lo que lo puede parecer a los desarrolladores.

 El problema es que basarse solo en criterios puede pasar por alto
situaciones especiales.
 Requiere conocimientos del Dominio, Testing e Interfaces de Usuario.
 Casi no requiere conocimientos tradicionalmente adquiridos en CS.
 Experiencia en el dominio del software es esencial.
 Experiencia empírica es muy útil (biología, psicología, …).
 Experiencia en uso de la lógica es muy útil (derecho, filosofía,
matemáticas….).
 22
Automatización de tests

Integrar valores de test en scripts ejecutables.

 Es algo menos técnico.
 Requiere conocimientos de programación.
 Requiere muy poca teoría.
 A menudo requiere soluciones a problemas no triviales
relacionados con observabilidad y controlabilidad (veremos más
sobre este tema).
 Puede resultar aburrido para diseñadores de tests.
 Nótese que expertos en ciertos dominios (pruebas basadas en
criterios no tienen que tener conocimientos de programación.
 ¿Quién es el responsable de definir e integrar las salidas
esperados?
 Los diseñadores no siempre conocen los valores esperados.
 Se debe acudir a la ayuda de los evaluadores para ayudar aquí.
 23
Ejecución de tests

Ejecutar tests y almacenar los resultados.

 Es fácil (de hecho, es trivial si los tests están bien
automatizados).
 Requiere habilidades básicas que pueden ser
cubiertas por empleados sin un background
técnico.
 Si, por ejemplo, los tests para una GUI no están bien
automatizados entonces esta actividad requiere
mucho trabajo manual.
 Los empleados que ejecutan tests deben tener ser
muy meticulosos y cuidadosos a la hora de
almacenar toda la información obtenida.
 24
Evaluación de tests

Evaluar los resultados obtenidos e informar a los desarrolladores.

 Características similares a los basados en criterios.

 Requiere poco conocimiento sobre el área, mucho
conocimiento del dominio y, usualmente, no suele
gustar a graduados en área.
 25
Otras actividades

 Gestión de tests: Marca líneas generales, organiza el equipo,

interacciona con desarrollo, elige criterios, decide grado de
automatización, ….
 Mantenimiento de tests: Guarda los tests para reutilizarlos según el
software evolucione.
 Requiere cooperación de los diseñadores y automatizadores de tests.
 Decide cuanto recortar un conjunto de tests. Esta es una tarea
parcialmente política y parcialmente técnica (y muy difícil).

 Documentación de tests: Participan todos los miembros del equipo.

 Cada test debe estar bien documentado: criterios y requisitos de test
satisfechos o justificación de tests diseñados a mano.
 Asegurar trazabilidad durante el proceso.
 Mantener documentación sobre los tests automatizados.
 26
Organización del equipo

 Una organización madura debería tener un único

diseñador de tests que trabaje con varios
automatizadores, ejecutores y evaluadores.
 La mejora de la automatización disminuirá el
número de ejecutores.
 En teoría hasta cero… aunque en la práctica…
 Asignar personal inadecuado (sobre/infra-
cualificado) lleva a ineficiencia, baja satisfacción y
rendimiento reducido.
 27
Organización del equipo

 Consideremos las siguientes situaciones:

 Un diseñador de tests cualificado se aburrirá con otras
tareas y, seguramente, buscará otro trabajo.
 Un evaluador de tests cualificado no entenderá los
beneficios de utilizar criterios de testing.
 Sin embargo, los evaluadores tienen conocimiento del
dominio que les permitirá sugerir tests para estudiar
situaciones que podrían haberse pasado por alto
 En resumen, las cuatro actividades de testing son
bastante diferentes y sin embargo, como ya hemos
dicho:

Muchos equipos de testing usan el mismo personal para las CUATRO

actividades
 28
MDTD en la práctica

 Esta metodología deja que un diseñador de tests

haga las cuentas.
 A partir de aquí, los testeadores tradicionales y los
programadores pueden realizar sus tareas.
 Encontrar valores.
 Automatizar los tests.
 Ejecutar los tests.
 Evaluar los tests.
Model-Driven Test Design
Requisitos
Modelo / Requisitos refinados/
Estructura de test especificaciones de
tests
Requisitos
de test
DISEÑO

Valores de
entrada
Artefacto
IMPLEMENTACIÓN
software

pasa / Resultados de Scripts

tests tests
falla de tests

29
Model-Driven Test Design: Pasos
Criterio
Requisitos
Modelo / Requisitos
refinados/
Estructura de test
especificaciones
de tests
Análisis Requisitos
de test Generar
Análisis del DISEÑO
dominio

Artefacto
software IMPLEMENTACIóN Valores de
inputs

Evaluar Ejecutar Prefijo y

Automatizar
Resultados sufijo
pasa / Scripts
de tests tests esperado
falla de tests

30
Model-Driven Test Design : Actividades
Requisitos
Modelo / Requisitos
refinados/
Estructura de test
especificaciones
Diseño de tests de tests

DISEÑO
Aumentar nuestro nivel de abstracción
facilita enormemente
Artefacto el diseño de tests
software IMPLEMENTACIóN Valores de
inputs

Evaluación Ejecución de
de tests tests
pasa / Resultados Scripts
de tests tests
falla de tests

31
 32
Ejemplo pequeño pero ilustrativo

Artefacto Software : Método Java Grafo de control de

/** flujo
* Return index of node n at the
1 i=0
* first position it appears,
* -1 if it is not present
*/ 2
i < path.size()
public int indexOf (Node n)
{
for (int i=0; i < path.size(); i++) 3 if
if (path.get(i).equals(n))
return i;
return -1; 5 4
} return -1 return i
 33
Ejemplo pequeño pero
ilustrativo
6 requisitos para
Aristas
obtener cobertura
12
Versión abstracta de pares de aristas
23
del grafo 32
1. [1, 2, 3]
2. [1, 2, 5]
1 34
3. [2, 3, 4]
25
4. [2, 3, 2]
Nodo inicial: 1
5. [3, 2, 3]
2 Nodos finales: 4, 5
6. [3, 2, 5]
Caminos de tests
3
[1, 2, 5]
[1, 2, 3, 2, 5] Encontrar valores…
[1, 2, 3, 2, 3, 4]
5 4