Proyecto:

SEMI-AUTOMATIZACIÓN DE PRUEBAS
DE INTERFAZ EN MODERNIZACIÓN
FORMS

Autor:

Nicolás Bonet González

n.bonet2476@uniandes.edu.co

Asesor:

Kelly Garcés Pernett, Ph.D.

kj.garces971@uniandes.edu.co

Página 1 de 63
Contenido
0. Resumen..................................................................................................................................................... 5

1. Introducción ............................................................................................................................................... 5

2. Descripción General .................................................................................................................................... 7

2.1 Objetivos .............................................................................................................................................. 7

2.2 Antecedentes ........................................................................................................................................ 8

2.3 Identificación del problema y su importancia ........................................................................................ 9

3. Diseño y especificaciones ......................................................................................................................... 10

3.1 Especificaciones .................................................................................................................................. 10

3.2 Restricciones ....................................................................................................................................... 13

4. Desarrollo del diseño ................................................................................................................................ 13

4.1 Diseño de pruebas generadas ............................................................................................................. 13

Prueba de creación ............................................................................................................................... 13

Prueba de actualización de información ............................................................................................... 14

Prueba de eliminación de información .................................................................................................. 14

Prueba de navegación ........................................................................................................................... 15

Prueba de navegación maestro/detalle................................................................................................. 15

Prueba de errores ................................................................................................................................. 16

Prueba de existencia de gráficos. .......................................................................................................... 17

4.2 Evaluación modelo Oracle Forms ........................................................................................................ 17

4.3 Diseño de las relaciones entre modelos .............................................................................................. 19

4.4 Diseño del perfil .................................................................................................................................. 20

4.5 Definición de variables ........................................................................................................................ 25

4.6 Consideraciones para la implementación ............................................................................................ 25

5. Desarrollo del proyecto ............................................................................................................................ 26

Página 2 de 63
 5.1 Desarrollo de la transformación de Oracle Forms a diagramas de actividad ........................................ 26

Archivo principal ................................................................................................................................... 27

Elementos compartidos entre los elementos derivados ........................................................................ 27

Archivo de prueba create ...................................................................................................................... 28

Archivo de prueba update .................................................................................................................... 28

Archivo de prueba navegación .............................................................................................................. 28

Archivo de prueba delete ...................................................................................................................... 29

Archivo de prueba de existencia de graficos ......................................................................................... 29

Archivo de prueba para muestreo de errores........................................................................................ 29

5.2 Desarrollo de la transformación de diagramas de actividad a Selenium IDE ........................................ 30

Generación de los Test Suite para el IDE ............................................................................................... 30

Generación de los Test Case para el IDE ................................................................................................ 31

5.3 Desarrollo de la transformación de diagramas de actividad a Selenium Webdriver ............................. 33

6. Validación ................................................................................................................................................. 34

6.1 DEFINICIÓN DE LAS PRUEBAS ESPERADAS ........................................................................................... 35

Para el formulario maestro de Software (maestro): .............................................................................. 36

Para el formulario de gráficos (maestro): .............................................................................................. 38

Para el formulario de equipos (maestro/detalle): ................................................................................. 39

Para el formulario de software instalado (detalle): ............................................................................... 41

6.2 Validación con aplicación ADF ............................................................................................................. 43

6.3 Validación con EVL .............................................................................................................................. 45

Validación EVL para el modelo UML ...................................................................................................... 45

Validación EVL para cada paquete UML ................................................................................................ 45

Validación EVL para cada diagrama de actividad ................................................................................... 45

Validación EVL para cada acción ........................................................................................................... 46

6.4 Validación con EUnit ........................................................................................................................... 47

7. Resultados ................................................................................................................................................ 59

Página 3 de 63
 7.0 Costo de la cadena transformadora .................................................................................................... 59

7.1 Con una aplicación ADF de prueba ...................................................................................................... 60

7.2 Con una aplicación empresarial real .................................................................................................... 60

8. Conclusiones............................................................................................................................................. 61

8.1 Discusión ............................................................................................................................................ 61

8.2 Trabajo futuro ..................................................................................................................................... 62

9. Bibliografía ............................................................................................................................................... 62

Página 4 de 63
0. RESUMEN

La automatización de procesos en software haciendo uso de especificaciones de alto nivel

(como los modelos) permite aumentar la productividad en la construcción y
modernización de software en cerca de un 80%. Al hacer uso de metamodelos y técnicas
de transformación es posible definir generalizaciones de datos y/o aplicaciones para
poder así generar nuevas o extender las existentes con un mínimo esfuerzo. El presente
proyecto se basa en la construcción semi-automatizada de software para aplicar dichos
sistemas a la modernización de aplicaciones en el sector empresarial y en el proceso
manual que se realiza luego de hacer la uso del sistema automatizado. El desarrollo de la
presente tesis de grado se realizó con el objetivo de ser incluida en el proyecto
“Modernización Forms” realizado por el grupo TICSw de la Universidad de los Andes en
conjunto con la empresa Asesoftware[1].

1. INTRODUCCIÓN

En la actualidad los sistemas de automatización de software se hacen cada vez más

populares debido a que permitensolucionar distintos problemas de empresas y otros
sectores organizacionales, siendo útiles para modernizar aplicaciones legado, migrar bases
de datos, generar aplicaciones, agilizar procesos de desarrollo y pruebas, entre otros
posibles usos. Haciendo uso de dichos sistemas automatizadores es posible llevar a cabo
proyectos que de otra manera tomarían mucho tiempo y personal capacitado. Se ha
comprobado que su utilización permite reducir los esfuerzos requeridos en cerca de un
80%, siendo entonces sistemas atractivos para las compañías desarrolladoras y
proveedoras de servicios, debido a que dichos procesos podrían ser modeladosy

Página 5 de 63
posteriormente automatizados con el fin de ahorrar dinero en costos de producción y de
soporte.

La Universidad de los Andes, específicamente el grupo TICSw, y la empresa privada

Asesoftware[1] se encuentran trabajando en conjunto en el proyecto titulado
“Modernización Forms” mediante el cual se pretende construir un sistema semi-
automatizado basado en metamodelos que permita tomar aplicaciones Oracle Forms
existentes y modernizarlas a sistemas modernos que ofrezcan un conjunto más completo
de componentes, funciones, prestaciones y flexibilidad. En el marco de Modernización
Forms se pretende transformar las aplicaciones legado a unas nuevas igualmente
funcionales y que se basen en tecnologías web Oracle ADF modernas.

Actualmente las aplicaciones existentes en Oracle Forms están pasando a ser poco
recomendables para empresas que quieren usar tecnologías de vanguardia, debido a que
cada vez menos profesionales las conocen en detalle y el soporte se va perdiendo a
medida que avanza el tiempo. Teniendo en cuenta lo anterior las empresas que tienen sus
sistemas en dicha plataforma de Oracle están interesadas en la modernización de las
mismas o en desarrollar nuevas que cumplan los mismos requisitos que la aplicación
legado. En el contexto colombiano se estiman que existen miles de aplicaciones basadas
en Oracle Forms, motivo por el cual dicho mercado resulta ser muy atractivo como posible
negocio empresarial destinado a dichas compañías y como motivación inicial del proyecto
que está realizando la universidad.

En el marco del proyecto mencionado se encuentra el presente proyecto de tesis, en

donde se pretende semi-automatizar el proceso que viene después de la modernización
de las aplicaciones generadas, dicho proceso es elde hacer pruebas funcionales, de
persistencia e interfaz, siendo esta última el objeto central de esta tesis. Con el presente
proyecto se espera poder mejorar los tiempos empleados por los empleados de
Asesoftware[1] en verificar que los componentes visuales de la aplicación cumplan con los
estándares designados.

Página 6 de 63
La transformación de las aplicaciones escritas en Oracle Forms debe hacerse de modo tal
que se respeten ciertos estándares establecidos por las organizaciones involucradas en el
proceso y que permitan funcionalidades adicionales a la transformación básica. Estas son
necesarias para poder extender el uso de la plataforma que se propone en el presente
documento y así poder ser de utilidad para realizar procesos adicionales que podrían no
haber sido contemplados debido a las necesidades únicas de cada uno de los casos de
modernización posibles.

El presente documento se centra en el proceso completo que inicia una vez se tiene la
instancia del modelo de la aplicación legado, hasta que se logra llegar a código y
aplicaciones ejecutables las cuales tienen las pruebas que se van a generar con el fin de
poder ser ejecutadas una vez se finaliza el proceso. Adicionalmente, se da la opción de
modificar todas las pruebas resultantes a gusto del encargado del proceso para adaptarla
a los requerimientos específicos de cada proyecto.

2. DESCRIPCIÓN GENERAL

2.1 OBJETIVOS

El objetivo principal del presente proyecto es diseñar e implementar toda la cadena de

transformaciones que parte de una instancia de la aplicación legado, la cual se rige según
un metamodelo especifico de aplicaciones Oracle Forms. A partir del modelo se debe
poder generar todo el proceso de forma automatizada para que una vez se tenga la
aplicación moderna en ejecución sea posible ejecutar las pruebas de interfaz que hayan
sido creadas.

Este proyecto ha sido implementado haciendo uso de diversas tecnologías de

modelamiento modernas y basándose en sistemas abiertos que permitan su uso bajo
distintos contextos, con el fin de servir como base para futuros proyectos que puedan
extender las funcionalidades aquí ofrecidas y así poder ofrecer aún más posibilidades para
las personas que deseen trabajar sobre automatización de pruebas.

Página 7 de 63
2.2 ANTECEDENTES

Debido a la importancia que tienen los sistemas de modelamiento en la actualidad se han

venido dando nuevos trabajos basándose en dichas tecnologías para el desarrollo de todo
tipo de cadenas de transformación, incluyendo trabajos en modernización de aplicaciones,
migración de bases de datos y optimización de procesos.

El documento desarrollado por el instituto de investigación de Siemens [2] titulado

Automation of GUI testingusing a model-drivenapproachexpone cómo se pueden llevar a
cabo las pruebas de interfaz haciendo uso de modelos para poder automatizar el proceso.
Este documento empresarial propone el uso de modelos en UML para diseñar las pruebas
de interfaz que van a ser ejecutadas posteriormente. De manera que este es un inicio
perfecto para el presente proyecto de tesis que utiliza parte de lo que encontraron dichos
trabajadores para llevar a cabo el objetivo central de la automatización de pruebas. El
proyecto de Siemens, descrito en el documento referenciado, está enfocado en las
pruebas de diseño e interfaz, sin embargo es posible re-utilizar los conceptos allí
planteados para poder tomar nuevas pruebas y procesos que no estén necesariamente
vinculados a dichas pruebas, aprovechando las ventajas que ofrecen los modelos de UML
y todas sus diversas implementaciones y opciones.

Otro caso de investigación que se basa en pruebas fue el realizado por Fröhlich y Link [3]
en donde se plantea la generación de las pruebas, partiendo de la documentación de las
mismas y pasando dicha información a modelos de estado de UML para posteriormente
convertir dichos modelos a casos de pruebas que cumplan con las especificaciones
iniciales que dieron lugar al modelo del primer paso en la cadena. Dicho documento
también fue utilizado como base para la implementación que se presentará más adelante.

Finalmente se estudió el documento Using UML forAutomatic Test Generation[7] en

donde se plantearon los distintos usos que puede tener el conjunto de diagramas en UML

Página 8 de 63
para desarrollar pruebas con modelos. En este documento se hace especial énfasis en la
arquitectura que debe seguirse para modelar adecuadamente el conjunto de pruebas,
basándose en tres tipos de diagramas principales: clases, estado y de objetos.

2.3 IDENTIFICACIÓN DEL PROBLEMA Y SU IMPORTANCIA

En la actualidad existen cientos de empresas que hacen uso de programas cliente-servidor

que corren en la plataforma creada por Oracla llamada Oracle Forms. Dichas aplicaciones
son consideradas “anticuadas” en el mercado actual, por lo que las compañías del mundo
que hacen uso de aplicaciones en dicha plataforma están buscando la posibilidad de
modernizar sus aplicaciones a tecnologías modernas, siendo Oracle ADF la preferida en la
actualidad por su versatilidad y el soporte existente para dicha plataforma. ADF es,
además, la opción sugerida por Oracle para las empresas que desean modernizar sus
aplicaciones de Oracle Forms.

Actualmente se estima que existen cerca de mil aplicaciones programadas en Oracle

Forms en el mercado colombiano, lo que da lugar a un mercado muy grande de empresas
interesadas en realizar el proceso de modernización. Se calcula que estos procesos de
desarrollo y mantenimiento para la actualización de código puedan ascender a $100.000
millones de pesos.

El presente proyecto se justifica a partir del deseo de las empresas que usan Oracle Forms
y que ven la migración a código ADF como una forma eficiente de ahorrar dinero en
soporte y mantenimiento. Igualmente, como una reducción de la dificultad para encontrar
mano de obra para sus aplicaciones. Así pues, la transformación semi-automatizada será
una solución mediante la cual se podrá realizar dichas transiciones con menos esfuerzo e
inversión de recursos humanos.

Página 9 de 63
Oracle por su parte ya se encuentra aconsejando a las empresas que deseen hacer estos
cambios de plataformas pues saben que las dificultades que se encuentran en la
actualidad con Oracle Forms. Entre los motivantes que existen, según Oracle[4], para
hacer la transición a una tecnología moderna como ADF se encuentra los siguientes:

 Debido a cambios en los negocios y sus procesos las aplicaciones en Oracle Forms
ya no cumplen los requisitos mínimos de operación.
 Las aplicaciones de Forms implementadas ya han terminado su ciclo de vida y es
momento de moverse a otros sistemas.
 Determinados negocios deben adoptar tecnologías modernas debido a
restricciones propias de su sector empresarial.

Teniendo en cuenta lo anterior, un proyecto de modernización como el que se está

realizando en la universidad resulta ser una iniciativa que podría tener un impacto
significativo para el mercado empresarial actual. La idea de poder agilizar todos los
procesos de desarrollo dentro de una empresa y de modernización son lo suficientemente
significativos como para pensar que el desarrollo de una semi-automatización como la
presentada sea de gran interés para el mercado corporativo.

3. DISEÑO Y ESPECIFICACIONES

3.1 ESPECIFICACIONES

El trabajo actualmente mostrado se basa en una cadena de transformación que se encarga

de reconocer la aplicación legado y a partir de allí generar las pruebas pertinentes. Dichas
pruebas también deben admitir modificaciones y una vez dichos cambios sean realizados,
la cadena debe encargarse de traducir las pruebas modificadas a código ejecutable por los
ingenieros de modernización.

Con base en el trabajo realizado por los ingenieros de Siemens[2] se decidió hacer uso de
los diagramas de actividad como modelo intermedio, puesto que estos permiten realizar

Página 10 de 63
modificaciones (creando nuevos nodos, acciones o modificando las existentes) y modelar
de forma directa la ejecución de pruebas (un conjunto de acciones queestán
concatenadas entre sí). Adicionalmente ya se cuenta con un metamodelo de dichos
diagramas de actividad, dicho metamodelo se encuentra en la suite de Epsilonde esta
manera es posible acceder a sus especificaciones por cualquier persona que tenga el
proyecto, cumpliendo así la condición de contar con una cadena de código abierto. Como
punto final, se pueden aprovechar los conceptos de UML (más específicamente los
conceptos de perfiles y estereotipos) con los cuales es posible definir de forma dinámica
los tipos de acciones que son ejecutadas en una prueba.

Teniendo en cuenta lo anterior, se definió la primera parte de la cadena, se parte de una

instancia de la aplicación legado y se realiza la transformación a diagramas de actividad,
durante dicho proceso se deben generar las pruebas de interfaz que tengan lugar según
los distintos formularios del modelo de la aplicación origen. Sin embargo, el
modelamiento de pruebas como diagramas de actividad no es suficiente para realizar las
pruebas, por lo que se definió la segunda parte de la cadena en donde se pasan los
diagramas creados a código ejecutable con el cual es posible comprobar (teniendo la
aplicación generada) el funcionamiento de la interfaz de la misma.

Para cumplir con las funcionalidades que se deseaban ofrecer en un inicio se planteó que
el código ejecutable debería ser código SeleniumHQ[5], SeleniumHQ se compone de dos
grandes plataformas en las que es posible automatizar la ejecución de acciones con el fin
de realizar todo tipo de pruebas sobre el navegador web elegido. Las dos plataformas son
el Selenium IDE y el SeleniumWebDriver. Ambos serán explicados a continuación.

El IDE de Selenium es un plugin disponible para Mozilla Firefox, cuando se usa dicho plugin
es posible ir monitoreando y controlando la ejecución de cada una de las pruebas que se
van a correr, debido a que el plugin cuenta con un panel de control en donde se va
manejando la ejecución de cada uno de los test case generados. Como requisito de dicha
plataforma únicamente está el tener instalado el navegador web de Mozilla y el plugin
que da el proyecto Selenium.

Página 11 de 63
Por otro lado se encuentra el WebDriver de Selenium, dicha plataforma se ejecuta como
pruebas JUnit tradicionales y permiten tener un poco más de flexibilidad al momento de la
generación de pruebas puesto que se cuenta con todos los componentes de Java y JUnit
con las que es posible realizar pruebas adicionales, sin embargo necesita usar un servidor
que se puede descargar de la página del proyecto y se recomienda tener un navegador
(como Firefox) para la ejecución de las pruebas usando el navegador.

Teniendo claro que las pruebas de interfaz se ejecutarían sobre Selenium, se decidió que
las pruebas se generarían para ambas plataformas de Selenium, es decir que la cadena de
transformación inicial cuenta con dos caminos finales, en uno se generá código Selenium
IDE y en el otro código SeleniumWebDriver.

Contando ya con todos los pasos de la cadena se diseñó como esqueleto del proyecto la
siguiente cadena de transformación:

Modelo Diagramas
Codigo
aplicación de
Selenium.
legado. actividad.
• Transformación • Transformación • Tanto IDE como
Modelo a Modelo a Texto WebDriver.
Modelo (M2M) (M2T)

Finalmente se estudió el trabajo existente en el proyecto “Modernización Forms” por el

grupo TICSw y se alcanzó a lograr la generación automática de pruebas para dos de los
tres tipos de formularios existentes en las aplicaciones Oracle Forms. Los dos tipos que
son manejados por la cadena son:

a. Maestro: Son formularios en donde se la información mostrada no tiene

dependencia con otros formularios.

Página 12 de 63
 b. Maestro/Detalle: Son formularios en donde hay dos segmentos distintos: uno
maestro y otro detalle, en este caso la información desplegada en el segmento
detalle depende de lo que esté siendo mostrado en el formulario maestro.

3.2 RESTRICCIONES

Para el desarrollo del proyecto se encontraron las siguientes restricciones:

1. Durante la transformación debe ser posible modificar las pruebas generadas o

crear nuevas, sin tener que modificar las transformaciones.
2. El código resultante debe ser Selenium en sus dos plataformas: IDE y WebDriver.
3. El modelo intermedio que permite modificaciones debe ser lo suficientemente
flexible como para poder generar pruebas de otras capas (como persistencia y
funcionalidad) usando el mismo modelo.
4. El sistema debe generar automáticamente las pruebas iniciales haciendo una
evaluación del modelo para saber que conceptos pueden ser probados en que
formularios de la aplicación objetivo.
5. La ejecución de las pruebas generadas debe poder realizarse una vez se hace la
última transformación (M2T).

4. DESARROLLO DEL DISEÑO

4.1 DISEÑO DE PRUEBAS GENERADAS

A partir de la aplicación Oracle Forms se crean las siguientes pruebas. Cada una de ellas es
generada única y exclusivamente si la aplicación origen permitía realizar dicha acción y
contaba con los requerimientos mínimos de cada una.

PRUEBA DE CREACIÓN

Página 13 de 63
En los formularios que tengan la propiedad de inserción de información se realiza la
prueba de insertar un nuevo elemento al formulario. Dicha prueba se genera sobre las
tablas maestro y detalle por aparte. La prueba generada toma todos los elementos del
formulario y genera datos que estén dentro de los parámetros de cada uno de los ítems y
posteriormente llena cada uno de los campos con el dato correspondiente,
posteriormente se envía el formulario y una vez se tiene la página recargada se encarga de
verificar que los datos desplegados sean los que se habían fijado inicialmente.

Verificar que los

Llenar todos los
Enviar el datos
campos con
formulario. desplegados sean
datos aleatorios.
los iniciales.

PRUEBA DE ACTUALIZACIÓN DE INFORMACIÓN

En caso de que el formulario permita la modificación de la información existente entonces

se procede a crear las pruebas de actualización, en este caso se cambian los dos datos
posteriores a la llave primaria del formulario y se envía el formulario, al realizar la recarga
de la página se procede a verificar que los datos ingresados sean los desplegados.

Llenar dos campos

Verificar que los
posteriores a la Enviar el
datos desplegados
llave con datos formulario.
sean los iniciales.
aleatorios

PRUEBA DE ELIMINACIÓN DE INFORMACIÓN

Cuando el formulario permite eliminar datos se puede verificar que al momento de

eliminar un dato este deja de mostrarse en la página. Lo que se realiza en esta prueba es

Página 14 de 63
el guardar en una variable el identificador de la llave primaria del formulario y
posteriormente se elimina el dato actual, una vez es cargada la página se procede a
verificar que el contenido de la llave primaria mostrada no sea igual al valor almacenado.

Verificar que el dato

Guardar la llave
Eliminar el dato del desplegado tenga
primaria del dato
formulario. una llave distinta a la
actual.
almacenada.

PRUEBA DE NAVEGACIÓN

En caso de permitir navegación se procede a verificar el funcionamiento de la misma. Para

esto se guarda en variables los datos de la llave primaria y seavanza en la navegación de
los datos, al hacer esto se verifica que el dato almacenado sea efectivamente el
desplegado y como parte final de la prueba se evalua el funcionamiento de los botones
“Last” y “First”, para esto se presionan ambos botones y luego se verifica que los botones
“Last” y “Next” se desactiven al presionar el primero, y que los botones “First” y “Back”
sean desactivados al oprimir el que lleva al primer dato.

Verificar su
Almacenar las
despliegue al
llaves primarias.
navegar.

Oprimir el botón Oprimir el botón

First y verificar que Last y verificar que
"First" y "Back" "Last" y "Next"
sean desactivados. sean desactivados.

PRUEBA DE NAVEGACIÓN MAESTRO/DETALLE

Página 15 de 63
Para todos los formularios detalles que tengan dependencia con uno maestro se
comprueba que la navegabilidad del formulario primario afecte los datos desplegados en
los de detalle. Los pasos para lograr lo anterior consisten en almacenar en variable la llave
primaria del elemento maestro, verificar que la llave que hace el “join” entre ambos
formularios corresponda a la variable almacenada y posteriormente se navega para
verificar que dicha relación se siga manteniendo.

Guardar la
llave primaria
del maestro en
variable.

Navegar para Verificar que el

verificar que se dato del join
siga sea el
manteniendo. adecuado.

PRUEBA DE ERRORES

Para los formularios con campos obligatorios se generan pruebas para verificar que la
interfaz este marcando el error en los campos al introducir información insuficiente para
el mismo, esto se realiza dejando los campos obligatorios vacíos y al enviar el formulario
esperar que dichos campos contengan la clase que marca el error en los formularios.

Página 16 de 63
 Dejar los Verificar que los
campos Enviar el campos tengan
obligatorios formulario. el error
vacios. marcado.

PRUEBA DE EXISTENCIA DE GRÁFICOS.

Los formularios con gráficos (como barras estadísticas o imágenes) tienen una verificación
adicional en donde se busca comprobar que los gráficos que se encuentren activados y
visibles sean cargados en la página.

Verificar que los graficos existan en la página.

4.2 EVALUACIÓN MODELO ORACLE FORMS

Como la parte primaria de la cadena se basa en el modelo Oracle Forms existente es

imperativo analizar los aspectos que se encuentran allí, puesto que los elementos del
modelo serán utilizados en las transformaciones.

La cabeza del modelo es la aplicación como tal, dicho elemento del modelo contiene a
todos los demás. Sin embargo, de este elemento los únicos que son de interés para el
proyecto serán los formularios, puesto que estos son los que son desplegados al usuario y
sobre los que se deberán generar las pruebas, los demás no son tenidos en cuenta en el
proyecto actual.

Los formularios de la aplicación son de interés para la modernización, puesto que estos
contienenlos bloques de datos en donde se agrupa información vital para la creación de

Página 17 de 63
las pruebas. Cada formulario tiene “Form Data Blocks” que son representaciones de datos
como formularios. Estos Data Blocks son utilizados como parte fundamental en la cadena
al ser procesados como paquetes en el modelo intermedio.

Los Form Data Block contienen cuatro elementos principales para la ejecución de pruebas,
el primero es el “Form Data Block Database” en donde está la información de que
operaciones son válidas sobre la base de datos (como eliminar o actualizar datos), en
segundo lugar están los “Form Data Block Relation” los cuales son las relaciones que
permiten conocer los formularios detalle (donde el maestro es el formulario en cuestión),
también cuentan con un “Form Data Block Navigation” que indica si se permite navegar
los datos del formulario y finalmente están los ítems de texto (“Item Text item”), que son
los que componen el formulario, junto con los ítems que modelan los elementos gráficos
(“Item Chart Item” e “ItemImageItem”) del formulario. En resumen se usará la siguiente
información del modelo Forms:

Aplicación

Formularios

Form Data
Blocks

Form Data Form Data

Form Data Item Text Item Chart Item Image
Block Block
Block Relation item Item item
Database Navigation

Teniendo claro los elementos significativos del modelo para la transformación es posible
empezar a crear las relaciones que definen que elementos del modelo van a ser
transformados y de qué manera.

Página 18 de 63
4.3 DISEÑO DE LAS RELACIONES ENTRE MODELOS

Es imperativo definir las relaciones entre los modelos con el fin de saber al momento de la
implementación que conceptos de cada modelo van a ser los del modelo destino, es decir
que partes del modelo original van a ser transformadas y en que lo serán.

Para la primera transformación del modelo Forms al de Diagramas de Actividad se

definieron las siguientes relaciones:

Modelo Forms Diagramas de Actividad

App. Modelo UML.

Form Data Block. Paquete UML.

Es decir, la aplicación como tal se verá representada como un modelo UML (al cuál se le
aplicará el perfil creado), luego cada uno de los data block de los formularios de la
aplicación pasaran ser un paquete UML estereotipado. Durante dicha transformación la
cadena misma creara los diagramas de actividad iniciales que vendrán en el paquete, los
cuales modelan las pruebas anteriormente detalladas.

Como segunda parte de la cadena se tiene la transformación del modelo UML a código
Selenium, dicha relación está dividida en dos, correspondientes a las plataformas de
Selenium IDE y SeleniumWebDriver:

Página 19 de 63
 Diagramas
WebDriver IDE
de Actividad
Paquete Archivo Java Test Suite

Diagrama de
@Test Test Case
Actividad

Acción del Acción en el

Acción en JUnit
diagrama IDE

Con lo anterior se definió el esqueleto de la última transformación, aquí se usan los

estereotipos aplicados a ambos: paquetes y acciones del modelo intermedio para definir
las acciones y los atributos del código generado para ambas plataformas.

4.4 DISEÑO DEL PERFIL

Como se explicó en un inicio se hace uso de un perfil UML con el cual se definen los
estereotipos que han de ser usados por los diagramas de actividad para modelar las
distintas acciones que pueden ser ejecutadas al momento de realizar pruebas de interfaz
gráfica.

Un perfil en UML[6] es el mecanismo utilizado para darle forma a un modelo UML para
que este cumpla con ciertos parámetros básicos en un dominio específico. Los perfiles
permiten tres métodos de definir los parámetros del dominio, las etiquetas, los
constraints (restricciones) y finalmente los estereotipos, siendo estos últimos los
seleccionados para parametrizar el modelo intermedio de la cadena al permitir la creación
de atributos sobre cada estereotipo y poder extender los mismos para tener facilidad de
manejo sobre estereotipos que comparten elementos en común.

Los estereotipos en UML son un método de extender las propiedades de los elementos
que conforman un modelo UML, es decir que no se restringen únicamente a diagramas de

Página 20 de 63
actividad. Sin embargo, en el marco del proyecto solamente se utilizará para modelar
componentes del mismo. Al tener claras las relaciones entre los modelos se procedió a
definir los estereotipos del modelo intermedio, obteniendo las siguientes conclusiones:

Estereotipos del
Modelo UML
Perfil
Paquete TestSuite

Diagrama de
TestCase
actividad

wait, open, close y/o

Acción del diagrama
action.

Teniendo ya claros los tres elementos que serían modelados en el perfil se empezó a
definir cada uno de los seis estereotipos mencionados, definiendo sus atributos y los
estereotipos hijos de cada uno en caso de ser necesarios.

Para el estereotipo del TestSuite se definieron dos atributos básicos de una prueba de
interfaz, la URL base (que es la raíz de la aplicación en donde se ejecutaran las pruebas) y
un timeout que permite modelar el tiempo máximo de ejecución de las pruebas que
pertenezcan al TestSuite en cuestión. Quedando así la definición del estereotipo:

Página 21 de 63
Para los diagramas de actividad como tal no fue necesario implementar ningún tipo de
atributo sobre el estereotipo, sin embargo dicho estereotipo está siendo aplicado durante
la transformación a los diagramas de actividad y se ha dejado definido en el perfil debido a
que puede ser utilizado en trabajos posteriores para extender las funcionalidades de las
pruebas.

Los últimos elementos del modelo UML que han sido estereotipo han sido las acciones del
diagrama de actividad que para el proyecto actual están siendo manejados como
OpaqueAction en dichos diagramas. Las acciones usadas en el diagrama representan cada
una de las operaciones realizadas durante una prueba de interfaz, por lo que los
estereotipos definidos en el perfil deben cubrir todas las necesidades básicas de una
prueba usual de interfaz. Como resultado del análisis realizado sobre las posibles acciones

Página 22 de 63
que se realizan en una prueba sobre la capa que ha sido trabajada en el proyecto se
obtuvo el siguiente conjunto de estereotipos:

Como se puede apreciar hay cuatro estereotipos generales sobre las acciones, estas son:

1. Wait: Encargada de detener la ejecución de la prueba durante el tiempo

especificado en el timeout.
2. Open: Representa la acción de abrir una URL sobre la cual se van a ejecutar las
acciones que le siguen a dicha acción.
3. Close: Se encarga de finalizar la ejecución de la prueba.
4. Action: Modela todo el conjunto de operaciones adicionales que se ejecutan sobre
cada elemento de la página. De aquí se derivan la mayoría de acciones que se
ejecutaran en las pruebas. Además, tiene como atributo un elementNamespace el
cual es el identificador del elemento sobre el que se va a realizar la acción.

Página 23 de 63
Para realizar los estereotipos que se derivan de action se tuvo en cuenta las acciones que
se necesitan para modelar pruebas de interfaz sobre los elementos de la página web en
cuestión, estas acciones fueron obtenidas al realizar pruebas manualmente, así fue que se
tuvo una idea de que cosas eran esenciales en una prueba de este estilo y como resultado
se obtuvieron los siguientes estereotipos:

1. Select: Se encarga de seleccionar el elemento especificado. Tiene un parentId

como atributo en caso de que se deba definir el contenedor del elemento.
2. Fill: Llena el elemento con el valor que se da como atributo.
3. Click: Representa un click sobre el elemento.
4. TestVariable: Define una variable nueva la cual podrá ser usada por otras acciones
en la misma prueba, lleva como atributo el nombre de la variable y el valor
asignado será el valor que tenga el elemento.
5. Verify: Es el conjunto de acciones que modelan las verificaciones sobre un
elemento.

Al disponer de múltiples verificaciones sobre el contenido y el estado de los elementos se

decidió generalizar estos estereotipos a partir del estereotipo Verify, de dicho estereotipo
se derivan los siguientes conceptos:

1. NotContentVerify: Verifica que el contenido del elemento no sea el dado por

parámetro.
2. ContentVerify: Verifica que el contenido del elemento sea igual al que se ha dado
por parámetro.
3. VerifyNotExist: Verifica que el elemento no exista en la página. Diseño del
comportamiento de las defensas del sistema inmunológico
4. ExistVerify: Verifica que el elemento exista en la página.
5. EnabledVerify: Verifica que el elemento no se encuentre desactivado en la página.
6. NotEnabledVerify: Verifica que el elemento este desactivado.

Al tener definido adecuadamente el perfil mencionado fue posible continuar con la

implementación de las transformaciones, contando con el modelo de origen, los

Página 24 de 63
componentes necesarios de este, las relaciones, el perfil UML y las plataformas para las
cuales se crearan las pruebas.

4.5 DEFINICIÓN DE VARIABLES

Debido a que las pruebas pueden requerir el uso de variables durante la ejecución de un
Test Case, se da la opción de crear dichas variables creando acciones con el estereotipo:
“TestVariable”. Sin embargo, se debe tener en cuenta que el nombre que le asigne a la
variable debe tener el siguiente formato: ${NOMBRE} en donde NOMBRE es reemplazado
por el que se le quiera dar a la variable en cuestión, esto debe tenerse en cuenta al
modificar o crear diagramas de actividad.

Para leer las variables en cuestión se debe utilizar el mismo formato, es decir que si en
una acción específica se quiere comparar el valor de un elemento con el de una variable
que ha sido almacenada, se debe usar el valor: ${NOMBRE} en donde NOMBRE
corresponde al de la variable contra la que se quiere comparar el valor.

4.6CONSIDERACIONES PARA LA IMPLEMENTACIÓN

Debido a que en el proyecto “Modernización Forms” aún no se ha llegado a la generación

de las aplicaciones, no es posible realizar la implementación sobre la plataforma destino
del proyecto. Teniendo en cuenta lo anterior, se decidió modelar la cadena para que
funcione en aplicaciones Oracle ADF, la cual es una plataforma que comparte buena parte
de las propiedades y componentes de Oracle Forms y sobre las que se han hecho las
pruebas de para validar el funcionamiento de la cadena.

Como consideración adicional se han definido ciertas restricciones para las aplicaciones
ADF que se realicen pensando en hacerlas funcionar con el presente proyecto, dichas
consideraciones son las siguientes:

1. Los botones: Next de navegación Next, Previous, Last y First, junto con los de
acciones: Submit, Create, Update, Delete, deben tener el siguiente formato:

NOMBRE_DEL_FORMULARIO:NOMBRE_DEL_DATA_BLOCK-BOTON

En donde BOTON corresponde a Next, Submit, Create… según sea el caso.

2. Cada uno de los campos de los campos de texto debe tener como identificador el
siguiente namespace:

NOMBRE_DEL_FORMULARIO:NOMBRE_DEL_DATA_BLOCK-IDENTIFICADOR

Página 25 de 63
5. DESARROLLO DEL PROYECTO

5.1 DESARROLLO DE LA TRANSFORMACIÓN DE ORACLE FORMS A DIAGRAMAS

DE ACTIVIDAD

La primera transformación se inició con el análisis del metamodelo de aplicaciones Oracle

Forms desarrollado por el grupo TICSw, posteriormente se empezaron a crear las
relaciones que fueron mostradas en la definición del diseño, finalmente se procedió a
implementar la generación automática de pruebas basándose en los datos que nos da el
modelo inicial sobre la aplicación.

Para realizar la transformación se utiliza el lenguaje ETL (EpsilonTransformationLanguage)

el cual posee todas las herramientas que se necesitan para transformar a modelos UML,
puesto que nos permite utilizar perfiles y estereotipos, con lo que es posible parametrizar
los diagramas de acuerdo al diseño que hemos definido.

Para facilitar el mantenimiento de la cadena de transformación se ha decidido tener un

conjunto de archivos *.etl, en donde se tiene un archivo principal de ejecución y los
demás se encargan de crear, por separado, diagramas de actividades para cada una de las
seis pruebas definidas.

PruebaCreate

PruebaUpdate
Principal

PruebaNavegacion

PruebaDelete

PruebaGraficos

PruebaError

Página 26 de 63
Cada uno de los seis archivos derivados del principal se encarga de crear un diagrama de
actividad (dos en el caso de la navegación, uno para maestro y otro para maestro/detalle),
dichos diagramas generados son adheridos a un paquete principal UML que se crea en el
archivo principal con el fin de contener todas las pruebas sobre un bloque del formulario
en formato de diagrama de actividad.

ARCHIVO PRINCIPAL

Este etl se encarga de realizar la transformación, es decir que crea el esqueleto del
modelo objetivo (el conjunto de diagramas de actividad), por lo que se encarga de
modelar cada aplicación como un modelo UML, le aplica el perfil UML creado a dicho
modelo, crea un paquete UML por cada Form Data Block, le asigna el estereotipo de
TestSuite al paquete y empieza a realizar la ejecución de cada uno de los archivos etl que
generan pruebas, verificando que el Form Data Block en cuestión cumpla con los
prerrequisitos de cada una de las pruebas.

Al momento de crear el paquete UML por cada Form Data Block el archivo principal se
encarga de asignarle como nombre al paquete el mismo que tiene el bloque de datos,
luego le asigna el estereotipo mencionado y para el presente proyecto le da una URL base
que ha sido previamente definida, esta URL corresponde a la base que tienen las
aplicaciones Oracle ADF.

El archivo principal tiene, a parte del método que da inicio a la transformación, una
operación que permite, para un Item Text Item dado, obtener un valor aleatorio valido
para dicho elemento. Este valor se genera teniendo en cuenta tres propiedades del Text
Item: longitud máxima, valor mínimo y valor máximo. El programa se encarga de revisar
dichas propiedades y a partir de estos valores se puede generar un valor valido que pueda
ser usado para realizar las pruebas de creación y actualización para los campos de texto en
cuestión.

ELEMENTOS COMPARTIDOS ENTRE LOS ELEMENTOS DERIVADOS

Página 27 de 63
Todos los archivos derivados del principal tienen algunos elementos compartidos, propios
de un diagrama de actividad tradicional. Los elementos en cuestión son los siguientes:

1. Un nodo inicial, el cual se denomina “InitialNode” este nodo es el encargado de

marcar el inicio de la actividad.
2. Un nodo final, llamado “ActivityFinalNode” dicho nodo se encarga de marcar el
momento en que la ejecución del diagrama de actividad termina, dando por
finalizada la ejecución de la prueba.
3. Cada uno de los diagramas generados tienen el estereotipo “TestCase” asignado a
ellos.
4. Las primeras acciones de cada uno de los diagramas son un open, en donde se
abre la URL de la aplicación, y un wait, el cual le da un tiempo de 10 segundos a la
aplicación desde que se inicia para que cargue los gráficos y datos.

ARCHIVO DE PRUEBA CREATE

El archivo pruebaCreate se encarga de crear un solo diagrama de actividad para los

formularios que permitan inserción de datos. La lógica consiste en generar una cadena de
nodos y arcos, en donde se le asignan valores aleatorios validos a cada uno de los campos
de texto del formulario, se envía el formulario y luego se verifica que los datos enviados
sean desplegados satisfactoriamente.

Como consideración especial en este archivo se verifica si el formulario en cuestión es

detalle de algún otro, en este caso se omite el ponerle un valor al primer campo (el cual
modela la relación con el maestro) y se realizan las acciones sobre los demás, puesto que
el campo omitido es automáticamente diligenciado por el formulario maestro.

ARCHIVO DE PRUEBA UPDATE

El archivo de generación de pruebas de actualización considera de igual forma si el

formulario es detalle de algún otro, en dado casos se prueba modificando los dos campos
de texto que se encuentren después de este, de lo contrario se hacen pruebas son los
iniciales. Para realizar las pruebas se generan valores aleatorios y se envía el formulario.
Por último, se verifica que los datos ingresados sean los mismos que están desplegados.

ARCHIVO DE PRUEBA NAVEGACIÓN

Aquí se generan las dos pruebas de navegación principales, la navegación para formularios
maestros y los que son maestro/detalle. Ambos son muy similares, se guarda la llave y se
va navegando para verificar que el campo desplegado sea el adecuado y posteriormente

Página 28 de 63
se verifica el funcionamiento de los cuatro botones examinando si estos se desactivan
cuando deben estarlo.

ARCHIVO DE PRUEBA DELETE

Para este caso se verifica el valor de la llave primaria de cada formulario, es decir que esta
se almacena en una variable y se elimina el dato en cuestión, posteriormente se recarga la
página y se verifica que el campo mostrado no sea igual al que había sido guardado.

En los formularios detalle se deben tener los campos de llave de unión con la maestra en
primer lugar y el de la llave primaria del formulario en segundo lugar.

ARCHIVO DE PRUEBA DE EXISTENCIA DE GRAFICOS

El diagrama generado aquí muy básico, consta de los nodos de inicio y fin, con la adición
de un conjunto de verificaciones para examinar si el grafico se encuentra desplegado en la
aplicación. Debido a que el contenido de estos gráficos no puede ser evaluado
sistemáticamente no es posible realizar pruebas de contenido sobre el mismo.

ARCHIVO DE PRUEBA PARA MUESTREO DE ERRORES

Las pruebas de error son un poco distintas a las demás debido a que en estas se debe usar
la propiedad “XPath” de los navegadores web. Esta consideración se hizo debido a la
restricción que posee Selenium para verificar si un elemento contiene una clase
específica.Para el proyecto actual se diferencia la utilización de un XPath al de un
identificador tradicional sobre un elemento utilizando como inicio del namespace dos
slash (//), posterior a esto se inserta el XPath en cuestión.

Un XPath es una ruta mediante la cual el navegador puede llegar a un elemento

específico. En Selenium la práctica de XPath es muy recomendada para el manejo de
elementos en tablas, puesto que estos permiten acceder a determinada fila, columna o
celda, sin necesidad de utilizar identificadores.

En este script etl, el XPath se utiliza examinando si la tabla que contiene un campo de
texto en donde se espera obtener un error contiene la clase ADF que muestra errores, la
cual es “p_AFError”.

Página 29 de 63
5.2 DESARROLLO DE LA TRANSFORMACIÓN DE DIAGRAMAS DE ACTIVIDAD A
SELENIUM IDE

La creación del código para Selenium IDE debe seguir el formato propio del plugin del
proyecto el cual indica que los archivos que allí se usaran: Test Suite y Test Case, deben
ser *.html y seguir un formato básico de Selenium.

GENERACIÓN DE LOS TE ST SUITE PARA EL IDE

Para el caso de los Test Suite el formato definido por el plugin es el siguiente:

1. Tener como líneas iniciales la declaración de XML y HTML.

2. Tener un <title> en el <head>.
3. El <body> del archivo debe tener una tabla, en la cual la primera fila representa el
nombre del test suite.
4. Las demás filas de la tabla deben enlazar a los archivos *.html de los Test Suite
pertenecientes a dicho Test Case.

Teniendo en cuenta lo anterior se realizó la transformación a texto, esto se

empezóobteniendo todos los paquetes UML del modelo, aquí se debe tener cuidado de
no incluir paquetes sin elementos y que no sean los que genera la primera
transformación: PrimitiveTypes, el paquete del perfil ni el paquete del modelo.

Para cada uno de los paquetes que pasen el filtro se crea un nuevo directorio dentro de la
carpeta que contiene todo el código generado, dicho directorio tiene como nombre el
mismo del paquete y allí se pondrán todos los archivos *.html pertenecientes al paquete
que está siendo tratado. Adentro de cada uno de estos directorios creados se crea el
archivo Test Suite, el cual tiene como prefijo el texto “TEST_SUITE_” y se complementa
con el nombre del paquete en cuestión. El archivo mencionado se genera siguiendo la
estructura que requiere el plugin de Selenium IDE, es decir que se pone la información del
nombre del paquete en el título y la primera fila, y las demás filas de la tabla se

Página 30 de 63
populancon los diagramas de actividad del paquete, es decir que cada diagrama
corresponde a una fila de la tabla en donde se enlaza al Test Case correspondiente.

GENERACIÓN DE LOS TE ST CASE PARA EL IDE

El formato del archivo HTML que representa un Test Case para Selenium IDE es el
siguiente:

1. La misma cabecera con la información del XML, HTML y el título del caso.
2. Una tabla adentro del <body> en donde la primera fila sea el nombre del Test
Case.
3. Posteriormente se tiene el cuerpo de la tabla, los cuales son filas con tres casillas:
a. Nombre del comando Selenium IDE a ejecutar.
b. Objetivo del comando, generalmente es el elemento o una propiedad
básica de la acción como el timeout para el comando wait. (Opcional para
algunos comandos).
c. El valor del comando, por ejemplo en el comando fill este campo
representa el valor que se le pondrá al elemento especificado en el
objetivo. (Opcional para algunos comandos).

Para iniciar la creación de los mismos se crea un archivo *.html el cual tiene como nombre
el que trae el diagrama de actividad, la ubicación del archivo es la misma en donde se
deposita su Test Suite respectivo.

La creación del archivo como tal se le encarga al script egl denominado

“SeleniumTestCaseIDE.egl” el cual tiene como cabecera los datos de XML y HTML, así
como meta data para marcar la URL base para las pruebas (la cual se obtiene del
estereotipo del paquete) y se tiene el título del Test Case. Lo que va a continuación es el
<body> del ejecutable en donde se sigue el formato explicado anteriormente, es decir que
se tiene una tabla en donde la primera fila tiene el nombre del Test Case, una acción de
espera en caso de que esté presente el atributo timeout en el paquete y luego se

Página 31 de 63
empiezan a agregar las acciones de la prueba, siguiendo el mismo sistema de antes:
comando, objetivo y valor.

Como detalle de esta transformación hay que tener en cuenta los acentos para los
objetivos y valores, así como el nombre de las operaciones en Selenium IDE, a
continuación se muestra un mapeo de los estereotipos con su respectivo comando en el
plugin:

Estereotipo Comando Selenium IDE

fill type

TestVariable storeValue

NotEnabledVerify verifyNotEditable

EnabledVerify verifyEditable

wait pause

NotContentVerify verifyNotValue

ContentVerify verifyValue

ExistVerify isElementPresent

VerifyNotExist isElementNotPresent

Página 32 de 63
Realizando las operaciones anteriormente mencionadas es posible generar los Test Case
de Selenium IDE, incluyéndolos dentro del Test Case respectivo para que estos sean
cargados al plugin del navegador.

5.3 DESARROLLO DE LA TRANSFORMACIÓN DE DIAGRAMAS DE ACTIVIDAD A

SELENIUM WEBDRIVER

Las pruebas que hacen uso del WebDriver se ejecutan en un archivo JUnit, por lo cual para
esta transformación se tiene que cada paquete corresponde a un archivo *.java, el
nombre del archivo corresponde al nombre del paquete UML. El archivo representa una
clase de prueba que tiene como nombre el mismo del archivo.

Como la prueba es un JUnit tradicional, entonces se tiene como inicio la definición del
paquete y algunos import básicos que permiten la ejecución de métodos de Selenium y de
JUnit. En la clase se tiene un atributo llamado sel del tipo DefaultSelenium, con dicha
instancia se usaran los métodos que da el SeleniumWebDriver.

El primer método de la clase se llama prepare y se ejecuta antes del resto de pruebas,
motivo por el cual tiene la anotación @Before, allí se genera la instancia del
DefaultSelenium y es asignada al atributo mencionado anteriormente. En caso de que el
paquete tenga como atributo un timeout, entonces se utiliza el método setTimeout de la
clase para definir de antemano la demora máxima de cada acción.

Como parte final se crean los métodos de la clase, todos estos llevan la anotación de
prueba, es decir @Test y el nombre es el mismo del diagrama de actividad, luego se
recorre el diagrama, es decir que se inicia en el InitialNode y se empiezan a recorrer las
acciones del mismo, en cada acción se verifican los estereotipos aplicados y se van
escribiendo las líneas JUnit respectivas apoyándose en los métodos de
SeleniumWebDriver.

Para la implementación en el WebDriver se tiene un mapeo similar de acciones del

WebDriver con las que vienen de los estereotipos:

Página 33 de 63
Estereotipo Comando SeleniumWebDriver

fill type

TestVariable Se usan las variables Java tradicionales

NotEnabledVerify isEditable (se evalúa que sea falso)

EnabledVerify isEditable

wait Se detiene la ejecución del Thread con Java

NotContentVerify getValue (se evalúa que el valor obtenido

sea diferente al del valor asignado)

ContentVerify getValue (se evalúa que el valor obtenido

sea igual al del valor asignado)

ExistVerify isElementPresent

VerifyNotExist isElementPresent (se evalúa que retorne

falso)

Finalmente, se hace el cierre de la instancia de Selenium, es decir que al final de cada uno
de los métodos generados se llama el método close de la instancia del WebDriver.

6. VALIDACIÓN

La validación del trabajo realizado se realizó en cuatro etapas:

Página 34 de 63
 1. Definición de las pruebas esperadas

2. Validación con aplicación ADF

3. Validación con EVL

4. Validación con diagramas hechos manualmente

6.1 DEFINICIÓN DE LAS PRUEBAS ESPERADAS

Con el fin de validar el funcionamiento de las pruebas se diseñó una aplicación ADF de
prueba, la cual fue modelada utilizando el metamodelo de Oracle Forms de TICSw y a
partir de dicho modelo de la aplicación se ejecutó la cadena de transformación con el fin
de verificar el correcto funcionamiento de las pruebas generadas. El modelo de la
aplicación de prueba se presenta a continuación:

Página 35 de 63
A partir de dicho modelo se definieron las siguientes pruebas esperadas, las cuales fueron
realizadas a mano sobre el Selenium IDE con el fin de comparar las pruebas obtenidas en
la cadena con las que se realizaron manualmente. Las pruebas esperadas son las
siguientes:

PARA EL FORMULARIO MAESTRO DE SOFT WARE (MAESTRO):

Página 36 de 63
ID: FSTC1

Nombre: Prueba de navegación

Orden: 1

Propósito: Probar que la navegación está funcionando adecuadamente.

Pasos:  Guardar el valor del primer campo del formulario.

 Verificar que el campo guardado sea el mismo del campo inicial.
 Dar click en Next.
 Guardar el valor del primer campo del formulario.
 Verificar que el campo guardado sea el mismo del campo inicial.
 Dar click en Next.
 Guardar el valor del primer campo del formulario.
 Verificar que el campo guardado sea el mismo del campo inicial.
 Dar click en First.
 Verificar que el botón de First quede desactivado.
 Verificar que el botón de Previous quede desactivado.
 Dar click en Last.
 Verificar que el botón de Last quede desactivado.
 Verificar que el botón de Next quede desactivado.

ID: FSTC2

Nombre: Prueba de update

Orden: 2

Propósito: Probar que el formulario está permitiendo actualizar elementos.

Pasos:  Agregar un valor aleatorio al segundo campo.

 Agregar un valor aleatorio al tercer campo.
 Dar click en Submit.
 Esperar a que recargue la página.
 Verificar que al recargar el segundo campo tiene el valor que se le
fue asignado.
 Verificar que al recargar el tercer campo tiene el valor que se le fue
asignado.

ID: FSTC3

Nombre: Prueba de delete

Orden: 3

Página 37 de 63
Propósito: Probar que el formulario está permitiendo eliminar elementos.

Pasos:  Guardar valor del primer elemento del formulario.

 Dar click en Delete.
 Esperar a que cargue la página.
 Verificar que el primer elemento del formulario es distinto al que
está almacenado.

ID: FSTC4

Nombre: Prueba de create

Orden: 4

Propósito: Probar que el formulario está permitiendo crear elementos.

Pasos:  Dar click en Create.

 Asignar valores aleatorios a cada uno de los campos del
formulario.
 Dar click en Submit.
 Verificar que cada uno de estos valores aleatorios sea el que está
al recargar la página.

ID: FSTC5

Nombre: Prueba de errores

Orden: 5

Propósito: Probar que el formulario está dando error cuando se dejan vacíos
elementos obligatorios.

Pasos:  Dejar vacíos todos los campos obligatorios.

 Dar click en Submit.
 Verificar que cada uno de estos campos estén con la clase de
error (borde rojo).

PARA EL FORMULARIO D E GRÁFICOS (MAESTRO):

ID: FSTC6

Nombre: Prueba de existencia de elementos.

Página 38 de 63
Orden: 6

Propósito: Probar que el formulario está cargando los elementos.

Pasos:  Verificar que exista cada uno de los elementos gráficos (imágenes
y datos graficados).

PARA EL FORMULARIO D E EQUIPOS (MAESTRO/DETALLE):

ID: FSTC7

Nombre: Prueba de navegación

Orden: 7

Propósito: Probar que la navegación está funcionando adecuadamente.

Pasos:  Guardar el valor del primer campo del formulario.

 Verificar que el campo guardado sea el mismo del campo inicial.
 Dar click en Next.
 Guardar el valor del primer campo del formulario.
 Verificar que el campo guardado sea el mismo del campo inicial.
 Dar click en Next.
 Guardar el valor del primer campo del formulario.
 Verificar que el campo guardado sea el mismo del campo inicial.
 Dar click en First.
 Verificar que el botón de First quede desactivado.
 Verificar que el botón de Previous quede desactivado.
 Dar click en Last.
 Verificar que el botón de Last quede desactivado.
 Verificar que el botón de Next quede desactivado.

ID: FSTC8

Nombre: Prueba de update

Orden: 8

Propósito: Probar que el formulario está permitiendo actualizar elementos.

Pasos:  Agregar un valor aleatorio al segundo campo.

 Agregar un valor aleatorio al tercer campo.
 Dar click en Submit.
 Esperar a que recargue la página.

Página 39 de 63
  Verificar que al recargar el segundo campo tiene el valor que se le
fue asignado.
 Verificar que al recargar el tercer campo tiene el valor que se le fue
asignado.

ID: FSTC9

Nombre: Prueba de delete

Orden: 9

Propósito: Probar que el formulario está permitiendo eliminar elementos.

Pasos:  Guardar valor del primer elemento del formulario.

 Dar click en Delete.
 Esperar a que cargue la página.
 Verificar que el primer elemento del formulario es distinto al que
está almacenado.

ID: FSTC10

Nombre: Prueba de create

Orden: 10

Propósito: Probar que el formulario está permitiendo crear elementos.

Pasos:  Dar click en Create.

 Asignar valores aleatorios a cada uno de los campos del
formulario.
 Dar click en Submit.
 Verificar que cada uno de estos valores aleatorios sea el que esta
al recargar la página.

ID: FSTC11

Nombre: Prueba de navegación maestro/detalle

Orden: 11

Propósito: Probar que el formulario está navegando adecuadamente los dos

formularios relacionados. Equipos y Software Instalado.

Pasos:  Guardar el valor del primer campo en el formulario maestro.

Página 40 de 63
  Verificar que ese valor sea el mismo del primer campo del
formulario detalle.
 Dar click en Next.
 Guardar el valor del primer campo en el formulario maestro.
 Verificar que ese valor sea el mismo del primer campo del
formulario detalle.
 Dar click en Next.
 Guardar el valor del primer campo en el formulario maestro.
 Verificar que ese valor sea el mismo del primer campo del
formulario detalle.

ID: FSTC12

Nombre: Prueba de errores

Orden: 12

Propósito: Probar que el formulario está dando error cuando se dejan vacíos
elementos obligatorios.

Pasos:  Dejar vacíos todos los campos obligatorios.

 Dar click en Submit.
 Verificar que cada uno de estos campos esten con la clase de
error (borde rojo).

PARA EL FORMULARIO D E SOFTWARE INSTALADO ( DETALLE):

ID: FSTC13

Nombre: Prueba de navegación

Orden: 13

Propósito: Probar que la navegación está funcionando adecuadamente.

Pasos:  Guardar el valor del primer campo del formulario.

 Verificar que el campo guardado sea el mismo del campo inicial.
 Dar click en Next.
 Guardar el valor del primer campo del formulario.
 Verificar que el campo guardado sea el mismo del campo inicial.
 Dar click en Next.
 Guardar el valor del primer campo del formulario.
 Verificar que el campo guardado sea el mismo del campo inicial.

Página 41 de 63
  Dar click en First.
 Verificar que el botón de First quede desactivado.
 Verificar que el botón de Previous quede desactivado.
 Dar click en Last.
 Verificar que el botón de Last quede desactivado.
 Verificar que el botón de Next quede desactivado.

ID: FSTC14

Nombre: Prueba de update

Orden: 14

Propósito: Probar que el formulario está permitiendo actualizar elementos.

Pasos:  Agregar un valor aleatorio al segundo campo.

 Dar click en Submit.
 Esperar a que recargue la página.
 Verificar que al recargar el segundo campo tiene el valor que se le
fue asignado.

ID: FSTC15

Nombre: Prueba de delete

Orden: 15

Propósito: Probar que el formulario está permitiendo eliminar elementos.

Pasos:  Guardar valor del primer elemento del formulario.

 Dar click en Delete.
 Esperar a que cargue la página.
 Verificar que el primer elemento del formulario es distinto al que
está almacenado.

ID: FSTC16

Nombre: Prueba de create

Orden: 16

Propósito: Probar que el formulario está permitiendo crear elementos.

Pasos:  Dar click en Create.

Página 42 de 63
  Asignar valores aleatorios a cada uno de los campos del formulario
(a excepción del primero debido a que este guarda la relación).
 Dar click en Submit.
 Verificar que cada uno de estos valores aleatorios sea el que esta
al recargar la página.

ID: FSTC17

Nombre: Prueba de errores

Orden: 17

Propósito: Probar que el formulario está dando error cuando se dejan vacíos
elementos obligatorios.

Pasos:  Dejar vacíos todos los campos obligatorios.

 Dar click en Submit.
 Verificar que cada uno de estos campos esten con la clase de
error (borde rojo).

6.2VALIDACIÓN CON APLICACIÓN ADF

Como se puede apreciar la instancia del metamodelo cuenta con un formulario y cuatro
Form Data Block, teniendo una relación maestro detalle entre equipos y software de
equipos y un data block únicamente diseñado para el despliegue de un gráfico circular. Al
realizar la ejecución de la primera parte de la cadena, es decir de la transformación Oracle
Forms a Diagramas de Actividad se obtuvo el siguiente modelo:

Página 43 de 63
Como se puede apreciar para cada uno de los paquetes anteriormente mencionados se
generaron distintos diagramas de actividad. Para el primer Data Block, es decir el de
software, se obtuvieron las pruebas CRUD, de navegación y de error. Lo anterior también
aplica para el paquete de software requerido, sin embargo en el tercero (equipos) se
adiciono el encargado de probar la navegación maestro/detalle del Data Block en cuestión
junto con el de software instalado. Para finalizar la transformación genero una única
prueba de existencia de gráficos para el Data Block llamado gráficos de sistemas
instalados.

Los anteriores paquetes y sus respectivos diagramas eran los que se esperaban de la
primera transformación, puesto que no se tienen ciertos elementos en todos los Data
Block y la información del modelo instanciado de la aplicación modela los que han sido
generados. En una etapa de validación posterior se verificaran las condiciones de cada
diagrama y si contienen los elementos adecuados.

Página 44 de 63
Al ejecutar la segunda parte de la cadena de transformación se obtuvo como resultado el
código en ambas plataformas: IDE y WebDriver. Ambas plataformas fueron probadas
satisfactoriamente, es decir que al tener la aplicación desplegada y al ejecutar tanto las
del IDE como las del WebDriver se pudo verificar que las pruebas habían sido creadas por
la transformación y que además verificaban el estado de la interfaz gráfica.

6.3 VALIDACIÓN CON EVL

El lenguaje EVL (EpsilonValidationLanguage) es una herramienta que permite verificar el

estado de una instancia de un modelo. En este caso, se creó un script EVL con el fin de que
este se encargará de analizar los paquetes UML generados y así encontrar posibles errores
que pudieron ser hechos por la transformación inicial o por modificaciones propias del
programador. En caso de que el ingeniero de modernización decida crear un nuevo
diagrama desde cero también puede validar el contenido de dicho diagrama utilizando el
script EVL.

En detalle el script en EVL se encarga de verificar los siguientes elementos:

VALIDACIÓN EVL PARA EL MODELO UML

1. Se valida que el modelo tenga un nombre.

2. El modelo tiene aplicado el perfil generado en este proyecto.
3. El modelo contiene al menos un paquete UML.

VALIDACIÓN EVL PARA CADA PAQUETE UML

1. Se valida que el paquete tenga un nombre.

2. El paquete debe tener el estereotipo TestSuite asignado.
3. El modelo contiene una URL base que no está vacía.

VALIDACIÓN EVL PARACADA DIAGRAMA DE ACTIVIDAD

1. Se valida que el diagrama tenga un nombre.

2. El diagrama debe tener el estereotipo TestCase asignado.

Página 45 de 63
 3. El diagrama debe tener al menos un OpaqueAction (encargados de modelar las
acciones).
4. El diagrama debe tener un único nodo inicial.
5. El diagrama debe contar con un único nodo final.
6. El diagrama tiene una ruta definida, es decir que tiene un nodo inicial y a partir del
mismo es posible recorrer los OpaqueAction hasta llegar a un nodo final.

VALIDACIÓN EVL PARACADAACCIÓN

1. Se valida que el action tenga un nombre.

2. El action debe tener al menos un estereotipo.
3. Si el action requiere un namespace entonces este valor debe estar dado y no
puede ser vacio.
4. En caso de tener el estereotipo open entonces se debe tener la URL.
5. Si tiene el estereotipo wait se debe contar con el timeout.
6. Cuando tiene el estereotipo select debe tener el identificador del padre.
7. Para los actions con el estereotipo TestVariable se debe tener el nombre de la
variable.
8. En caso de tener el estereotipo fill se debe tener el valor que ha de ser llenado.
9. Si cuenta con el estereotipo NotContentVerify se debe contar con el valor que se
espera no obtener.
10. Si por el contrario tiene ContentVerify debe tener el valor esperado.
11. Como punto final se revisa que en el paquete no hayan variables duplicadas.

Al probar el modelo generado con el script EVL fue satisfactorio encontrar que el validador
no encontró errores en la operación, sin embargo se realizaron modificaciones
intencionales, dando lugar a errores que efectivamente fueron reportados por el
validador, comprobando así que el validador funciona de forma adecuada.

Página 46 de 63
6.4 VALIDACIÓN CON DIAGRAMAS HECHOS MANUALMENTE

Para realizar la validación, se crearon los 17 diagramas de actividad correspondientes a

cada una de las pruebas mencionadas. Teniendo dicho repositorio de diagramas hechos
manualmente fue posible comparar el contenido de los diagramas generados con los que
se realizaron manualmente para este fin. El resultado fue que los diagramas
correspondían (omitiendo el orden) a los que se generaban, por lo que se pudo
comprobar que la cadena de transformación M2M daba como resultado el modelo UML
que se esperaba.

Como ejemplo de lo anteriormente explicado, se muestran los 17 diagramas

correspondientes a las pruebas que fueron mostradas inicialmente:

DIAGRAMAS DE ACTIVID AD PARA FORMULARIO DE EQUIPOS (MAESTRO)

Crear

Página 47 de 63
 Eliminar

Verificación de errores

Página 48 de 63
Navegación

Página 49 de 63
Navegación maestro/detalle

Página 50 de 63
 Actualizar

DIAGRAMAS DE ACTIVID AD PARA FORMULARIO DE GRAFICOS (MAESTRO)

Existencia de gráficos

Página 51 de 63
DIAGRAMAS DE ACTIVID AD PARA FORMULARIO DE SOFTWARE (MAESTRO)

Crear

Página 52 de 63
 Delete

Verificación de errores

Página 53 de 63
Navegación

Página 54 de 63
 Actualización

DIAGRAMAS DE ACTIVID AD PARA FORMULARIO DE SOFTWARE INSTALADO (DETALLE)

Página 55 de 63
Crear

Página 56 de 63
 Eliminar

Verificación de errores

Página 57 de 63
Navegación

Actualización

Página 58 de 63
Por otro lado en la generación de la primera transformación al convertir el modelo de
Oracle Forms de la aplicación ADF de pruebas a diagramas de actividad se obtuvieron los
siguientes diagramas:

Al hacer las comparaciones de los componentes de los diagramas con los que han sido
mostrados en las últimas páginas se puede comprobar que la primera transformación
tiene como resultado lo que se esperaba de él.

7. RESULTADOS

7.0 COSTO DE LA CADENA TRANSFORMADORA

El resultado en la creación de la cadena de transformación se reduce a los siguientes

datos:

Página 59 de 63
 PRIMERA SEGUNDA
VALIDACIONES
TRANSFORMACIÓN TRANSFORMACIÓN

1.291 7 358 6 240

1 ARCHIVO
LINEAS ARCHIVOS LINEAS ARCHIVOS LINEAS

Es decir que en conjunto se crearon 1.889 líneas de código junto con 14 archivos para la
implementación de la cadena, desde que se estudia el modelo inicial, se generan las
pruebas, se transforman a diagramas de actividad y se llevan los diagramas a código
Selenium en sus dos plataformas.

7.1 CON UNA APLICACIÓN ADF DE PRUEBA

En el caso de la aplicación de prueba se contabilizaron aproximadamente cinco segundos

ejecutar las tres transformaciones. En dicha aplicación se obtuvieron un total de:

APLICACIÓN ADF

IDE WEBDRIVER

1.092 LINEAS 21 ARCHIVOS 607 LINEAS 4 ARCHIVOS

7.2 CON UNA APLICACIÓN EMPRESARIAL REAL

Página 60 de 63
Para la toma de resultados sobre una aplicación real se utilizó el modelamiento de una
aplicación empresarial real de Oracle Forms. El modelo de la aplicación cuenta con 89
formularios y la cadena de transformación para este modelo se demora cerca de 2
minutos y 20 segundos para la transformación a Selenium IDE, mientras que para el
WebDriver se demora cerca de 3 minutos con 15 segundos. Como resultado de la cadena
se generan los siguientes resultados:

APLICACIÓN EMPRESARIAL REAL

IDE WEBDRIVER
34.564 660 17.814 168
LINEAS ARCHIVOS LINEAS ARCHIVOS

8. CONCLUSIONES

8.1 DISCUSIÓN

Como conclusión inicial podemos decir que la cadena de transformación, aplicada a

contextos reales, es capaz de agilizar en enorme medida los procesos de pruebas básicos.
Los resultados arrojados con el modelo empresarial real son prueba de ello, puesto que en
conjunto se lograron generar 52.378 líneas de código en 828 archivos.

Adicionalmente se puede destacar que cualquier encargado de realizar la transformación

puede generar pruebas de interfaz con facilidad sin necesidad de conocer en mayor
detalle las plataformas de Selenium, en este caso únicamente se requiere de un editor
gráfico que soporte modelamiento de diagramas de actividad (como Papyrus) y con ellos y
la cadena aquí presentada es posible crear las pruebas realizando un esfuerzo mínimo.

Página 61 de 63
Fue posible incluir las pruebas que se plantearon en un inicio, es decir que en efecto se
crean pruebas para las operaciones CRUD básicas, la navegación de los formularios, la
verificación de errores y la existencia de los gráficos. Todas estas operaciones se pueden
hacer en formularios maestro y maestro/detalle.

8.2 TRABAJO FUTURO

El trabajo presentado en la presente tesis de grado permite extender las funcionalidades

aquí ofrecidas debido a que el software utilizado aquí es 100% abierto y las tecnologías
usadas son abiertas y de mantenimiento continuo por parte de la comunidad dedicada a
ello.

Entre los aspectos sobre los que se puede mejorar la implementación actual está el incluir
generación de pruebas para el modo de vista de tablas en los formularios maestro y
maestro/detalle, a partir de aquí se tienen que tener en cuenta las 3 combinaciones
restantes: tabla/tabla, tabla/formulario y formulario/tabla. En el presente proyecto se
manejan únicamente en formato de formulario.

Adicionalmente se pueden incluir las pruebas sobre formularios Lookup, los cuales son
una implementación adicional de Oracle Forms y que se encuentran contenidos en las
tecnologías que funcionan de manera similar.

Finalmente, es posible extender el proyecto actual con las demás capas de las
aplicaciones, es decir que se pueden crear pruebas de persistencia y de funcionalidad, con
las cuales sería posible automatizar aún más el proceso de pruebas.

9. BIBLIOGRAFÍA

[1] Asesoftware. (n.d.). Recuperado en Noviembre 10, 2014, desde

http://www.asesoftware.com/

Página 62 de 63
[2] Vieria, M., Leduc, J., Hasling, B., Subramanyan, R., &Kazmeier, J. (2006, Mayo 23).
Automation of GUI TestingUsing a Model-drivenApproach. Recuperadoen Septiembre 20,
2014, desde http://dl.acm.org/citation.cfm?id=1138932

[3] Fröhlich, P., & Link, J. (2000). Automated Test Case Generation from Dynamic
Models.Recuperado en Septiembre 20, 2014, desde http://extras.springer.com/2000/978-
3-540-67660-7/papers/1850/18500472.pdf

[4] Grant, R. (n.d.). From Forms to ADF – When, Why and How? Recuperado en Agosto
10, 2014, desde http://download.oracle.com/otndocs/OTNVDD-
REA/ppt/FormstoADF2.pdf

[5] Selenium HQ. (n.d.). Retrieved August 17, 2014, from http://www.seleniumhq.org

[6] Vladan, D., Dragan, D., & Dragan, G. (2006). TheOntology UML Profile. Recuperado en
Noviembre 28, 2014, desde http://link.springer.com/chapter/10.1007/3-540-32182-9_9

[7] Cavarra, A., Davies, J., Jeron, T., Mounier, L., Hartman, A., &Olvovsky, S. (2002). Using
UML for Automatic Test Generation.Recuperado de
http://www.research.ibm.com/haifa/projects/verification/mdt/papers/uml4testgen.pdf

Página 63 de 63