Universidad Tecnológica Nacional

Facultad Regional Córdoba

Cátedra de Diseño de Sistemas

Diseño de Casos de Prueba

Ing. Judith Meles

Condiciones de prueba
Esta es la reacción esperada de un
sistema frente a un estímulo particular,
este estímulo está constituido por las
distintas entradas.
Una condición de prueba debe ser
probada por al menos un caso de prueba

2 Ing. Judith Meles

1
 CASOS DE PRUEBA
Un caso de prueba es la unidad de la
actividad de la prueba.

Consta de tres partes:

1) Objetivo: la característica del sistema a
comprobar
2) Datos de entrada y de ambiente: datos a
introducir al sistema que se encuentra en
condiciones preestablecidas.
3) Comportamiento esperado: La salida o la
acción esperada en el sistema de acuerdo a
los requerimientos del mismo.

3 Ing. Judith Meles

CASOS DE PRUEBA
“Los bugs se esconden en las esquinas
y se congregan en los
límites ..."
Boris Beizer

OBJETIVO descubrir errores

CRITERIO en forma completa

RESTRICCIÓN con el mínimo de esfuerzo y

tiempo
4 Ing. Judith Meles

2
 CASOS DE PRUEBA
Los casos de prueba se deben confeccionar en forma
paralela al desarrollo.
Si contamos con casos de uso, los utilizaremos como
base para el desarrollo de casos de prueba para
probar la funcionalidad requerida del sistema.

Además debemos generar:

casos de prueba para el control de rango y manejo
de errores.
casos de prueba que tengan en cuenta la
interacción entre los diversos casos de prueba

5 Ing. Judith Meles

Derivación de Casos de Prueba

En base a documentos del cliente
En base a documentos de relevamiento
En base a casos de uso
En base a especificaciones de programación
En base a código

6 Ing. Judith Meles

3
 Derivación de Casos de Prueba

La actividad de diseño de casos de

pruebas siempre debe realizarse.
Debe basarse en alguna documentación
existente del sistema.
La documentación a recibir en el área de
testing, dependerá de:
Madurez de la organización en cuanto al
proceso.
Metodología de diseño de software
seleccionada.

7 Ing. Judith Meles

En base a documentos del cliente

Cobertura muy condicionada: dependerá

de cuán completa sea la documentación
del cliente.
Descripción de casos de pruebas
generales que luego se particularizarán
on-working.
Esos casos de pruebas generales son
útiles para medir o estimar el trabajo de
testing requerido y poder cotizar.

8 Ing. Judith Meles

4
 En base a documentos del cliente

Útil para el diseño de casos de prueba

de funciones de negocio.
Aconsejable para las pruebas de
aceptación de usuario.
Puede ser muy pobre para un testing
funcional.

9 Ing. Judith Meles

En base a documentos de
relevamiento
Se puede caer en supuestos equivocados para aplicar
un testing funcional, de carga, performance, etc.
Así como en el relevamiento se puede basar un
diseño de software, así también puede basarse el
diseño de casos de pruebas.
El diseño de casos de pruebas, debería ser más
completo que el logrado en base a documentos del
cliente.
Se pueden perder detalles que se contemplan en el
diseño, pero deben completarse más adelante,
incluso en el ciclo 0 del testing.

10 Ing. Judith Meles

5
 En base a documentos de
relevamiento
Cobertura condicionada: dependerá de
cuán completa sea la documentación de
relevamiento.
Aconsejable para las pruebas de
sistema.
No debería ser pobre para un testing
funcional.

11 Ing. Judith Meles

En base a documentos de
relevamiento
Si se detectan omisiones o supuestos
equivocados en el relevamiento, se debe
informar para corregir.
El diseño de casos de pruebas generado
de estos documentos tiene que servir al
testing, y no hay que confundir con el
diseño del desarrollo.

12 Ing. Judith Meles

6
 En base a Casos de Uso
Cobertura completa del diseño.
El diseño de casos de pruebas logrado
es bien detallado.
Aconsejable para las pruebas
funcionales.
No se cae en supuestos equivocados.

13 Ing. Judith Meles

En base a Casos de Uso

La plantilla para la descripción de los
casos de prueba, puede ser la misma
utilizada para el caso de uso.
Pero pueden utilizarse otras plantillas,
planillas de condiciones, tablas, etc.
Será dependiente de lo que se requiera
testear.

14 Ing. Judith Meles

7
 En base a Casos de Uso

Casos de uso vs. Casos de prueba

Los casos de uso describen lo que el
sistema deberá hacer, mientras que
los casos de prueba aseguran que el
sistema sea todo lo que se definió.

15 Ing. Judith Meles

En base a Casos de Uso

Casos de uso vs. Casos de prueba
Los casos de prueba y los casos de uso son
dependientes en dos sentidos:
Si los casos de uso están completos, precisos y
claros el proceso de derivación de casos de prueba
es transparente y directo.
Si los casos de uso no están bien delineados, el
intento de derivar de ellos los casos de prueba
ayudará a depurar los mismos.

16 Ing. Judith Meles

8
 En base a Casos de Uso
Casos de uso vs. Casos de prueba
Cada alternativa de un caso de uso define
automáticamente un caso de prueba.
Normalmente hay más de un caso de prueba para cada
alternativa de un caso de uso.
Además recordar que los casos de uso no especifican
requerimientos no funcionales.
Y los casos de uso no contemplan la interacción entre
ellos, con lo que hay que definir casos de prueba
específicos.

17 Ing. Judith Meles

En base a especificaciones de
programación
En Testing se reciben las mismas especificaciones
que se le envían al programador.
Si un programador puede codificar en base a estas
especificaciones, Testing debe poder diseñar casos
de prueba y testear.
Más completo que el diseño que se logra en base a
documentos del cliente y de relevamiento. Más
detalle.
Se puede lograr un diseño de casos de prueba de
amplia cobertura

18 Ing. Judith Meles

9
 En base a especificaciones de
programación
Sirve para el testing funcional.
Si las especificaciones incluyen
un prototipo de pantalla, se
pueden diseñar casos para testing
de usabilidad.

19 Ing. Judith Meles

En base a especificaciones de
programación

DESVENTAJA:
Si empezamos acá a diseñar casos de prueba, ya
hemos empezado tarde las tareas de testing. Lo
que implica que los errores que encontremos
serán más caros de corregir para la organización.

20 Ing. Judith Meles

10
 En base a código
En Testing se recibe el CODIGO.
Es aplicable en el diseño con técnicas de CAJA
BLANCA.
Adquiere las mismas ventajas y desventajas que esta
técnica tiene.
Es complementario al diseño de casos de prueba en
base a documentación.
Amplia cobertura del código y por supuesto del diseño.
Se usa para el diseño de casos de prueba de Test de
Componentes.
Permite completar los casos de prueba para asegurar
una mayor cobertura

21 Ing. Judith Meles

Diseño de Casos de Prueba

desde los casos de uso

Prueba de Software

11
 CASOS DE PRUEBA vs. CASOS DE USO

Los caso de uso describen lo que el sistema

deberá hacer, mientras que los Casos de Prueba
aseguran que el sistema sea todo lo que se
prometió.
Los casos de uso son generales, mientras que los
casos de prueba son particulares.

Se construyen casos de prueba para cada

escenario de un caso de uso.

23 Ing. Judith Meles

Estrategia de Prueba
La actividad de construcción de casos de prueba puede distribuirse
a lo largo del desarrollo de software en lugar de dejarlo para el final.
Muchas cosas pueden salir mal en un sistema, tal vez lo más fácil de
probar sea la funcionalidad del sistema definida por un Modelo de
Casos de Uso.
Muchos tipos de problemas están relacionados con requerimientos
no funcionales, que están más allá del modelado de casos de uso.
Un problema a tener en cuenta es la interacción entre casos de uso,
dado que el modelo no muestra secuencialidad  orden natural.
El control de rangos y el manejo de errores en el ingreso de valores
representan otra clase de problemas a considerar.
Los rangos pueden reflejar la habilidad del sistema para crecer a lo
largo del tiempo.

24 Ing. Judith Meles

12
 Estrategia de Prueba

Una estrategia de prueba completa incluye:

Pruebas Funcionales.
Pruebas de Interacción
Pruebas de Rango
Pruebas de Manejo de Errores
Pruebas relacionadas con requerimientos no funcionales, que
están fuera del alcance de la técnica.
Nos concentramos en los tipos de prueba que pueden derivarse
implícita o explícitamente del Modelo de Casos de Uso.

25 Ing. Judith Meles

Creación de Casos de Prueba

Se puede construir un juego de casos de prueba para cada caso de

uso.
Cada caso de prueba representa un escenario del caso de uso.
Algunos pasos representan puntos de decisión donde el sistema
necesita más información del actor.
Se indica con “A” los pasos ejecutados por el ACTOR.
Se indica con “S” cuando el sistema realiza una acción.
Se indica con “E” cuando un paso es una condición excepción o no
es parte del curso normal.

26 Ing. Judith Meles

13
 Ejemplo: Caso de Uso “Generar Factura”

Vendedor Generar Factura

(f rom Modelo del SI)

27 Ing. Judith Meles

Ejemplo: Caso de Uso “Generar Factura”

Nombre del Use Case: GENERAR FACTURA Nro. de Orden: 1

Actor Principal: Vendedor Actor Secundario: no aplica

Tipo de Use Case: Concreto Abstracto

Objetivo: generar la factura correspondiente a un pedido determinado.

Precondiciones: no aplica

Post- Condiciones: factura generada, el use case se cancela si no se confirma la generación de la misma o si no se selecciona ningún pedido.

Curso Normal Alternativas

A 1. El use case comienza cuando el vendedor ingresa la opción de generar

factura.
2. El sistema muestra la lista de pedidos que estén listos y no hayan sido 2.A. No existen pedidos en ese estado.
S facturados aún. 2.A.1. El sistema informa la situación mostrando un
E mensaje
A 3. El vendedor selecciona el pedido que desea facturar. 2.A.2. Se cancela el use case.

4. El sistema muestra los datos completos del pedido y calcula el monto total
S
a cobrar
S 5. El sistema solicita la confirmación de la generación de la factura.

A 6. El vendedor confirma la generación de la factura. E 6.A. El vendedor no confirma la generación de la factura.

6.A.1. Se cancela el use case.
S 7. Se genera la factura actualizando el estado del pedido según corresponda.

8. El sistema solicita confirmación de la impresión de la factura.

S
9. El Vendedor confirma la impresión E 9.A. El vendedor no confirma la impresión
A 9.A. 1. Fin del use case
S 10. Se imprime la factura
S 11. Fin del use case
28 Ing. Judith Meles

14
 Grafo de Caminos para el Caso de Uso “Generar Factura”
A1

S2 SE2 Caminos Resultantes:

A3
Casos de Prueba Positivos:
S4
CANCELA USE CASE 1. A1 – S2- A3- S4- S5-A6-S7-
S8- A9- S10.
S5 2. A1 – S2- A3- S4- S5-A6-S7-
S8- AE9.
A6
AE6 Casos de Prueba Negativos:

S7 3. A1 – SE2.
4. A1 – S2- A3- S4- S5- AE6.
S8

AE9
A9

S10 FIN USE CASE

29 Ing. Judith Meles

Construcción de Casos de Prueba

Para crear casos de prueba desde los casos de uso, se invierte el

proceso por el cual los escenarios se transformaron en casos de
uso.
Se reemplazan las entidades abstractas del caso de uso por
instancias específicas, esto ocurre en las pre y pos condiciones y
flujos de eventos.
Las precondiciones se mapean a la sección de SETUP del caso de
prueba.
Las post condiciones se mapean a la sección de RESULTADOS del
caso de prueba.
Cada paso en el caso de prueba debe tener un estado de: PASÓ,
FALLÓ o ADVERTENCIA después que el caso de prueba se ha
completado.

30 Ing. Judith Meles

15
 Plantilla para la Construcción de Casos de Prueba
Id del Caso de Nombre del Caso de
Prueba Prueba Tipo de Prueba
Juego de Prueba Prioridad
Camino de Prueba
Resultado
Condiciones de
Inicio

Ciclo 0
Id de
Paso Descripción Resultado Esperado Resultado Obtenido Estado Problema

Estado del Caso de Prueba en el Ciclo

Nombre del Analista de Prueba que ejecutó el caso de prueba en el Ciclo
Fecha de Ejecución del Caso de Prueba

31 Ing. Judith Meles

Prueba de Interacción
Las interacciones entre caso de uso son las áreas más difíciles de
probar.
Esto se debe a la gran cantidad de combinaciones, aún en un
sistema de tamaño moderado.
Se pueden utilizar técnicas para buscar áreas donde la interacción
entre casos de uso pueda traer problemas.

Caso de Prueba 1 -3
Use case 1

Juego de Pruebas 1 +
Caso de Prueba 14-1

Juego de Prueba de Interacción

Caso de Prueba 2-1

Use case 2

Juego de Pruebas 1
32 Ing. Judith Meles

16
 Prueba de Interacción
Una forma de buscar interacciones es buscar objetos compartidos
entre use cases.
Las matrices CRUD pueden utilizarse entre para ver use cases
relacionados.
En especial se buscan situaciones donde los objetos son: LEIDOS,
ACTUALIZADOS o BORRADOS en un use case y creados en otro.
¿Qué pasa cuando los objetos no existen?  “Leer antes de crear”.
¿Qué pasa cuando borramos objetos que otros leen o actualizan? 
“Leer después de borrar”.
Veamos la matriz de interacción:

Use Case 1 Use Case 2 Use Case 3

Use Case 1 LAC
Use Case 2 LAC
Use Case 3 LDB

33 Ing. Judith Meles

¿Cuántos casos de Prueba?

Los Use Cases son un punto de partida excelente para definir caso de prueba, y en
particular los casos de prueba de aceptación de usuarios:
 Se debe crear al menos un caso de prueba por cada caso de uso.
En general, se tendrán 4 o 5 casos de prueba por cada caso de uso.
 Se debe crear al menos un caso de prueba por cada alternativa de un caso de uso.
 Si hay una relación de extensión, se debe plantear un Caso de Prueba que la
contenga y uno que no.
 Si hay alternativas se debe preparar al menos un caso en que la expresión contenga
el curso normal y uno con cada alternativa.
 Por cada caso de uso, debo incluir al menos un caso de prueba con una acción
inválida por parte del usuario.
 En todos los casos de prueba se debe especificar el comportamiento esperado del
sistema.
 Es muy importante crear los casos de prueba en el momento en que finalizó la
documentación de los caso de uso, si es posible antes que se dé por concluido el
análisis.

34 Ing. Judith Meles

17