De casos de uso a casos de prueba

Propuestas existentes Javier Gutirrez / javierj@us.es

Presentacin del seminario

Objetivo: Describir las ideas claves y el estado del arte de las propuestas de generacin de pruebas a partir de casos de uso.

Probando casos de uso

ndice:
1. 2. 3. 4. 5. Introduccin. Tcnicas de pruebas Estudio de propuestas existentes. Estudio comparativo. Conclusiones.

Introduccin

Introduccin
No es lo mismo probar automticamente que generar pruebas automticamente. Podemos generar las pruebas automticamente y realizarlas a mano o bien disear las pruebas a mano y ejecutarlas de manera automtica.

Introduccin
Punto de partida. Punto de llegada.

Use case UC-01 UC-01 UC-03 UC-03 UC-03 UC-03 UC-04

Variable

Name

Type

Dom ain

System configuration C In (SR-01) Use Variable Nam Type Combination to Cd Out e Array case discover UC-01 configuration System configuration In C In System C (SR-01) UC-01 Combination to Cd Out Combination to Cd In Array discover discover Use Variable UC-03 System C In User combination configuration Inner Array Cj case UC-03 In User tries Combination to System Cd UC-01 Ni Inner Integer configuration discover System configuration Out (SR-01) UC-01 C Combination to UC-03 User combinationdiscover Cj Inner UC-03 User tries Inner UC-03 System Ni configuration UC-04 System configuration C UC-03 Combination to Out discover UC-03 User combination UC-03 User tries UC-04 System configuration

Domain (SR-01) Array Name (SR-01) CArray Cd Array CInteger (SR-01) Cd Cj Ni C

Type In Out In In Inner Inner Out

Dom ain (SR-01) Array (SR-01) Array Array Integer (SR-01)

Proceso

Introduccin
Tiempo de prueba (TP)

Introduccin
Problemas:
Poco tiempo para disear buenas pruebas y probar el sistema a fondo. Menos tiempo an para analizar los errores. Falta de valor de las pruebas.

Pero tenemos los requisitos desde el principio.

Introduccin

Tiempo de prueba (TP)

Ventajas e inconvenientes
Ventajas:
Valida los requisitos Evita problemas de tiempo y dinero Evita las pruebas manuales Automatiza no solo el proceso de prueba sino tambin la obtencin de dichas pruebas Evita la dependencia de las pruebas respecto del sistema. Genera un conjunto rico de pruebas (en que cada prueba aporte algo).

Inconvenientes:

Falta de herramientas y metodologas Susceptible a cambios del sistema. Explosin del espacio de prueba. Susceptible a sistemas distintos a su implementacin. Imposible considerar todos los casos.

Tcnicas de prueba

Tcnicas de prueba
Cuando probamos los casos de uso
1. Consideramos que el sistema es una caja negra. 2. Nos basamos en actores humanos. 3. Interactuamos con el sistema a travs de interfaces grficas. 4. Comprobamos los resultados a travs de interfaces grficas.

Tcnicas de prueba
Veremos tres tcnicas clsicas para probar casos de uso:
1. Caminos de ejecucin. 2. Valores de prueba. 3. Perfiles de usuario.
La mayora de las propuestas existentes se basan en estas tcnicas.

Tcnicas de prueba
Usaremos el siguiente caso de uso como ejemplo
Nombre Precondicin Secuencia principal UC-02. Cargar documento desde fichero No 1 El usuario selecciona la opcin abrir un fichero. 2 El sistema solicita el fichero a abrir. 3 El usuario selecciona el fichero y selecciona la opcin abrir. 4 El sistema descarta el documento de trabajo actual y muestra como nuevo documento de trabajo el contenido del fichero. 3 El usuario puede seleccionar la opcin de cerrar y abortar el caso de uso 4 Si el usuario seleccion un archive inexistente o surge un error al abrir el archivo, el sistema vuelve al documento actual. No.

Alternativas y Errores

Pos-condicion

Tcnicas
Caminos de ejecucin
1. Identificar todas las secuencias de pasos posibles a partir de un caso de uso. 2. Identificar los resultados de cada secuencia. 3. Asignar valores de prueba a cada secuencia. 4. Escribir una prueba para cada secuencia.

Pruebas
Caminos de ejecucin
Nombre Precondicin Secuencia principal UC-02. Cargar documento desde fichero No 1 El usuario selecciona la opcin abrir un fichero. 2 El sistema solicita el fichero a abrir. 3 El usuario selecciona el fichero y selecciona la opcin abrir. 4 El sistema descarta el documento de trabajo actual y muestra como nuevo documento de trabajo el contenido del fichero. 3 El usuario puede seleccionar la opcin de cerrar y abortar el caso de uso 4 Si el usuario seleccion un archive inexistente o surge un error al abrir el archivo, el sistema vuelve al documento actual. No.

Alternativas y Errores

Pos-condicion

Cules son los resultados de estas secuencias?.

Id 1 2 3

Secuencia Cargar un documento Inicar la carga y cancelar Error en la carga.

Pruebas
Caminos de ejecucin
Id 1 2 3 Secuencia Cargar un documento Inicar la carga y cancelar Error en la carga. Resultado El sistema muestra el contenido del nuevo documento. El sistema muestra el mismo documento que mostraba antes de iniciar la operacin. El sistema muestra un mensaje de error y el mismo documento que mostraba antes de iniciar la operacin.

Qu valores de prueba necesitamos para ejecutar estas secuencias y obtener estos resultados?.

Pruebas
Caminos de ejecucin
Id 1 2 Secuencia Cargar un documento Inicar la carga y cancelar Error en la carga. Resultado El sistema muestra el contenido del nuevo documento. El sistema muestra el mismo documento que mostraba antes de iniciar la operacin. El sistema muestra un mensaje de error y el mismo documento que mostraba antes de iniciar la operacin. Valores Archivo correcto Ninguno

Archivo incorrecto (no existe, no es un documento, etc.)

Cada fila es una prueba.

Pruebas
Valores de prueba
1. Identificar todas las variables operacionales de un caso de uso. 2. Identificar dominios y particiones equivalentes. 3. Asignar valores de prueba a cada particin. 4. Identificar los resultados esperados para cada combinacin de valores. 5. Escribir una prueba para cada secuencia.

Una variable operacional es cualquier cosa que puede variar entre dos ejecuciones de un mismo caso de uso.

Pruebas
Valores de prueba Particin: subconjunto del dominio para los cuales el sistema exhibe el mismo comportamiento. Ejemplo: booleano esCero(entero)

10

Pruebas
Valores de prueba
Nombre Precondicin Secuencia principal UC-02. Cargar documento desde fichero No 1 El usuario selecciona la opcin abrir un fichero. 2 El sistema solicita el fichero a abrir. 3 El usuario selecciona el fichero y selecciona la opcin abrir. 4 El sistema descarta el documento de trabajo actual y muestra como nuevo documento de trabajo el contenido del fichero. 3 El usuario puede seleccionar la opcin de cerrar y abortar el caso de uso 4 Si el usuario seleccion un archive inexistente o surge un error al abrir el archivo, el sistema vuelve al documento actual. No.

Alternativas y Errores

Pos-condicion

Id 01 02

Nombre Fichero Opcin

Tipo Dominio Cadena Ficheros de texto Enumerado { Cargar, Cancelar }

Pruebas
Valores de prueba
Categoras Categoras

Usamos la notacin propuesta en UML Testing Profile.

11

Pruebas
Valores de prueba
Valores Valores de prueba de prueba

Cules son los resultados Para estos valores de prueba?.

Cada objeto es un valor concreto de prueba.

Pruebas
Valores de prueba
Id Valor de prueba 1 Load, File01 2 3 Cancel, * Load, File02 Resultado El sistema muestra el contenido del nuevo documento (This is a text). El sistema muestra el mismo documento que mostraba antes de iniciar la operacin. El sistema muestra un mensaje de error indicando que no tenemos permisos para leer el archivo y el mismo documento que mostraba antes de iniciar la operacin.

Cada fila es una prueba.

12

Tcnicas de prueba
Perfiles de usuario 1. Buscamos a un usuario real. 2. Lo sentamos delante del sistema para que trabaje como lo hara cualquier da. 3. Capturamos toda su sesin de trabajo. 4. Reproducimos su sesin para ver si todo sigue funcionando bien.

Sesiones de trabajo
Perfiles de usuario
Podemos unir varias sesiones de trabajo (o datos) para crear sesiones mayores.

Veamos las ventajas e inconvenientes de cada una de estas tres aproximaciones.

13

Tcnicas de prueba
Caminos de ejecucin
Ventajas:
Comprobamos todas las alternativas. Facilidad para identificar caminos.

Inconvenientes:
Podemos olvidar valores de prueba importantes. Problemas con alternativas complejas o con bucles. Explosin combinatoria.

Tcnicas de prueba
Valores de prueba
Ventajas:
Pruebas ms exhaustivas. Pruebas de caja negra.

Inconvenientes:
Identificar variables. Identificar categoras. Restricciones entre valores. Explosin combinatoria.

14

Tcnicas de prueba
Perfiles de usuario
Ventajas:
Cmodo y rpido. Probamos ms a fondo las partes ms importantes.

Inconvenientes:
Podemos dejar partes por probar. Slo podemos hacerlo si tenemos las herramientas adecuadas !!!!. Si cambia la interfaz podemos perder las pruebas. Necesitamos un sistema presentable !!!!. Un usuario real tiene que dedicarnos su (valioso) tiempo.

Tcnicas de prueba
Conclusiones.
Tcnicas muy superficiales. Difcil de automatizar con herramientas. Pruebas muy genricas. Tcnicas no sistemticas. Dependen mucho de la pericia de quien las aplica

15

Conclusiones
Hemos visto cmo obtener pruebas del sistema a partir de casos de uso. sin embargo ese no era nuestro objetivo.
Cmo podemos sistematizar y automatizar este proceso (en la medida de lo posible)?. Cmo podemos desarrollar este proceso antes de que el sistema est construido (en la medida de lo posible)?.

Conclusiones
Esto no es fcil:
Cmo obtenemos los caminos? Cmo obtengo las particiones?. Son las variables / particiones adecuadas?. Cmo descubrimos los resultados esperados?. Etc

? ?

16

Estudio de propuestas existentes.

Estudio de propuestas existentes.

23 propuestas en total. [Denger02] (12 propuestas)

www.lsi.us.es/~javierj/approaches.html

[Gutirrez04] (12 ms)

17

Estudio de propuestas existentes.

Caractersticas comunes de las propuestas.

Bsqueda de caminos / anlisis de valores de prueba. Modelos grficos. Casos de uso individuales / en secuencia.

Estudio de propuestas existentes.

Seleccionamos las que nos dan ms ideas.

www.lsi.us.es/~javierj/approaches.html

Veamos algunas.

18

Estudio de propuestas existentes.

Binder. Naresh Labiche. Ruder. Nebut
Extended Use Case Test Design Pattern.

Extended Use Case TD Pattern

Caractersticas Ataca directamente la plantilla de caso de uso (no usa modelo grfico). Resultados en texto estructurado. Basada en el estudio de valores de prueba. Difcil de automatizar.

19

Extended Use Case TD Pattern

Proceso 1. 2. 3. 4. Identificacin de variables operacionales. Definicin de dominios de variables op. Desarrollo de relaciones operacionales. Construccin de los casos de prueba.

Extended Use Case TD Pattern

Ejemplo
1. Identificacin de variables operacionales.
Nombre Precondicin Secuencia principal UC-01. Aadir nuevo enlace. Enlace a aadir (E). No 1 El visitante solicita aadir un nuevo enlace 2 El sistema selecciona la categora Top y solicita la informacin del enlace (SR-02). Cancelar (C). 3 El usuario introduce la informacin del nuevo enlace. 4 El sistema almacena el nuevo enlace. 3.1.i El usuario cancela la operacin y este caso de uso Cambiar categora. termina. (no la usamos) 3.2.i Si el usuario desea cambiar la categora, se ejecuta el caso de uso Cambiar categora y este caso de uso continua.. Necesitamos ms 4.1.p Si el nombre del enlace o su URL estn vacos, el informacin: Qu es un sistema muestra un mensaje de error y solicita de nuevo la informacin del enlace. enlace? Nuevo enlace aadido al sistema.

Error / Secuencias alternativas

Post-condicin

20

Extended se Case TD Pattern

Ejemplo
Nombre Precondicin Secuencia principal UC-01. Aadir nuevo enlace. No 1 El visitante solicita aadir un nuevo enlace 2 El sistema selecciona la categora Top y solicita la informacin del enlace (SR-02). 3 El usuario introduce la informacin del nuevo enlace. 4 El sistema almacena el nuevo enlace. 3.1.i El usuario cancela la operacin y este caso de uso termina. 3.2.i Si el usuario desea cambiar la categora, se ejecuta el caso de uso Cambiar categora y este caso de uso continua.. Nombre 4.1.p Si el nombre del enlace o su URL estn vacos, el Informacin sistema muestra un mensaje de error y solicita de nuevo especfica la informacin del enlace. Nuevo enlace aadido al sistema.

Error / Secuencias alternativas

Enlace
SR-02. Enlaces. Nombre Dominio Identificador Entero Nombre Cadena Categora Entero URL Cadena Descripcin Cadena Aprobado Boolean Fecha Fecha El identificador debe ser nico. Todos los campos son obligatorios excepto descripcin.

Post-condicin

Restricciones

Extended Use Case TD Pattern

Ejemplo
2. Definicin de dominios de variables op. Variable Enlace a aadir (E) Cancelar (C) Dominio Una instancia del requisito de informacin SR-02 Booleano.

Enlace correcto / enlace incorrecto.

21

Extended Use Case TD Pattern

Ejemplo
3. Desarrollo de relaciones operacionales.
Variables Enlace (E) Cancelar (C) X Cierto Correcto Incorrecto Falso Falso Resultado Mensaje Pantalla X La pantalla anterior Mensaje de La pantalla confirmacin anterior Mensaje de La misma error pantalla

1 2 3

Extended Use Case TD Pattern

4. Construccin de los casos de Var. prueba.
1 C F 2 C F 3 C F

Ejemplo
Variables Enlace (E) Cancelar (C) X Cierto Pular botn de cancelar 2y3 Falso Resultado Mensaje Pantalla X La pantalla anterior

Correcto Tabla anexa 3 Incorrecto Tabla anexa 2

Mensaje de confirmacin

La pantalla anterior

1 Falso

Mensaje de error

La misma pantalla

22

Extended Use Case TD Pattern

Ideas Identificar y definir valores de prueba. Considerar las opuestas de las combinaciones de valores de prueba. Definir los resultados de cada caso de prueba.

Algunas propuestas existentes

Binder. Naresh Labiche. Ruder. Nebut
Use Case Path Analysis.

23

Use Case Path Analysis

Caractersticas

1: Acceso correcto 3: Nombre o contrasea en blanco 2: Fallo de pgina

4: Nombre o contrasea introducidos 5: Nombre inexistente 6: Contrasea no vlida

7: Acceso a pgina de inicio

Basada en bsqueda de caminos / escenarios. Notacin grfica propia. Puntuacin de los caminos de ejecucin.

Use Case Path Analysis

Proceso
1. Elaboracin de diagramas de flujo a partir de los casos de uso. 2. Identificacin de todos los posibles caminos de ejecucin. 3. Anlisis y baremacin de los caminos. 4. Seleccin de caminos a probar. 5. Elaboracin de los casos de prueba a partir de los caminos seleccionados.

24

Use Case Path Analysis

Ejemplo
1. Elaboracin de diagramas de flujo.
Nombre Precondicin Secuencia principal UC-01. Aadir nuevo enlace. No 1 El visitante solicita aadir un nuevo enlace 2 El sistema selecciona la categora Top y solicita la informacin del enlace (SR-02). 3 El usuario introduce la informacin del nuevo enlace. 4 El sistema almacena el nuevo enlace. 3.1.i El usuario cancela la operacin y este caso de uso termina. 3.2.i Si el usuario desea cambiar la categora, se ejecuta el caso de uso Cambiar categora y este caso de uso continua.. 4.1.p Si el nombre del enlace o su URL estn vacos, el sistema muestra un mensaje de error y solicita de nuevo la informacin del enlace. Nuevo enlace aadido al sistema.

6: Cambiar categora 5: Cancelar 4: Mensaje de error

Error / Secuencias alternativas

1: Introducir nuevo enlace

Post-condicin

Leyenda
3: Enlace incorrecto 2: Enlace correcto

Use Case Path Analysis

Ejemplo
2. Identificacin de todos los posibles caminos de ejecucin.

Buscamos todos los caminos posibles.

Id 1 2 3

Nombre 1, 2 5 1, 2, 3, 4, 1, 2

Descripcin

25

Use Case Path Analysis

Ejemplo
3. Anlisis y baremacin de los caminos.

Id 1 2 3

Frecuencia 10 5 8

Importancia 10 5 10

Total 20 10 18

Valoracin subjetiva

Use Case Path Analysis

Ejemplo
4. Seleccin de caminos a probar.

Id 1 3 2

Frecuencia 10 8 5

Importancia 10 10 5

Total 20 18 10

26

Use Case Path Analysis

Ejemplo
5. Elaboracin de los casos de prueba.

Id 1 3 2

Frecuencia 10 8 5

Importancia 10 10 5

Total 20 18 10

Un caso de prueba para cada camino. Multiples escenarios de prueba (valores de prueba). Aadir detalles de la interfaz.

Use Case Path Analysis

Ideas Generar un modelo del caso de uso. Buscar caminos sobre el modelo. Baremar y priorizar los casos de uso. Evitar, en la medida de lo posible, la subjetividad.

27

Algunas propuestas existentes

Binder. Naresh Labiche. Ruder. Nebut
TDE/UML.

TDE/UML
Caractersticas
Basada en UML Contempla la prueba de casos de uso aislados y la prueba de secuencias de casos de uso. Es una propuesta incompleta.

28

Algunas propuestas existentes

Binder. Naresh Labiche. Ruder. Nebut
TDE/UML.

Algunas propuestas existentes

Binder. Naresh Labiche. Ruder. Nebut
Requirement by Contract Testing

29

Requirement by Contract Testing

Caractersticas Se basa en secuencias de ejecucin de casos de uso. Presupone que todos los casos de uso se ejecutan correctamente. No incluye valores de prueba.

Requirement by Contract Testing

Proceso 1. Extensin de casos de uso con contratos parametrizados. 2. Seleccin de instancias de prueba y construccin del UCTS. 3. Generacin de objetivos de prueba. 4. Generacin de casos de prueba.

30

Requirement by Contract Testing

1. Extensin de casos de uso con contratos parametrizados.
UC Connect(U:USER) pre not connected(U) post connected(U) #-----------------UC Disconect(U:USER) pre connected(U) post not connected(U) #-----------------UC Enter(U:USER; M:MEETING) pre connected(U) and not present(U, M) post present(U, M) #-----------------UC Leave(U:USER; M:MEETING) pre connected(U) and present(U, M) post not present(U, M) #-----------------UC Speak(U:USER; M:MEETING) pre connected(U) and present(U, M) post

Requirement by Contract Testing

2. Seleccin de instancias y construccin del UCTS.
UC Connect(U:USER) pre not connected(U) post connected(U) #-----------------UC Disconect(U:USER) pre connected(U) post not connected(U) #-----------------UC Enter(U:USER; M:MEETING) pre connected(U) and not present(U, M) post present(U, M) #-----------------UC Leave(U:USER; M:MEETING) pre connected(U) and present(U, M) post not present(U, M) #-----------------UC Speak(U:USER; M:MEETING) pre connected(U) and present(U, M) post

Instancias: 1 Usuario (U1). 2 Reuniones (M1, M2)

31

Requirement by Contract Testing

3. Generacin de objetivos de prueba.

Criterios de cobertura:
Todos los bordes. Todos los vrtices. Todas las instancias de casos de uso. Todos los vrtices e instancias. Todas las precondiciones.

Requirement by Contract Testing

3. Generacin de objetivos de prueba.

[Connect(u1), Disconect(u1)] [Connect(u1), Enter(u1, m1), Leave(u1, m1)] [Connect(u1), Enter(u1, m1), Speak(u1, m1)] [Connect(u1), Enter(u1, m2), Enter(u1, m1)] [Connect(u1), Enter(u1, m2), Leave(u1, m2)] [Connect(u1), Enter(u1, m2), Speak(u1, m2)] [Connect(u1), Disconect(u1)] [Connect(u1), Enter(u1, m1), Disconect(u1), Connect(u1)] [Connect(u1), Enter(u1, m1), Leave(u1, m1)] [Connect(u1), Enter(u1, m1), Enter(u1, m2), Leave(u1, m1)] [Connect(u1), m1), Speak(u1, [Connect(u1), Enter(u1, m1), Enter(u1, m2), Leave(u1, m1)] [Connect(u1), Enter(u1, m2)] [Connect(u1), Enter(u1, m1), Enter(u1, m2), Speak(u1, m1)] [Connect(u1), Leave(u1, m2)] [Connect(u1), Enter(u1, m1), Enter(u1, m2), Speak(u1, m2)] [Connect(u1), [Connect(u1), Enter(u1, m2), Disconect(u1), Connect(u1)] [Connect(u1), Enter(u1, m1), Enter(u1, m2), Disconect(u1), Connect(u1)]

32

Requirement by Contract Testing

4. Generacin de casos de prueba.
Actor Sistema

Nombre Precondicin Secuencia principal

Error / Secuencias alternativas

Post-condicin

UC-01. Aadir nuevo enlace. No 1 El visitante solicita aadir un nuevo enlace 2 El sistema selecciona la categora Top y solicita la informacin del enlace (SR-02). 3 El usuario introduce la informacin del nuevo enlace. 4 El sistema almacena el nuevo enlace. 3.1.i El usuario cancela la operacin y este caso de uso termina. 3.2.i Si el usuario desea cambiar la categora, se ejecuta el caso de uso Cambiar categora y este caso de uso continua.. 4.1.p Si el nombre del enlace o su URL estn vacos, el sistema muestra un mensaje de error y solicita de nuevo la informacin del enlace. Nuevo enlace aadido al sistema.

Validar Valido infoCompra

pagar

RealizarOperacin Operacin realizada

Use Case Path Analysis

Ideas
Herramienta de soporte. Solo para sistemas basados en mquinas de estados y para prelaciones claras de casos de uso. Compatible con las propuestas anteriores. Casos de prueba como diagramas de secuencia (un unico flujo de ejecucin).

33

Estudio comparativo

Estudio comparativo
No existe la propuesta completa. Indican como obtener objetivos, pero no casos de prueba (cdigo ejecutable). La documentacin es escasa y los trabajos son aislados. Falta de sistematizacin y de automatizacin. Falta de herramientas que soporten las propuestas. Falta de estudios empricos.

www.lsi.us.es/~javierj/approaches.html

34

Estudio comparativo
Aspectos resueltos Aspectos por resolver

Construccin de modelos a partir de los casos de uso. Herramientas de soporte. Generacin de pruebas de casos de uso de manera independiente y de secuencia de casos de uso. Definicin de los casos de uso.

Poca documentacin y casos prcticos. Sin estudios de efectividad y validez. Explosin combinatoria. Implementacin de los casos de prueba. Accesibilidad de herramientas de soporte. Sin referencias del impacto de su aplicacin. Sin referencias de interfaces grficas.

Conclusiones

35

Conclusiones
Hemos visto interesantes.
Variables operacionales, dominios y valores de prueba. Anlisis de caminos. Criterio de seleccin de caminos. Representaciones grficas. Cmo probar secuencias de casos de uso.

Conclusiones !
Pero esto slo sirve si tenemos buenos requisitos.

Si los requisitos no describen todo el sistema o no coincide con lo que se implementa estas ideas no sirven.

36

Conclusiones !
Y si cambian los requisitos?. Perdemos todo el trabajo?

Automatizacin Ms adelante veremos el coste de la automatizacin.

Conclusiones

A continuacin expondremos nuestro trabajo, en el que hemos aprovechado todas las buenas ideas y suplido las carencias detectadas para crear un proceso completo.

37