Manual de usuario

A.1 Antes de comenzar a utilizar la herramienta
A.1.1 Instalación
Para el correcto funcionamiento y utilización de la herramienta, será necesario instalar los
siguientes componentes:
- Java JDK
- Eclipse
- Plugins de Eclipse para eOPSOA
Pasamos a describir los pasos para proceder a la instalación de cada componente:

  • Instalación de Java JDK: Actualmente la última versión del JDK de Java es la 6. El paquete JDK puede bajarse de http://java.sun.com.
  • Instalación de Eclipse: La versión que manejamos en la actual versión de la herramienta es la de Galileo. El IDE Eclipse puede bajarse de http://www.eclipse.org. Para instalar, descomprimir eclipse-rcp-galileo-SR2-win32.zip en un directorio del disco local.
  • Instalación de plugins de Eclipse para eOPSOA: La forma más sencilla de instalar eOPSOA es utilizar el gestor de instalaciones de Eclipse. Serán necesarios añadir dos Updates Sites. El procedimiento para la instalación de ambos será el mismo. Para ello nos situaremos en el menú Help de Eclipse, y una vez allí seleccionamos la opción de Install New Software…


Allí, escribiremos las URLs correspondientes a las Updates Sites de los plugins y procederemos a la instalación siguiendo los pasos del asistente de instalación de plugins, proporcionado por la plataforma Eclipse.
Debido a que la versión utilizada de Eclipse es la de Galileo, deberemos seleccionar el plugin de SWTBot apto para esta versión.
La segunda referencia será la correspondiente a la herramienta eOPSOA con la propuesta de automatización de casos de prueba. Esta la podemos visualizar en la página de Descargas en este mismo blog. Finalmente seleccionaremos la feature de eOPSOA.


A.1.2 Crear un proyecto eOPSOA
Cuando un Analista tuviera que aplicar la metodología de calidad OPSOA para estudiar un programa, lo primero que tendría que hacer es crear un nuevo proyecto en eOPSOA para el mismo. Normalmente un proyecto estará asociado con un único proceso OPSOA, y viceversa.
Antes de crear un proyecto eOPSOA nos aseguraremos que tenemos seleccionada la vista eOPSOA para poder habilitar el explorador eOPSOA. De esta forma podremos visualizar el proyecto recién creado. Para activar la vista eOPSOA realizamos los siguientes pasos:
1. Hacemos click en el menú: Window -->  Open Perspective-->  Other…

2. Seleccionamos la perspectiva eOPSOA:
Para crear un proyecto eOPSOA seguimos los siguientes pasos:
1. Hacemos click derecho sobre el Explorador eOPSOA y seleccionamos el menú:New  Project…
2. Seleccionamos la opción de Nuevo Proyecto OPSOA y pulsamos Next >


OPSOA propone una serie de tareas o actividades que debe realizar el Analista/Tester. eOPSOA da soporte a estas actividades, proveyendo de documentos y editores para estos documentos.
Una vez creado un proyecto eOPSOA nuevo éste contiene las cuatro actividades que darán soporte al marco metodológico OPSOA.
La nueva versión de eOPSOA ha realizado cambios en la tercera y cuarta actividad tan sólo, por lo que pasaremos a describir esas dos actividades. 

A.1.3 Tareas de Generación de Pruebas y Análisis de Resultados
- Generación de Pruebas: Esta fase de OPSOA está orientada básicamente a la generación de las pruebas que se ejecutarán posteriormente de forma automática y que ayudarán a determinar el nivel de conformidad del producto objeto de la aplicación de OPSOA. El objetivo principal de la actividad es generar los Casos de Prueba necesarios para la implementación de los Scripts de Prueba.
- Análisis de Resultados: El objetivo de esta actividad es el análisis de los resultados existentes a fin de determinar el nivel de certificación del producto software. Para ello se hace uso de los artefactos de la actividad anterior.


A.2 Artefactos de la Generación de Pruebas
A.2.1 Datapool
El artefacto de Datapool incorpora la posibilidad de introducir datos de entrada a nuestros casos pruebas a través de una estructura representada en forma de tabla de datos. De esta forma si deseamos realizar un Caso de Prueba que ingresa al sistema un número elevado de registros nuevos podemos crear un Datapool que contenga las columnas de los atributos de entrada a los registros. Después creamos un Caso de Prueba cuyos comandos utilicen el Datapool definido para ingresar los valores en la aplicación y recorrer cada dato diferente del Datapool cada vez que se ejecute el Caso de Prueba. Para crear un Datapool, realizaremos los siguientes pasos:
1. Realizamos click con el botón derecho del ratón sobre la actividad tercera (Generación de Pruebas) y seleccionamos la opción del menú New Datapool.
2. Introducimos una descripción en el Datapool (opcional) y pulsamos Finish.

Antes de añadir datos de entrada, será necesario añadir variables en el Datapool. Para ello, en la sección Variables podremos añadir y eliminar variables en el Datapool según las necesidades a satisfacer en nuestra aplicación a probar.

Ahora si podemos comenzar a introducir datos de prueba a nuestro Datapool. Para ello en la sección de Datapool Inputs podemos añadir o eliminar datos con el uso de los botones habilitados para tal efecto.

Es necesario referir que los datos introducidos en la variable del Datapool debe respetar el tipo de variable definido en dicha variable. En caso contrario no podremos salvar los cambios realizados en el Datapool. Esta medida adoptada evita posibles errores futuros en la ejecución de pruebas.


A.2.2 STCS
Un STCS es un artefacto que permitirá albergar un conjunto de pruebas para ser ejecutadas y evaluadas posteriormente. Este artefacto contendrá principalmente Escenarios y Casos de Prueba que serán descritos a continuación. A diferencia de los TCS manuales, un STCS incorpora el concepto de prueba automática, que permitirá una generación de Casos de Prueba y una ejecución automatizada de los mismos. Para crear un STCS, realizaremos los siguientes pasos:
1. Realizamos click con el botón derecho del ratón sobre la actividad tercera (Generación de Pruebas) y seleccionamos la opción del menú New SWTBot Test Case Set.

2. Introducimos una descripción en el STCS (opcional) y un nombre para el Tester (obligatorio) y pulsamos Finish.

Tras haber creado un STCS, podemos abrirlo y observar que aparecen tres pestañas asociada al artefacto recién creado. Las dos primeras (Overview y Needs) ya fueron descritas nuevamente en el manual de usuario de la herramienta eOPSOA. La tercera pestaña la podemos analizar en la sección Escenario de este mismo capítulo.


A.2.3 Carpetas
Una carpeta es un artefacto genérico que podrá albergar a su vez un conjunto cualquiera de artefactos. Estas carpetas serán de ayuda a la hora de gestionar y clasificar las diferentes pruebas en la aplicación. Así, una carpeta podrá contener carpetas, datapools y diferentes Conjuntos de pruebas. Para crear una carpeta, realizaremos los siguientes pasos:
1. Realizamos click con el botón derecho del ratón sobre la actividad tercera (Generación de Pruebas) y seleccionamos la opción del menú Nueva Carpeta.



2. Introducimos un nombre en la carpeta (obligatorio) y pulsamos Finish.

A.2.4 Escenario
Un Escenario es un artefacto contenido en un STCS que sirve como contenedor de Casos de Prueba que persiguen probar una actividad concreta de la aplicación.
Para crear un escenario será necesario tener creado anteriormente un STCS. Una vez realizado esto, tras abrir el STCS donde deseamos crear el Escenario, los pasos a realizar son:
1. Pulsamos la pestaña Scenarios del STCS y seleccionamos en el listado visualizado, el registro donde queremos añadirlo. Una vez realizado esto, pulsamos el botón Añadir.


2. Introducimos un nombre válido para el Escenario y pulsamos Finish. El Escenario se listará debajo del STCS referenciado en el paso anterior y mostrará unas pestañas con información del artefacto recién creado. Este Escenario podrá ser eliminado en cualquier momento a través del botón habilitado a tal efecto.
Las pestañas Master Script y Mapping serán descritas en las secciones Master Script y Mapping de este capítulo.

A.2.5 STC
Un STC es un Caso de Prueba generado y con posibilidad de ser ejecutado posteriormente de forma automática. Un Caso de Prueba intenta testear una especificación concreta de la aplicación sometida a pruebas. Un STC está contenido en un Escenario.
Hay dos formas de crear un STC:
- STC Generado de forma automática: Ver sección Generando STCs de forma automática.
- STC Generado de forma manual: En este caso, en la pestaña Scenarios del STCS, seleccionamos el Escenario donde queremos incorporar el STC. Una vez realizado esto, pulsamos el botón Añadir.
Tras introducir un nombre válido para el Caso de Prueba, pulsamos OK. El Caso de Prueba se insertará en el Escenario seleccionado habilitándose un editor para el Caso de Prueba donde podremos construir modificar la instrucción de comprobación de Resultado Esperado.

A.3 Grabando un Script de Pruebas
A.3.1 Instrucciones automáticas
Una instrucción automática es la unidad mínima de ejecución automática del sistema. El conjunto de estas instrucciones dará lugar a los Scripts de prueba del sistema.
Las instrucciones podrán ser de tres tipos:
- Instrucción de entrada: una instrucción de entrada (o simplemente entrada) consiste en asignar a una instrucción, uno o más valores (datos) recibidos desde un Datapool.
-  Instrucción de comprobación: una instrucción de comprobación (o simplemente salida) es una instrucción que consigue llevar hacia el exterior los valores (datos) obtenidos de la evaluación de un resultado esperado frente a un resultado real.
- Instrucción de Acción: las instrucciones de acción son aquellas que no son ni de entrada, ni de salida. Se limitan a ejecutar la sintaxis que la componen, sin interaccionar con posibles datos de entrada, y sin generar resultados de salida observables por el usuario.
Estas instrucciones están basadas en la librería SWTBot y para su construcción se ha implementado un editor y un traductor genérico de instrucciones, que facilitan la interacción entre usuario y librería. Para facilitar el entendimiento entre ambas partes, una instrucción estará compuesta por partes que el traductor irá recibiendo en la interpretación de instrucciones. Estas partes que iremos editando son:
- Componente: Este campo contendrá el tipo de elemento gráfico ubicado en la interfaz de usuario, con el que interactuará la instrucción de forma automática.


- Matcher: Es el tipo de buscador que la instrucción utiliza para encontrar el componente mencionado anteriormente.
- Acción: Como su nombre indica, este campo especificará la operación concreta que ejecutará el componente gráfico localizado.
- Identificador: Este campo especifica el nombre con el que se reconoce al componente gráfico seleccionado en la instrucción. Este identificador será utilizado por el matcher en las labores de localización del componente.
Estas partes serán comunes a todas las tipologías de instrucciones existentes. Además de estas fracciones de instrucción, existen otras específicas las instrucciones de entrada y salida que pasamos a comentar:
- Input data: En las instrucciones de entrada, es el dato externo procedente del Datapool que recibe la instrucción.
- Subacción: En las instrucciones de salida, es la tarea de comprobación entre el resultado esperado y real, que pretende realizar la instrucción.
- Resultado esperado: En las instrucciones de salida, es el dato a comparar frente el resultado real de la aplicación. La coincidencia o no, del mismo frente al resultado real de la ejecución de la prueba, determinará el estado de la instrucción.
- Tipo esperado: En las instrucciones de salida, es el tipo de dato que devolverá la comprobación de la prueba a la instrucción, tras ejecutar la tarea de verificación en la aplicación sometida a pruebas. Este campo no será editable e irá ligado al campo Subacción. Al cambiar el estado de la Subacción, este campo cambiará automáticamente.
No se podrán salvar instrucciones en las que no concuerden Tipo y Resultado esperado. Con esta medida, se pretende evitar errores no intencionados en la posterior ejecución de pruebas.

A.3.2 Master Script
Al crear un Escenario (Escenario) de forma automática se generará un Master Script de forma automática dentro del mismo Escenario. Un Master Script será el contenedor de instrucciones necesario para situarse en el contexto concreto, que el Escenario necesita para ejecutar los Casos de Prueba que contiene. Estas instrucciones podrán ser de varios tipos y se ejecutarán de forma automática una vez invocado el Escenario padre que contiene los Casos de Prueba a ejecutar. Para editar el Master Script del Escenario, será necesario seleccionar la pestaña Master Script del Editor del Escenario donde está contenido. En la pestaña tendremos dos tablas diferentes:
- Tabla de instrucciones de acción y entrada: En esta tabla podremos introducir y reordenar todas aquellas instrucciones que sean necesarias en los pasos previos para llegar al contexto del Escenario.
- Tabla de instrucción de comprobación: En esta tabla se incorporará una y sólo una instrucción de comprobación de resultado esperado.
En ambas tablas, se agilizará la construcción de instrucciones cargando en el resto de combos las opciones permitidas, dada la previa elección del componente.



A.3.3 Mapping
Si en la elaboración de los Scripts de Prueba ha sido necesaria la incorporación de instrucciones de entrada, será necesario alimentar los Input data de dichas instrucciones procedentes de los Datapool previamente definidos. El procedimiento para sustituir los datos de las Variables Datapool en las instrucciones comentadas se llama Mapping.
Antes de realizar los mapeos, será necesario asociar un Datapool al Escenario que contiene el Master Script, que a su vez contiene las instrucciones de entrada. Para ello será necesario realizar los siguientes pasos:
1. Seleccionamos el Escenario al que queremos realizar el mapeo y nos situamos en la pestaña Mapping del Editor.
2. Para asociar el Datapool, tenemos dos opciones:
a. Si el Datapool no ha sido definido previamente, pulsamos el link Datapool y la aplicación procesará el flujo descrito en la sección Datapool del presente manual.


b. Si el Datapool ha sido definido previamente, pulsamos el botón Browse, seleccionamos el Datapool y pulsamos OK. El Datapool habrá quedado asignado al Escenario.


Ahora podremos proceder al mapeo de instrucciones de entrada con las variables del Datapool asociado. Para ello, desplegamos el combo situado en la columna Datapool Variable y seleccionamos la opción que servirá como fuente de alimentación a los datos de entrada requeridos por las instrucciones de entrada. En este combo se cargarán todas aquellas variables que hayan sido declaradas previamente en el Datapool.



A.3.4 Generando STCs de forma automática
Una vez que tenemos el Escenario completamente definido, con su Master Script construido y sus mapeos determinados correctamente, podemos comenzar a generar de forma automática los Casos de Prueba (STCs) que compondrán el Script de pruebas que ejecutará el sistema.

Los STCs como describimos en la sección STC, se pueden generar de dos formas diferentes: manual (ya comentada) y automática. La generación automática de STCs nos ofrece la posibilidad de elaborar tantos STCs como entradas de datos de prueba hayamos ingresado al sistema a través de un Datapool. Un criterio a tener en cuenta en la generación de STCs es que los mapeos deben ser válidos. En caso contrario no se podrá realizar la generación de casos.
Una vez generado un STC, este contendrá las instrucciones que fueron declaradas en el Master Script del cual ha sido generado el Caso. A excepción de la instrucción de comprobación, el resto de instrucciones no se podrán modificar.
Así, si tenemos dos instrucciones de entrada en el Master Script y otras filas de entradas definidas en el Datapool, al pulsar el botón de Generar se crearán un total de cuatro Casos de Pruebas fruto de combinar cada una de las entradas del Datapool con las instrucciones mapeadas. Vemos este sencillo paso por paso:
1. Definimos las entradas en el Datapool que asociaremos posteriormente en el Escenario.
2. Asociamos el Datapool y mapeamos las variables del Datapool con las instrucciones de entrada que están contenidas en el Master Script.
3. Pulsamos el botón Generar y observamos los Casos de Prueba generados.

A.4 Reproduciendo un Script de Pruebas
Los Casos de Prueba generados en el punto anterior serán los artefactos que compondrán nuestros Scripts de pruebas. Para conseguir reproducir las instrucciones contenidas en los mismos, hemos declarado una configuración en la lanzadera de ejecuciones donde podremos seleccionar los STCs contenidos en los diferentes Escenarios del proyecto OPSOA creado.
Para ejecutar nuestro Script de Pruebas realizamos los siguientes pasos:

1. Hacemos click derecho en el proyecto OPSOA creado y seleccionamos las opciones del menú: Run As  --> Run Configurations…
2. Hacemos doble click sobre el tipo de configuración que soporta nuestro Traductor Genérico de instrucciones SWTBot. De esta forma nos crearemos una nueva configuración de lanzadera.
3. Configuramos el entorno de la plataforma donde se ejecutarán las pruebas y seleccionamos los STCs que van a componer el Script de prueba, así como y los tiempos de retardo de las instrucciones y pulsamos el botón Run.
A partir de este momento la herramienta tomará el control del proceso de pruebas automático. Por lo que no debemos manipular ningún control, ni interactuar con la aplicación hasta haber terminado la reproducción de pruebas. En caso contrario, el resultado de pruebas puede que no sea el esperado.

A.4.1 Analizando resultados
Para visualizar las ejecuciones de prueba, descritas en el anterior punto, podremos hacer uso de la actividad “Resultados de Pruebas”, donde se ha creado un conjunto de tablas donde podremos analizar los resultados de las pruebas, sacar conclusiones de las mismas y detectar posibles fallos para su posterior arreglo. Estas tablas, además de contener los resultados de las pruebas, contendrán distintas informaciones de los componentes y artefactos que componen la fase de prueba.
Para analizar los resultados de pruebas, bastará con hacer doble click en el documento asociado a la actividad cuarta, del proyecto OPSOA donde queramos analizar conclusiones. Si seleccionamos una ejecución en la tabla principal, aparecerán los STCs que la componen. Y si volvemos a pulsar en un STC, se mostrarán a su vez las instrucciones que componen dicho STC.