Anda di halaman 1dari 37

UNIVERSIDAD MAYOR DE SAN SIMON

FACULTAD DE CIENCIAS Y TECNOLOGIA


DIRECCIÓN DE POSGRADO

“AUTOMATIZACION TEST DE UI WEB CON


ARCHIVO XML”

TRABAJO FINAL PRESENTADO PARA OBTENER EL CERTIFICADO


DE DIPLOMADO EXPERTO EN DESARROLLO DE APLICACIONES
EMPRESARIALES VERSIÓN I
.

POSTULANTE : Roberto Carlos Olguin Ledezma


TUTOR : MSc. Lic. Valentin Laime Zapata

Cochabamba – Bolivia
2018

1
Quiero agradecer en primer lugar a DIOS por darme la
fortaleza y perseverancia para llegar a este punto, a mi familia
que siempre me dio el apoyo incondicional y siempre creyó
en mí, en especial a mis padres y hermanos. Y como no
olvidar a las personas y amigos que siempre estuvieron
predispuestos a ayudar para la finalización de los estudios.

2
INDICE

RESUMEN .................................................................................................................................................. 6

1. INTRODUCCION .................................................................................................................................. 7

2. ANTECENDENTES ............................................................................................................................... 8

2.1 ANTECEDENTES GENERALES .................................................................................................. 8

2.2 ANTECEDENTES ESPECIFICOS ................................................................................................ 9

3. METODOLOGIA ................................................................................................................................. 10

3.1 METODO BIBLIOGRAFICO ...................................................................................................... 10

3.2 METODO ANALITICO ................................................................................................................ 10

4. SELENIUM Y EL PATRON PAGE OBJECT PARA PRUEBAS AUTOMATIZADAS.............. 11

4.1 SELENIUM ANTECEDENTES ............................................................................................ 11

4.2 SELENIUM 1.0 ........................................................................................................................ 11

4.3 SELENIUM 2.0 ........................................................................................................................ 13

4.4 AUTOMATIACION DE PRUEBAS ..................................................................................... 14

4.5 BENEFICIOS DE AUTOMATIACION DE PRUEBAS ..................................................... 16

4.6 CLAVES PARA REALIZAR UNA AUTOMATIZACION PRODUCTIVA .................... 17

4.7 HERRAMIENTAS DE AUTOMATIZACION .................................................................... 18

5. PAGE OBJECT COMO PATRON DE DISEÑO .............................................................................. 21

5.1 PROBLEMA ................................................................................................................................... 22

3
5.2 MOTIVACION ............................................................................................................................... 22

5.3 APLICABILIDAD .......................................................................................................................... 22

5.4 CONSECUENCIAS........................................................................................................................ 22

5.5 IMPLEMENTACION .................................................................................................................... 23

6. LA POSICION DE AUTOMATIZACION EN EL DESARROLLO DE SOFTWARE ................ 23

7. XML MAPEO DE DATOS ANTES DE LA AUTOMATIZACION ............................................... 26

7.1 CASTOR ......................................................................................................................................... 29

7.2 MARSHALLING............................................................................................................................ 29

7.3 UNMARSHALLING ...................................................................................................................... 30

7.3 ARCHIVOS DE MAPEO .............................................................................................................. 31

8. INTERACION DE XML CON SPRING ............................................................................................ 33

8.1 SPRING FRAMEWORK .............................................................................................................. 33

8.2.1 CARACTERISTICAS................................................................................................................. 33

8.2.1 BENEFICIOS AL UTILIZAR SPRING ................................................................................... 34

8.2 RESULTADO ESPERADO ........................................................................................................... 34

10. CONCLUSIONES .............................................................................................................................. 36

11. BIBLIOGRAFIA ................................................................................................................................ 37

4
TABLA DE FIGURAS Y CONTENIDOS

Figura1:Selenium 1.0 ............................................................................................................................... 12.

Figura2:Selenium 2.0 ............................................................................................................................... 13.

Figura3:Tabla Ejemplo ............................................................................................................................ 14.

Figura4:Selenium UI test ......................................................................................................................... 16.

Figura5:Interacción de los Page Object .................................................................................................. 21.

Figura6:Retroalimentación ...................................................................................................................... 24.

Figura7:Flujo de desarrollo y posición de prueba funcional ................................................................. 25.

Figura8:Mapeo de clases .......................................................................................................................... 31.

Figura9:Clases .......................................................................................................................................... 32.

Figura10:Maping requerido por castor ................................................................................................... 32.

Figura11:Resultado generado por Castor ............................................................................................... 35.

5
RESUMEN

El siguiente trabajo muestra una visión general sobre la automatización de pruebas de software, ya que es

un proceso que ha crecido a gran escala en los últimos años debido a las ventajas que presenta, situación

por el cual, algunas empresas de desarrollo de software lo han estado realizando como una estrategia de

automatización, que permita llevar el proceso a nivel operativo. Este proceso va utilizando un lenguaje de

programación orientado a objetos con el objetivo de realizar validaciones y/o verificaciones para

incluirlos en una plataforma de automatización de pruebas, cuyo principal objetivo es convertirse en una

herramienta de automatización personalizada de la empresa. Dicho proyecto se desarrolló utilizando Java

como lenguaje de programación e IDEA como entorno de desarrollo, además de incluir las herramientas

Junit, Selenium.

No olvidar, Junit permite ejecutar clases Java de manera controlada para evaluar si el funcionamiento de

cada uno de los métodos de una clase se comporta de la manera esperada.

Por otra parte, Selenium es un conjunto de clases que provee funciones que se encargan de interactuar con

el navegador, permitiendo el envío y recepción de acciones y datos.

Donde lo anterior mencionado y las acciones que realizan dichas herramientas son aprovechadas desde

una lectura de archivos .xml siendo así el principal proceso para la captura de datos y a su vez

aprovechado por el mismo Selenium, agilizando así otra forma de automatizar las pruebas.

6
1. INTRODUCCION

Producir software con un nivel de calidad insuficiente puede ser un pésimo negocio. Ya no es suficiente

con que las aplicaciones estén completas, también deben satisfacer otros aspectos en términos de

rendimiento, accesibilidad, seguridad, etc. Por lo tanto, el objetivo de cualquier organización que se

dedique al desarrollo de software debe ser producir software de calidad, es decir, generar software con el

número menor de errores y de forma eficiente.

Con lo anterior mencionado, la calidad debe ser una exigencia obligada dentro del proceso de desarrollo,

debido a ello cada vez mayor número de empresas consideran dentro del proceso de desarrollo, a las

actividades de aseguramiento de la calidad. Dichas actividades comprenden variedad de tareas como el

establecimiento de métodos técnicos sólidos, métricas análisis e informes, pruebas de software bien

planificadas, revisiones, etc. Todo ello aportando con gran claridad sobre el estado y la madurez del

producto que se está desarrollando.

Una de las partes importantes que compone las tareas propias de un sistema de aseguramiento de calidad

son las pruebas de software. Existen pruebas unitarias, de integración, funcionales, de rendimiento, etc.

Cabe mencionar que algunas de ellas son susceptibles de ser automatizadas, lo que significa que la

ejecución del control de calidad lo realiza una maquina en lugar del tester.

Actualmente la automatización de pruebas es el paso ideal para mejorar la calidad del desarrollo. Cada

vez que las aplicaciones se vuelven más complejas y/o los requisitos van variando a medida que avanza el

desarrollo del software, haciendo de esta manera que la fiabilidad del software vaya disminuyendo.

Es en estos casos de pruebas donde la automatización cobra más importancia y representa una ventaja

clara a la hora de abordar el proceso de ejecución de las pruebas. Esto puede ser aplicada en diferentes

niveles de prueba, desde pruebas unitarias, hasta pruebas de aceptación.

7
Dentro las herramientas de testeo de aplicaciones web con mayor importancia, se puede mencionar a

Selenium (un framework opensource) que permite una navegación a través de una aplicación web tal y

como lo haría un usuario final.

2. ANTECENDENTES

Actualmente, algunas organizaciones de grupos de individuos de la sociedad utilizan lectura de archivos

cuyo formato es ..JSON para un determinado proyecto en la ejecución de pruebas de automatización, lo

cual ha despertado interés en cómo mejorar este proceso para archivos con formatos .xml para las pruebas

automatización. Para más detalle se verá en el capítulo 7.

Sin embargo, al intentar implementar iniciativas de automatización de pruebas, las organizaciones se

enfrentan a:

Un incremento de los costos del proyecto originado por la inversión adicional en la tecnológica a utilizar

y en contratación o entrenamiento de personal con conocimiento en automatización

Actividades adicionales durante la fase de operación del proyecto, enfocadas al mantenimiento de los

scripts de automatización.

2.1 ANTECEDENTES GENERALES

Las pruebas de software son organizadas mediante casos de pruebas, los cuales son un conjunto de

condiciones o variables bajo los que se determinará si el requerimiento a probar de la aplicación es

satisfactorio o no. Son utilizadas con el propósito de mejorar la calidad mediante la realización de tareas

de verificación y validación, permitiendo conocer la calidad del producto y simplificando la detección y

corrección de posibles fallos.

Dichos beneficios se pueden aprovechar para actuar a tiempo y así reducir costos de mantenimiento y de

soporte hacia usuarios insatisfechos, además de la obtención de información útil que ayudará a futuros

proyectos.

8
2.2 ANTECEDENTES ESPECIFICOS

Debido al gran crecimiento y la alta competitividad del mercado las herramientas utilizadas para pruebas

también evolucionaron ayudando a reducir costos en procesos que solían consumir muchos recursos. La

automatización de pruebas es un claro ejemplo de dicha evolución.

El proyecto para realizar se enfoca en crear scripts con métodos genéricos utilizando las herramientas

Selenium Web Driver y JUnit mediante Java, los cuales permitan la creación de casos de pruebas

automáticos, utilizando la estructura contenida dentro de un archivo .xml colaborando así con la

automatización del proceso de pruebas.

Selenium Web Driver es una tecnología opensource, que tiene el objetivo de automatizar pruebas,

brindando una serie de funcionalidades que permiten el manejo total del navegador, tanto en ambientes

web como móvil. Por su parte JUnit pone a disposición un entorno con una gran cantidad de métodos que

permiten desarrollar, ejecutar y obtener resultados de casos de pruebas automáticos.

Al tratarse de un API orientado a las aplicaciones web modernas, donde anteriormente había problemas

para el testing de las mismas. Además, tiene pasarelas de comunicación que funcionan directamente con

el servidor en diversos lenguajes. Selenium Web Driver permite crear Scripts de pruebas más robustos

pues se puede desarrollar sobre varios lenguajes de programación, entre ellos C# y Java. Es de gran ayuda

en las pruebas de Regresión y Retesting. Este componente permite además de la ejecución local, la

ejecución remota haciendo uso de "Selenium Server".

Aquella empresa de desarrollo de software que utilice automatización necesita manejar y mejorar la

prestación de servicios en el área de calidad del software, por lo que contar con una nueva estrategia

operativa de automatización de casos de prueba y ejecución de pruebas de rendimiento vendrán de ayuda

en la obtención de datos, mediante la mejora de dicho proceso.

9
El desarrollo e implementación de este plan operativo, ampliara en los servicios de obtención de datos

para la calidad del software, evolucionando de esta manera las pruebas manuales a las pruebas

automáticas, y de este modo ahorrando tiempo y recursos que podrán ser utilizados en otras actividades o

proyectos.

3. METODOLOGIA

La metodología para emplear en la presente investigación será de tipo: bibliográfico y empírico. Por

tanto, el desarrollo del proyecto se agrupará en:

➢ Método bibliográfico
➢ Método empírico o de campo

3.1 METODO BIBLIOGRAFICO

Nos referimos a revisiones bibliográficas y de fuentes electrónicas sobre los ejes conceptuales

fundamentales del proyecto (Reglas de Negocio y Automatización de Pruebas). Para ello, se utilizarán

fuentes secundarias, las cuales servirán como soporte teórico y documental sobre el uso de

automatización de pruebas.

3.2 METODO ANALITICO

Se realizarán actividades relacionadas con:

La selección del motor de reglas de negocio y el framework de automatización de pruebas.

La creación de una arquitectura candidata para la integración del motor de reglas y el framework de

automatización.

El análisis del Software caso de estudio sobre el cual se va a aplicar la arquitectura propuesta.

La aplicación de la arquitectura candidata sobre el Software caso de estudio (es decir, la construcción del

prototipo)

10
4. SELENIUM Y EL PATRON PAGE OBJECT PARA PRUEBAS AUTOMATIZADAS

4.1 SELENIUM ANTECEDENTES

En 2004, el probador Jason Higging estaba probando una aplicación interna de ThoughtWorks (empresa

que tiene como foco desarrollo ágil de software), cuando percibió que podría gestionar mejor su tiempo

en las actividades de prueba manuales. Para ello, creó una biblioteca Javascript que interactuaba con el

navegador, que pronto pasaría a interactuar con otros navegadores. A este proyecto se le concedió el

nombre de Selenium que en realidad, se trata de una analogía sobre una herramienta de prueba alternativa

para probadores que ya no soportan más dependen de la herramienta Quick Test, de la empresa Mercury,

que por señal era pagada y muy cara. En la química, el antídoto del Mercurio es el Selenio. Está ahí, el

porqué del nombre. En el año 2006, el ingeniero de Google llamado Simon Stewart decidió explorar aún

más la biblioteca Selenium, creando así el proyecto WebDriver, donde acabó mezclándose con la antigua

biblioteca (Selenium RC), dando origen a la segunda versión del Selenium en 2008 . Hoy, Selenium es

una suite compuesta por las herramientas: Selenium IDE, Selenium Remote Control, Selenium

WebDriver y Selenium Grid. Cada uno con una finalidad, pero con objetivos en común, que es garantizar

la automatización de las pruebas funcionales de forma práctica y eficiente.

4.2 SELENIUM 1.0

Selenium nace con el objeto de ofrecer una librería de funciones, que permita automatizar pruebas de

interfaz de usuario sobre aplicaciones web. El concepto es sencillo, un test escrito en un lenguaje de alto

nivel, haciendo uso de API ofrecida por selenium, es capaz de interactuar con una aplicación web

(WAUT -Web App under Test) a través de un navegador, de forma similar a como lo haría un usuario real

Selenium 1.0 o Selenium RC (Remote Control) es la primera versión de selnium. Desde el punto de vista

técnico, Selenium RC utiliza dos componentes, Selenium Remote Control Server y Selenium Core. Estos

dos componentes se comunican entre si mediante una serie de comandos llamados “selenese commands”

11
Selenium Core, por su parte es un componente escrito en JavaScript que ejecuta dentro del navegador y se

encarga de ir dirigiendo la navegación sobre WAUT.

Por otro lado, Selenium RC server es el encargado de inyectar el código de Selenium Core en el

navegador y traducir las funciones de librería a comandos que intercambia con Selenium Core (Selenese

Commands) para dirigir la navegación sobre una determinada WAUT.

Figura1:Selenium1.0

Fuente: Testing y calidad de software. Automatización de pruebas con Selenium WebDriver

En el diagrama anterior, el navegador interpreta que el código JavaScript del componente Selenium Core

pertenece a un dominio diferente al código que compone la WAUT, por lo que realiza su ejecución de

manera aislada, no permitiendo la interacción entre ambos.

12
4.3 SELENIUM 2.0

La primera versión de Selnium fue un buen punto de partida en el camino de la automatización de pruebas

funcionales sobre aplicaciones web, evolucionando de esta manera a Selenium 2.0 o Selenium WebDriver

debido a algunas limitaciones que tuvo la anterior versión

Figura2:Selenium2.0

Fuente: Testing y calidad de software. Automatización de pruebas con Selenium WebDriver

Selenium WebDriver emplea implementaciones nativas específicas para cada navegador, evitando

limitaciones que suponía el uso de código JavaScript para dirigir las acciones sobre la WAUT.

Cada implementación particular de WebDriver maneja instrucciones nativas de un navegador especifico,

manteniendo una interfaz de acceso común que permite a un script escrito en un lenguaje de alto nivel

13
simular diferentes acciones sobre una página web, siendo transparente para el en que navegador se

ejecuten.

4.4 AUTOMATIACION DE PRUEBAS

¿Por qué puede ser necesaria la automatización de pruebas?

Suponiendo que un equipo de desarrollo de software tiene listo el primer prototipo de una aplicación web.

El equipo de calidad de software realiza un análisis sobre la validación y verificación de software con los

distintos escenarios posibles, mostrando resultados astronómicos.

Figura3: Tabla Ejemplo

Fuente: Testing y calidad de software. Automatización de pruebas con Selenium WebDriver

¿Cuál sería la solución para ello? ¿Recorte de numero de pruebas? ¿Aumentar el tiempo de puesta en

producción de la aplicación?

Si se disminuye la cantidad de pruebas, podría suceder que no se detecten ciertos fallos o anomalías, lo

que conduciría a entrega de producto poco fiable. Por otro lado, si el tiempo necesario para alcanzar el

14
nivel de calidad deseado es muy elevado, puede provocar que los costes aumenten y que la viabilidad del

proyecto peligre.

Para esta situación una solución podría ser automatizar un porcentaje de los test, de forma que el tiempo

de ejecución de la fase de pruebas se redujese.

Otra forma donde la automatización es necesaria es cuando diferentes versione de un software van siendo

liberadas y las nuevas funcionalidades deben ser privadas en conjunto con las ya existentes, generándose

gran cantidad de pruebas de regresión y creando ciclos de pruebas cada vez mas grandes. Si las pruebas

que se deben ejecutar cada vez que se libera una versión están automatizadas la carga de trabajo para el

equipo de pruebas disminuyen considerablemente, pudiendo centra su esfuerzo sobre todo en las nuevas

funcionalidades.

¿Qué es automatización de pruebas?

Cuando se usa el termino automatizar, nos referimos a conseguir que las pruebas que se realizan de forma

manual pueden ser ejecutadas de forma desatendida (sin intervención de tester) por medio de alguna

herramienta que realice el proceso automáticamente.

4.4.1 NIVELES DE AUTOMATIZACION


Según la pirámide de Cohn descrita en su libro de “Succeding with Agile”, aparecen 3 niveles de

automatización, la automatización de los test unitarios, la de los test de aceptación y la de los test de

interfaz de usuario. Esta pirámide representa el esfuerzo o la cantidad de test automáticos que deberían

tener cada nivel, empezando por el más bajo, donde se debería concentrar el mayor número de test

automáticos, hasta llegar al tercer nivel, el de la interfaz de usuario, donde el número de pruebas, por la

complejidad debería ser menor

15
Figura4: Selenium UI test

Fuente: Testing y calidad de software. Automatización de pruebas con Selenium WebDriver

El conjunto de pruebas que nos ofrece Selenium sirve para cubrir toda la capa de automatización de nivel

3 (Interfaz de usuario) y la parte del nivel 2 (test de aceptación), de una aplicación web.

4.4.2 ¿Por qué usar Selenium?


Aunque ya existen diversas herramientas de automatización de prueba, Selenium se destaca por ser un

conjunto de herramientas, permitiendo al usuario probar las aplicaciones web en las más diversas formas

de automatización, como, por ejemplo: Cree y ejecute secuencias de comandos de prueba independiente

del explorador o sistema operativo. Realizar pruebas de carga / estrés mediante la ejecución de pruebas en

diversos navegadores, provenientes de uno o más ordenadores. Agregar complementos que permiten

elaborar scripts de pruebas robustos y que atienden las necesidades de los negocios. Integrar los scripts de

prueba a un proyecto de prueba, ya sea en Java, C #, PHP, Python o Ruby.

4.5 BENEFICIOS DE AUTOMATIACION DE PRUEBAS

La automatización de pruebas puede traer consigo una serie de beneficios que podrían ayudar a elevar el

nivel de calidad de producto software.

16
➢ Se puede ejecutar un número mayor de pruebas, Una vez que se ha automatizado un determinado
caso de pruebas, es fácil ejecutarlo n-veces variando los datos de entrada
Consecuencia: la cobertura aumenta, se prueban muchas más combinaciones, aumentando el
nivel de fiabilidad de producto
➢ Se puede ejecutar pruebas de forma desatendida, la ejecución se puede lanzar a cualquier hora del
día
Consecuencia, se reduce el tiempo de la fase de ejecución de pruebas. Menor coste
➢ Reducción de errores durante la ejecución de las pruebas, una prueba Automatizada se ejecuta
siempre de la misma manera, ya que en la ejecución manual se pueden cometer errores
dependiendo del nivel del tester
Consecuencia, aumenta la calidad de las pruebas
➢ Ayuda a estandarizar procesos, dependiendo del análisis de los procesos para la ejecución de
pruebas
➢ Facilita las pruebas de regresión, favoreciendo a las pruebas de regresión, ya que la repetición de
pruebas no supone una inversión grande de tiempo.
Consecuencia, se reduce el coste durante las fases de mejora o evolución del producto de
software.
También se debe tener en cuenta diversos factores antes de decidir si merece la pena invertir tiempo y

dinero en automatizar pruebas. Por ejemplo, el personal cualificado para automatización. La falta de

experiencia provocaría que la pruebas no estén bien diseñadas, que surjan problemas técnicos que alargue

el proceso de creación de los test automáticos, etc.

Otro problema puede venir de una mala decisión sobre lo que se automatizara y sobre lo que no Es

necesario saber bien dónde invertir los esfuerzos de automatización.

4.6 CLAVES PARA REALIZAR UNA AUTOMATIZACION PRODUCTIVA

Para conseguir el éxito del proyecto es elegir una buena estrategia de pruebas, Por ello, es necesario tener

en cuenta que:

➢ No todo se puede automatizar. Un proyecto realista podría ser entorno al 50% de las pruebas.
➢ Comenzar automatizando las tareas repetitivas más básicas que consumen una cantidad
significativa de tiempo
➢ La automatización se basa en la reutilización, si un test se diseña para ser ejecutado una sola vez,
no tiene sentido automatizarlo.
➢ Los test que utilizan múltiples valores para las mismas tareas también son buenos candidatos.
➢ En cada caso, es necesario realizar una valoración si realmente la automatización puede acarrear
algún beneficio frente al testing manual

17
➢ Los test con resultados NO predecibles deben ser descartados para el proceso de automatización.

4.7 HERRAMIENTAS DE AUTOMATIZACION

Con el auge que está tomando el desarrollo ágil de software, representado en marcos de trabajo como

Scrum, la Programación extrema (XP) y el Agile Testing, cada vez es más crítico contar con la

posibilidad de realizar constantes refactorizaciones e integraciones de código. La automatización de

prueba es ventajosa en situaciones en las cuales el software se modifica constantemente, dado que hasta

las modificaciones menores pueden ocasionar que funcionalidad ya desarrollada deje de funcionar.

4.7.1 Selenium
Es un framework para pruebas de aplicaciones Web, descargable de forma gratuita desde su sitio web.

Proporciona una herramienta de grabación y playback, que permite desarrollar pruebas sin necesidad de

aprender un lenguaje de Scripting. Incluye características como grabación, playback, selección de

campos, auto completar formularios, pruebas de recorrido (Walkthrough), debug, puntos de control,

scripts ruby y otros formatos.

4.7.2 HP Quicktest Professional (QTP)


Proporciona la capacidad de automatizar pruebas funcionales y pruebas de regresión para software y

ambientes de prueba. Proporciona la capacidad de definir Scripts de prueba y posee una interfaz gráfica

que le permiten al usuario emular la funcionalidad que desea probar, incluyendo el uso de interfaces de

usuario de las aplicaciones a probar. Incluye características como: Vista de experto, pruebas de procesos

de negocio, grabado de pantalla (para captura de las evidencias de prueba), entre otras posibilidades. HP

QTP forma parte de la solución de HP Quality Center (HP QC), aquí te dejamos un enlace a un artículo

de herramientas de gestión de calidad de software, que incluye HP QC.

18
4.7.3 Watir
Pronunciado “Water”, es una familia de librerías Ruby de Código Abierto (Open Source) para la

automatización de navegadores web. Le permite a su usuario escribir pruebas fáciles de leer y mantener.

Sencilla y flexible. Tiene la capacidad de hacer clic en enlaces, llenar formularios de pantallas con datos y

presionar botones. Watir también revisa los resultados, incluyendo verificar si los textos esperados se

muestran en las páginas. Tiene la capacidad de enlazarse con bases de datos, leer archivos de datos y

hojas de cálculo, exportar XML y estructurar los códigos como librerías reutilizables.

4.7.4 Visual Studio Test Proffessional


Conjunto de herramientas de pruebas integradas desarrolladas por Microsoft, que proporcionan soporte a

todo el ciclo de planificación, ejecución y registro de pruebas, con facilidades de colaboración entre

analistas de prueba (testers) y desarrolladores en la herramienta. Proporciona capacidad de realizar

pruebas manuales, reutilización de pruebas manuales, integración con el “team foundation server”,

gestión de ciclo de vida de aplicaciones, entre otros.

4.7.5 Rational Functional Tester


Herramienta de automatización de pruebas funcionales y de regresión. Proporciona capacidades de

pruebas de interfaz gráfica, pruebas manejadas por datos (Data Driven), pruebas funcionales y puebas de

regresión. Algunas de sus características son: Simplificación de creación y visualización de pruebas,

pruebas de tipo storyboards, trazabilidad en todo el ciclo de vida, validación de data dinámica (por medio

de un wizard), e inclusive capacidad de definir scripts (por medio de lenguajes de Scripting).

19
En la actualidad la automatización de pruebas resulta ser un componente importante dentro del ciclo de

desarrollo de software y más aún para el desarrollo de software ágil. Al ser un proceso automatizado

facilita realizar pruebas repetitivas, end to end en flujos de negocio, abarcando muchos escenarios, lo cual

es más complicado y más costoso cuando se lo realiza de forma manual. Selenium como herramienta es

de gran ayuda, ya que da una visión más amplia y permite detectar errores en fases tempranas del

desarrollo, tanto así, que, en ciclos de integración continua, con el uso de esta herramienta es posible

detectar errores antes de que los cambios sean liberados en ambientes de calidad, esto es favorable ya que

desde el área de control de calidad se generarían menos reprocesos.

La reducción considerable de errores en ambientes de calidad y productivos es significativa y por tanto el

costo de mantenibilidad es mucho menor. Las pruebas automatizadas facilitan realizar regresiones y

pruebas de integración muy fácil y repetitivamente

Page Object es el concepto básico en el que se basa este patrón es el de representar cada una de las

pantallas que componen el sitio web o la aplicación que nos interesa probar, como una serie de objetos

que encapsulan las características y funcionalidades representadas en la página. De esta manera, nos

permite consolidar el código para interactuar con los elementos de una página en cada uno de los Page

Object.

Al crear un Page Object, lo que estamos consiguiendo es crear una capa de abstracción entre el « ¿Qué

podemos hacer/ver en la página? », y el « Cómo » se realiza esta acción, simplificando enormemente la

creación de nuestras pruebas y reutilizando el código con el que interactuamos con la página en concreto.

Y a la vez, cualquier cambio que se produzca en la UI únicamente afectará al Page Object en cuestión, no

a los test ya implementados.

Esto se debe a que un test nunca debe manipular directamente elementos de la página (UI), si no que este

manejo debe realizarse a través del Page Object correspondiente que representa la página. Para

entendernos, el Page Object se convierte en una API con la que fácilmente podemos encontrar y

20
manipular los datos de la página. Básicamente se ha popularizado para mejorar el mantenimiento de las

pruebas y reducir el código duplicado.

Figura 5: Interacción de los Page Object

Fuente: https://qanewsblog.com/2014/08/07/patrones-de-diseno-en-automatizacion-page-objects

Se puede encontrar que una página corresponda a más de un Page Object, si se da el caso de que algunas

áreas de la página son lo suficientemente significativas. Por ejemplo, en una página web, podemos tener

un Page Object para el header y otro para el body.

Tratemos de simplificar aún más la definición, creamos los page objects para agrupar comportamientos

comunes y generar una capa de abstracción con la aplicación, con el objetivo de reducir el trabajo de

mantenimiento y que la estructura de los tests reduzca complejidad. Por eso, comúnmente se tiene un

Page object donde se agrupa aquellos métodos comunes a todas las páginas y luego vamos creando un

page object para cada grupo de elementos que se relacionen de alguna manera (ya sea una barra de menú

que se repite en varias páginas, una página con una funcionalidad específica, un popup que aparece en

varias páginas, etc.). Lo mismo se va a aplicar para los tests, ya que se puede centralizar en un TestPage

object todo lo relacionado a la configuración de los tests y métodos de validación/generación de datos.

5. PAGE OBJECT COMO PATRON DE DISEÑO

Los patrones de diseño son unas técnicas para resolver problemas comunes en el desarrollo de software y

otros ámbitos referentes al diseño de interacción o interfaces.

Un patrón de diseño resulta ser una solución a un problema de diseño. Para que una solución sea

considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su

21
efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo

que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias ya que algunos

conceptos en su gran mayoría se adecuan según el uso del desarrollo de software

5.1 PROBLEMA

Las pruebas automatizadas necesitan adaptarse a los cambios en la interfaz de usuario fácilmente

5.2 MOTIVACION

Las pruebas de automatización pueden necesitaran diversas interfaces de usuario para diferentes entornos
ya sea: como un sitio web normal en un navegador de escritorio y una versión móvil para un celular,
también utilizando los mismos datos de prueba para correr las pruebas en los distintos navegadores y
ambientes.

5.3 APLICABILIDAD

Crear una clase con métodos apropiados para cada página web o grupo de elementos de una página

(navegación principal, grilla de datos, etc.). Los métodos de la clase deben reflejar las operaciones de

interacción para la página en un nivel de negocio.

Además, cada clase debe proporcionar campos apropiados para cada elemento con que el usuario está

interactuando.

5.4 CONSECUENCIAS

Puede adaptar sus pruebas automatizadas a los cambios en la interfaz de usuario cambiando los Page

Object relacionados. Los Page Object nos proporcionan una capa para desacoplar los cambios en la

aplicación bajo los datos de prueba, cambiando asi la jerarquía Page Object para cada dispositivo o

diferentes entornos.

22
5.5 IMPLEMENTACION

Poner esfuerzo en el diseño de la jerarquía Page Object para reflejar el flujo de negocio a través de la

aplicación. Cuando el flujo a través de la aplicación cambia, es necesario cambiar el código que conecta

la representación textual de las pruebas y la jerarquía Page Object, esta jerarquía está estrechamente

unida a la forma de la aplicación diseñada. Si las páginas de la aplicación cambian de formato o

contenido, sus Page Object tendrán que cambiar de la misma forma.

Si los cambios no son realizados en los Page Object después de la actualización de una aplicación a

automatizar podrían surgir inconvenientes catastróficos deteniendo así la corrida de la automatización.

6. LA POSICION DE AUTOMATIZACION EN EL DESARROLLO DE SOFTWARE

El flujo contempla los siguientes pasos:

1. Inicio del Proyecto, el proyecto inicia con la solicitud del cliente y su necesidad de automatizar,

controlar y administrar procesos y tareas.

2. Análisis y Diseño, el equipo de gobierno electrónico interactúa directamente con el cliente, se encarga

de concertar reuniones, obtener insumos, elaborar el listado de requerimientos y en base a estos,

desarrollar historias de usuarios.

En esta etapa el equipo de QA realizará las siguientes tareas:

a) Verificación de Procesos del Negocio.

b) Validación de la Especificación de Procesos del Negocio.

c) Verificación de requerimientos.

3. Desarrollo, el equipo de desarrollo recibe los documentos generados en el paso anterior y a partir de

estos, elabora documentación técnica para el inicio del proyecto de software.

En esta etapa el equipo de QA realizará las siguientes tareas:

23
a) Verificación del Modelo de análisis.

b) Verificación del Diseño.

c) Revisión de los entregables semanales (Ejecución de pruebas de funcionalidad según los planes y las

tareas programadas para el entregable).

El equipo de QA también se apoyará en la integración continua para poder ejecutar los test y realizar el

análisis estático de código.

Integración continua, con el fin de tener software de calidad se implementará la integración continua, esto

permitirá minimizar los bugs en el producto final, calidad desde el inicio y adaptación al cambio. Este

proceso tendrá el siguiente flujo:

Figura 6: Retroalimentación

Fuente - https://gitlab.geo.gob.bo/bolivia-libre/bolivia-libre/blob/master/doc/diagrama-flujo-software.md

4. Puesta en producción, la puesta en producción del proyecto de software es obtenida de un tag de

GitLab, el pase a producción no es automático y debe ser autorizado por el personal encargado de esta

tarea.

5. Test de Aceptación, cuando el proyecto de software pasa a producción, se otorga al cliente un test de

aceptación, con el cual el cliente registra observaciones o indica su conformidad con el producto

elaborado.

24
El flujo presentado es cíclico y puede repetirse hasta obtener un producto de calidad.

Figura 7: Flujo de desarrollo y posición de prueba funcional

Fuente - https://gitlab.geo.gob.bo/bolivia-libre/bolivia-libre/blob/master/doc/diagrama-flujo-software.md

25
7. XML MAPEO DE DATOS ANTES DE LA AUTOMATIZACION

INTRODUCCION

XML, siglas en inglés de eXtensible Markup Language ('lenguaje de marcas extensible'), es un lenguaje

de marcas desarrollado por el World Wide Web Consortium (W3C). Deriva del lenguaje SGML y permite

definir la gramática de lenguajes específicos (de la misma manera que HTML es a su vez un lenguaje

definido por SGML) para estructurar documentos grandes. A diferencia de otros lenguajes XML da

soporte a bases de datos, siendo útil cuando varias aplicaciones se deben comunicar entre sí o integrar

información.

XML no ha nacido sólo para su aplicación en Internet, sino que se propone como un estándar para el

intercambio de información estructurada entre diferentes plataformas. Se puede usar en bases de datos,

editores de texto, hojas de cálculo y casi cualquier cosa imaginable.

XML es una tecnología sencilla que tiene a su alrededor otras que la complementan y la hacen mucho

más grande y con unas posibilidades mucho mayores. Tiene un papel muy importante en la actualidad ya

que permite la compatibilidad entre sistemas para compartir la información de una manera segura, fiable y

fácil. Para ejemplificar JSON volveremos a presentar ese archivo XML y luego el equivalente JSON, para

ver las diferencias entre ambos estándares de intercambio de datos.

Utilizando un ejemplo de un archivo XML. Para ejemplificar lo que es JSON y XML

Ejemplo de XML
<Clientes>
<Cliente ID="283">
<Nombre>Juan Carlos Crespin</Nombre>
<Direccion verificada="si">
<Calle>Avda Perú</Calle>
<Numero>235</Numero>
<Ciudad>Bahía Blanca</Ciudad>
<Provincia>Buenos Aires</Provincia>
<CodigoPostal>8000</CodigoPostal>
<Pais>Argentina</Pais>
</Direccion>

26
</Cliente>
</Clientes>

Equivalente en JSON
{
"Clientes": {
"Cliente": {
"-ID": "283",
"Nombre": "Juan Carlos Crespin",
"Direccion": {
"-verificada": "si",
"Calle": "Avda Perú",
"Numero": "235",
"Ciudad": "Bahía Blanca",
"Provincia": "Buenos Aires",
"CodigoPostal": "8000",
"Pais": "Argentina"
}
}
}
}
Con la existencia de Librerías hace fácil el manejo de datos, entre ellas Castor como librería genera una

mayor posibilidad de adaptación para el manejo de flujo de datos.

Previamente tomemos en cuenta algunos detalles:

Marshalling: Significa crear un documento XML desde un árbol de contenido (En nuestro caso el árbol

del contenido sería un Objeto Java).

Unmarshalling: Significa crear un árbol de contenido desde un documento XML.

Básicamente esto sería serialización y deserialización.

La asignación de Castor XML es una forma de simplificar el enlace de las clases java al documento

XML. Permite transformar los datos contenidos en un modelo de objeto java en / desde un documento

XML.

Aunque es posible confiar en el comportamiento predeterminado de Castor para reunir y desmarcar

objetos Java en un documento XML, puede ser necesario tener más control sobre este comportamiento.

27
Por ejemplo, si ya existe un modelo de objetos Java, Castor XML puede usarse como un puente entre el

documento XML y ese modelo de objetos Java.

Castor le permite a uno especificar algunos de sus comportamientos de ordenación / improvisación

utilizando un archivo de mapeo. Este archivo proporciona información explícita a Castor sobre cómo un

determinado documento XML y un conjunto determinado de objetos Java se relacionan entre sí.

Un archivo de mapeo de Castor es una buena manera de realizar los cambios en la estructura de un

modelo de objetos Java de los cambios en el documento XML correspondiente.

La información de mapeo es especificada por un documento XML. Este documento está escrito desde el

punto de vista del objeto Java y describe cómo las propiedades del objeto deben traducirse a XML. Una

restricción para el archivo de mapeo es que Castor debería poder inferir de forma inequívoca de cómo un

elemento / atributo XML dado, debe ser traducido al modelo de objeto durante la creación de un árbol de

contenido de un documento XML.

El archivo de asignación describe para cada objeto cómo cada uno de sus campos debe asignarse a XML.

Un campo es una abstracción para una propiedad de un objeto. Puede corresponder directamente a una

variable de clase pública o indirectamente a una propiedad a través de algunos métodos de acceso (setters

y getters).

Es posible usar el mapeo y el comportamiento predeterminado de Castor en conjunto: cuando Castor tiene

que manejar un objeto o datos XML pero no puede encontrar información al respecto en el archivo de

mapeo, se basará en su comportamiento predeterminado. Castor utilizará la API de Java para examinar los

objetos de Java y determinar qué hacer.

28
Nota: Castor no puede manejar todas las asignaciones posibles. En algunos casos complejos, puede ser

necesario confiar en una transformación XSL junto con Castor para adaptar el documento XML a un

formato más amigable.

7.1 CASTOR

Castor XML es un "XML data binding framework" de código abierto bastante veterano pero que aún

sigue dando guerra y que permite mapear los datos contenidos en objetos Java a documentos XML y

viceversa. Castor XML realiza mapeo o binding de forma automática y sin necesidad de tener que escribir

una sola línea de código más allá de las necesarias para utilizar el propio framework. Asimismo, el mapeo

realizado por Castor XML es configurable, e incluso podemos generar un modelo de clases que represente

la estructura definida en un esquema.

7.2 MARSHALLING

Para Castor, una clase Java tiene que asignarse a un elemento XML. Cuando Castor maneja un objeto,

será:

➢ Usar la información de mapeo, si la hay, para encontrar el nombre del elemento a crear o por
defecto, crea un nombre usando el nombre de la clase

Luego utilizará la información de los campos del archivo de mapeo para determinar cómo una propiedad

dada del objeto debe traducirse en uno y solo uno de los siguientes:

➢ Un atributo
➢ Un elemento
➢ Contenido del texto
➢ Nada, ya que podemos optar por ignorar un campo particular.

29
Este proceso será recursivo: si Castor encuentra una propiedad que tiene un tipo de clase especificado en

otro lugar en el archivo de mapeo, usará esta información para calcular el objeto.

De manera predeterminada, si Castor no encuentra información para una clase dada en el archivo de

mapeo, inspeccionará la clase y aplicará un conjunto de reglas predeterminadas para adivinar los campos

y ordenarlos. Las reglas predeterminadas son las siguientes:

➢ Todos los tipos primitivos, incluidos los envoltorios de tipos primitivos (Boolean, Short, etc.) se
clasifican como atributos.
➢ Todos los demás objetos se agrupan como elementos con contenido de texto o contenido de
elementos.

7.3 UNMARSHALLING

Cuando Castor encuentra un elemento al desmontar un documento, intentará utilizar la información de

mapeo para determinar qué objeto crear una instancia. Si no hay información de mapeo presente, Castor

usará el nombre del elemento para intentar adivinar el nombre de una clase para crear una instancia (por

ejemplo, para un elemento llamado 'test-element', Castor intentará crear una instancia de una clase

llamada 'TestElement 'si no se proporciona información en el archivo de mapeo). Castor utilizará la

información de campo del archivo de mapeo para manejar el contenido del elemento.

Si la clase no se describe en el archivo de mapeo, Castor realizará una inspección de la clase utilizando la

API de Java para determinar si existe alguna función de la forma getXxxYyy () / setXxxYyy (<type> x).

Este elemento de acceso se asociará con un elemento / atributo XML denominado 'xxx-yyy'. En el futuro,

proporcionaremos una forma de anular este comportamiento predeterminado.

Castor realizará una introspección de las variables de objeto y utilizará el acceso directo _only_ si no se

han encontrado métodos get / set en la clase. En este caso, Castor buscará variables públicas de la forma:

30
public <type> xxxYYY;

Y se espera un elemento / atributo llamado 'xxx-yyy'. Las únicas colecciones manejadas para <type> son

java.lang.Vector y array. (Hasta la versión 0.8.10)

Para el <type> primitivo, Castor buscará primero un atributo y luego un elemento. Si <type> no es un tipo

primitivo, Castor buscará primero un elemento y luego un atributo.

7.3 ARCHIVOS DE MAPEO

Esta sección define un modelo de dominio al que se hará referencia mediante varios archivos de mapeo

(fragmentos / muestras) en las siguientes secciones

Estructura que debería al menos tener durante antes del mapeo realizado con Castor

Figura 8: Mapeo de clases

Fuente: propio

31
Figura 9: Clases

Fuente: propio

Figura 10: Maping requerido por castor

Fuente: propio

32
8. INTERACION DE XML CON SPRING

Al utilizar las librerías de Spring, además de ello por ser código libre para la plataforma Java, por lo tanto,

cualquier sistema operativo con una máquina virtual de java puede ejecutar aplicaciones desarrolladas con

este framework. Debido al aumento de la complejidad que presentan la mayoría de los sistemas web,

tanto en temas de seguridad, funcionalidad y gráficas, la comunidad de desarrolladores se vio en la

necesidad de diseñar ciertas ayudas, a fin de no tener que repetir código, reduciendo de este modo el

tiempo y el espacio para el desarrollo de aplicaciones.

8.1 SPRING FRAMEWORK

Escrito inicialmente por Rod Johnson, fue lanzado por primera vez en el mes de Junio del año 2003 bajo

la licencia Apache 2.0, siendo una plataforma Java de código abierto. Convirtiéndose desde entonces en el

framework más popular para Java empresarial, para crear código de alto rendimiento, liviano y

reutilizable. Ya que su finalidad es estandarizar, agilizar, manejar y resolver los problemas que puedan ir

surgiendo en el trayecto de la programación.

Spring se puede considerar como el padre del los frameworks Java, ya que da soporte a varios

frameworks como: Hibernate, Struts, Tapestry, EJB, JSF, entre otros.

8.2.1 CARACTERISTICAS

Mencionaremos algunas características sobresalientes

➢ Acceso a datos: soporte DAO, JDBC, ORM, Marshalling XML.


➢ Pruebas (Testing): simulacro de objetos, el framework TestContext.
➢ MVC (Modelo Vista Controlador).
➢ Seguridad.
➢ La Inyección de Dependencias: Al momento de escribir una aplicación Java compleja, las clases
de la aplicación deben ser lo más independientes posible de otras clases Java, para aumentar la
posibilidad de reutilizarlas y probarlas independientemente de otras clases, mientras se prueban
las unidades. Básicamente la inyección de dependencias (DI) ayuda a unir estas clases y al mismo
tiempo mantenerlas

33
8.2.1 BENEFICIOS AL UTILIZAR SPRING

Algunos aspectos de la utilización de Spring

➢ Spring está organizado de forma modular. A pesar de la cantidad de paquetes y clases que tiene,
solo debemos ocuparnos de aquellos que necesitemos para nuestro desarrollo e ignorar el resto.
➢ Probar una aplicación escrita con Spring es un proceso simple, porque el código dependiente del
entorno se traslada a este framework. Además, mediante el uso de JavaBeanstyle, se vuelve más
fácil utilizar la inyección de dependencia para hacer pruebas, para ello podemos hacer uso de
datos dummies o mocks, para ver las respuestas.
➢ Spring proporciona una API para traducir excepciones específicas de la tecnología (como por
ejemplo las generadas por JDBC, Hibernate o JDO) en excepciones consistentes y no verificadas.

8.2 RESULTADO ESPERADO

A partir de una aplicación base para el proyecto que contenga características similares para el entorno de
automatización tales como:
La ejecución de archivos .xml para este caso será utilizados: castor-xml ,jackson-data-format en esta
librería con alta gama de manejo de xml

Con la captura de datos por parte del usuario e interacción de la misma generamos una visualización de la
estructura del archivo .xml utilizando la estructura más utilizada divida por capas modelo, repositorio,
servicio y controladores
• Mapping
• Librerías (modelos, servicios y controladores)

Mapping: La librería castor en la cual se encarga de generar una estructura definida es esta la razón por la
cual generamos una estructura específica, de tal manera que sea el resultado esperado para la interacción
final para la obtención de datos

34
Figura 11: Resultado generado por Castor

Fuente: propio

35
10. CONCLUSIONES

El formato para intercambio de información JSON cada vez se ha vuelto más popular en determinado

documento de XML. Muchos servicios web siguen trabajando con XML, pero muchos otros ya lo hacen

sólo con JSON. Podemos vernos en la necesidad de convertir XML utilizando Castor como intermedio y

llevarlo a JSON, dependerá mucho de como este la arquitectura del mapeo para llevarlo así a una

estructura JSON, caso contrario se deberá realizar una serie de cambios dentro de lo que es el mapeo de

Castor.

El resultado generara una estructura cuyo valor es un archivo. JSON puesto que el resultado esperado, lo

de Selenium actuara como parte complementaria de lo que es Automatización desde un archivo .XML.

Ventajas: en algunas empresas aún se sigue utilizando JSON como raíz para la ejecución de

automatización, y la ejecución de este archivo será de vital importancia debido a que la estructura de al

archivo JSON será generado desde un archivo XML (este archivo contiene la estructura de los diferentes

tipos de aplicaciones), es decir la estructura del JSON podrá generarse desde un archivo XML y será

como mejora para el área de automatización.

Las horas hombre dependerá del contenido y estructura del archivo XML.

36
11. BIBLIOGRAFIA

https://castor-data-binding.github.io/castor/reference-guide/reference/xml/xml-mapping.html

http://adrianmoya.com/2013/09/aplicando-el-patron-page-object-en-la-automatizacion-de-

escenarios/#sthash.9AbWrUqL.58Alj64a.dpbs

https://gitlab.geo.gob.bo/bolivia-libre/bolivia-libre/blob/master/doc/diagrama-flujo-software.md

http://www.javiergarzas.com/2015/01/automatizacion-pruebas.html

http://castor-data-binding.github.io/castor/

https://www.oracle.com/technetwork/es/articles/java/api-java-para-json-2251318-esa.html

Tesis: Estrategia Operativa para pruebas de Automatización y Rendimiento

Tesis: Testing y calidad de software. Automatización de pruebas con Selenium WebDriver

37