_DiseñoDeCasosDePrueba
17
1 Diseño de Casos de Prueba Ing. Judith Meles Universidad Tecnológica Nacional Facultad Regional Córdoba Cátedra de Diseño de Sistemas 2 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
-
Upload
ricardo-rodriguez -
Category
Documents
-
view
112 -
download
0
Transcript of _DiseñoDeCasosDePrueba
1
Diseño de Casos de Prueba
Ing. Judith Meles
Universidad Tecnológica Nacional
Facultad Regional Córdoba
Cátedra de Diseño de Sistemas
2 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
3 Ing. Judith Meles
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.
4 Ing. Judith Meles
CASOS DE PRUEBA
“Los bugs se esconden en las esquinas
y se congregan en los
límites ..."
Boris Beizer
OBJETIVO
CRITERIO
RESTRICCIÓN
descubrir errores
en forma completa
con el mínimo de esfuerzo y
tiempo
3
5 Ing. Judith Meles
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
6 Ing. Judith Meles
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
Derivación de Casos de Prueba
4
7 Ing. Judith Meles
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.
Derivación de Casos de Prueba
8 Ing. Judith Meles
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.
En base a documentos del cliente
5
9 Ing. Judith Meles
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.
10 Ing. Judith Meles
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.
En base a documentos de
relevamiento
6
11 Ing. Judith Meles
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.
En base a documentos de
relevamiento
12 Ing. Judith Meles
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.
En base a documentos de
relevamiento
7
13 Ing. Judith Meles
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.
En base a Casos de Uso
14 Ing. Judith Meles
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.
En base a Casos de Uso
8
15 Ing. Judith Meles
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ó.
En base a Casos de Uso
16 Ing. Judith Meles
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.
En base a Casos de Uso
9
17 Ing. Judith Meles
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.
En base a Casos de Uso
18 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
10
19 Ing. Judith Meles
Sirve para el testing funcional.
Si las especificaciones incluyen
un prototipo de pantalla, se
pueden diseñar casos para testing
de usabilidad.
En base a especificaciones de
programación
20 Ing. Judith Meles
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.
En base a especificaciones de
programación
11
21 Ing. Judith Meles
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
En base a código
Prueba de Software
Diseño de Casos de Prueba
desde los casos de uso
12
23 Ing. Judith Meles
CASOS DE PRUEBA vs. CASOS DE USO
Los caso de uso describen lo que el sistema deberá hacer, mientras que los Casos de Pruebaaseguran 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.
24 Ing. Judith Meles
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.
Estrategia de Prueba
13
25 Ing. Judith Meles
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.
Estrategia de Prueba
26 Ing. Judith Meles
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.
Creación de Casos de Prueba
14
27 Ing. Judith Meles
Ejemplo: Caso de Uso “Generar Factura”
Generar FacturaVendedor
(f rom Modelo del SI)
28 Ing. Judith Meles
A
A
A
A
S
S
S
S
S
S
E
E
E
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
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
facturados aún.
2.A. No existen pedidos en ese estado.
2.A.1. El sistema informa la situación mostrando un
mensaje
2.A.2. Se cancela el use case.3. El vendedor selecciona el pedido que desea facturar.
4. El sistema muestra los datos completos del pedido y calcula el monto total
a cobrar
5. El sistema solicita la confirmación de la generación de la factura.
6. El vendedor confirma la generación de la factura. 6.A. El vendedor no confirma la generación de la factura.
6.A.1. Se cancela el use case.
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.
9. El Vendedor confirma la impresión 9.A. El vendedor no confirma la impresión
9.A. 1. Fin del use case
10. Se imprime la factura
11. Fin del use caseS
15
29 Ing. Judith Meles
Grafo de Caminos para el Caso de Uso “Generar Factura”
A1
S5
S2
AE9
S10
A9
S8
S7
AE6
SE2
A6
S4
A3
FIN USE CASE
CANCELA USE CASE
Caminos Resultantes:
Casos de Prueba Positivos:
1. A1 – S2- A3- S4- S5-A6-S7-
S8- A9- S10.
2. A1 – S2- A3- S4- S5-A6-S7-
S8- AE9.
Casos de Prueba Negativos:
3. A1 – SE2.
4. A1 – S2- A3- S4- S5- AE6.
30 Ing. Judith Meles
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.
Construcción de Casos de Prueba
16
31 Ing. Judith Meles
Plantilla para la Construcción de Casos de Prueba
Id del Caso de
Prueba
Nombre del Caso de
Prueba Tipo de Prueba
Juego de Prueba Prioridad
Camino de Prueba
Resultado
Condiciones de
Inicio
Paso Descripción Resultado Esperado
Ciclo 0
Resultado Obtenido Estado
Id de
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
32 Ing. Judith Meles
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.
Prueba de Interacción
Use case 1
Juego de Pruebas 1
Caso de Prueba 1 -3
Use case 2
Juego de Pruebas 1
Caso de Prueba 2-1
Caso de Prueba 14-1
+
Juego de Prueba de Interacción
17
33 Ing. Judith Meles
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:
Prueba de Interacción
Use Case 1 Use Case 2 Use Case 3
Use Case 1 LAC
Use Case 2 LAC
Use Case 3 LDB
34 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.
