The Art of Software testing

MYERS
Casos de Prueba

Cul es el subconjunto de casos de

prueba que tiene una mayor
probabilidad de detectar errores.
Test de Unidad
Tipos
Caja Blanca
statement coverage
Decision coverage
decision / condition coverage
Multiple-condition coverage
Caja Negra
particin equivalente
anlisis de los valores lmites
Grafo de causa efecto
adivinacin/suposicin de errores
Caja Blanca
A

> = 20

B
Caja Blanca
Testeo exaustivo de caminos
Imposibilidad real de hacerlo
No asegura la correccin del programa
No necesariamente machea las
especificaciones
Pueden faltar caminos
Errores que se manifiestan dependiendo de los
datos que estemos usando
Statement Coverage

Todos los statements del programa

deben ser ejecutados al menos una
vez
Caja Blanca / Statement
Coverage
a

c X=X/A
A>1 AND
B=0 A B X
ace 2 0 3
b

A=2 OR e
X>1 X=X+1

d
Caja Blanca /Statement Coverage
a

c X=X/A
A>1 AND
B=0 A B X
ace 2 0 3
b

A=2 OR e
X>1 X=X+1 Mal
abd especificados
AND por OR
d
X>0
Caja Blanca / Decision Coverage

Suficientes casos de prueba para que los

resultados de las decisiones (V o F) se ejecuten
al menos una vez y que todos los statement sean
ejecutados.
Normalmente esta incluido Statement Coverage,
salvo las siguiente excepciones:
El programa no tiene decisiones
Si tienen ms de una entrada el programa
case
Caja Blanca / Decision Coverage
a

c X=X/A
A>1 AND
B=0 A B X
acd 3 0 3
b abe 2 1 1
A=2 OR e
X>1 X=X+1
Si X<1 en vez de
X>1
d
Caja Blanca / Condition
Coverage

Un criterio ms fuerte es escribir casos

de prueba de tal forma que cada
condicin de cada decisin tome todos
los valores posibles por lo menos una
vez.
Caja Blanca / Condition
Coverage
a
A>1 A<=1
c X=X/A B=0 B=/0
A>1 AND
B=0
A=2 A=/2
X>1 X<=1
b

A=2 OR e
X>1 X=X+1
A B X
ace 2 0 4
d abd 1 1 1
Caja Blanca / Condition
Coverage

No siempre la Condition coverage

incluye la decision coverage
Caja Blanca / Decision /
Condition Coverage A>1 A<=1
a B=0 B=/0

c A=2 A=/2
A>1 AND X=X/A
B=0 X>1 X<=1

A B X
b
abe 1 0 3
A=2 OR e
X>1 X=X+1 abe 2 1 1

d
Caja Blanca / Decision /
Condition Coverage

Suficientes casos de prueba para que

cada condicin en una decisin, tome
todas las posibles salidas al menos una
vez y sea invocado cada punto de
entrada al menos una vez
Caja Blanca / Multiple
Condition Coverage

Errores en la expresin lgica no se hacen

especialmente visibles por la condition /
decition coverage.
Hay que escribir suficientes casos de prueba
de tal forma que todas las posibles
combinaciones de las condiciones de salida
en cada decisin y todos los puntos de
entrada sean invocados al menos una vez
Caja Blanca / Multiple
Condition Coverage A B A X
a >1 =0 2 >1
>1 =/0 2 <=1
c X=X/A
A>1 AND
B=0 <=1 =0 =/2 >1
<=1 =/0 =/2 <=1
b A B C

A=2 OR e 2 0 4
X>1 X=X+1
2 1 1
1 0 2
d
1 1 1
Caja Negra / Particin
equivalente
Maximizar el nmero de errores encontrados en
un nmero finito de casos de prueba
Incluir la mayor cantidad posible de condiciones
de entrada en los casos de prueba para minimizar
el nmero total de casos de prueba
Se debe tratar de particionar los dominios de las
entradas del programa en un nmero finito de
clases equivalentes (el test del valor
representativo es equivalente al test de cualquier
otro valor)
Se deben definir las clases equivalentes vlidas y
las no vlidas
Caja Negra / Particin
Equivalente
Identificacin de los los casos de prueba a partir de la
entrada
Rango de valores
una clase equivalente vlida
dos clases invlidas
Nmero de valores
una clase equivalente vlida
dos clases invlidas
Conjunto de valores de entradas, manejados en
forma diferente por el programa
uno vlido y otro invlido
debe ser
Caja Negra / Anlisis de Valores
lmites
Un rango de valores para la entrada / salida
caso de prueba para los extremos del intervalo
caso de pruebas invlidos alrededor de los
extremos
Un nmero de valores entrada / salida
un caso de prueba para el mximo y otro para
el mnimo
un caso de prueba en los alrededores del
nmero
Si la entrada o salida es un conjunto ordenado
focalizarse en el primero y ltimo elemento
Caja Negra / Grafo de causa
efecto
Explora las circunstancias en donde se
dan combinaciones de las entradas
Tabla de Decisin
Causas son las entradas
Efectos son las salidas
Columnas de la Tablas son los casos de
Prueba
Estrategia
Si las especificaciones contienen combinaciones
de las entradas, comenzar con un grafo de causa
efecto
Siempre usar anlisis de los valores lmites
(entrada o salida), completando el anterior
Completar los casos de prueba, identificando las
clases equivalentes para las entradas y las
salidas. Usar suposicin de errores para agregar
adicionales casos de prueba
Examinar los casos de prueba considerando la
lgica del programa.
Test de Integracin
El orden en que los mdulos deben ser
testeados e integrados, la forma en que van
a ser combinados para construir el sistema
No incremental o Big-Bang
Testeamos cada mdulo en forma independiente
y despus combinamos los mdulos para formar
el programa
Incremental
Testeamos el nuevo mdulo con los mdulos
testeados antes de que sea testeado
Test de Integracin

B C D

E F

ECF, 3 DRIVERS E+B F+D C, 2 DRIVERS A

FI:
STUB = PUNTA,
CABO
Test de Integracin

DRIVER MODULE (tool): transmite los

casos de prueba al mdulo que se esta
testeando, y muestra los resultado
producidos por el mdulo
STUB MODULES: simula la
transferencia de control a otro modlo y
la respuesta de este mdulo
Test de Integracin
Ventajas
Incremental No incremental
Menos trabajo
5 drivers no stubs b-u
Menos tiempo de
5 stubs no drivers t-d mquina
Errores en interfaces o Se pueden realizar
valores asumidos por los
mdulos en forma ms actividades en
incorrecta, se evidencian paralelo
antes
Se puenden aislar los
errores anteriores. El
debbuging es ms facil
Los modulos estn ms
expuestos, testing ms
profundo
Test de Integracin Test
Incremental Top Down
Ventajas
Es mejor si hay ms probabilidad de
encontrar defectos en la cima
Cuanto ms temprano se incorpore las
funciones de I/O, la representacin de los
casos de prueba es ms fcil
Cuanto antes se pueda tener el esqueleto
del programa facilita la comprensin y
anima la operacin
Test de Integracin Test
Incremental Top Down
Desventajas
Se deben construir los stubs. Suelen ser ms
complicados de los que aparentan
Antes de que las funciones de las I/O estn presentes
la representacin de los casos de prueba en los stubs
puede dificultarse
Condiciones de prueba pueden ser imposibles o muy
difciles de crear
La observacin de la salida es ms dificil
Puede llevar a pensar que el diseo y teteo se pueden
superponer (el diseo es iterativo)
Induce a diferir la finalizacin del test de un mdulo
Test de Integracin Test
Incremental Botton-Up
Ventajas Desventajas
Es mejor si hay ms
Se deben prepara
probabilidad de
los drivers
encontrar defectos en
las puntas El programa como
Las condiciones de una unidad no exite
Test en ms fcil crear hasta que no se
Las observaciones de prueba el ltimo
los resultados son ms mdulo
fciles
Test Funcional

Un error en el software existe cuando el

programa no hace algo que el usuario
final espera razonablemente que lo
haga
Tiende a encontrar diferencia entre las
especificaciones externas y el
programa.
Caja negra
Test de Sistema
Se realiza para comparar el sistema con sus
objetivos originales .
Se busca demostrar que objetivos no se cumplen
No es posible realizarlo si no existen objetivos
documentados
No significa probar la funcionalidad en su conjunto
Se usa como base los objetivos originales y la
documentacin del susuario para ampliarla
No existe un mtodo, se dan lineamientos, a la
hora de preparar los casos de prueba
Test de Sistema
Test de Funcionalidad: si cada
funcionalidad nombrada en los objetivos esta
presente. Se comparan mentalmente los
objetivos con la documentacin del usuario
Test de Volumen: se trata de probar que el
sistema no soporta la carga establecida en
las especificaciones
Test de Stress: se ve la reaccin del sistema
con picos de mayor volumen en un tiempo
limitado ( puede ser en situaciones que
nunca ocurran o que puedan eventualmente
ocurrir)
Test de Sistema
Usabilidad:
Interfaz del usuario (uso)
Salidas de los programas
Comprensin de los mensajes
Integridad conceptual de las interfaces
Redundancia para controlar la seguridad
Nmero excesivo de opciones
Uso del teclado
Test de seguridad
Test de Performance
Test Storage
Test de Sistema

Test de Configuracin: se debe tratar

de probar que alguna configuracin
especificada no se soporta
Test de Compatibilidad
Test de instalacin
Test de Recuperacin
Test de Procedimiento (por ej.
Mantenimiento)
Test de Sistema

Test de documentacin
Test de proceso manuales
Test de aceptacin (usuario)
Test de instalacin (casos de prueba
para encontrar fallas de instalacin)
Planificacin y control del
Testing Plan de Testing
Objetivos de cada fase
Criterio de finalizacin
Calendarios
Responsabilidades:
quien disea, ejecuta verifica los casos de prueba
Quien corrige los errores, y ejecuta el test de
regresin
arbitro
Libreras de Test-case
Tools
Planificacin y control del
Testing Plan de Testing
Tiempo de mquina
Configuracin de Hardware
Integracin
Procedimientos de Seguimiento y
Debugging
Test de Regresin
Criterio de Finalizacin
Test de unidad: aplicar un mtodo
Test de Integracin: se finaliza cuando se
cumplieron los XXX meses programados y se
han hallado y corregido XXX errores.
Test de Sistema: se finaliza cuando se
cumplieron los XXX meses programados y se
han hallado y XXX 100 errores.
En los dos ltimos casos es importante llegar
a probar que seguir testeando es
improductivo
2. Tcnicas de Prueba
Black Box Testing:
Prueba funcional, producida por los datos, o producida por la
entrada/salida
Prueba lo que el software debera hacer
Se basa en la definicin del mdulo a probar (definicin necesaria
para construir el mdulo)
Nos desentendemos completamente del comportamiento y
estructura internos del programa
La prueba de caja negra exhaustiva es imposible de realizar
Tendra que probar todos los valores posibles de todos los datos
de entrada.
Qu hacemos?
Seleccionamos subconjuntos de los datos de entrada posibles,
esperando
2. Tcnicas de Prueba
White Box Testing:

Prueba estructural
Usa la estructura interna del cdigo para
derivar los casos de prueba

Prueba lo que el software hace

Se basa en la definicin del mdulo a
probar (definicin necesaria para construir el
mdulo)
3. Tipos de Prueba

Prueba y Ciclo de Vida

3. Tipos de Prueba
Unit Test

Prueba el componente en forma

independiente

Generalmente lo realiza el rea que

construy el mdulo

Se basa en el diseo detallado

Comienza una vez codificado, compilado y

revisado el mdulo
 3. Tipos de Prueba

Pruebas de
Integracin

Es un tcnica sistemtica para

construir la estructura del
programa mientras que voy
probando las interacciones
 3. Tipos de Prueba

Regresion Test

Pruebas orientadas a verificar que, luego de introducido un cambio

en el cdigo, la funcionalidad original no se modific

Tengo que probar lo nuevo y lo viejo

Por eso necesitamos guardar los casos de prueba

(registrarlos)
 3. Tipos de Prueba
System Test

Una vez integrado debo probar el software como

conjunto y en conjunto con el resto del Sistema

Debemos probar en un ambiente similar al real:

Hay otras aplicaciones
Hay hardware y otros equipos

Tipos de Pruebas de Sistema

Pruebas de Recuperacin
Prueba de Seguridad
Prueba de Resistencia (Stress)
 3. Tipos de Prueba
User Acceptance Test (UAT):

Pruebas realizadas por los usuarios para verificar que el sistema se ajusta
a sus requerimientos

Los casos de prueba estn basados en la especificacin de

requerimientos

Es una tcnica de caja negra