Validación y Verificación de Software

Testing
 La Crisis del
Software
• Fenómeno mundial “decretado” hace muchos años
– Muchos dicen que es crónica
– Algunos casos traumáticos…
• Therac-25 (6 vidas)
• Arianne 5 (500 mill.)
• AT&T Switching System, etc, etc…
• Denver Airport (9 meses penalidad de 1.1 x día)
– Miles de fracasos en Information Systems

• Cada vez + software crítico y + complejo

2
 ¿Por qué es tan
difícil?
• No existen soluciones mágicas, o “Balas de
Plata”
– Dificultades esenciales y accidentales
• Inmadurez de la Disciplina
• Abismo entre el “Estado del Arte” y el
“Estado de la Práctica” (Ing. en Verificación)
• Problemas de Gerenciamiento
• Confusión Calidad Proceso  Calidad
Producto 3
Ciclo de Vida y la introducción, detección y
eliminación de defectos

4
Algunos números sobre los defectos

• 50 % de los defectos se introducen durante la

programación
• Hoy, no más del 15% de los defectos iniciales
son detectados antes del testing
• Al comienzo del test de unidad la densidad es
de 20 defectos x cada 1000 líneas de código
(no comentadas)
• 80% de los defectos de prog. se encuentran en
el 20% de los módulos de programación.
Muchos se evidencian durante la integración
• Costo de reparación (1000 en test de unidad a
12500 durante operación)
5
 Calidad en software

• Confiabilidad • Usabilidad
• Corrección • Facilidad de
• Robustez Mantenimiento
• Seguridad (en • Reusabilidad
datos, • Verificabilidad +
en acceso, Safety) Claridad
• Funcionalidad • Interoperabilidad

6
 Asegurar la calidad vs.
controlar la calidad
Una vez definidos los requerimientos de
calidad, tengo que tener en cuenta que:
– Las calidad no puede “inyectarse” al final.
– La calidad del producto depende de tareas
realizadas durante todo el proceso.
– Detectar errores en forma temprana ahorra
esfuerzos, tiempo, recursos.

7
 Testear antes de
codificar
• “El acto de diseñar tests es uno de los mecanismos
conocidos más efectivos para prevenir errores…
El proceso mental que debe desarrollarse para crear
tests útiles puede descubrir y eliminar problemas en
todas las etapas del desarrollo”
B. Beizer
• “Test-Driven Development”: Kent Beck. XP

8
 Definiciones

• Validación
– ¿Estamos haciendo el producto correcto?
– Basada en el uso de modelos

• Verificación
– ¿Estamos haciendo el producto correctamente?
– Necesariamente es en relación a un componente
anterior, que describe nuestro producto

9
Aspectos de los “errores” de software

• Falla (failure)
• Diferencia entre los resultados esperados y reales

• Defecto (defect o fault)

• Está en el texto del programa, una especificación, un
diseño, y desde allí se hace visible una falla

• Error = equivocación humana

• Un error lleva a uno o más defectos, que están
presentes en un producto de software
• Un defecto lleva a cero, una o más fallas: la
manifestación del defecto

10
 Verificación
estática y dinámica
• Dinámica: trata con ejecutar y
observar el comportamiento de un
producto

• Estática: trata con el análisis de una

representación estática del sistema
para descubrir problemas
11
 Técnicas de
Verificación Estática
• Inspecciones, Revisiones, Walkthrough
(31 a 93 % media de 60%)
• Análisis de Reglas Sintácticas sobre
código
• Análisis Data Flow sobre código
• Model Checking
• Theorem Proving (prueba de teoremas),
etc.
12
 Técnicas de
Verificación Dinámica
• Testing

• Run-Time Monitoring.
(pérdida de memoria,
performance)

• Run-Time Verification
13
 Testing

• Verificación Dinámica de la adecuación del

sistema a los requerimientos (de distinto tipo)

• Objetivo: encontrar los errores importantes

Mundialmente: 30 a 50% del costo de un

software confiable

14
 Testing

• Es el proceso de ejecutar un producto para

– verificar que satisface los requerimientos
– identificar diferencias entre el comportamiento
real y el comportamiento esperado
(IEEE Standard for Software Test Documentation,
1983)

No prueba la corrección del software!

15
 Cómo se hace testing?

Input

Comportamiento Comportamiento
esperado del obtenido del
programa - programa
ORÁCULO

= ? ¹

ok Falla
16
 Estamos asumiendo...

que se puede ejecutar el programa

que se conoce el resultado esperado

y que el resultado esperado puede

compararse con el resultado obtenido
(problema del oráculos: visibilidad y
comparación)
17
 Limitación del testing

• El testing puede demostrar la presencia de

errores, nunca su ausencia [Dijkstra]
– entonces, el testing NO puede probar que el
software funciona ok
• Una de las mayores dificultades es encontrar
un conjunto de tests adecuado:
– suficientemente grande para abarcar el dominio y
maximizar la probabilidad de encontrar errores
– suficientemente pequeño para poder ejecutar el
proceso de testing con cada elemento del conjunto
y minimizar el costo del testing

18
 La visión moderna

• Se puede invertir mucho esfuerzo en testear

• Testear es el proceso • Mejor
de establecer confianza prevenir
en que un programa hace 120
% Errores
100

lo que se supone Detectados

80

60

que tiene que hacer 40

20

• Testear es una 0

10
0

8
decisión
Unidad de Tiempo
económica
19
 La paradoja del
pesticida (Beizer)
• El pesticida mata el 98% de los bichos,
dejando un residuo (los más fuertes)
• Al siguiente año, necesito un pesticida mejor
• Bicho en inglés es bug
• El buen uso del testing implica que los
errores que no se encuentran son los más
sutiles
• ¡Si todo anda bien, el tipo de errores
encontrados tiene que cambiar! 20
 Cuándo Parar?

Problema: imposible en la práctica de estimar la

intensidad del testing para alcanzar determinada
densidad de defectos
• Estrategias (confiando en la convergencia):
– Pasa exitosamente el conjunto de pruebas
diseñado (“No Failure”) + cobertura estructural
– “Good Enough”: cierta cantidad de fallas no
críticas es aceptable (umbral de fallas no críticas
por unidad de testing).
– Defectos detectados es similar a la cantidad de
defectos estimados, etc.
21
Test de requerimientos no funcionales -
Ejemplos
• Test de seguridad, validando disponiblidad,
integridad y confidencialidad de datos y
servicios
• Test de performance, validando los tiempos de
acceso y respuesta del sistema
• Test de stress, validando el uso del sistema en
sus límites de capacidad y verificando sus
reacciones más allá de los mismos
• Test de Usabilidad

22
 Niveles de test

• Test de sistema (o subsistema)

• Test de integración
• Test de unidad

23
 Testing de Integración

• Test orientado a verificar que las

partes de un sistema que funcionan
bien aisladamente, también lo
hacen en conjunto
– Testeamos la interacción,
la comunicación entre partes
– No debe confundirse
con testear un sistema-integrado (test de sistema)

24
 El test de Integración

• Unimos y testeamos partes ya testeadas (que

se asumen correctas)
• La “estrategia” de unión depende del tipo de
sistema
– Sistema organizado jerárquicamente
• Top-down, bottom up, combinación de ambos
– Sistema batch de procesamiento secuencial
• Por partes del flow de corrida
– Sistema sin jerarquía (p.e., objetos)
• libre, salvo por el orden del desarrollo

25
 Programa auxiliares:
Stubs y drivers
• Driver simula las llamada
• Stub simula subprograma
• En total, exigen un esfuerzo
considerable de programación

26
 Hints

• Los puntos clave del test de integración:

– Conectar de a poco las partes más complejas
• Esto permite identificar más fácil las causas de
errores
– Minimizar la necesidad de programas
auxiliares
• Para ahorrar esfuerzo de programación

27
 Error de Interpretación

• La funcionalidad provista por un módulo

difiere del comportamiento esperado por
quien usa un módulo
• Ejemplos: supongamos que A llama a B,
La funcionalidad provista por B no es la requerida por la
especificación de A
B provee más funcionalidades de las que usa A
A puede llamar a B con parámetros fuera del dominio
de B
28
 Error de ubicación de llamada

• La (instrucción de) llamada a un módulo

no está en un lugar correcto del código
• Ejemplos:
la instrucción está en un camino que no
debiera contener la llamada
la instrucción está mal ubicada dentro de un
camino que debe contener a la llamada
la instrucción no está presente en un camino
que debiera contener a la llamada

29
 Error de Interfaz

• El estándar establecido entre llamador y

llamado se viola
• Ejemplos:
los parámetros no están en el orden correcto
los parámetros no son del tipo correcto
las reglas de llamadas no se respetan (por valor, por
referencia)
el dominio del parámetro formal difiere del dominio
del parámetro real
Problemas de sincronismo que hace que se acceda a
información desactualizada
30
 Tipos de interfaces más comunes

• Interfaces de parámetros tipo “call -

return”
– datos pasados de un procedimiento a otro
• Interfaces de memoria compartida
• Interfaces de intercambio de mensajes
– Un subsistema requiere servicios de otro
– En general son asincrónicas

31
Algunos hints para el testing de interfaces

 Aplicar el criterio de condiciones de borde

 Probar todos los parámetros de punteros con
nulos
 Diseñar tests que hagan fallar al componente
 En el caso de memoria compartida, cambiar la
secuencia de acceso a los datos
 Usar testing de estrés en interfaces de
mensajes
 En interfaces de mensajes, cambiar el orden

32
 Testing de Unidad

• Se realiza sobre una unidad de código

pequeña, claramente definida
– qué es una unidad

• En general es llevado a cabo

por los desarrolladores

33
 Test de unidades

• ¿Qué es una unidad?

– Un programa…
– Una función o procedimiento…
– Un form…
– Un script de un form…
– Un subsistema…
– Una clase…

34
 Qué es y qué no es una unidad

• Una unidad es
– El trabajo de un único programador
– La cosa más pequeña que puede ser probada
– Pequeña... 50 a 300 líneas de código
• Una unidad no es
– La entidad más pequeña que provee una
determinada funcionalidad
– Lo primero que se puede probar sin programas
auxiliares
– 50,000 - 100,000 líneas de código

35
 El Testing y el ciclo de
vida de un sistema
Preparar test Test de
Requerimientos
de sistema sistema

Diseño Preparar test Test de

preliminar de integración integración

Diseño Preparar Test Test de

detallado de unidades unidades
Test de
aceptación

Programación

Modelo del Ciclo de Vida en “V”

36
 Proceso de testing

• El testing no es sólo una etapa del

proceso de desarrollo
– Tradicionalmente, empezaba al término de
la implementación, y terminaba con la puesta
en producción
• es un proceso, paralelo al desarrollo

37
 Actividades del proceso de testing

• Asociadas a requerimientos
– Planificación de test de sistema
• Derivación de casos de test funcionales
– Corrección de requerimientos a partir de lo
detectado al confeccionar el plan

38
 Actividades del proceso de testing

• Asociadas a arquitectura y diseño

detallado
– Planificación de test de integración y unidad
– Generación de casos de test funcionales

39
 Actividades del proceso de testing

• Asociadas a la implementación
– creación de ambiente de ejecución de tests
– generación de casos de test estructurales
– ejecución de test de unidad
– ejecución de test de integración
– documentación de resultados
– seguimiento de errores
– test de regresión

40
Testing Funcional
 Test funcional -
Corrección funcional

Inputs Outputs
espec. f(i)
i
f

El programa p implementa correctamente

a f si
∀ i ∈ dom(f): p(i) = f(i)
42
Qué debe testear el testing funcional?

• p implementa correctamente a f
• Además, lo hace en forma razonable
– por ejemplo, si i ∈ dom(f) y f(i) = error, p da
un error razonable (por ejemplo, no se
cuelga!)
• Además, ∀ i ∉ dom(f), p avisa que i ∉
dom(f)

43
 Cómo seleccionar datos de
test?...Intuiciones
• Agrupando los inputs
• Hipótesis: hay inputs “parecidos”
(tratamiento), entonces testear el
programa con uno de estos, equivaldría a
testearlo con cualquier otro de estos
– Esto no es verdad pero sirve y es la base de
la mayor parte de las técnicas!!!

44
 Terminología (I)

• Casos de test: descripciones de condiciones o

situaciones a testear. Suele surgir de una
especificación de test.
• Dato de test: asignación de valores concretos de
parámetros para ejecutar un caso de test
• Test Suite T: conjunto de datos de test con los que
se testea el programa
• Si P es correcto para todo elemento de T, se dice
que T es exitoso para P
• Crear especificaciones y casos es un proceso creativo
• Crear datos de test es un proceso laborioso, y hay creatividad
en cumplir económicamente con los casos 45
 De manera Simple

• Caso1: cond1, cond2, cond3,..., condn1 y ResEsp(1)

...
• Casok: cond1, ..., ..., condnk
ResEsp(k)

Datos Param1 Param2 Param3 Res. Esp.

D1 X1 Y1 Z1 R1
... ... ... ... ...
Dk Xk Yk Zn Rn

46
 Terminología (II)

• Requerimientos de Test: Qué quiero

testear. En el marco del testing de sistemas
reactivos se llama el Test Purpuse.
• Especificaciones de Test :Supuestos y
definiciones que sirven para generar los
casos de test para el requerimiento de
test

47
 Criterios de Selección:
La base Teórica de las
Técnicas de Generación de
Casos
Criterios de selección de datos de test

• Un criterio es un subconjunto de
conjuntos finitos del dominio de Inputs
del programa P (puede estar expresado
en términos de un conjunto de
predicados también llamados casos)
• Se dice que un conjunto de datos T
satisface un criterio C sii T∈ C

49
 Criterios “ideales”

• Un Criterio C es Consistente para P sii

para todo par T1 y T2 de test sets que
satisfacen C, T1 es exitoso para P sii T2
lo es

• Un Criterio C es Completo para P sii si P

es incorrecto entonces hay un test set T
que no es exitoso para P

50
 Son estas nociones efectivas?

• es decir, hay un algoritmo que proponga casos

(i.e., un criterio) tales que encuentren todos
los errores en cualquier programa?
NO!
• Ni siquiera un algoritmo que diga si un criterio
es completo y/o consistente.
• Ninguna técnica puede ser efectiva para
detectar todos los errores en un programa
arbitrario
• Uso de heurísticas en forma de criterios de
testing
51
 Criterios“caja negra”

• También llamado testing producido por los datos, o

testing producido por la entrada/salida
– nos desentendemos completamente
de la estructura interna del programa,
pero no de su x,y
especificación
function fastexp(x,y: int): int;
{devuelve x a la y}

xy
“¿Que casos probarían?”

52
 Criterios estructurales o
de “caja blanca o de cristal”
• Los casos de test se definen a partir x,y
de la estructura interna
function fastexp (x,y: int):int;
del programa
% pre: y >= 0
% post: devuelve x a la y
z :int :=1;
while y ¹ 0 do
if odd(y) then
z :=z*x; xy
y :=y-1
endif;
x := x*x; y :=y/2
endwhile
return(z) “¿Qué pasa si y es potencia de 2?”
“¿Qué pasa si y = 2n -1?”

53
Cómo evaluar en la práctica la calidad
de los casos o datos generados

• Cobertura estructural del código (ej.:

branching coverage)
• Cobertura contra especificación (ej.:
caso de uso, workflow, etc.)
• Cobertura de GUI
• Fault Seeding (ej.: mutation testing), etc.

54
 Importante

• No sólo testear casos válidos!!!!

• Condiciones válidas y esperadas

– hace lo que se supone que hace
• Condiciones inválidas o inesperadas
– no hace lo que se supone que no hace

55
Técnicas de Selección de
Casos:
“Partir y Combinar”
 Qué se busca con las Técnicas?

• alta probabilidad de encontrar errores

• a bajo costo (o al menos controlable)
• usando ideas generales, sistematizables
y semiautomatizables
• y un modelo de fallas subyacente como
“rationale”

57
 Técnicas de partición de
Dominio

Técnica II: Category-Partition de T.

Ostrand & M. Balcer -1988
(generalización de Técnica I)

58
Método de Partición en Categorías -
Ejemplo
• FIND
Dado un nombre de archivo A y una
expresión E, FIND devuelve la lista L de
las palabras en A que comienzan con E,
sin repeticiones. E no puede ser vacía ni
contener blancos

59
 Ejemplo
PASO 1
1. Elegir una funcionalidad que pueda
testearse en forma independiente

Ya lo tenemos!

60
 Ejemplo
PASO 2
2. Determinar sus parámetros u otros
objetos del ambiente que pueden
afectar su funcionamiento

-Archivo (nombre)
-Expresión

61
 PASO 3
3. Determinar las características
relevantes de cada objeto determinado
en el punto 2 (Archivo, Expresión) y de
la relación entre estos objetos en el
output (relación Archivo/Expresión)
“Category” en el artículo original de
Ostrand & Balcer 1988

62
 Ejemplo - PASO 3
Características de E
• longitud de expresión
• blancos en la misma

63
 Ejemplo - PASO 3
Características de A
• Tamaño de A

64
 Ejemplo - PASO 3
Características de A/E
• número de ocurrencias de E en A
• número máximo de ocurrencias de E en
una línea de A
• longitud de A vs. longitud de E
• repeticiones de palabras que contienen a
E en A
• ubicación relativa de E en palabras de A
• ...

65
 PASO 4
4. Determinar elecciones (“choices”) para
cada característica de cada objeto

66
 Ejemplo en
Categorías de E
• longitud de expresión
– vacía
– no vacía
• contiene blancos
– sí
– no

67
 Ejemplo en
Categorías de A
• existe
– sí
– no
• tamaño
– vacío
– no vacío

68
 Ejemplo en
Categorías de A/E (I)
• número de ocurrencias de E en A
–0
– al menos 1
• número máximo de ocurrencias de E en
una línea de A
–0a1
– más de 1

69
 Ejemplo en
Categorías de A/E (II)

• longitud de A vs. longitud de E

– long A >= long E
– long A < long E
• repeticiones de palabras que contienen a E en A
– Sin repeticiones
– A contiene repetida a p, palabra que comienza con
E
• Ubicación relativa de E
– p en A, E es prefijo de p
– p en A, p contiene a E pero p no comienza con E...

70
PASO 5 - Clasificación : errores, únicos,
restricciones
E A
• longitud • existe
– vacía - ERROR – sí
– no vacía – no - ERROR
• blancos • tamaño
– sí - ERROR – vacío - ÚNICO
– no – no vacío

71
PASO 5 - Clasificación : errores, únicos,
restricciones
A/E • número máximo de
• número de ocurrencias de E en
ocurrencias de E en una línea de A
A –0o1
– 0 - ÚNICO – más de 1 (A no
– al menos 1 (A no vacío) ÚNICO
vacío)
• ETC.

72
 PASO 6
Armado de casos
• Ver una posible solución en archivo Word

73
 Resumen del Método

1. Elegir una funcionalidad que pueda testearse en

forma independiente
2. Determinar sus parámetros u otros objetos del
ambiente que pueden afectar su
funcionamiento
3. Determinar las características relevantes de
cada objeto determinado en el punto 2 y de la
relación entre estos objetos en el output
4. Determinar elecciones para cada característica
de cada objeto
5. Clasificación: errores, únicos, relaciones, 74

restricciones
Información para identificar categorías

• Texto informal o formal de la

especificación
• Características propias de los param.
de I/O de la funcionalidad a probar
• Cardinalidad del modelo de datos, que
define reglas del negocio
• Ciclo de Vida de las entidades del
modelo de datos
75
 Algunas Conclusiones

• El método se aplica a cualquier

descripción de funcionalidad (formal,
semiformal o informal)
• Es necesario usar los requerimientos
para planificar el testing
• Esto genera preguntas de incompletitud,
ambigüedad, inconsistencia, e
incorrección en un momento en que es
“fácil” corregir requerimientos
76
 Algunas Conclusiones (cont.)

• No hay una única solución: dependiendo

de cómo se realice el proceso se
obtendrá un conjunto de casos de test
particular
• Los casos de test pueden darse a
conocer a los programadores antes de
que implementen

77
 Técnicas de partición de
Dominio

Técnica para la identificación de

Categorías

78
 Especificaciones de Servicios o
Requerimientos
• Aparecen de manera + o – clara los
(parámetros implícitos y explícitos), su
casuística, la relación entre ellos
• Ejemplo:en los casos de uso: hay
escenarios distintos dependiendo de
valores de parámetros o de acciones
decididas por el actor. Son parámetros
candidatos con sus categorías y
elecciones
79
 Análisis de condiciones de borde

• Los casos de test que exploran los

bordes de las clases de equivalencia
producen mejor resultado
– Cada margen de la clase de equivalencia
debe quedar sujeto a un test
– input y output

80
 1. Heurística

Si una condición de input especifica un

rango de valores (intervalo), identificar
una clase válida y dos inválidas
Ejemplo: el item puede variar entre 1 y 999
VÁLIDA: 1 < valor < 999
INVÁLIDAS: 1 ≥ valor y valor ≥ 999
DE BORDE: valor = 1 y valor = 999

81
 2. Heurística

Si una condición de input especifica un

número de valores, identificar una clase
válida y dos inválidas
Ejemplo: un automóvil puede tener entre
uno y seis dueños
VÁLIDA: entre uno y seis dueños
INVÁLIDAS: ningún dueño y más de seis
dueños
DE BORDE: 1 dueño y 6 dueños
82
 3. Heurística

Si una condición de input especifica un

conjunto de valores, y hay razones para
pensar que cada uno es manejado por el
programa en forma distinta, identificar
una clase válida por cada elemento y una
clase inválida
Ejemplo: tipo de vehículo: camión, taxi,
auto, moto
VÁLIDAS: camión, taxi, auto, moto
INVÁLIDA: algún tipo que no es camión, 83

taxi, auto ni moto

 4. Heurística

Si una condición de input especifica una

situación que debe ocurrir,
identificar una clase válida y una
clase inválida
Ejemplo: el primer caracter debe ser
una letra
VÁLIDAS: es una letra
INVÁLIDA: no es una letra
84
 5. Sobre clases inválidas

• ¿Qué me falta?
• Probar el ingreso de valores de otro tipo
que la clase
– numéricos en vez de alfabéticos
– alfabéticos en vez de numéricos
– combinaciones de alfabéticos y numéricos
– fechas erróneas, etc.
• El entorno de desarrollo puede ahorrar
este trabajo
85
6. Tipos de Datos de input y output

• Características propias de los tipos de

datos de entrada y salida de la
funcionalidad testeada. Ejemplo: Fechas,
listas, archivos de texto con
determinado formato, etc.

86
8. Cardinalidad del modelo de datos

• La cardinalidad de las relaciones define reglas

del negocio que deben ser probadas
• Cardinalidad mínima: cuántas instancias hay
como mínimo de una entidad por cada instancia
de una entidad relacionada con ella
• Cardinalidad máxima: cuántas instancias hay
como máximo de una entidad por cada
instancia de una entidad relacionada con ella

87
 Ejemplo

• Cuenta sin firmante

(inválido)
Cuenta
• Cuenta con un firmante
(válido)
• Cuenta con más de un
firmante (válido)
Firmante
• Cuenta con más
firmantes del máximo
permitido (inválido)
88
 9. Ciclo de vida de las entidades

• Visión temporal del modelo de datos:

– a partir de un diagrama del ciclo de vida de
una entidad

89
 Ejemplo

Inicio

Solicitud Ingresada
• Debo probar:
– Transiciones
Solcitud Preadjudicada Solicitud Rechazada válidas
– Transiciones
Solicitud Aceptada inválidas

90
 Técnicas Combinatorias

Técnica III: Notación Arbórea

91
 Definición Arbórea

• Un ejemplo: Alta de Cuenta

Datos Válidos Datos inválidos

Caja de ahorro Cuenta corriente

Dólares Común

92
 Definición Arbórea
• Puede verse como category-partition especial donde el
mismo diseñador de casos decide explicítimanete cómo
combinar
• Por ejemplo, cuando hay idea de orden de ingreso de
parámetros se puede minimizar casos sin sentido
• Se arma un árbol donde cada nodo indica “category”
sobre un parámetro o combinación entre un parámetro
y uno anterior descripto en el árbol
• Los ejes que salen son las choices compatibles con las
condiciones acumuladas desde la raíz
• Los casos de tests especificados y ejecutados son los
caminos del árbol
93
 Definición Arbórea: Consejos

– Hay categorías que pueden ser irrelevantes en

una rama, entonces no se abren
– Varios choices pueden agruparse
– Un error corta la rama
– Condiciones normales de un lado, errores del
otro...
– Tener en cuenta que el orden en que aparecen
los parámetros y sus categorías puede ser
importante (ej: del año y día)
– Mantener el mismo orden parámetro-categoría
en todas las ramas para facilitar la
documentación posterior 94
Combinando Category-Partition Fases 1-
5 con Definición Arbórea
• Si primero hago un category partition
(salvo combinatoria):
– conviene anotar la relevancia de cada
categoría respecto a choices de otras
categorías
– Criterio de cobertura: hay que revisar que
todos los choices sean ejercitados en el
árbol

95
 Técnicas Combinatorias

Técnica I: Grafo Causa-Efecto

96
 Grafo de Causa-Efecto

• Especificaciones de I/O complejas (mucha

dependencia entre Inputs, entre Outputs y
entre I/O)
• Nos permite definir combinaciones relevantes
de categorías binarias sobre inputs para
definir casos. Allí difiere del la parte
combinatoria de Category-Partition
• Provee un display visual de las relaciones entre
una causa y la otra
• Ayuda a detectar ambigüedades o
incompletitud en la especificación
97
 Grafo de Causa-Efecto

• Idea: Generar todos los outputs

admisibles con la siguiente heurística:
– Si hay un “or” (todas las opciones con sólo
una señal en True)
– Si hay un “and” (todas con sólo una en falso)

• O(n*k*o) en lugar de O(2n) dónde n es la

cantidad de categorías binarias sobre el input,
k la profundidad del DAG y o la cantidad de
combinaciones del output válidas
98
 Ejemplo Grafo de Causa-Efecto

• Para mostrar una de las 10 posibles secciones

del índice se debe entrar un comando que
consiste en una letra y un dígito
– El primer carácter debe ser una D para display o
una L para List, y debe estar en la columna 1
– El segundo carácter debe ser un número (0..9) en la
columna 2
– Si se ingresa un comando como éste, el índice de la
sección identificada por el dígito es mostrada en la
terminal. Si el primer caracter es incorrecto
“comando inválido”, y si el 2do caracter es
incorrecto “número de índice inválido” 99
 Grafo de Causa-Efecto: Ejemplo

• Causas
• Efectos
1. Carácter en la 1er
50. El índice de la sección
columna es D
es mostrado
2. Carácter en la 1er
51. Msg “comando inválido”
columna es L
52 Msg “número de indice
3. Carácter en la 2da
inválido”
columna es un dígito 51
1

o not
E 2 r 20
50
a
n
d

3 not 52

1=causa Grafo booleano

presente pasa,
nulo no importa 100
Grafo de Causa-Efecto: Ejemplo
Tabla de decisión y casos de test

Casos de test
Causas 1 2 3 4
1 1 0 0
2 0 1 0
3 1 1 0
Efectos
50 1 1 0 0
51 0 0 1 0
52 0 0 0 1

Ejemplo de datos de test derivados

Caso de test Input RE
1 D5 Se muestra indice 5
2 L4 Se muestra indice 4
3 B2 "Comando inválido"
4 DA "Número de índice inválido"

101
Grafo de Causa-Efecto: Otro Ejemplo

m I b
m o
P r

E a m
i
n
m
E=B d
p
SE

E=I o a
r n
SE=B
d
SE=I
SE=I+B
102
 Técnicas Combinatorias

Técnica II: 2-wise Partition & Arreglos

Ortogonales

103
 2-Wise Testing y OATS

• Aplicando 2-wise Testing, se seleccionan casos de

test de manera tal de testear las interacciones entre
pares de parámetros (factores) independientes de una
manera económica
• Ej.: 75 parámetros de 2 estados c/u se pueden
testear con 28 tests!
• Inputs independientes enumerados
• Supuesto: errores son de tipo single o double mode.
• OATS (Orthogonal Array Testing Strategy)
• Herramientas de Telecordia y Freeware.

104
 Arreglo Ortogonal: Ejemplo

• La sintaxis de un comando consiste en 3 posibles

parámetros:
– Command PARM1, PARM2, PARM3 (enter)
• PARMx=1, 2, 3
– En teoría un tester debería
1 1
crear
1
33=27 combinaciones
1 1 2
1 1 3
1 2 1
1 2 2
1 2 3
1 3 1
1 3 2
1 3 3
... ... ...

– En este caso hay 3 factores con 3 niveles cada uno. 105

 Arreglo Ortogonal: Ejemplo

• Las combinaciones entre 2 parámetros son 9:

1 1
1 2
1 3
2 1
2 2
2 3
3 1
3 2
3 3

• Una posible solución es la dada en el siguiente

arreglo ortogonal
– En el arreglo ortogonal las columnas se corresponden con
los factores y las filas los casos de test. Las filas
representan todas las posibles combinaciones de a pares 106
entre los posibles niveles de los factores
 Arreglo Ortogonal: Ejemplo

Caso de test PARM1 PARM2 PARM3

Caso de test PARM1 PARM2 PARM3
1 1 1 3
1 1 1 3
2 1 2 2
2 1 2 2
3 1 3 1
3 1 3 1
4 2 1 2
4 2 1 2 5 2 2 1
5 2 2 1 6 2 3 3
6 2 3 3 7 3 1 1
7 3 1 1 8 3 2 3
8 3 2 3 9 3 3 2
9 3 3 2

Caso de test PARM1 PARM2 PARM3

1 1 1 3
2 1 2 2
3 1 3 1
4 2 1 2
5 2 2 1
6 2 3 3
7 3 1 1
8 3 2 3
9 3 3 2
107
 Arreglo Ortogonal (OATS)

• Factors: Columnas=Parámetros
• Levels: cantidad de valores posibles para cada
columna (e.g.,choices)
• Strength: Cantidad de columnas tales que las
Levels Strenght posibilidades aparecen la misma
cantidad de veces
• Tabulados como: Lruns(Levels Factors)
• Ej: L4(2 3): cuatro corridas para cubrir 3 factores
con dos elecciones posibles c/u
• L18(3 6 6 1 ): 18 corridas para 7 factores, 6 de 3
niveles y 1 de 6 niveles. Mejor que 216 tests! 108
Conclusiones sobre la Generación de
Casos
• Ninguna técnica es completa
• Las técnicas atacan distintos problemas
• Lo mejor es combinar varias de estas técnicas para
complementar las ventajas de cada una
• Depende del programa a testear
• Sin especificaciones de req. todo es mucho más difícil
• Tener en cuenta la conjetura de defectos
• Ser sistemático y documentar las suposiciones sobre
el comportamiento o el modelo de fallas

109
 Cobertura: evaluación
de la calidad de los
Casos de test (I)
• La especificación de tests cubre la
especificación o los requerimientos del sistema?
– Tengo requerimientos de Test para cada funcionalidad
pedida (ej. Caso de uso)?

• El conjunto de casos de test cubre la estructura

de mi workflow o mi caso de uso?
– Para los escenarios normales y las acciones alternativas:
Hay datos que ejerciten cada uno de estos flujos?
– Todas las actividades y todas las elecciones que hacen
cambiar el flujo de trabajo han sido ejercitadas?
– Determinemos flujos punta a punta interesantes del 110
workflow y verifiquemos que los estamos cubriendo
 Cobertura: evaluación
de la calidad de los
Casos de test (II)
• Los casos de tests cubren la combinatoria
esperada sobre mi especificación?
– Tengo identificadas como categorías o
“choices” las condiciones que aparecen en la
especificación?
– Se dan los cruces que espera un experto en el
dominio?. Inspección de Casos de Test
• Los datos cubren a los casos de test?
– La pregunta básica usada para definir cuando un
conjunto de datos cubre un conjunto de casos
111
 Cobertura: evaluación
de la calidad de los
Casos de test (III)
• Las ejecuciones cubren el grafo de control o el
de flujo de datos siguiendo algún criterio
estructural?
– Ejecuté todas las instrucciones?
– Ejecuté todas las ramas -de los grafos de control de
las componentes involucradas- después de mi set de
prueba?
• Los datos cubren estructuralmente la GUI?
– Se realizaron eventos relevantes sobre todos los
objetos de la GUI? (ej: botones clickeados, combos
abiertos e items seleccionados, etc.) 112
Cómo Documentar los Casos: Algunas
Sugerencias
• Ordenar las categorías por parámetro, y
ordenar los parámetros
• Poner la categorías de las relaciones P1/P2
después de P1 y de P2
• Esto sale naturalmente de recorrer el árbol (si
usé esa técnica)
• Describir genéricamente el resultado esperado
• Al TestDirector o a una planilla Excel. Vincular
a los requerimientos de testing (test
requirement)
113
Testing Estructural de Unidades
Representación del flujo de control

 Representamos el flujo de control de un programa a través

de un grafo de flujo o flowgraph
 Programas secuenciales, con un único punto de ingreso y
un único punto de terminación

Secuencia

if then else if then

115
 Representación del flujo de control

repeat until
do while

case, o selección
múltiple

• Esta es una representación posible. Existen

varias.
116
 Flowgraph - Ejemplo

begin
1: read(x,y) 2

2: while x ¹ y do
3: if x > y 3

4: then x := x-y
4
5: end-if
6: end-while 5

7: return x
8: end 6

7 8

117
 Caminos del flowgraph

• Un camino en un flowgraph desde el nodo

asociado al inicio del programa hasta el nodo
asociado a la terminación del programa se
llama camino completo
• Una ejecución del programa que termina
satisfactoriamente, está asociada a un camino
completo en el flowgraph del programa
• Cada camino del flowgraph corresponde a una
ejecución? Y los caminos completos?

118
 De caminos a casos de test

• Dado un camino completo en un

flowgraph, ¿cómo obtengo un caso de
test que lo fuerce?
– A partir de un camino completo, se puede
obtener condiciones sobre los inputs para
forzar dicho camino
• ejecución simbólica
• caso de test

119
 Caminos no factibles

• Un camino en un flowgraph para el cual no

existe input del programa que fuerce su
ejecución, se dice camino no factible
– Cada camino factible puede tener muchos inputs
asociados que fuercen su ejecución

• Cuál es el problema de los caminos no

factibles?

120
 Criterios de
Testing Estructural
• Un criterio de testing estructural
permite identificar entidades que deben
cubrirse con los datos de test para
satisfacer el criterio

121
 Cubrimiento de sentencias o
instrucciones

• Todas las sentencias del programa deben

ejercitarse

• equivale a cubrir todos los nodos del flowgraph

122
 Flowgraph - Ejemplo 2

begin
1: read(a,b,x) 2

2: if (a>-1) and (b=0)then

3
3: x := x/a
4: end if 4

5: if (a=2) or (x >1) then

6: x := x+1 5

7: end if 6
8:end
7

123
 Ejemplo sentencias

• en el ejemplo, debemos cubrir los nodos 1, 2,

3, 4, 5, 6, 7 y 8
• el siguiente camino cubre todos los nodos
1, 2, 3, 4, 5, 6, 7, 8
• por ejemplo, con el input siguiente forzamos el
camino
– Test 0: a=2, b=0, x=1

124
 Testing estructural - proceso

1- Con el código como base, dibujamos el grafo

de flujo de control
2- Determinamos un conjunto de caminos que
cumple el criterio
3- Preparamos los datos de test que forzarán la
ejecución de cada camino
– p.e., usando ejecución simbólica
4- Evaluamos si satisfacemos el criterio
5- Eventualmente, iteramos

125
 Observaciones

• El testing basado en código encuentra

muchos errores
• Se ha realizado mucha investigación para
determinar qué técnica estructural es la
mejor

• Pero…

126
 Problemas

• Cualquier técnica de selección de casos

que no está basada en el comportamiento
funcional, está mal guiada desde el
comienzo
– La gente no usa el software para ejecutar
sus instrucciones, sino para invocar sus
funcionalidades
– Es fácil ejecutar todas las instrucciones y
sin embargo no invocar ciertas funciones

127
Técnicas estructurales como criterio
de adecuación

Derivar casos de test funcionales

No usar información
estructural
Ejecutar tests

NO SI
Fallas? Reparar

NO Cubrimiento SI
estructural?
Terminación
del testing

128
 Cubrimiento de decisiones
o Branch
• Problema: el “else” del “then” no está testeado

• Todas las decisiones en el control del

programa deben ejercitarse al menos una vez
por true, y al menos una vez por false

• branch equivale a cubrir todos los arcos del

flowgraph
• branch implica sentencias

129
 Ejemplo cubrimiento de decisiones

• en el ejemplo, debemos cubrir todos los arcos (y

en particular, los arcos 2-3, 2-4, 5-6 y 5-7)
• por ej., con los inputs siguientes
– Test1: a=0, b=0, x=0
– Test2: a=-2, b=0, x=2
• ejecutamos los siguientes caminos, que cubren
todos los arcos
– Camino1: 1, 2, 3, 4, 5, 5-7, 7, 8
– Camino2: 1, 2, 2-4, 4, 5, 6, 7, 8
130
 Problema...

• Una decisión puede estar compuesta de

varias condiciones
• En el ejemplo, (a>-1) and (b=0)
Test1: a=0, b=0, x=0
– condiciones: a>-1, b=0, a ≠ 2, x≤1
Test2: a=-2, b=0, x=2
– condiciones: a≤-1, b=0, a≠2, x>1

131
 Cubrimiento de condiciones

• Todas las condiciones de todas las decisiones

en el control del programa deben ejercitarse
al menos una vez por true, y al menos una vez
por false

132
 Condiciones

• Para satisfacer condiciones hay que

ejecutar: (a>-1) (a≤-1) (b=0) (b≠0) (a=2)
(a≠2) (x>1) (x≤1)
• Por ejemplo, Test1, Test2 y Test3,
donde:
Test3: a=2, b=1, x=0
– camino: 1, 2, 4, 5, 6, 7, 8
– condiciones: a>-1, b≠0, x≤1 , a=2
se satisface el criterio condiciones
133
Relación entre branch y condiciones

Consideramos la guarda If A&B

• branch: (A & B), (¬(A & B))
– puede faltar ¬A o ¬B
 branch no implica condiciones
• condiciones: A, ¬A, B, ¬B
– (A & ¬B) (¬A & B)
 condiciones no implica branch
 es decir, ninguno garantiza al otro!
 Lo mismo sucede entre sentencias y condiciones

134
 Cubrimiento de caminos

• Todo camino del flujo de control del programa

debe ejercitarse al menos una vez

• equivale a cubrir todos los caminos del

flowgraph

• Es factible?
• Garantiza algo?

135
 Criterios estructurales basados en
flujo de control
Control flow testing

• sentencias
• branch
• decisiones
• caminos

136
 Data Flow Testing
Motivación
• Programas = control + data

137
 Definiciones y Usos

• una sentencia que guarda un valor en la

posición de memoria de una variable, crea una
definición
• una sentencia que trae el valor de la posición
de memoria de una variable es un uso de la
definición activa de esa variable
– un uso de x es un un uso predicado o p-uso si
aparece en el predicado de una sentencia que
representa una bifurcación de control
– en otro caso, se llama uso computacional o c-uso
(aparece del lado derecho de una asignación) 138
 Def-Use flowgraph

Dado un programa P y una variable x en P, el def-

use flowgraph es el flowgraph de P anotado de
la siguiente manera:
• por cada definición de x, el nodo asociado está
etiquetado con una definición de x
• por cada c-uso, el nodo asociado está
etiquetado con un uso de x
• Por cada p-uso todos los arcos salientes del
nodo asociado están etiquetados con un uso de
x
139
 Def-use flowgraph para a Ejemplo

1 da
begin
1: read(a,b,x) ua 2
ua
2: if (a>-1) and (b=0)then ua 3
3: x := x/a
4: end if 4

5: if (a=2) or (x >1) then

6: x := x+1 ua 5
ua
7: end if 6
8:end
7

140
Def-use flowgraph para b Ejemplo

1 db
begin
1: read(a,b,x) ub 2
ub
2: if (a>-1) and (b=0)then
3
3: x := x/a
4: end if 4

5: if (a=2) or (x >1) then

6: x := x+1 5

7: end if 6
8:end
7

141
Def-use flowgraph para x Ejemplo

1 dx
begin
1: read(a,b,x) 2

2: if (a>-1) and (b=0)then ux dx 3

3: x := x/a
4: end if 4

5: if (a=2) or (x >1) then

6: x := x+1 ux 5
ux
7: end if ux dx 6
8:end
7

142
 DUA (definition-use association)

Una DUA es una terna [d, u, x] tal que

• la variable x está definida en el nodo d
• la variable x se usa en el nodo u o en el arco u
• hay al menos un camino desde d hasta u que no
contiene otra definición de x además de la de
d (def-clear para x o libre de definiciones
para x)

143
 Ejemplo – DUAS ejemplo 2

• [1, 2-3, a] • [1, 3, x]

• [1, 2-4, a] • [1, 5-6, x]
• [1, 3, a] • [1, 5-7, x]
• [1, 5-6, a] • [1, 6, x]
• [1, 5-7, a] • [3, 5-6, x]
• [3, 5-7, x]
• [1, 2-3, b] • [3, 6, x]
• [1, 2-4, b]

144
 Criterios estructurales basados en
flujo de datos
Data flow testing
• all defs
• all c-use
• all p-use
• all uses
• all c-use some p-uses
• all p-uses some c-uses
• all du-paths

145
 Cubrimiento All-uses

• Para cada variable en el programa, deben

ejercitarse toda las asociaciones entre
cada definición y toda uso de la misma
(tal que esa definición esté activa)

• All-uses equivale a cubrir todas las

DUAS del programa

146
 Ejemplo All-Uses

• Test 0: a=2, b=0, x=1

– Cubre las DUAS [3, 5-6, x], [3, 6, x]
• Test1: a=0, b=0, x=0
– Cubre las DUAS [1, 2-3, a], [1, 3, a], [1, 5-7, a], [1, 2-
3, b], [1, 3, x], [3, 5-7, x]
• Test2: a=-2, b=0, x=2
– Cubre las DUAS [1, 2-4, a], [1, 5-6, a], [1, 2-4, b],
[1, 5-6, x], [1, 6, x]
• Test3: a=2, b=1, x=0
– Cubre las DUAS [1, 2-4, a], [1, 5-6, a], [1, 2-4, b],
[1, 5-6, x], [1, 6, x]
147
 Ejemplo (cont.)

Falta cubrir la DUA [1, 5-7, x]

Por ejemplo, el test

• Test 4: a=1, b=1, x=0
cubre esta DUA

148
Subsumption en Criterios estructurales

• Un criterio A All paths

subsume a otro All du paths

criterio B si un
conjunto de datos All uses

de test T satisface All-c/some-p All-p/some-c

un criterio A, All c/uses

All defs All p/uses
entonces T
satisface B Branch

Statement
• Qué relación existe
a la hora de 149
Ejecución del testing
 Ejecución del testing

selección de datos
• dónde testear: ambiente de test
• terminación del testing
• documentación
• reporte y seguimiento de errores
• test de regresión

151
 Ejecución del testing

• selección de datos
dónde testear: ambiente de test
• terminación del testing
• documentación
• reporte y seguimiento de errores
• test de regresión

152
 Movimiento de componentes

integración,
programación testing del sistema
testing de unidades testing de aceptación

Desarrollo Testing Producción

153
 Ejecución del testing

• selección de datos
• dónde testear: ambiente de test
• terminación del testing
• documentación
• reporte y seguimiento de errores
• test de regresión

154
 Terminación del testing

 Se terminó el tiempo o recursos

 Se corrieron todos los tests derivados sin
detectarse ningún error
 % de cubrimiento de ciertas técnicas elegidas
 Fault-rate más bajo que un cierto valor
especificado (# de errores por unidad de
tiempo de testing)
 Se encontró un número predeterminado de
errores (% del número total de errores
estimado)
155
 Ejecución del testing

• selección de datos
• dónde testear: ambiente de test
• terminación del testing
documentación
reporte y seguimiento de errores
• test de regresión

156
 Documentos de
Casos de test

• Criterios de derivación de casos empleados

• Casos de test organizados por
– Módulo, sistema, unidad, etc.
– Incluyendo el resultado esperado
– con referencia al requerimiento que prueban
• Criterios de terminación del testing
• Datos de prueba
157
 Documentos de
reporte de ejecución

• ambiente de test
• selección de datos
– referencia a casos de test que prueban
• ejecución y resultado obtenido
– reporte de errores
• re-ejecución luego de las modificaciones
pertinentes
158
 Gerenciamiento de errores

· Determinación del origen del error

· una vez detectado un error, se busca el
problema que lo originó haciendo debugging
· Clasificación de errores
· prioridad
· severidad
· Seguimiento de errores

159
 Gerenciamiento de errores

· Reparación del software

· Testing y testing de regresión
· Iterar hasta terminar

160
 Ejecución del testing

• selección de datos
• dónde testear: ambiente de test
• terminación del testing
• documentación
• reporte y seguimiento de errores
test de regresión

161
 Test de Regresión

• Tareas de testing luego de que un sistema

ha sido modificado
– Algunos estudios dicen que la probabilidad de
introducir un error al hacer un cambio es entre
50-80% [Hetzel: The complete guide to software testing,
QED Info. Sciences, Wellesley, 1984]

162
 ¿Cuándo hacer test de regresión?

• Durante el desarrollo de software

• En tareas de mantenimiento, por

– corrección
– adaptación a nuevo ambiente
– mejora de las prestaciones

163
 Selección de casos de regresión

• Casos reusables: corresponden a partes del

software no modificadas (ni especificación, ni
implementación)
• Retesteables: la especificación no cambia,
pero sí la implementación
• Obsoletos: no pueden seguir usándose
– p.e., test case que especifica una relación I/O
incorrecta, por modificación de la especificación

164
 Bibliografía

• Beizer: Software Testing Techniques, Van

Nostrand Reinhold, 1990.
• Myers: The art of Software Testing, John
Wiley & Sons, 1979.
• Ghezzi et al.: Fundamentals of Software
Engineering, Prentice Hall, 1992.
• Rapps, Weyuker: Selecting software test
data using data flow information, IEEE
Trans. on Software Engineering, SE-
11(4):367-375, April 1985.
• Michal Young, Mauro Pezze: Software
Testing and Analysis. 2006.
165