Está en la página 1de 48

UNIVERSIDAD MAYOR DE SAN SIMON

FACULTAD DE CIENCIAS Y TECNOLOGIA


DIRECCIÓN DE POSGRADO

“COMO HACER UN MARCO DE TRABAJO DE


PRUEBAS AUTOMATIZADAS USANDO
DOCKER”

TRABAJO FINAL PRESENTADO PARA OBTENER EL CERTIFICADO DE


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

POSTULANTE : ANGHELA B. ANZALDO CADIMA.


TUTOR : Msg. VALENTIN LAIME ZAPATA.

Cochabamba – Bolivia
2018
Agradezco a mi Familia, en especial a mis

padres por el apoyo incondicional y la fe que

han tenido en mi persona para cumplir esta

meta.
ii
Tabla de Contenido

RESUMEN 7

INTRODUCCIÓN 8

1. ANTECEDENTES 9

1.1 Antecedentes Generales 9

1.2 Antecedentes Específicos 9

2 METODOLOGÍA 10

2.1 Método Bibliográfico 10

2.2 Método Analítico 10

3 PRUEBAS 10

3.1 Pruebas de Software 10

3.1.1 Niveles de Pruebas 11

3.1.1.1 Pruebas Unitarias 11

3.1.1.2 Pruebas de Integración 12

4 AUTOMATIZACIÓN DE PRUEBAS 14

4.1 Frameworks de Automatización 14

4.2 Enfoques de diseño de Frameworks de Automatización 15

3
4.2.1 Page Object 15

5 HERRAMIENTAS DE AUTOMATIZACIÓN 16

5.1 Herramientas para pruebas estáticas o de calidad del Producto de Software 16

5.2 Herramientas para la planificación y gestión de pruebas 16

5.3 Herramientas para pruebas funcionales o de automatización 18

5.3.1 Prueba Funcional 18

5.3.1.1 De pago 18

5.3.1.2 Gratuitas Open Source 18

5.3.1.3 Selenium 19

5.4 Herramientas para pruebas carga 20

5.5 Conceptos para usar Pruebas automatizadas 21

6 VIRTUALIZACIÓN DE MÁQUINAS VIRTUALES 22

6.3 Diferencia entre un Contenedor y Máquina Virtual. 23

6.3.3 Docker 24

6.3.4 Arquitectura de Contenedores Docker 26

6.3.5 Descripción de Las imágenes como aplicaciones 26

6.4 Imágenes de Contenedores 27

7 MARCO DE TRABAJO DE PRUEBAS AUTOMATIZADAS CON DOCKER 30

4
7.1. Selenium Grid 31

7.1.1. Arquitectura de Selenium Grid 31

7.1 Flujo del Marco de Trabajo 34

7.1.1 Selección la Página web Objeto para el proyecto de Automatización de pruebas 34

7.1.2 Selección del Proyecto de automatización de pruebas web 36

7.1.3. Como montar Selenium Grid con Docker 37

7.1.3.1 Pasos de Selenium Grid con Docker: 38

CONCLUSIONES 46

BIBLIOGRAFÍA 48

5
Tabla de Cuadros, Gráficos y Figuras

Figura 1: Niveles de Pruebas 11

Figura 2 : Modelo en V 13

Figura 3 : Suite de Selenium 20

Figura 4 : Diferencia entre un Contenedor vs. Máquina Virtual 24

Figura 5 : Arquitectura Mínima de Docker 24

Figura 6 : Arquitectura de Aplicaciones en Contenedores 26

Figura 7 : Página oficial de Docker Hub 27

Figura 8 : Página oficial de Docker Hub 28

Figura 9 : Fichero Docker file de una Imagen Base para Linux 29

Figura 10 : Construcción de una Imagen Base para uno de los contenedores 29

Figura 11 : Lista de Imágenes resultado del comando Docker images 30

Figura 12 : Arquitectura Selenium Grid 32

Figura 13 : Ejecución de pruebas en Paralelo 33

Figura 14 : Arquitectura de Selenium Grid con Docker 34

Figura 15 : Page Object sobre una Pagina Web 35

Figura 16 : Patrón de Diseño Modelo Page Object 35

Figura 17 Page Model sobre el proyecto a ser automatizado 37

Figura 18 : Imágenes para descargar y tenerlas en contenedores Docker 38

Figura 19 Archivo Docker-Compose .yml 44

6
RESUMEN

El presente documento muestra las directrices para la creación de un marco de trabajo (Framework)
para realizar las pruebas automatizadas de un sistema de desarrollo de Software utilizando
contenedores Docker.

Una de las ventajas de las pruebas automatizadas es la reducción costo-beneficio, puesto que este
tipo de pruebas requieren de la mínima interacción entre el ingeniero de control de calidad y el
producto de software a hacer validado.

Se realizará un análisis de las herramientas más utilizadas en las pruebas automatización, se hará
énfasis en el Framework Selenium Grid, Docker para realizar la integración, para esto
aprovecharemos todas las ventajas que tiene a disposición los contenedores. Como se ha
mencionado anteriormente el presente trabajo será una guía para realizar el marco de trabajo y no
así una descripción de un trabajo de software desarrollado.

7
INTRODUCCIÓN

Una de las principales dificultades a la hora de empezar a estructurar las soluciones para las
pruebas automatizadas es tener las directrices establecidas, es decir, por dónde empezar, que usar,
y en que entorno de pruebas de software para aplicaciones basadas en la web apoyarse.

Por tal motivo se ve conveniente crear un Marco de Trabajo para gestionar esas pruebas
automatizadas combinando las tecnologías Open Source y las herramientas más populares en el
ámbito del Software actual.

Se analizará las principales características de Selenium Grid para automatizar la aplicación


utilizando los diferentes navegadores existentes en el mercado y mediante estas realizar las pruebas
sobre las aplicaciones web, ya que todas las tareas repetitivas a través del navegador pueden y
deben automatizarse para reducir los tiempos de ejecución de pruebas. El presente trabajo dará
un conjunto de directrices utilizando metodologías y set de las herramientas Open Source más
utilizadas para llevar a cabo la automatización de pruebas funcionales en productos con interfaz
web.

El Framework no es una guía de cómo desarrollar un producto de software, es más un análisis de


carácter investigativo.

8
1. ANTECEDENTES

1.1 Antecedentes Generales

La Ingeniería de calidad en el proceso de Ingeniería de Software se define como “Proceso eficaz


de software que se aplica de manera que crea un producto útil que proporciona valor medible a
quienes lo producen y a quienes lo utilizan.” (Pressman,2000).

La automatización de las pruebas funcionales reduce significativamente el esfuerzo dedicado a los


distintos tipos de prueba en productos que se encuentran en continuo desarrollo y/o mantenimiento.
En estos días en los que la transformación digital es una prioridad para la mayoría de las empresas,
es muy probable que los contenedores sean la tecnología más atractiva para dar agilidad y
automatización a los negocios; sin embargo, los contenedores pueden ser un concepto “nuevo” o
desconocido.

Como objetivo es el de facilitar la distribución de los entornos para el desarrollo de pruebas


automatizadas que sean homogéneos y puedan desplegarse independientes del entorno en que se
ejecutan utilizando todas las características y ventajas que nos ofrece los contenedores Docker.
Entre la principal podemos destacar la capacidad de encapsular todo el entorno de trabajo de
manera que los ingenieros de calidad puedan realizar sus trabajos de manera local con la seguridad
de que al desplegar en diferentes entornos va a continuar ejecutándose con la misma configuración
del marco de trabajo con la que se diseñó. De esta forma se reduce los tiempos de testeo y
adaptaciones al hardware con los que se dispone en los entornos.

1.2 Antecedentes Específicos

Extender y aprovechar la capacidad de las pruebas de automatización utilizando características


avanzadas de Selenium Grid dentro de contenedores Docker.

9
2 METODOLOGÍA

Para la siguiente monografía se usaran los siguientes métodos de investigación.

2.1 Método Bibliográfico, debido a que se realizara la lectura y compilación de libros


relacionados al tema de estudio.

2.2 Método Analítico, debido a que se procederá a revisar y analizar ordenadamente


documentos relacionados al tema de estudio, para la redacción de esta monografía.

3 PRUEBAS

A continuación, se hará una revisión, análisis de las pruebas y pruebas automatizadas.

3.1 Pruebas de Software

Se define como fase de pruebas del ciclo de vida del Software como “un proceso o una serie
de procesos diseñados para asegurar que el código cumple para lo que está diseñado y no
haga nada de forma involuntario” (Myers y Sandler, 2004). De esta forma se toman datos de
ejemplo de entrada, y se plantean salidas esperadas de acuerdo a los requerimientos. Para hacer
esta fase de forma correcta, se recomienda responder las siguientes preguntas (Black,2009):

 ¿Que podría probar?


 ¿Qué debería probar?
 ¿Qué puedo probar?

En lo que se podría probar, debería existir el enfoque racional enfocado en probar el software con
el fin de buscar errores durante su ejecución más que crear casos de prueba para todas las posibles
entradas y salidas que es impráctico, y requeriría de muchos recursos humanos para ser
económicamente factible (Myers y Sandler, 2004).

10
En cuanto a lo que se debería probar, el enfoque está en identificar aquellos errores o bugs que
afecten la experiencia del cliente respecto a la calidad del producto. Los enfoques de pruebas
deberían enfocarse a encontrar los defectos críticos que limitan la habilidad de los usuarios de
llevar a cabo su trabajo usando el software desarrollado (Black, 2009).

Respecto a lo que se puede probar, es revisar el recurso humano, financiero y de tiempo con el que
se cuenta para realizar pruebas, y verificar que tanto de lo que “se debería probar” se puede realizar
con los recursos disponibles.

3.1.1 Niveles de Pruebas

Existen 4 niveles de pruebas en la fase de la ejecución de las pruebas, las cuales dependen de la
fase en la cual se encuentra en ejecución el proyecto de software (Black, 2009). Ilustrados en la
siguiente figura:
Niveles de Pruebas

Figura 1: Niveles de Pruebas


(Fuente: Black,2009)

Donde se describe de la siguiente manera:

3.1.1.1 Pruebas Unitarias


Como la unidad más pequeña del software que se puede probar tales como procedimientos y
funciones, clases y sus métodos (Burnstein, 2010).
11
3.1.1.2 Pruebas de Integración
Con el objetivo de detectar defectos que pueden suceder en las interfaces de las unidades de
software una vez que se ponen en funcionamiento con otras unidades, y estas a su vez se conviertan
en subsistemas funcionales posteriormente para ser probados en las pruebas de sistema (Burnstein,
2010).

3.1.1.3 Pruebas de Sistema

Tiene la meta de verificar que el sistema se comporta de acuerdo a los requerimientos. Evalúa
tanto funcionalidad como atributos de calidad tales como: confiabilidad, usabilidad, rendimiento
y seguridad.

3.1.1.4 Pruebas de Aceptación

Se las define así: “Las pruebas de aceptación, también llamadas pruebas del cliente, son
especificadas por el cliente y se centran en las características y funcionalidad generales del sistema
que son visibles y revisables por parte del cliente”. Lo hacen los usuarios finales en conjunto con
los ingenieros de calidad, con el fin de verificar que sus requerimientos y expectativas hayan sido
cumplidas en el producto final (Pressman,2010).
En la figura siguiente se ilustra el modelo en V (Pressman,2010).

12
Acciones para asegurar la calidad

Figura 2 : Modelo en V
(Fuente: Pressman,2010)

Donde se ve la relación entre las acciones para el aseguramiento de la calidad y aquellas asociadas
con la comunicación, modelado y construcción temprana. A medida que el equipo de software
avanza hacia abajo desde el lado izquierdo de la V, los requerimientos básicos del problema
mejoran hacia representaciones técnicas cada vez más detalladas del problema y de su solución.

Una vez que se ha generado el código, el equipo sube por el lado derecho de la V, y en esencia
ejecuta una serie de pruebas (acciones para asegurar la calidad) que validan cada uno de los
modelos creados cuando el equipo fue hacia abajo por el lado izquierdo.

13
4 AUTOMATIZACIÓN DE PRUEBAS
Se define como “el uso de software para controlar la ejecución de pruebas, la comparación de las
salidas actuales con salidas predichas, la configuración de las precondiciones, y otras funciones de
control y reportes” (Amaricai y Constantinescu, 2014). Entonces las pruebas automatizadas
generan como resultado scripts que a su vez generan reportes sobre la efectividad de las pruebas
ejecutadas sobre el Software Bajo Prueba (Software Under Test SUT).

El uso de la automatización de pruebas ayuda en gran medida al personal de Calidad ya que con
el uso de test automáticos ellos podrán dedicar más tiempo a escribir más casos de prueba para
cubrir más aspectos del sistema, y delegar el tema de validación y evaluación a los scripts de
prueba (Yu y Patil,2007), el uso de los scripts de prueba mejora la calidad de las pruebas, originado
por la mínima intervención humana que requieren durante su ejecución (Gojare, Joshi y
Gaigaware, 2015).

Entre otras ventajas de la automatización de pruebas se encuentra (Joy y Singh, 2015):


 Optimización de velocidad, eficiencia y calidad del Software bajo prueba
 Costo reducido en la ejecución de prueba manuales
 Mayor retorno a la inversión

Las pruebas automatizadas tienen el mismo carácter y estructura que un proyecto normal de
software. De ahí que requiera características tales como manejo externo de archivos, interacción
con interfaz de usuario y manejo de plantillas de casos de pruebas. Para la administración de cada
uno de los artefactos que participan en la automatización de pruebas, surge como respuesta la
creación de Frameworks de Automatización.

4.1 Frameworks de Automatización


Un framework de automatización está definido como un “conjunto de conceptos, procesos,
procedimientos y entornos abstractos en los cuales los test automáticos son diseñados, creados e
implementados” (Amaricai y Constantinescu, 2014, pág. 2). Además, un framework proporciona
“guías, estándares de código, (…), practicas, jerarquías de código, modularidad y mecanismos de

14
reporte” (Joy y Singh. 2015. Pag 1) a los ingenieros y personas encargadas de la implementación
de la automatización de pruebas.

La funcionalidad central de estos frameworks va enfocada a generar logs y reportes de la ejecución


de los scripts de automatización, además de permitir extender su funcionalidad agregando librerías.

Como ventajas del uso de un Framework de automatización de pruebas (Joy y Singh, 2015)
Están las siguientes:
 Reusabilidad del código
 Costo mínimo de mantenimiento
 Intervención manual mínima
 Facilidad en la generación de reportes

Los frameworks se diseñaron teniendo en cuenta los aspectos que se requieren para probar una
aplicación de forma automática, a saber, (Amaricai y Constantinescu, 2014, pág. 2):

 Caso de prueba o flujo de prueba


 Script de prueba
 Datos de prueba
 Localizadores, que son todos aquellos identificadores que permiten ubicar en la interfaz
gráfica elementos como botones, cuadros de texto, etc. haciendo uso de estilos CSS o
Html5.

Es importante escoger un enfoque de diseño que permita implementar el tipo de framework


escogido.

4.2 Enfoques de diseño de Frameworks de Automatización


4.2.1 Page Object
El enfoque de diseño más popular es Page Object, el cual se encuentra dentro de la clasificación
de orientados por palabras clave. Dicha implementación permite que las pruebas puedan acceder

15
a funcionalidades del Software bajo prueba a través de funciones sencillas de una clase, y dichos
métodos contienen a su vez las acciones que se deben realizar sobre la interfaz gráfica para lograr
el objetivo de la función/método invocado (Amaricai y Constantinescu, 2014).

Ventaja de la metodología Page Object:


 Cualquier cambio en el Software bajo prueba solo requerirá modificación de la clase que
implementa el diseño y no de los test.

Desventaja:
 Requiere de ingenieros de calidad que tengan cierto nivel de programación, además de que
su tiempo de mantenimiento incrementa de manera lineal.

A pesar de ello Page Object al día de hoy se ha convertido en la implementación más extendida en
varios Frameworks reconocidos.

5 HERRAMIENTAS DE AUTOMATIZACIÓN
Las herramientas para la automatización de pruebas funcionales para aplicaciones web permite:
- Crear pruebas de regresión
- Probar la aplicación con diferentes navegadores y sobre diferentes plataformas

El número de herramientas para la automatización de pruebas sobre páginas webs se pueden


clasificar en varias categorías dependiendo del uso que se pueda hacer de ellas:

5.1 Herramientas para pruebas estáticas o de calidad del Producto de Software


(PMD, CheckStyle, SonarQube, Simian)

5.2 Herramientas para la planificación y gestión de pruebas


Gratuitas Open Source
 Bugzilla Testopia,
 FitNesse,qaManager,

16
 qaBook,RTH (open source),
 Salome-tmf,
 Squash TM,
 Test Environment Toolkit,
 TestLink
 Testitool,
 XQual Studio,
 Radi-testdir,
 Data Generator

De pago
 (HP Quality Center/ALM,
 QA Complete,
 qaBook,
 T-Plan Professional,
 SMARTS,
 QAS.
 Test Case Studio,
 PractiTest,
 SpiraTest,
 TestLog,
 ApTest Manager,Zephyr).

Las más populares en el ámbito de trabajo actual son las siguientes:

5.2.1 Squash TM:


Es un gestor de repositorios test del kit de herramientas Open Source de Squash. Permite gestionar
requisitos, casos de testeo y campañas de ejecución en un contexto multiproyecto.

17
5.2.2 Test Link:

Es un sistema de gestión y ejecución de tests basado en web. Incluye especificación de tests,


planeamiento, informes, seguimiento de requisitos y colaboración con los controladores de errores
(bug trackers) más conocidos. Con los requisitos: Apache, MySQL, PHP.

5.3 Herramientas para pruebas funcionales o de automatización


5.3.1 Prueba Funcional
El objetivo principal de una prueba funcional es validar cuando el comportamiento observado del
software cumple o no las especificaciones.

La prueba funcional toma el punto de vista del usuario, las funciones que son probadas a partir de
datos de entrada examinado las salidas por lo general la estructura interna del programa no se
analiza o no es considerada.
Les diferencia si son de código abierto, que son gratuitas(libres) y herramientas comerciales (pago
por licencia)
5.3.1.1 De pago

 QuickTest Pro,
 Rational Robot,
 Sahi,
 SoapTest,
 Test Complete.

5.3.1.2 Gratuitas Open Source


Selenium,
 Soapui,
 Watir (Pruebas de aplicaciones web en Ruby),
 WatiN (Pruebas de aplicaciones web en .Net),
 Capedit,
 Canoo WebTest, Solex ,

18
 Imprimatur,
 SAMIE,
 ITP,
 WET,WebInject.

Las más populares en el ámbito de trabajo actual:

5.3.1.3 Selenium Suite

Selenium es uno de los marcos de prueba más conocidos del mundo que está en uso. Es un proyecto
de código abierto que permite a los probadores y developers, desarrollar pruebas funcionales para
controlar el navegador. Se puede usar para registrar flujos de trabajo para que los desarrolladores
puedan evitar futuras regresiones de código. Selenium puede funcionar en cualquier navegador
que admita JavaScript, ya que Selenium se ha creado utilizando JavaScript.

 Utilizada en multitud de lenguajes de Programación (Java, Groovy, Python, C#, PHP,


Ruby y Perl).
 Es multiplataforma (Windows, Mac y Linux)
 Soporte para múltiples navegadores (Chrome, Firefox, IE, Edge, Safari, opera)
 Incluye herramientas para grabación (Selenium IDE), para ejecución remota (Selenium
Grid) e integración con otros frameworks (Appium)

Compuesta por:
1. Selenium Core: Ejecución de pruebas automatizadas.
2. Selenium IDE: Creación y mantenimiento de pruebas automatizadas
3. Selenium Remote Control: Creación de pruebas escritas en lenguajes de programación
como Java o C# que ofrece diferentes soluciones para atender diferentes requisitos de
automatización de pruebas. En sus versiones anteriores y ahora en la actualidad Selenium
1.0 + WebDriver = Selenium 2.0.

19
4. Selenium Grid: Permite la distribución de ejecución de Pruebas en navegadores y sistemas
Operativos.

La siguiente figura muestra las bondades que presenta, la suite de Selenium.

Figura 3 : Suite de Selenium


(Fuente: Elaboración Propia)

5.4 Herramientas para pruebas carga


Este es el tipo más sencillo de pruebas de rendimiento. Una prueba de carga se realiza
generalmente para observar el comportamiento de una aplicación bajo una cantidad de peticiones
esperada. Esta carga puede ser el número esperado de usuarios concurrentes utilizando la
aplicación y que realizan un número específico de transacciones durante el tiempo que dura la
carga. Esta prueba puede mostrar los tiempos de respuesta de todas las transacciones importantes
de la aplicación. Si la base de datos, el servidor de aplicaciones, etc. también se monitorizan,
entonces esta prueba puede mostrar el cuello de botella en la aplicación.

Open source
Entre las herramientas de prueba de carga open source mas conocidas tenemos:

20
 FunkLoad,
 FWPTT load testing,
 loadUI,
 jmeter.

Comerciales

Tambiens existen herraminetas de prueba de carga comerciales, podemos citar

 HP LoadRunner,
 LoadStorm,
 NeoLoad,
 WebLOAD Professional,
 Forecast ,
 ANTS – Advanced .NET Testing System,
 Webserver Stress Tool,
 Load Impact

5.5 Conceptos para usar Pruebas automatizadas


Antes de abordar las pruebas automatizadas es necesario conocer algunos terminos esenciales para

realizar estas tareas:

 Test Case.
 Test Script.
 Suite de Pruebas.
5.5.1 Test case

Un caso de prueba o test case es un conjunto de valores de entrada, precondiciones de ejecución,


resultados esperados y postcondiciones de ejecución, desarrollados con un objetivo particular o
condición de prueba el mismo que nos permite verificar que se cumple un requerimiento
especifico.

5.5.2 Test script

21
Un script de prueba o test script son datos e instrucciones escritas en una sintaxis formal
almacenado en un archivo y usado por una herramienta de automatización de pruebas. Un script
de prueba puede automatizar uno o varios casos de prueba, navegación, inicialización u
operaciones y configuración de entorno. Un script de prueba previsto para la ejecución manual de
las pruebas es un procedimiento de prueba.

5.5.3 Suite de Pruebas

Una suite de prueba es uno o más conjuntos de pruebas reunidos para satisfacer un objetivo de
prueba. Un conjunto de prueba incluye scripts, documentación y recursos para nuestro Framework
estas suites de pruebas contendrán un conjunto de scripts además del orden de ejecución de las
mismas.

6 VIRTUALIZACIÓN DE MÁQUINAS VIRTUALES


Existen herramientas que permiten instalar varios sistemas operativos sobre un mismo hardware,
lo que comúnmente se conoce como máquinas virtuales. Las más conocidas son las siguientes:
6.1 VMware Workstation

Como una de las principales herramientas en sistemas de virtualización tanto para ordenadores de
escritorio como sistemas de servidores.
Ofrece una versión libre para uso doméstico, con las siguientes características:
 Virtualización completa: Sistemas operativos Windows, Linux, Mac.
 Virtualización de hardware asistido
 Conversión p2p: Maquinas físicas hacia máquinas virtuales.
 Migraciones de máquinas virtuales
 Restauración y copia de seguridad de las máquinas virtuales.
6.2 Virtual Box Equivalente gratuito de VMware para virtualizar sistemas operativos Windows,
Linux o Mac. Es propiedad de Oracle. El uso de algunas características requiere disponer de
licencia de pago.

Con las siguientes características:

22
 Virtualización completa: Sistemas operativos Windows, Linux, Mac y Solaris.
 Compatible con máquinas Virtuales VMware.
 Cifrado de unidades y soporte para puertos USB 2.0 Y 3.0 (con licencia).

Debido a la constante evolución tecnológica surgida en los últimos años con la aparición de la
computación en la nube, surgieron nuevas tecnologías que se consideran una evolución a las
máquinas virtuales, son los llamados Contenedores.

6.3 Diferencia entre un Contenedor y Máquina Virtual.


6.3.1 Máquina Virtual

Consisten en un hipervisor que sobre un hardware físico permite emular varias máquinas virtuales
cada una con su propio sistema operativo, librerías y aplicaciones, con esto en un servidor físico
se pueden tener varios sistemas operativos y aplicaciones, reduciendo costes, con un
provisionamiento más rápido y una mejor recuperación ante fallos, aunque con un consumo
elevado en recursos de computación, procesador, memoria y almacenamiento.

6.3.2 Contenedor

Los contenedores son una nueva tecnología que busca lo mismo, pero con la gran diferencia que
además del servidor físico, se tiene un solo sistema operativo host compartido para todos los
contenedores. Gracias a esto el tamaño de los contenedores es mucho menor, haciéndolos más
eficientes, más fácil de migrar, iniciar, recuperar y mover entre nube pública y privada.

Podríamos decir que las máquinas virtuales que se ejecutan en un host comparten los recursos
físicos, pero no comparten ningún recurso software. En el caso de Docker, además de compartir
los recursos hardware también comparten recursos a nivel software. El objetivo de Docker es
centrarse en la aplicación, dejando de lado el sistema operativo donde se ejecuta. La siguiente
figura muestra la diferencia de un contenedor vs una Máquina virtual.

23
Figura 4 : Diferencia entre un Contenedor vs. Máquina Virtual
(Fuente: http://despliegue.codeandcoke.com/doku.php?id=apuntes:docker, agosto del 2018)

Un ejemplo de esta tecnología es Docker, que está revolucionando la forma de virtualizar


sistemas y servicios, en comparación de los sistemas tradicionales como VMware, Virtual Box,
etc.
6.3.3 Docker

Es un proyecto de código abierto con el que fácilmente podremos crear “contenedores”. En la


siguiente figura se ve una arquitectura mínima de un Contenedor Docker.

Figura 5 : Arquitectura Mínima de Docker


(Fuente: http://despliegue.codeandcoke.com/doku.php?id=apuntes:docker , agosto del 2018)
Las principales características de este contenedor son:

24
Rapidez Los contenedores son capaces de compartir un solo núcleo y librerías de aplicaciones,
esto ayuda a que los contenedores se carguen antes que las máquinas virtuales. Los procesos son
mucho más ligeros y se reaprovecha el hardware. Además, no es necesario el sistema de archivos
completo del sistema operativo invitador con lo que Docker únicamente usa una fracción de
espacio de almacenamiento necesario en la virtualización.

Portabilidad Las imágenes Docker se pueden desplegar en diferentes sistemas, el único requisito
es que la herramienta Docker este instalada en el sistema huésped. Además, se pueden desplegar
multitud de contenderos en un mismo equipo físico.

Seguridad Los contenedores carecen de seguridad. Lo que se ve como una desventaja frente a las
máquinas virtuales.

Administración Existen dificultades en la gestión de contenedores Docker, existen soluciones


tales como Docker Swarm o Kubernetes que hacen un poco más fácil la gestión de múltiples
contenedores.

Autosuficiencia Un contenedor Docker no contiene todo un sistema completo, sino únicamente


aquellas librerías, archivos y configuraciones necesarias para desplegar las funcionalidades que
contenga. Además, las aplicaciones desplegadas en un contenedor están libres de dependencias
instaladas en el sistema anfitrión.

Multiplataforma: Docker está disponible para Ubuntu, ArchLinux, Gentoo, Fedora, Open SUSE
y FrugalWare y permite desplegar contenderos bajo entornos Windows. Mac, Amazon EC3,
Rackspace Google Cloud.

Docker también se compone de herramientas para construir imágenes, gestionarlas y un repositorio


para compartirlas. Existen diferentes alternativas a Docker, entre ellas las más populares son:
Rtk, lxc y lxd.

25
6.3.4 Arquitectura de Contenedores Docker
Para poder visualizar la idea de cómo trabaja Docker con los contenedores y estos a su vez
contengan las aplicaciones a ser ejecutadas por una serie de Archivos o Archivos para poder
componer como una “orquesta” se muestra la arquitectura de aplicaciones en la siguiente figura:

Backend

Figura 6 : Arquitectura de Aplicaciones en Contenedores


(Fuente: http://despliegue.codeandcoke.com/doku.php?id=apuntes:docker , septiembre del 2018)

6.3.5 Descripción de Las imágenes como aplicaciones

6.3.5.1 Static WebSite (Pagina web Desarrollada), puede ser como el proyecto de
Automatización de Pruebas usando Selenium, webDriver, Selenium grid.

6.3.5.2 User DataBase, Las Bases de datos si se desea en un contenedor (deseable).


Se puede tener imágenes de los diferentes DBMS entre los principales tenemos:

 Mysql https://hub.docker.com/r/_/mysql/
 Sql server https://hub.docker.com/r/microsoft/mssql-server-linux/

26
 PostgresSQl https://hub.docker.com/r/_/postgres/

6.3.5.3 Sobre el Proyecto Web Backend (Pagina web donde se encuentra la aplicación Web de
Fondo es decir la estructura de un software sin Interfaz), se recomienda el Framework
Sprint boot.

6.4 Imágenes de Contenedores


Una imagen Docker es una especie de plantilla, una captura del estado de un contenedor, no es una
máquina virtual, es como una snapshot de una máquina virtual, pero más ligero como ejemplo una
imagen podría contener un sistema Operativo Linux o Ubuntu son un servidor Apache y una
Aplicación web instalada. Las imágenes se utilizan para crear contenedores, y nunca cambian.

Hay muchas imágenes públicas con elementos básicos como Java, MySQL, Apache, Ubuntu. etc.,
que se pueden descargar y utilizar. Cuando se crea una imagen, partimos de una imagen padre a la
que vamos añadiendo otras herramientas (ejemplo una imagen padre con Ubuntu y Apache o Linux
con SQL-server).

Docker tiene un registro público de imágenes de donde se puede obtener la mayoría de las
imágenes que se puede necesitar con el siguiente link: https://hub.docker.com/ como se ve en la
siguiente figura:

Figura 7 : Página oficial de Docker Hub

27
(Fuente: https://hub.docker.com/ , septiembre 2018)

Por ejemplo, si se desea descargar una Imagen para Selenium solo basta buscar en el buscador de
la página oficial de Docker Hub como se ve la siguiente figura:

Figura 8 : Página oficial de Docker Hub


(Fuente: https://hub.docker.com/ , septiembre 2018)

6.4.1 Construcción de Imágenes Docker

Para poder ejecutar un proyecto de forma remota, necesitamos tener previamente construidas las
imágenes Docker necesarias para nuestro Proyecto.
Para ello necesitamos tener instalado Docker en nuestro dispositivo. Se ha utilizado la versión
Docker 17.09-ce. Se uso algunas herramientas útiles para el manejo de archivos y manipulación
de los scripts como: Git, Putty, mRemoteNG y console Linux previamente instalados.

Posteriormente se procede con crear una imagen en el Sistema Operativo Linux o Windows, con
Java 8 ó cualquier otra combinación de lenguaje o Manejador de Base de Datos se debe crear:

 Un fichero “Dockerfile”, que contendrá los comandos necesarios para configurar la imagen
haciendo uso de las herramientas anteriormente mencionadas. Como se muestra en la
siguiente figura:

28
Figura 9 : Fichero Docker file de una Imagen Base para Linux
(Fuente: https://github.com/harbur/docker-workshop/, septiembre del 2018)

Figura 10 : Construcción de una Imagen Base para uno de los contenedores


(Fuente: https://medium.com/@tushar0618, septiembre del 2018)

 Crear la imagen Docker y almacenarla en nuestro repositorio local, esto se hace


situándonos en el directorio donde este ubicado el fichero Dockerfile y ejecutando el
siguiente comando:

$ docker build -t [nombre-imagen].


 Verificar que se ha creado correctamente y se encuentra en el repositorio local de imágenes
Docker se ejecuta el siguiente comando:

$ docker images

29
Figura 11 : Lista de Imágenes resultado del comando Docker images
(fuente: https://medium.com/@tushar0618, septiembre del 2018)

Iniciar la imagen o imágenes con los siguientes comandos:


$ docker run -d -p 8000:8080 --name back-end:latest
Donde (8000 es el puerto local o interno y el 8080 del contenedor)
$ docker run -d -p 9000:8080 --name selenium front-end:latest
Para listar los contenedores y ver su estado el siguiente comando
$ docker ps
Para cuando se requiera finalizar la ejecución de estos contenedores se podrán parar mediante el
comando:
$ docker stop [Id_container]
Aunque estén inactivos se podrán aun listar como inactivos si se requiere borrar el siguiente
comando:
$ docker rm [Id_container]
Para comprobar la comunicación de las respectivas imágenes se deberá probar por la url:
http:localhost:8000 o en vez de localhost la ip de la maquina donde este alojado los contenedores.

7 MARCO DE TRABAJO DE PRUEBAS AUTOMATIZADAS CON DOCKER


Una vez que se describen y se elaboran las pruebas automatizadas se escoge las tecnologías o
herramientas que pueden ayudar a conformar el marco de trabajo como las siguientes:

 De los diferentes lenguajes de programación a Java por tener una mayor experiencia en la
codificación de desarrollos de software además es importante sobre el tema de los lenguajes
de programación el conocimiento, portabilidad y facilidad de codificación.

30
 Las herramientas de Automatización de pruebas se han visto necesario las herramientas libres,
sin costo, que se puedan integrar de forma fácil con los lenguajes de programación elegidos,
en este aspecto, los candidatos son Selenium para las pruebas automatizadas y Selenium Grid
para la distribución de los test. Puesto que las pruebas están más dirigidas a pruebas funcionales
que pruebas de aceptación, se enfocó en el primero.

 En el tema de virtualización, se encamino a contenedores en vez de máquinas virtuales, para


reutilizar el núcleo del sistema operativo host (en el caso de investigación es Linux), y por la
capacidad de virtualización, Docker.

7.1. Selenium Grid

Es una herramienta de Selenium que permite lanzar test de forma distribuida,utiliza internamente
Selenium Remote Control para ejecutar los test de integración con distintos navegadores y
plataformas.

7.1.1. Arquitectura de Selenium Grid

La siguiente figura describe muy bien la arquitectura Selenium Grid:

31
Figura 12 : Arquitectura Selenium Grid
(Fuente: http://despliegue.codeandcoke.com/doku.php?id=apuntes:docker , septiembre del 2018)

Donde se Observa conceptos como:


 Hub: Como una Computadora o Servidor (para el control de la red de las máquinas de
testeo), Es el punto central donde se almacenarán las pruebas, Es un solo Hub y es el
Master de la Red.

32
Si se desea puede configurar en Windows 10 y el navegador Chrome con la versión 8 por ejemplo,
entonces Hub intentara encontrar una maquina en Grid el cual coincida con el criterio y se ejecutara
la prueba en esa máquina, sino es encontrada Hub, responderá con un mensaje de error.

 Node: Es una referencia a la Maquina de Pruebas el cual opta por conectarse con el Hub.
Esta máquina de pruebas será usada por Hub para ejecutar las pruebas. Una Red Grid puede
tener múltiples nodos, los cuales pueden tener diferentes plataforma y sistemas operativos
y navegadores.

La estrategia se resume en crear un Hub, después se registra nodos a ese Hub. Los nodos
están donde las pruebas se ejecutarán, Hub es responsable de asegurarse que las pruebas terminen
de la forma correcta. Una de las ventajas de tener esta arquitectura es la que se muestra en la
siguiente figura, donde se ahorra tiempo en ejecución de las pruebas en paralelo:

Figura 13 : Ejecución de pruebas en Paralelo


(Fuente: http://despliegue.codeandcoke.com/doku.php?id=apuntes:docker , septiembre del 2018)

La siguiente figura describe la infraestructura de Selenium Grid con Docker, donde se tiene una
imagen para Selenium Hub, un contenedor por nodo que ejecuta una suite de test automatizados
ejecutándose en diferentes navegadores de forma paralela, los mismos que puede ser ejecutados
en diferentes sistemas operativos y esto gracias a la portabilidad de Docker.

33
Figura 14 : Arquitectura de Selenium Grid con Docker
(Fuente: Elaboración Propia)

7.1 Flujo del Marco de Trabajo


En este subtema se describe los aspectos técnicos a considerar para el despliegue de un proyecto
teniendo en cuenta los siguientes pasos:

7.1.1 Selección de la Página web Objeto para el proyecto de Automatización de pruebas


Se recomienda aplicar sobre el diseño de los test, usar la metodología Page Object, que nos
permite abstraer las aplicaciones a ser validadas.

en la cual cada página de la web se identifica como un objeto, en el cual se encapsula todas sus
características y posibles acciones, en forma de atributos y métodos.
Como se ve en la siguiente figura:

34
Figura 15 : Page Object sobre una Pagina Web
(Fuente: Elaboración Propia, mayo del 2018)

Como ventaja es que si hay cambios de UI (Interfaz gráfica) para la página objeto, las clases test
no necesariamente cambian, solo cambia el código dentro de la Pagina Objeto que requiera los
cambios. La Siguiente figura describe de forma mas abstracta el concepto de un Patrón de diseño
Page Model.

Figura 16 : Patrón de Diseño Modelo Page Object


(Fuente: Elaboración Propia)

35
7.1.2 Selección del Proyecto de automatización de pruebas web
Se recomienda que las pruebas automatizadas estén bajo un proyecto en lenguaje de programación
Java basado en Maven para la gestión y construcción del proyecto.
Que Contenga el siguiente Entorno:
Java 8(versión 1.8)
Maven 3 (versión 3.3.9)
Apoyado en las siguientes librerías:

 Selenium como librería de apoyo a la automatización web, se utilizó sobre la plataforma


Java en su versión 3.7.1
 TestNG como librería de ejecución de pruebas unitarias que trabaja sobre Java y está
basado en Junit. Se utiliza en su versión 6.8
 Log4j: como librería de gestión y configuración de logs en Java, en su versión 1.2.15.

Estas versiones incluyen el archivo pom.xml que maneja el proyecto mediante Maven y se
descargaran en fase de compilación del proyecto. Es necesario definir los drivers que manejan la
navegación sobre los diferentes navegadores webs a utilizar, mediante la creación y configuración
de objetos de la clase WebDriver de Selenium, que permitirán ejecutar las acciones pertinentes
sobre el navegador web real.

El proyecto está organizado Como se muestra en la siguiente figura:

36
Figura 17 Page Model sobre el proyecto a ser automatizado
(Fuente: Elaboración Propia)

7.1.3. Como montar Selenium Grid con Docker

Se muestra como iniciar un grid sencillo usando Docker.


Precondiciones:
Tener instalado docker. Para versiones inferiores a la 10, instalar docker toolbox en Windows 10.

37
En la siguiente página podemos crear las imágenes necesarias para crear nuestro grid:
https://github.com/SeleniumHQ/docker-selenium/ , donde se muestra las imágenes que se
pueden descargar de la página oficial de Selenium Grid, como se muestra en la siguiente figura:

Figura 18 : Imágenes para descargar y tenerlas en contenedores Docker


(Fuente: Elaboración Propia)

Hay dos formas de crear nuestro grid una es usando docker networking y la otra docker compose.

7.1.3.1 Pasos de Selenium Grid con Docker:

El siguiente cuadro muestra los pasos a seguir para ejecutar las pruebas valiéndose de Selenium
Grid con Docker y los posibles resultados:

38
No Pasos Resultados

1
Descargar la
imagen del hub:

2
Descargar las
imágenes de los
nodos:

3
Iniciar el
contenedor del
docker run -d -p 4446:4444 --name selenium-hub -P selenium/hub
hub:

El primer puerto es el de la máquina host. El segundo es el puerto interno del

contenedor.

Ver el hub iniciado: http://192.168.99.100:4446/grid/register/

Iniciar el
contenedor del
docker run -d -P --link selenium-hub:hub selenium/node-chrome-debug
nodo chrome:

39
Acá estamos haciendo un linkeo del nodo hacia el contenedor hub, usando el

parametro --link.

Iniciar el
contenedor del
docker run -d -P --link selenium-hub:hub selenium/node-firefox-debug
nodo firefox:

Selenium Grid registrado con dos o tres nodos Chrome y Firefox.

6 Abrir la consola http://192.168.99.100:4446/grid/console


del grid para
ver los nodos
registrados:

40
Con sus diferentes contenedores:

7 Instalar un
servidor VNC,
para poder
conectarse y ver
que pasa dentro
de los
contenedores.
Usando el
comando docker
port {container}
podemos ver
el puerto para
podernos
conectar a estos.

41
Conectando ….

Entrando al Conector que es un Ubuntu.

8
Configurar el
Poner la dirección del hub y esperando que Hub lo envié por ese nodo
proyecto para
que apunte a
Grid y ejecutar
los tests.

42
Corriendo el Test

Registro de un usuario en el Nodo: Chrome

43
El resultado en la terminal es un reporte como test automatizado con los

detalles de usar la herramienta que hace posible hacer los test WebDriver y

en el nodo que se probó el test que es Chrome.

La segunda manera es ejecutando el archivo docker-compose la estructura se detalla de la


siguiente manera:
Segunda opción el archivo DOCKER COMPOSE.
Crear el archivo docker-compose.yml e introducir lo siguiente:

Figura 19 Archivo Docker-Compose .yml


(Fuente: Elaboración Propia)

44
Donde:
paso 1 es ejecutar la imagen Hub como servidor, imagen principal
Como el nro. 2 la imagen del Firefox y 3 la imagen del nodo del navegador Chrome
La diferencia con el anterior procedimiento es que esta última orquesta las imágenes ya hechas de
una sola vez.

Por las dos maneras salen la ejecución con los mismos resultados, luego de haber hecho las pruebas
se llega a la siguiente sección de Conclusión.

45
CONCLUSIONES

La presente monografía ha cumplido con la investigación bibliográfica y analítica sobre un marco


de trabajo alcanzando con los subtemas descritos al principio de este documento como las
siguientes:
Se ha reforzado las ideas de los conceptos de Pruebas.
Se ha investigado las herramientas de software:
Las herramientas que permiten realizar el marco de trabajo para pruebas automatizadas son:
 Selenium Grid

 Se ha visto que la Organización de las pruebas automatizadas (Generación de suites y


Scripts para las pruebas) con el apoyo de Selenium Grid y su ejecución en paralelo de los
diferentes tipos de navegadores es de gran utilidad ya que hacen que las validaciones se
ejecuten de forma rápida y eficientemente.

Se ha investigado sobre el uso de contenedores para la agilidad y reducción de costes como:


 Docker

Además, se pudo identificar que utilizar contenedores Docker para ambientes de prueba tiene las
siguientes ventajas:
 Requerimientos de hardware Mínimas (al menos si se usa UNIX system)
 Configuración de todos los ambientes de testeo en un solo archivo(docker-compose.yml)
 El comando Cli ayuda a iniciar los contenedores y hacerlos correr en pocos segundos
 La posibilidad de dividir los testeos en procesos paralelos que corren de forma simultanea

 Repositorio de gran tamaño con las imágenes oficiales para crear ambientes con
diferentes bases de datos, navegadores y servidores web.

 Es Multiplataforma

 Se recomienda utilizar la metodología Web Page Object en el Desarrollo de un Proyecto


de Pruebas automatizadas.

46
Como conclusión Final es posible realizar pruebas automatizadas y crear un marco de trabajo
usando Docker, resultó ser una interesante actividad para futuros proyectos, ya que la
tecnología avanza que sin duda seguirán apareciendo nuevas y/otras herramientas potenciadas
para la Fase de Pruebas que es muy importante a la hora de desarrollar Software.

47
BIBLIOGRAFÍA
Libros

Roger S. Pressman, 2010. Ingeniería del Software Un enfoque practico, Séptima Edición
Amaricai, S. & Constantinescu, R. (2014). Designing a software test automation framework.
Informática Económica, 18(1), 152-161.
Myers, G. J. & Sandler, C. (2004). The art of software testing. John Wiley & Sons.
Black, R. (2009). Managing the testing process: practical tools and techniques for managing
hardware and software testing (3rd). Wiley Publishing.
Burnstein, I. (2010). Practical software testing: a process-oriented approach (1st). Springer
Publishing Company, Incorporated.
Gojare, S., Joshi, R. & Gaigaware, D. (2015). Analysis and design of selenium webdriver
automation testing framework. Procedia Computer Science, 50, 341-346. doi:http://dx.
doi.org/10.1016/j.procs.2015.04.038
Joy, J. & Singh, D. P. (2015, octubre). A generic framework design to enhance capabilities of
an enterprise test automation framework. En 2015 international conference on applied and
theoretical computing and communication technology (icatcct) (pp. 207-212).
Walls C. (2016) Spring Boot in Action

Referencias

https://es.wikipedia.org/wiki/Framework_para_aplicaciones_web

48