Está en la página 1de 38

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 particin equivalente anlisis de los valores lmites Grafo de causa efecto adivinacin/suposicin de errores

Caja Negra

Caja Blanca

> = 20

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
A>1 AND B=0

X=X/A A B X ace 2 0 3

b
A=2 OR X>1

e X=X+1

Caja Blanca /Statement Coverage


a
A>1 AND B=0

X=X/A A B X ace 2 0 3

b
A=2 OR X>1

e X=X+1 abd

Mal 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
A>1 AND B=0

X=X/A A B X acd 3 0 3 2 1 1

b
A=2 OR X>1

abe e 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
A>1 AND B=0

X=X/A

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

b
A=2 OR X>1

e X=X+1 ace A B X 2 0 4 1 1 1

abd

Caja Blanca / Condition Coverage




No siempre la Condition coverage incluye la decision coverage

Caja Blanca / Decision / Condition Coverage A>1 A<=1


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

b e X=X+1 abe

1 0 3 2 1 1

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


a
A>1 AND B=0

A 2 2

X >1 <=1

>1 =0 c >1 =/0 X=X/A <=1 =0 <=1 =/0

=/2 >1 =/2 <=1

b
A=2 OR X>1

A B C e X=X+1 2 1 1 1 0 2 2 0 4

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 uno vlido y otro invlido

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
A D

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
Menos trabajo
5 drivers no stubs b-u 5 stubs no drivers t-d

No incremental
Menos tiempo de mquina Se pueden realizar ms actividades en paralelo

Errores en interfaces o valores asumidos por los mdulos en forma incorrecta, se evidencian 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  Es mejor si hay ms probabilidad de encontrar defectos en las puntas  Las condiciones de Test en ms fcil crear  Las observaciones de los resultados son ms fciles

Desventajas  Se deben prepara los drivers  El programa como una unidad no exite hasta que no se prueba el ltimo mdulo

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