_diseñodecasosdeprueba 5k2y4a

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)

2)

3)

Objetivo: la característica del sistema a comprobar Datos de entrada y de ambiente: datos a introducir al sistema que se encuentra en condiciones preestablecidas. 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 . 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”

Generar Factura

Vendedor (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

A S 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 facturados aún.

S A

6. El vendedor confirma la generación de la factura.

S

7. Se genera la factura actualizando el estado del pedido según corresponda.

S A S S 28

2.A. No existen pedidos en ese estado. 2.A.1. El sistema informa la situación mostrando un

E 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.

S

Alternativas

E

6.A. El vendedor no confirma la generación de la factura. 6.A.1. Se cancela el use case.

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

E 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 case

Ing. Judith Meles

14

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

SE2

A3

Caminos Resultantes: Casos de Prueba Positivos:

S4 CANCELA USE CASE

1. 2.

S5 A6

AE6

A1 – S2- A3- S4- S5-A6-S7S8- A9- S10. A1 – S2- A3- S4- S5-A6-S7S8- AE9.

Casos de Prueba Negativos:

S7

3. 4.

S8

A1 – SE2. A1 – S2- A3- S4- S5- AE6.

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 Prueba

Nombre del Caso de Prueba

Tipo de Prueba

Juego de Prueba

Prioridad

Camino de Prueba Resultado Condiciones de Inicio

Ciclo 0 Paso

Descripción

Resultado Esperado

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

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 relacionados.

CRUD

pueden

utilizarse

entre

para

ver

use

cases

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 1

Use Case 3 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 s:  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 .  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