De los casos de uso a los casos de prueba Objetivo

De los casos de uso a los casos de
prueba
Proceso ETUC
Javier Gutiérrez / [email protected]
Objetivo
Objetivo: resumir los aspectos
más importantes de nuestra
propuesta de generación de
pruebas a partir de casos de
uso.
1
Índice
•
•
•
•
•
•
•
Introducción.
Actividades y tareas.
Modelos.
Generación de objetivos de prueba.
Cobertura.
Herramienta ObjectGen.
Conclusiones.
Introducción
2
Un proceso de generación de pruebas
Casos de uso
Requisitos de información
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 e Array
Type
Combination
to
Cd
Out
case
discover
UC-01
System configuration
In
System configuration
C
InC
(SR-01)
UC-01
Combination
to
Out
Combination
to
Cd
InCd
Array
discover
discover
Use
Variable
UC-03
System
configuration
C
In
User combination
Cj
Inner
Array
case
UC-03
Cd
In
User tries Combination
UC-01 to
Ni SystemInner
configuration
Integer
discover
System configuration
Out
UC-01 C Combination
to(SR-01)
UC-03
User combinationdiscoverCj
Inner
UC-03
User tries
Ni
Inner
UC-03
System 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
Dom ain
In
Out
(SR-01)
Array
In
In
(SR-01)
Array
Inner
Inner
Out
Array
Integer
(SR-01)
Otros requisitos
• Comenzaremos viendo las ideas
generales.
• Nuestro punto de partida son
requisitos escritos en lenguaje
informal.
• Es difícil manipularlos de
manera automática.
… el primer paso será transformar los
requisitos en modelos manipulables
automáticamente.
Un proceso de generación de pruebas
• A partir de dichos modelos
obtenemos los objetivos de
prueba.
• Un objetivo de prueba es algo
que tenemos que probar.
• Por ejemplo un escenario de un
caso de uso o un conjunto de
valores o una secuencia de
casos de uso.
Para obtener objetivos de prueba aplicamos
criterios de cobertura sobre los modelos.
3
Un proceso de generación de pruebas
• Los objetivos están expresados
en base a los requisitos.
• No es automático
implementarlos.
• Aún no tenemos la aplicación
final.
Para facilitar la implementación de las
pruebas, generamos pruebas independientes
de las herramientas.
Un proceso de generación de pruebas
• Cuando tenemos la aplicación
final tenemos la información
necesaria:
– Interfaces.
– Resultados.
– Herramientas de prueba
Traducimos las pruebas abstractas en
pruebas concretas ejecutables mediante una
herramienta.
4
Un proceso de generación de
pruebas
• Con la aplicación definitiva
podemos traducir las pruebas
abstractas a código ejecutable.
Un proceso de generación de
pruebas
Resumen de ideas.
1. Construir modelos manipulables
automáticamente.
2. Extraer objetivos de prueba (acciones y valores
de prueba).
3. Traducir los objetivos a casos de prueba
abstractos.
4. Implementar los casos de prueba.
5
Procesos e información
Algunas definiciones:
Objetivo de prueba: un escenario concreto de un
caso de uso (acciones de los actores y valores de
prueba).
Prueba abstracta: Prueba que verifica un objetivo
expresada de una manera genérica, no atada a
ninguna interfaz ni herramienta de prueba.
Prueba ejecutable: implementación de una prueba
abstracta, que puede ejecutarse directamente
contra la aplicación a prueba.
Actividades y tareas
6
Procesos e información
Una visión global
Proceso ETUC.
El proceso ETUC
7
El proceso ETUC
Construcción del modelo de comportamiento
1.
2.
3.
Construcción del modelo de
comportamiento.
Resolución de inclusiones y extensiones.
Identificación de variables operacionales.
Generación de secuencias de acciones.
1.
2.
Selección de criterios de cobertura y
recorrido.
Recorrido del modelo de comportamiento.
Generación de valores de prueba.
Resultado:
Objetivos de prueba.
(pasos + valores de prueba)
1.
2.
3.
Construcción del modelo de datos.
Partición en categorías.
Generación de valores de prueba.
Construcción de objetivos de prueba.
1.
Combinación de secuencias de ejecución
con valores de prueba.
El proceso ETUC
8
El proceso ETUC
Definición de interfaces abstractas.
1. Selección del metamodelo de componentes
GUI.
2. Definición de las interfaces abstractas.
Construcción de casos de prueba abstractos.
1. Construcción de casos de prueba abstractos.
Construcción de árbitros.
Resultado:
Pruebas abstractas.
(acciones sobre un interfaz +
valores de prueba + resultado
esperado)
1. Identificación de los puntos de verificación y
resultados esperados.
2. Construcción de los árbitros.
3. Combinación de árbitros y pruebas abstractas
El proceso ETUC
9
El proceso ETUC
Construcción de casos de prueba ejecutables.
1.
2.
3.
4.
Selección de la herramienta / plataforma de
pruebas.
Definición de la arquitectura de prueba.
Traducción de las pruebas, valores de prueba y
árbitros a código ejecutable.
Codificación de los test harness.
Resultado:
Código ejecutable.
(acciones sobre un interfaz + valores de
prueba + resultado esperado)
Arquitectura de prueba.
Modelos
10
Modelos
¿Por qué modelos?.
• Una propuesta de generación de pruebas
recibe información de entrada, va
transformando esa información y genera
información de salida.
• Los modelos describen cómo se define toda
esa información (entrada, transición,
salida).
Modelos
Proceso ETUC.
Modelo de
requisitos de
información
Modelo de casos
de uso
Modelo de
comportamiento
CIM
Modelo de datos
de prueba
Modelo de interfaz
abstracta
PIM
Modelo de
interacción
Modelo de interfaz
concreta
PSM
Modelo de
acciones
11
Modelo de comportamiento
Modelo de
requisitos de
información
Modelo de casos
de uso
Modelo de
comportamiento
Modelo de datos
de prueba
Modelo de interfaz
abstracta
Modelo de
interacción
Modelo de interfaz
concreta
Modelo de
acciones
Como ya hemos visto existen
muchas alternativas.
– Máquinas de estados.
– Modelos UML: actividades,
secuencia, etc.
– Modelos propios: escenarios de
uso, transiciones de casos de uso,
etc.
– Modelos matemáticos: Z, cadenas
de Markov, etc.
Modelos de comportamiento
Utilizamos diagramas de actividades porque…
• Son fáciles de construir.
• Se aprecia fácilmente
quien realiza las
actividades.
• Se muestra claramente
la interacción actores /
sistema.
• Permiten indicar la
información utilizada.
12
Modelo de datos de prueba
1
Modelo de
requisitos de
información
Modelo de casos
de uso
2
Modelo de
comportamiento
Modelo de datos
de prueba
Modelo de interfaz
abstracta
3
Modelo de
interacción
Modelo de interfaz
concreta
Modelo de
acciones
1
Estructura de la información (clases)
2
Categorías (clases)
3
Valores de prueba concretos (objetos)
Modelo de interfaz abstracta
Modelo de
requisitos de
información
Modelo de casos
de uso
Modelo de
comportamiento
Modelo de datos
de prueba
Modelo de interfaz
abstracta
Modelo de
interacción
Modelo de interfaz
concreta
Modelo de
acciones
• Definen los elementos de una
interfaz sin detalles de
implementación.
• Existen muchas alternativas en
procesos de desarrollo de sistemas.
• Dos submodelos:
– Modelo de componentes: describen los
elementos que podemos usar.
– Modelo de interfaz: un conjunto de
componentes concreto para una pantalla.
13
Modelo de interfaz abstracta
GUI Component
GUI Screen
-title
-name
1
GUIErrorScreen
-errorMsg : string
1
Componentes de la interfaz (clases)
2
Una pantalla concreta (objetos)
GUI Object
*
Field
-value
Text
Table
ActionObject
-text
*
1
*
1
1
Header
insertar : Action
1
name
Body
cancelar : Action
categoria : Action
name
name
1
1
nombreField : Field
name
value
1
1
1
1
URLField : Field
2
1
1
1
nombreLabel : Text
linkScreen : GUI1Screen
name
title
1
1 text
11
URLLabel : Text
name
value
1
name
text
1
descriptionField : Field
1
descripcionLabel : Text
name
value
name
text
Modelo de interacción
Modelo de
requisitos de
información
Modelo de casos
de uso
Modelo de
comportamiento
Modelo de datos
de prueba
Modelo de interfaz
abstracta
Modelo de
interacción
• Describe la interacción de la prueba
y los árbitros con el sistema a un
nivel abstracto.
• Dos submodelos:
– Lenguaje de interacción y árbitros.
– Modelo de interacción: interacciones y
validaciones entre la prueba y el sistema.
Modelo de interfaz
concreta
Modelo de
acciones
14
Modelo de interacción
Interacción prueba - sistema:
Instrucción
Descripción
ClickOn(component)
Representa una pulsación con el botón
izquierdo sobre el componente indicado
SetField(field, value) Asigna al campo el valor indicado.
Árbitros:
Instrucción
Assert(component.attribute, value)
Descripción
Verifica que el atributo del componente indicado coincide con el
valor.
AssertTable(table, index, GUIObject)
Verifica que la fila indicada por index de la tabla contiene todos los
atributos del objeto en el mismo orden y con el mismo valor.
Verifica que la pantalla que muestra el sistema coincide con la
pantalla indicada
Screen(GUIScreen)
Assert open file dialog
Assert file loaded
Assert(focusedScreen, openDialog)
Assert(focusedScreen,
mainScreen)
Assert(mainScreen.document,
file01.content)
Modelo de interfaz abstracta
Modelo de
requisitos de
información
Modelo de casos
de uso
Modelo de
comportamiento
Herramientas:
Modelo de datos
de prueba
Modelo de interfaz
abstracta
Modelo de
interacción
Modelo de interfaz
concreta
Modelo de
acciones
15
Herramienta ObjectGen
Herramienta ObjectGen
16
Conclusiones
Objetivos
Aspectos no contemplados en ETUC.
1.
2.
3.
4.
Pruebas de secuencias de casos de uso.
Test Oracles.
Estado inicial del sistema.
Prioridad y orden de las pruebas.
17
Modelos
Proceso ETUC.
Hemos viso el qué.
Nos falta el cómo.
?
?
?
Lo veremos con un
caso práctico
18
Generación de objetivos de prueba
19
• Presentamos una extensión a la plantilla de
requisitos de NDT.
• No es obligatoria utilizar esta extensión,
pero nos ayuda a automatizar el proceso.
Redactar casos de uso
•Del actor: describe una acción de un
actor con el sistema
•Del sistema: describe una acción del
sistema como solicitar información,
mostrar información …
•De caso de uso: si el paso consiste en la
realización de otro caso de uso.
•Condición de excepción: situación que
provoca la excepción.
•Acción asociada: Eespuesta a la
Seextrae la información mediante patrones lingüísticos.
excepción.
Español:
•Terminación
de la excepción: indica si,
[Número]. [Artículo] [actor / sistema / el evento] [verbo de acción] [lo que
hace].
después la acción asociada, el caso de uso
Inglés:
[Number]. [actor / system / event] [action verb][action performed].
continua o se cancela.
20
Aquí hay que que poner más cosas de los
casos de uso: triggers, resultados esperados,
estc.
Modelo de comportamiento
Diagramas de actividades:
Quién realiza cada acción.
Acción descrita en el caso
de uso.
Condición para ejecutar
una secuencia alternativa.
21
Generación de objetivos de
prueba
Criterios de cobertura:
Todos los nodos.
Todas las transiciones.
Etc.
Todos los escenarios.
7
4
Mejorar la tool.
22
Una descripción del proceso
Una vez visto los procesos, información
externa y modelos, aquí describo cada uno
de los procesos.
Me baso en lo que cuento en JISBD y RE.
23
Descripción del proceso
Objetivo: qué hay que
probar. Esto se traducirá
en prueba ejecutables.
Proceso: construir un
modelo formal a partir de
los casos de uso,
recorrerlo mediante un
criterio y calcular los
valores de prueba.
Plantillas de NDT
•Del actor: describe una acción de un
actor con el sistema
•Del sistema: describe una acción del
sistema como solicitar información,
mostrar información …
•De caso de uso: si el paso consiste en la
realización de otro caso de uso.
•Condición de excepción: situación que
provoca la excepción.
•Acción asociada: Eespuesta a la
excepción.
•Terminación de la excepción: indica si,
después la acción asociada, el caso de uso
continua o se cancela.
24
Descripción del proceso
Objetivo: traducir los
objetivos de prueba en
interacciones con la
interfaz gráfica del
sistema.
Proceso: construir un
modelo genérico de las
interfaces y traducir los
objetivos en acciones
sobre dicha interfaz.
Descripción del proceso
Objetivo: traducir
Proceso: construir
25
Validaciones
Dos tipos de validaciones.
Ejecución estricta: La prueba falla si no se
pueden ejecutar todas las instrucciones de
prueba en el orden en que se indicaron.
Asertos: La prueba falla si no se cumplen
todos los asertos en el orden indicado.
Un ejemplo.
Cobertura de las pruebas
26
Resumen
Hacer aquí un resumen de todo lo visto.
Es un proceso muy flexible, ya que nos
permite definir nuestra propia arquitectura,
por lo que, por ejemplo, podemos incrustar
los datos de prueba, o tener un selector o
incluso obtenerlos a partir de bases de
datos, etc.
27
Futura investigación
Modelo de
requisitos de
información
Modelo de casos
de uso
Modelo de
comportamiento
Modelo de datos
de prueba
Modelo de interfaz
abstracta
Modelo de
interacción
Metamodelos y transformaciones
Modelo de interfaz
concreta
Modelo de
acciones
Futura investigación
Modelo de
requisitos de
información
Modelo de casos
de uso
Modelo de
comportamiento
Modelo de datos
de prueba
Modelo de interfaz
abstracta
Tesis??
Modelo de
interacción
Valores de prueba
Modelo de interfaz
concreta
Modelo de
acciones
28