Tema I

Tema I
Testing Estructurado
1ra Parte
Verificación y Validación de Software ‐‐ UNS
1
Contenidos
y Conceptos de V&V
y Fundamentos de Testing
y Testing de Unidad
y Testing de Unidad: Caja Blanca
Verificación y Validación de Software ‐‐ UNS
2
Verificación y Validación
y Lectura
y Ghezzi, C., et.al. Fundamentals of Software Engineering. Prentice‐Hall, 1991. [Cap. 6]
Verificación y Validación de Software ‐‐ UNS
3
Conceptos de V&V (1)
y Durante el diseño y construcción de un Producto Software, se
requiere verificar el producto en todas las etapas intermedias
de desarrollo
y Aún con técnicas de diseño y programación sofisticadas, la
intervención humana implica equivocaciones que se traducen
en errores
y Los productos terminados que pasaron las
verificaciones intermedias, también
deben ser verificados
y Los Clientes deben dar su conformidad
con el Producto Software desarrollado
Verificación y Validación de Software ‐‐ UNS
4
Conceptos de V&V (2)
y Verificación: Proceso de evaluación de un sistema ¿Estamos
construyendo
correctamente
el producto?
(o de uno de sus componentes) para determinar si los productos de una fase dada satisfacen las condiciones impuestas al comienzo de dicha fase
¿Estamos
construyendo
el producto
correcto?
y Validación: Proceso de evaluación de un sistema (o de uno de sus componentes) durante o al final del proceso de desarrollo para determinar si satisface los requisitos marcados por el usuario
Verificación y Validación de Software ‐‐ UNS
5
Conceptos de V&V (3)
Ciclo de Vida de Software – Modelo V
Verificación y Validación de Software ‐‐ UNS
6
Conceptos de V&V (4)
y Debido a la urgencia de entregas de un Producto Software, es
una práctica común realizar una pobre verificación
y En general consiste de algunos casos de ejemplo, para
observar si los resultados de ejecución cumplen nuestras
expectativas
y Esto implica una pobre confianza en ese Producto Software
y La verificación no se puede sólo basar en la intuición humana,
experiencia o suerte.
y Se require que la actividad de verificación siga
principios y técnicas rigurosas y adecuadas
Verificación y Validación de Software ‐‐ UNS
7
Conceptos de V&V (5)
y Tanto el proceso de desarrollo de software
como los productos generados deben ser
verificados
y “Aún el proceso de verificación debe ser
verificado”
y Una vez realizada una verificación para comprobar un
comportamiento apropiado, es necesario verificar si los
experimentos se desarrollaron en forma apropiada
y Se aplican métodos y técnicas para la verificación, donde en
general se requiere alguna intervención humana, que es
falible a equivocaciones.
Verificación y Validación de Software ‐‐ UNS
8
Conceptos de V&V (6)
y A través de la verificación no solo debe controlarse si el
software implementado se comporta de acuerdo a la
especificación, sino certificar características de calidad.
y Atributos de calidad como Performance, Portabilidad,
Tolerancia a Fallas, etc. son requerimientos arquitectónicos,
priorizados por los Stakeholders (participantes) en un
Desarrollo centrado en Arquitectura Software
y Cuando el Producto Software ha pasado las
verificaciones iniciales y ha sido construido
“como un todo”, debe ser verificado en sus
cualidades arquitectónicas.
Verificación y Validación de Software ‐‐ UNS
9
Conceptos de V&V (7)
• La actividad de verificación debe realizarse en momentos
diferentes con objetivos, técnicas y personal diferente
• “Quien desarrolla su producto no debería verificar su producto”
• El ego humano no permite ser objetivo. No queremos aceptar
nuestras equivocaciones, y queremos “terminar pronto”.
• La verificación no puede reducirse a una respuesta binaria
(“si/no”) ya que:
• la presencia de defectos en software complejo no puede evitarse
completamente
• a veces, algunos defectos pueden ser tolerados
• en la práctica, la correctitud es relativa
• la eficiencia es un ejemplo típico de calidad que puede aparecer
en distintos niveles
Verificación y Validación de Software ‐‐ UNS
10
Conceptos de V&V (8)
Enfoques de Verificación
• Experimentar con el comportamiento de un producto para
observar si realiza lo esperado, i.e. testear el producto
• Es una técnica dinámica, dado que requiere
ejecutar el sistema para ser verificado.
• Analizar el producto (o especificación de diseño) para deducir
su operación correcta como consecuencia lógica de las
decisiones de diseño.
• Es una técnica estática, dado que no requiere ejecutar
el producto, y se puede realizar temprano en el
Ciclo de Vida.
Verificación y Validación de Software ‐‐ UNS
11
Conceptos de V&V (9)
•
El mito dice que si somos realmente buenos programando, no
habrá errores que encontrar.
•
Si nos concentramos bien, si usamos programación estructurada,
OO, silver bullets ...
•
Hay bugs, dice el mito, porque somos
malos programando, y si somos malos
debemos sentirnos culpables!
La producción de software, como cualquier actividad humana,
es un proceso sujeto a errores. Cualquiera sean los métodos
usados, no es posible garantizar que el producto final se
comporte siempre como es requerido.
Verificación y Validación de Software ‐‐ UNS
12
Fundamentos de Testing (1)
Testing de Software: verificación dinámica del comportamiento
de un programa contra el comportamiento esperado, usando un
conjunto finito de casos de test, seleccionados de manera
adecuada desde el dominio infinito de ejecución. (SWEBOK04)
• El test de un programa puede revelar la PRESENCIA
de fallas pero NUNCA demostrar su AUSENCIA
[Dijkstra’72]
Verificación y Validación de Software ‐‐ UNS
13
Fundamentos de Testing (2)
• El test debe:
• ayudar a localizar errores (no solo detectarlos),
• ser repetible (riguroso, objetivo e independiente),
• ser preciso (confiable y formal)
Modelos de Testing
Destrucción: detección de errores de implementación (fines
‘70, inicio ‘80)
Evaluación: detección de errores en el análisis, la especificación,
el diseño, la implementación (década de los ‘80)
Verificación y Validación de Software ‐‐ UNS
14
Fundamentos de Testing (3)
• La mayor parte del costo del software es el costo de los bugs:
detectarlos, corregirlos, diseñar los test, ejecutar los test
• El diseño de tests es uno de los mejores métodos para
prevenir bugs ...
• Un diseño de test debe documentar: expectativas, el
procedimiento del test en detalle, los resultados del test
Un bug se manifiesta como una conducta no esperada
Saber que el programa es incorrecto no implica conocer el bug
- diferentes bugs se pueden manifestar de la misma manera
- un bug puede tener diferentes síntomas
Verificación y Validación de Software ‐‐ UNS
15
Fundamentos de Testing (4)
Los síntomas y las causas pueden ser descubiertas con muchos
pequeños tests
Tipos de bugs: estructurales, en los datos, en
el código, en las interfaces, en los tests . . .
1+1=3
Terminología IEEE
• falla (failure): manifiesta el sintoma
de la presencia de un error.
• defecto (fault): estado intermedio
incorrecto al que se puede ingresar
durante la ejecución.
• error: aspecto incorrecto
program doble (input, output)
var x,y: integer;
begin
read(x);
y := x * x;
write(y);
end.
Verificación y Validación de Software ‐‐ UNS
16
Fundamentos de Testing (5)
Un programa P es considerado una función del conjunto de datos D,
dominio de la función, en el conjunto de datos R, el codominio (P: D -> R)
• P(d) = r
(d en D, r en R) ejecución de P con d
• ok(P,d)
si P(d) es correcto, satisface la especificación
• ok(P)
P es correcto para cada elemento d del dominio de
ingreso D
ok(P) ssi For all d en D ok(P,d)
Un test T para un programa P con dominio D es un subconjunto del
dominio D
Un elemento t de un test T es un dato de test
La ejecución de un test T consiste en la ejecución de P para todos los
datos de test t contenidos en T
Verificación y Validación de Software ‐‐ UNS
17
Fundamentos de Testing (6)
• ok(P,T): un programa P es correcto respecto a un test T si el programa
es correcto para todos los elementos de T
ok(P,T) ssi For all t en T ok(P,t)
• éxito(T,P) ssi not ok(P,T) es decir, si encontró una falla
De un test que no revela ninguna falla no se deduce que
el programa es correcto, sino que el test es inadecuado
• Un test es ideal si de su NO éxito se puede deducir que el
programa es correcto
ok(P,T) -> ok(P)
Buscamos aproximarnos a test ideales
Verificación y Validación de Software ‐‐ UNS
18
Testing de Unidad (1)
• No existe algoritmo que dado un programa arbitrario P genere
un test ideal finito
• No es posible establecer si dos programas genéricos calculan
la misma función
qué hacer?
white-box vs. black-box
Verificación y Validación de Software ‐‐ UNS
19
Testing de Unidad (2)
Ciclo de Vida de Software – Modelo V
Verificación y Validación de Software ‐‐ UNS
20
Testing de Unidad (3)
Caja Blanca
Caja Negra
• Test Estructural:
• Test de Función:
basado en la estructura del
programa (ej.: código)
• Ventajas
• formal
• con una teoría completa
• eficiente
• metódico
basado en la conducta
requerida del programa
(ej.: especificaciones)
• Ventajas
• con significado asociado
• encuentra los errores que
ve el usuario
• no necesita análisis
• independiente de la
implementación
Verificación y Validación de Software ‐‐ UNS
21
Testing de Unidad (4)
Caja Blanca:
• Desventajas
• puede no ser útil o no
tener significado
• no encuentra muchos
errores importantes
• dependiente de la impl.
• Efectividad
• encuentra 50-75% de
los errores en test de
unidad
• . . . pero son los errores
más fáciles de encontrar
Caja Negra:
• Desventajas
• ineficiente
• teoría incompleta
• no puede ser automatizado
• intuitivo más que formal
• Efectividad:
encuentra errores...
• 10-30% en test de unidad
• 50-75% en test de sistema
• los errores más
embarazosos
Verificación y Validación de Software ‐‐ UNS
22
Testing de Unidad (5)
Estrategias de Testing de Unidad
Caja Blanca
Caja Negra
• Ejecución Simbólica
• Partición en Clases de
Equivalencia
• Análisis de Flujo de Datos
• Test basado en Defectos (fault)
• Análisis de Valores Límites
• Análisis Mutacional
• Grafos Causa-Efecto
• Debugging
• Test basado en Estado
Verificación y Validación de Software ‐‐ UNS
23
Testing de Unidad: Caja Blanca (1)
Cada estrategia tiene el concepto de cubrimiento asociado
Un cubrimiento del 100% no es equivalente a que el testing sea
completo, significa que es completo respecto a cierta estrategia
Existe gran cantidad de estrategias, ninguna es
la mejor, pero hay algunas mejores que otras.
Criterios de Flujo de Control:
•
•
•
•
•
•
Criterio de Comandos (o Sentencias, o Nodos)
Criterio de Decisiones (o Arcos)
Criterio de Condiciones y Decisiones
Criterio de Condiciones Múltiples
Criterio de Bucles (Loops, Iteraciones)
Criterio de Caminos
Verificación y Validación de Software ‐‐ UNS
24
Testing de Unidad: Caja Blanca (2)
Criterios de Flujo de Control
Criterio de Comandos:
Un test T satisface este criterio ssi cada comando
ejecutable del programa es ejecutado al menos una vez
en correspondencia a al menos un dato de test de T
Criterio de las decisiones (arcos):
Seleccionar un conjunto de test T tal que al
ejecutar P para cada d en T, cada arco del
grafo de flujo de control de P sea
atravesado al menos una vez
Verificación y Validación de Software ‐‐ UNS
25
Testing de Unidad: Caja Blanca (3)
Grafos de Flujo de Control
B1
B2
nodos de I/O,
asignación, o
llamada a función
While
B1
Dos bloques
secuenciales
B1
If-Then
B1
B2
If-Then-Else
Verificación y Validación de Software ‐‐ UNS
26
Testing de Unidad: Caja Blanca (4)
1 program statement;
read(x)
read(y)
2 var
3
x, y: real;
4 begin
not (x <> 0)
5
read(x);
6
read(y);
7
if x <> 0 then x := x + 10;
8
y := y / x;
9
write(x);
x <> 0
x := x + 10
y := y/x
TC = { (x=20, y=30) }
10 write(y);
11 end.
write(x)
write(y)
TD = { (x=20, y=30),
(x=0, y=30) }
Verificación y Validación de Software ‐‐ UNS
27
Testing de Unidad: Caja Blanca (5)
Cubrimiento de las condiciones:
Un test T satisface este criterio ssi cada condición simple
que aparece en cada decisión del programa es evaluada
al menos una vez a TRUE y al menos una vez a FALSE
para diferentes datos de test.
True
False
Cubrimiento de las condiciones múltiples:
Un test T satisface este criterio ssi cada condición
simple que aparece en cada decisión del programa
es evaluada a TRUE y a FALSE en todas las
combinaciones de la tabla de verdad, para
diferentes datos de test.
Verificación y Validación de Software ‐‐ UNS
28
Testing de Unidad: Caja Blanca (6)
read(x)
read(y)
1 program branch;
2 var
3 x, y: real;
4 begin
5 read(x);
6 read(y);
7 if x = 0 or y > 0
then y:= y/x
8
else x := y + 2 / x;
9 write(x);
10 write(y);
11 end.
1
2
x := y + 2 / x
x = 0 or y > 0
3
write(x)
4
y := y / x
5
write(y)
T1 = { (x=5, y=5), (x=5, y=-5) }
T2 = { (x=0, y=-5), (x=0, y=5) }
Verificación y Validación de Software ‐‐ UNS
29
Testing de Unidad: Caja Blanca (7)
Cubrimiento de los caminos:
Seleccionar un conjunto de test T tal que al ejecutar
P para cada d en T, todos los caminos desde el
nodo inicial al final del grafo de flujo de control sean
atravesados.
Condiciones para ejecutar
loops
Después de elegir un criterio, deberíamos buscar
valores que garanticen su aplicación.
• Podemos no necesitar read (x);
gran esfuerzo . . .
z := 2 * x;
if z = 4 then statement . . .
• . . . o nunca encontrar
datos de test . . .
if x > 0 then
if x < 0 then statement . . .
Verificación y Validación de Software ‐‐ UNS
30