UNIVERSIDAD MAYOR DE SAN SIMON

FACULTAD DE CIENCIAS Y TECNOLOGIA

DIRECCIÓN DE POSGRADO

“USO DE HERRAMIENTAS PARA LA

GENERACION DE REPORTES EN EL
PROCESO DE AUTOMATIZACION”

TRABAJO FINAL PRESENTADO PARA OBTENER EL

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

POSTULANTE : LIDIA CUSSI RAMIREZ

TUTOR : LIC. VALENTIN LAIME

Cochabamba- Bolivia
2018

1
Agradecimiento:
A mi madre, mi hermana, a mis amigos, las instituciones
que me han ayudado a formarme en cada momento, y las
personas con las que he trabajado ahí, de las cuales
siempre he aprendido algo más.
A la empresa Digital Harbor, por darme la oportunidad
tan grande y esperada de poder formar parte de su equipo,
aprender cada día más junto a ellos y ejercer la profesión
que me gusta con ellos.
A mis compañeros de trabajo, por su gran apoyo y su
ayuda incondicional por mejorar cada vez en
conocimiento y actitud.
Gracias a todos ellos que me han acompañado en el
camino duro y la mano amiga que me han brindado en
esta travesía.

2
Dedicatoria :
A mi madre Bernardina Ramírez, a mi hermana
Cristina Cussi, y a mi gran amigo Sergio Flores, los
que nunca dejaron de creer en mí.

3
 Introducción 7

1. Generalidades 9

1.1. Antecedentes Generales 9

1.2. Antecedentes Específicos 9

2. Metodología 10

3. Automatización de pruebas 10

3.1. Beneficios de la automatización de Pruebas 11

3.2. Métricas en Automatización 13

3.3. Frameworks para la Automatización 14

4. Generación de Reportes del proceso de automatización 15

4.1. Extent TestNG Report 15

4.2. TestNG con ITListener 19

4.3. TestNG y Allure Report 22

4.4. Klov report 25

4.5. BDD Report (Behavior Driven Development) 27

5. Características de un reporte de automatización de pruebas 35

6. Conclusiones 37

7. Bibliografía 38

4
Índice de Figuras

Figura 1.- Reporte de automatización de Pruebas 10

Figura 2.- Costo de arreglar un defecto con el tiempo 11
Figura 3.- Reporte de ejecución de pruebas con extent report 19
Figura 4.- Reporte utilizando TestNGListener – vista general 21
Figura 5.- Reporte utilizando TestNGListener – vista categorías 21
Figura 6.- Reporte utilizando TestNGListener – vista Exepciones 22
Figura 7.- Reporte utilizando TestNGListener – vista panel principal 22
Figura 8.- Pasos con la opción de anotación @step 23
Figura 9.- Parte del reporte que se muestra con relación a la implementación de steps
23
Figura 10.- Comando para generar el reporte 24
Figura 11.- Vista general del reporte con Allure 24
Figura 12.- Vista por Suites del reporte con Allure 25
Figura 13.- Vista general de builds del reporte klov 27
Figura 14.- Vista del panel principal del reporte klov 27
Figura 15.- Vista graficas de barras por builds del reporte klov 27
Figura 16.- El estilo de representación given, when, then, en BDD 28
Figura 17.- Reporte generado desde un proyecto de automatización utilizando Serenity
28
Figura 18.- Flujo de habilidades que los actores pueden utilizar 29
Figura 19.- Resultados de prueba de todos los escenarios ejecutados 30
Figura 20.- Ciclo para analizar los que se debe automatizar en BDD Serenity 31
Figura 21.- Resultados del reporte BDD de serenity, pestaña de pruebas ponderadas 32
Figura 22.- Reporte Serenity BDD para la estructura de prueba en la pestaña con
Requisitos 33
Figura 23.- Reporte Serenity BDD para la estructura de prueba en la pestaña
Características (Features) 33
Figura 24.- Reporte Serenity BDD para la estructura de prueba en la pestaña 34
Figura 25.- Reporte Allure que corresponde a un comportamiento BDD 34
Figura 26.- Características básicas de un reporte de automatización 35

5
Resumen

Muchas empresas de Software gastan una buena parte de su presupuesto de control de

calidad para las pruebas de regresión, que es de naturaleza recursiva. Dependiendo de la
cantidad de versiones y ciclos de prueba que tenga en un año, el objetivo en la mente del
propietario en cuanto el presupuesto es reducir el costo de la prueba de regresión
mediante la automatización de casos de prueba.

Es importante realizar un análisis para determinar qué casos de prueba pueden ser
automatizados y cuales seguirán con el proceso manual.

En el panorama de la automatización de pruebas, las herramientas de automatización

ciertamente ocupan un lugar central.
Sea cual sea el framework de automatización, los reportes son de vital importancia, para
la revisión de los resultados de la ejecución de los test cases automatizados. Estos darán
una visión de manera general y especifica de los test cases que pasaron la prueba, que
fallaron o se omitieron.
Se pueden elaborar estos reportes de muchas maneras, dependiendo del framework y
lenguaje que se está utilizando, en esta monografía veremos algunas formas.

La visión de un reporte de automatización de pruebas debe reflejar lo necesario para

tomar una buena decisión en base a los resultados, en este sentido las características
pueden ser muchas, dependiendo de lo que se requiera mostrar, veremos las mínimas en
esta monografía, y la función que cumple.

Los reportes de test de pruebas de automatización se pueden generar desde distintas

librerías que nos facilitan este proceso, en esta monografía veremos algunas, cada una
con sus respectivas descripción para tener una visión global y colaborar de esta forma
en la decisión de los interesados en este tema.

Los reportes de automatización de pruebas que se tomará en cuenta en esta monografía

son reportes html generados por librerías y que contienen diferentes cualidades, además
de la interfaz bastante llamativa y explicativa como ser porcentajes, descripciones,
graficas, entre otras.

Así como características y manera de mostrar la información en la interface, sobre la

ejecución de los test, se pueden tener ciertas cualidades que pueden mejorar la
información que se requiere para los resultados, en especial para los test que puedan
fallar, como también el envío de resultados mediante email, de manera automática.

6
Introducción

Cada grupo de desarrollo de software prueba sus productos, pero el software entregado
siempre tiene defectos. Los ingenieros de prueba se esfuerzan por atraparlos antes de
lanzar el producto, pero siempre se infiltran y, a menudo, vuelven a aparecer, incluso
con los mejores procesos de prueba manual. Por tanto el la automatización de pruebas,
es la mejor manera de aumentar la eficacia, la eficiencia y la cobertura de sus pruebas
de software.

La automatización de pruebas es, en informática, el conjunto de métodos que sirven

para realizar tareas repetitivas en un ordenador. Algunos métodos para la
automatización de tareas son la programación simple.

Los reportes en general pueden tener diversos niveles de complejidad, desde una lista o
enumeración hasta gráficos mucho más desarrollados.

Así mismo los reportes de pruebas pueden mostrar el resultado de una lista de ejecución
de Test Cases (TC).

Existen pruebas que se hacen o se realizan de manera redundante, es decir que el flujo
se repite con algunas pequeñas excepciones sin embargo la lógica es la misma, estas
pruebas y ejecuciones de TC de manera manual toman su debido tiempo, pruebas en las
que se podrían ahorrar más tiempo si estas se automatizan, los resultados de estas
pruebas ejecutadas de manera automatizada se reflejan en un reporte que muestran los
TCs ejecutados, exitosos, fallidos, omitidos, entre otras. Pudiendo además adaptar
ciertas características en el reporte según lo que requiera el proyecto, en cuanto a la
ejecución de las pruebas.

En este sentido es importante que si la ejecución de pruebas se realiza mediante pruebas

automatizadas, se debe tener un respaldo de ejecución, plasmada en un reporte con
características necesarias para analizar la ejecución de TCs y tomar las decisiones
adecuadas.

Estos reportes de ejecución de pruebas automatizadas pueden generarse de manera

sencilla dependiendo de la opción que uno decida implementar, y muestran la
información básica y necesaria de la ejecución de pruebas, los logs de pruebas pueden
tener muchas opciones dependiendo de cómo se implemente, y la información que
requiera el proyecto.

Los resultados se analizan, se corrigen, las pruebas se pueden ejecutar de forma

recurrente, tener un historial de reportes y un buen respaldo para el equipo de QA, para
el proyecto en sí, ahorrar tiempo y presupuesto en este tipo de pruebas.

7
Es por esto que el tema a tratar y analizar es la importancia de la generación de reportes
en el proceso de automatización y sus características.

Lo que se pretende mostrar en esta monografía para su debido análisis y relación con el
objetivo principal, pueden ser los siguientes puntos:

 Tener una visión general sobre el proceso de automatización de pruebas, para

ver la relación de este con los reportes que se deberían generar.
 Mostrar una visión general de las distintas librerías y formas de generar reportes
de automatización de pruebas
 Mostrar algunas funciones adicionales que se pueden añadir en nuestro reporte
de automatización de pruebas.
 Mostrar las características principales mínimas que todo reporte de
automatización de pruebas tiene en su forma básica, y como ayuda esto en la
toma de decisiones.

Existen muchas formas de generar este reporte después de la ejecución de pruebas

automatizadas, dependiendo de la herramienta y el lenguaje que se utilice en la
implementación, pero todos tienen un conjunto de características que mínimamente
deberían mostrarse, en esta monografía se limitara a explicar estas características
mínimas sin tomar en cuenta el lenguaje o herramienta que se utiliza en un proyecto de
Automatización.

Esta monografía pretende servir de una guía base para la decisión adecuada en cuanto a
la generación de reportes, de manera general, en este sentido las opciones que se
muestren no serán de manera detallada.

Con esta monografía se pretende contribuir a las personas interesadas en este tema,
como QA de automatización por ejemplo, para que lo tomen en cuenta y les ayude a
tomar una mejor decisión.

8
1. Generalidades

En este apartado se toman en cuenta los siguientes antecedentes:

1.1. Antecedentes Generales

En las pruebas de software, la automatización de pruebas es el uso de un software

especial (separado del software que se prueba) para controlar la ejecución de las pruebas
y la comparación de los resultados reales con los resultados previstos.

Como muestra el reporte, las organizaciones necesitan automatización inteligente y

análisis inteligente para acelerar la toma de decisiones y la validación, y para abordar
mejor los desafíos de probar dispositivos y productos más inteligentes que están
altamente integrados y en continuo cambio. El reporte también sugiere la necesidad de
plataformas de prueba inteligentes que sean conscientes de sí mismas y auto adaptativas
para admitir el ciclo de vida completo de la aplicación.

El reporte, de esta forma, confiere una mayor utilidad a los datos. No es lo mismo
trabajar con una planilla de cálculos con 10.000 campos que con un dibujo en forma de
torta que presenta dichos campos de manera gráfica, de manera más llamativa.

Gracias a los reportes cualquier persona puede proceder a realizar un resumen de datos
o a clasificar estos en grupos determinados. Por todo ello, se entiende que estos
documentos sean tan importantes en cualquier empresa ya que gracias a ellos cuenta con
sus propias bases de datos.

Estos reportes deberían ser lo más explícitos e informativos para la fácil interpretación y
análisis, para la toma de decisiones.

1.2. Antecedentes Específicos

Los scripts necesitan datos de prueba de entrada antes de que estén configurados para
ejecutarse. Una vez ejecutados, proporcionan informes de prueba detallados.

Los reportes en automatización de pruebas ha mejorado bastante y transformado los

informes de pruebas de automatización.

El propósito y proceso de reportes en la automatización de pruebas de software después

de la finalización de la ejecución del conjunto de pruebas, en la que necesitamos tener
un informe del estado de ejecución, es la única forma de evidencia para el estado de
"Pasar" y "Fallar" de las pruebas. La mayoría de los clientes se preocupan por el
informe detallado del estado de la ejecución.

9
La mayoría de las herramientas de prueba de automatización con licencia contarán con
una opción de informe enriquecido para mostrar el estado de la ejecución. Sin embargo,
en esta monografía se mostrarán las opciones que se pueden utilizar de manera libre.

A continuación se puede ver un ejemplo de un reporte de ejecución de pruebas

automatizadas en la Figura 1:

Figura 1.- Reporte de automatización de Pruebas

Fuente https://www.softwaretestingmaterial.com/generate-extent-reports/

2. Metodología

La metodología para el presente trabajo requerirá los siguientes métodos de

investigación:

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

libros relacionados al tema de estudio, para ser plasmados en el documento de
manera seleccionada.

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

documentos relacionados al tema de estudio, de la información recabada.

3. Automatización de pruebas

Las automatizaciones de pruebas significan utilizar una herramienta de automatización

para ejecutar su conjunto de casos de prueba.

10
El software de automatización también puede ingresar datos de prueba en el sistema
bajo prueba, comparar resultados esperados y reales y generar informes detallados de
prueba. La automatización de pruebas exige inversiones considerables de dinero y
recursos.

Los sucesivos ciclos de desarrollo requerirán la ejecución del mismo conjunto de

pruebas repetidamente. Con una herramienta de automatización de prueba, es posible
grabar este conjunto de pruebas y reproducirlo según sea necesario. Una vez que el
banco de pruebas está automatizado, no se requiere intervención humana. Esto mejora el
proceso de la automatización de pruebas. El objetivo de la automatización es reducir el
número de casos de prueba que se ejecutarán manualmente y no eliminarán las Pruebas
manuales por completo.

3.1. Beneficios de la automatización de Pruebas

a. Entrega más rápida

Uno de los mayores costos no contabilizados en el desarrollo de software es la fijación
de defectos. Largas demoras entre el desarrollo del código y el hallazgo de un defecto
aumentan el tiempo y el esfuerzo necesarios para solucionar el defecto. La
automatización de pruebas puede ayudar. Crear un ciclo de retroalimentación más
ajustado entre el desarrollo del código y la prueba de si el código hace lo que se
pretendía es la clave. Lo que solía tomar los desarrolladores días para arreglarlo porque
tenían que volver a aprender su propio código escrito hace meses, toma unos minutos
cuando la automatización de prueba está lista para ejecutarse cuando el código del
momento se completa.

Figura 2.- Costo de arreglar un defecto con el tiempo

Fuente https://usersnap.com/blog/an-agencys-guide-to-successful-user-acceptance-
testing-for-websites-and-products/

En este y en cada uno de los siguientes elementos, el retorno de la inversión (ROI) será
el rendimiento total (el número que acabamos de encontrar) menos el total invertido,

11
dividido por el total invertido. Si se obtiene un número mayor que 1, se ha ganado
dinero. Si no, se ha perdido dinero hasta ahora.

b. Encuentra más regresiones

Encontrar regresiones con más frecuencia después de la introducción de la
automatización de prueba es típico. La diferencia es que las regresiones generalmente se
encuentran tan rápidamente y se arreglan tan fácilmente que no se pueden informar
como hubieran sido en el pasado. Un desarrollador puede ver una prueba fallida en el
entorno de integración continua (IC), reconocer el problema y solucionarlo rápidamente,
en lugar de documentarlo. Entonces, contar regresiones puede requerir un poco más de
esfuerzo.

Tomar en cuenta el número de regresiones antes y después de introducir la

automatización de prueba y asígneles un valor. Los promedios son útiles. Si toma el
costo promedio de una regresión para corregir antes de la automatización y se multiplica
por el recuento de regresiones, haga lo mismo para las regresiones después de la
introducción de la automatización de la prueba; la diferencia es la ganancia. La
esperanza es que el tiempo promedio para corregir un defecto se reduzca después de un
tiempo y que la cantidad de regresiones encontradas aumente durante un período de
tiempo.
Si bien encontrar más regresiones puede ser un costo más alto, el contraste en el costo
en comparación con la cantidad de usuarios que los encuentran es evidente.

c. Un producto más comprobable

Algo gracioso sucede cuando uno se compromete a probar la automatización en todo el
proceso de desarrollo de su producto: las personas comienzan a crear productos más
comprobables.
Las organizaciones pueden definir los beneficios tanto cualitativa como
cuantitativamente.
El aspecto cuantitativo se puede encontrar respondiendo a la pregunta: "¿Cuánto tiempo
tarda su producto en crear una prueba para una función?" Si este tiempo tiende a la baja
durante períodos de tiempo significativos, está experimentando una ganancia en la
capacidad de prueba. Cuando un producto es más comprobable, puede ir al mercado
más rápido, realizar pruebas de más maneras y tener menos posibilidades de perder
casos de uso en sus pruebas. Los interesados y los propietarios de productos terminan
amando productos más comprobables porque tienen confianza en lo que hace el
producto

d. Cambio a la izquierda
¿Cuándo se escriben los casos de prueba? ¿Cuándo se escribieron antes de introducir la
automatización de prueba? Mientras más cerca estén de crearse al mismo tiempo que
cuando se definen las tareas, la prueba "más a la izquierda" ha cambiado. Mover la
actividad de crear automatización de prueba y planificarla hacia la izquierda también
obliga a aclarar las características y las rutas de usuario. La automatización de pruebas

12
escrita anteriormente significa una detección más temprana de defectos, lo que significa
una entrega más rápida y la entrega de un mejor producto.

e. Regresión menos dolorosa

Para muchas organizaciones, la regresión es dolorosa. Es lento y rara vez encuentra
problemas importantes. La automatización de pruebas puede ayudar con esto.
Reemplazar los controles manuales con los controles de la máquina nos proporciona
varios beneficios. Primero, sabemos que el control se realizó como siempre se realiza.
El software no varía sus procedimientos. Segundo, podemos ejecutarlo más a menudo
por un costo menor. En tercer lugar, podemos verificar fácilmente si una regresión ha
sucedido en cualquier momento.

3.2. Métricas en Automatización

Hay una cantidad de métricas que se pueden usar en un proyecto de automatización.

Algunas de las métricas clave se dan a continuación.
a) Porcentaje automatizable

Porcentaje Automatizable = Nro total de Test Cases que pueden ser

automatizados /Total de Test Cases

Nro total de Test Cases que pueden ser automatizados 1000

Nro Total de Test Cases 700
Porcentaje Automatizable 70%

b) Progreso de la automatización

Progreso de Automatización = Nro total de TC Automatizados/Nro total de

Test Cases que pueden ser automatizados
Semana1 Semana2 Semana3 Semana4
Nro de TC’s que pueden ser 700 700 700 700
automatizados
Nro total de TC’s automatizados 100 120 140 180
Progreso de Automatización 14% 17% 20% 26%

c) Productividad del diseño de scripts de automatización / horas

Productividad de diseño de script de automatización/hr = Nro Total de TC’s

automatizados/Tiempo total tomado para el desarrollo de scripts en hrs

d) productividad de ejecución de scripts de automatización / horas

Productividad de ejecución de scripts de automatización/hr = Nro Total de

TC’s automatizados/Tiempo total tomado en la ejecucion de scripts en hrs

13
3.3. Frameworks para la Automatización

Selenium
Selenium es posiblemente el marco de automatización de pruebas de código abierto más
popular para aplicaciones web. Originado en la década de 2000 y evolucionado durante
una década, Selenium ha sido un marco de automatización de elección para los
probadores de automatización web, especialmente para aquellos que poseen habilidades
avanzadas de programación y scripting. Selenium se ha convertido en un marco central
para otras herramientas de automatización de pruebas de código abierto como Katalon
Studio, Watir, Transportador y Robot Framework.

Serenity(Java)
Es un framework de pruebas automatizadas basado en Java que se integra con
herramientas behavior-driven development (BDD) como Cucumber y JBehave
permitiendo tener los escenarios como información de alto nivel mientras también
provee información detallada de los mismos en los reportes. Esta pensado
principalmente para pruebas de aceptación y regresión.

Se integra fácilmente con Selenium WebDriver y permite la abstracción necesario entre

los tests y la aplicación bajo pruebas. La integración con Jira no requiere de esfuerzo y
crea reportes detallados que permiten también documentar tu aplicación.

No solo nos sirve para las pruebas UI, también tiene soporte para pruebas de Servicios,
integrándose con REST Assured, incluyendo los resultados de los tests en el reporte.

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.

Robot Framework(Python)
Es el framework numero 1 para pruebas automatizadas en Python. Es un Framework del
tipo keyword-driven, lo que hace que los tests sean fáciles de leer y crear. Si no se usa
Python, de todas formas se puede utilizar igual gracias a Jython (Java) o IronPython
(.NET).

14
No solo puedes enfocar tus pruebas en la IU, también se puede hacer pruebas de niveles
más inferiores, como pruebas FTP, de base de datos, Android o Appium.
Su API permite extender su funcionalidad para cubrir cualquier necesidad especial de
nuestro proyecto.

4. Generación de Reportes del proceso de automatización

En esta monografía se mostrará una visión general de las distintas librerías y formas de
generar reportes de automatización de pruebas.
La mayoría de las herramientas de prueba de automatización con licencia tendrán una
opción de creación de informe enriquecido para mostrar el estado de la ejecución. Pero
al venir a las herramientas de automatización de código abierto que carecen de esta
opción. Por ejemplo, Selenium para ejecutar el conjunto de pruebas, depende de los
marcos de prueba de la unidad como TestNG y Junit.

Los ingenieros de prueba de automatización deben probar la aplicación ejecutando su

conjunto de pruebas de automatización, encontrar errores e informar al equipo de
manera que puedan entender fácilmente el resultado de la ejecución.

Cómo el framework de reporte ayuda al reporte de prueba de automatización. Después

de las ejecuciones de la suite de prueba usando TestNG o Junit, de forma
predeterminada proporcionarán los informes HTML, también puede ser enviado por
correo electrónico al equipo y a las partes interesadas del proyecto, pero aún así tener un
buen alcance de mejora.

Vemos una de las herramientas de reportes de Selenium más populares y ampliamente

utilizadas (Extent Reports). Los resultados de Selenium se pueden ver usando diferentes
herramientas de reportes de Selenium. Algunas de las herramientas de Selenium
WebDriver Reporting son las siguientes.

 Extent Reports
 TestNG Report Generation
 Junit Report Generation

4.1. Extent TestNG Report

Extent Report puede ser integrado con TestNG.-

El informe extensible es una libreria de informes HTML para Selenium Webdriver para
Java, que es en gran medida fácil de usar y ofrece excelentes informes de ejecución.
Podemos utilizar esta herramienta dentro de los objetos centrales de extent report en
nuestro marco de automatización luego de que podamos llamar y las funciones
requeridas por el usuario del extent report en nuestros Scripts de prueba.

Importamos dos clases para la generación del reporte.

15
ExtentReports: Al usar esta clase, establecemos la ruta donde nuestros informes deben
generar.
ExtentTest: al usar esta clase, podríamos generar los registros en el informe.

Si se está utilizando un proyecto maven, se utiliza la siguiente dependencia

extentreports en el archivo pom.xml de dependencias, como se ve a continuación:

A continuación se muestra un ejemplo de la implementación de las clases necesarias

para hacer posible la generación de los reportes en nuestro proyecto de automatización.
Tenemos una primera clase ExtentTestNGReportBuilder que es la encargada de crear
las instancias de los test de nuestro reporte asi como la salida respectiva del path y el
documento en formato html.

Se requiere iniciar y adjuntar reporters a la clase ExtentReports para generar

exitosamente información de prueba. Si no se inician los reporters o se adjuntan estos,
se producirá una IllegalStateException al crear pruebas o al descargar el contenido del
informe.

En la que se implementan los métodos con las anotaciones respectivas como se indica
en el ejemplo, @BeforeSuite, @BeforeClass, @BeforeMethod, @AfterMethod.

Se utiliza la clase ITestResult en @AfterMethod para describir el resultado de una

prueba.
En este ejemplo, el resultado de los test cases ejecutados que se escribirá en el reporte,
se encuentran en el método @AfterMethod, todos los estados que debería contener el
test case, después de la ejecución automatizada:
- En caso que el test falle
- En caso que el test pase
- En caso que el test sea ignorado

Puntos importantes a recordar:

 Extent Reports es la encargada de crear el archivo del reporte

 La prueba de extensión es la que registra la información en el informe.
 StartTest (), el método de clase ExtentReports es el punto de partida de la prueba
y es la que devuelve el objeto ExtentTest.

16
 Se necesita la referencia para registrar la información en el informe.
 El objeto ExtentReports se utilizará para agregar la información del informe
como Título, encabezado y tema, etc.
 La configuración anterior debe pasar desde el archivo XML externo utilizando el
método loadConfig() de la clase ExtentReports. Tomará la ruta del archivo XML
como argumento.
 El método EndTest() de ExtentReports detendrá la captura de información sobre
el registro de prueba.
 El método Flush() de ExtentReports insertará / escribirá todo en el documento.
 El método Close() de los ExtentReports borrará / cerrará todos los recursos del
objeto ExtentReports.

17
Se tomó tres métodos con la anotación @Test como passTest, failTest y skipTest y un
método startTest con la anotación @BeforeTest y otro método endReport con la
anotación @AfterMethod.
Se utiliza el objeto de clase ExtentReports (es decir, extent) en el método startReport
que se asignó a la anotación @BeforeTest para generar el informe HTML en la ruta
requerida
Se utiliza el objeto de la clase ExtentTest (es decir, extent) en los métodos restantes para
escribir registros en el informe.

Una vez ejecutadas las pruebas o suites de pruebas, se puede visualizar el reporte html
en la ruta a la que se re-direcciona en la implementación, como se ve en la Figura 3:

18
 Figura 3.- Reporte de ejecución de pruebas con extent report
Fuente: Reporte Generado, proyecto Automation Digital Harbor

4.2. TestNG con ITListener

Para implementar una clase de Listener, la clase debe implementar la interface

org.testng.ITestListener. Estas clases son notificadas en tiempo de ejecución por
TestNG cuando la prueba comienza, termina, falla, salta o pasa.

Los oyentes "escuchan" el evento definido en el guión de selenio y se comportan en

consecuencia. El objetivo principal de usar oyentes es crear registros. Hay muchos tipos
de oyentes, como WebDriver Listeners y TestNG Listeners.

En el siguiente ejemplo se puede ver una implementación con TestNG Listener, que
sobrecargan los métodos que tiene este, para hacer uso de las opciones que nos
proporciona y adecuarlo al reporte que queremos visualizar.

19
En esta clase, se crea un objeto ExtentReports y se puede acceder a través del método
getReporter (). Además, debe establecer la ubicación del archivo HTML del informe
ExtentReports.

20
Una vez finalizada la prueba, se podrá visualizar el archivo ExtentReportsResults.html
en la carpeta ExtentReports.

Cómo leer el informe de extensión extent report:

Informes de extensión se generan en un archivo con formato HTML con 3 secciones:
1.- Panel de control: Informe global del caso de prueba
2.- Categoría: Categoría sabio Resultado
3.- Pruebas: resultado del caso de prueba individual

Cuando se abra el informe, se pueden ver los resultados de la prueba como se muestra a
continuación, en las figuras 4, 5, 6 y 7.
Pruebas.-

Figura 4.- Reporte utilizando TestNGListener – vista general

Fuente: Reporte Generado, proyecto Automation Digital Harbor

Categorías.-

Figura 5.- Reporte utilizando TestNGListener – vista categorías

Fuente: Reporte Generado, proyecto Automation Digital Harbor

21
Excepciones.-

Figura 6.- Reporte utilizando TestNGListener – vista Exepciones

Fuente: Reporte Generado, proyecto Automation Digital Harbor

Panel principal (Dashboard).-

Figura 7.- Reporte utilizando TestNGListener – vista panel principal

Fuente: Reporte Generado, proyecto Automation Digital Harbor

4.3. TestNG y Allure Report

Para la integración de Allure, debe agregar dependencias maven a continuación en su

archivo pom.xml. en la sección de propiedades:

22
Dependencia de Allure TestNG:

Para hacer que el informe de prueba sea más comprensible, se uttiliza la propiedad de
descripción de anotación @test. Como se muestra en el ejemplo:
@Test (prioridad = 0, descripción = "Escenario de inicio de sesión no válido con
nombre de usuario y contraseña incorrectos")

Además, se puede agregar una descripción adicional con la anotación @Description,

por ejemplo:
@ Descripción ("Descripción de la prueba: prueba de inicio de sesión con nombre de
usuario incorrecto y contraseña incorrecta")

Se necesita definir los pasos en un lugar genérico en nuestro proyecto de prueba. Para
definir un paso, necesitamos usar la anotación @Step. En nuestro proyecto, los pasos se
definen en nuestras clases de página.

Figura 8.- Pasos con la opción de anotación @step

Fuente: https://www.swtestacademy.com/allure-testng/

Aquí están los resultados. Se debe buscar en el informe como se muestra en la figura 9.

Figura 9.- Parte del reporte que se muestra con relación a la implementación de steps
Fuente: https://www.swtestacademy.com/allure-testng/

23
Para generar un informe, se debe instalar el intérprete de línea de comandos de Allure, y
seguir os siguientes pasos:
1. Descargar la última versión como archivo zip.
2. Descomprimir el archivo en el directorio allure-commandline.
3. Navegar al directorio bin.
4. Agregar Allure al PATH del sistema.
5. Abrir una pantalla de símbolo del sistema, vaya al directorio del proyecto y
escribir debajo el siguiente comando:

Figura 10.- Comando para generar el reporte

Fuente: fuente propia
En un resultado general el reporte final se mostrará como se ven en las siguientes
imágenes, ver figuras 11, 12:

Vista General (Overview).-

Figura 11.- Vista general del reporte con Allure

Fuente: https://www.swtestacademy.com/allure-testng/

24
Suites.-

Figura 12.- Vista por Suites del reporte con Allure

Fuente: https://www.swtestacademy.com/allure-testng/

4.4. Klov report

En Para generar este reporte se. debe tener instalado MongoDB.

Hay dos archivos importantes para este caso:

1. klov-x-x.jar file
2. application.properties file.

Ejecutar Klov:
Se debe proporcionar la versión correcta.
java -jar klov-x.x.x.jar

Se puede configurar la configuración del entorno MongoDB desde

application.properties:

# data.mongodb
spring.data.mongodb.host = localhost
spring.data.mongodb.port = 27017
spring.data.mongodb.database = klov

Entonces se puede ir a la dirección http://localhost:NroPuerto y si se puede visualizar la

página de bienvenida. Todo está listo para Klov: Extentreports.
En primer lugar, no es necesario cambiar el código de prueba. Todo lo que se necesita
hacer es agregar un Listener de prueba en el proyecto y Klov informando el código de
Java básico.

25
Por ejemplo:

Código base de Klov:

 Crear un objeto KlovReporter.
 Definir la conexión MongoDB.
 Dar un nombre de proyecto a nuestro proyecto de prueba.
 Definir la compilación, no como nombre del Reporte.
 Establecer la URL del servidor klov.
 Finalmente, crear un objeto ExtentReports y vincularlo al objeto KlovReport.

Ahora se puede ejecutar sus pruebas y ver los resultados mágicamente en el reporte
Klov Web Dashboard. Se puede verificar las fallas en la vista histórica en la tabla de
línea de tiempo. Verá cuántas veces ejecutó esas pruebas y la información de ejecución
de compilación.
A continuación se puede mostrar las vistas que ofrece Klov Report , ver las siguientes
figuras 13,14, 15.

26
Vista General de Builds (Construcciones).-

Figura 13.- Vista general de builds del reporte klov

Fuente: http://extentreports.com/docs/klov/

Panel Principal (Dashboard)

Figura 14.- Vista del panel principal del reporte klov

Fuente: http://extentreports.com/docs/klov/

Graficas por Builds.-

Figura 15.- Vista graficas de barras por builds del reporte klov
Fuente: http://extentreports.com/docs/klov/

4.5. BDD Report (Behavior Driven Development)

BDD refiere a Behavior Driven Development, o sea, desarrollo dirigido por

comportamiento. Como bien lo indica su nombre, no se trata de una técnica de testing,

27
sino que es una estrategia de desarrollo (así como TDD, que es test driven
development). Lo que plantea es definir un lenguaje común para el negocio y para los
técnicos, y utilizar eso como parte inicial del desarrollo y el testing.

Figura 16.- El estilo de representación given, when, then, en BDD

Fuente: https://www.testingexcellence.com/bdd-guidelines-best-practices/
Serenity.-
En cuanto a BDD, el reporte es la mejor característica de Serenity. Puede compilar
documentación viva, combinar características e historias en un formato narrativo paso a
paso que incluye datos de prueba y capturas de pantalla de ejecución.

La página del informe principal muestra una gran cantidad de información sobre
pruebas: recuento de pruebas, duración de la ejecución, pruebas fallidas y pendientes,
etc. Como se muestra en la figura 17.

Figura 17.- Reporte generado desde un proyecto de automatización utilizando Serenity

Fuente: thucydides.info/docs/serenity-staging

28
Para tener una idea de cómo se crea una prueba típica de Serenity Screenplay. Las
pruebas de guión se expresan desde el punto de vista de uno o más actores. Los actores
tienen habilidades, como la capacidad de navegar por la web usando un navegador. Los
actores realizan tareas centradas en el negocio para lograr sus objetivos, como "Buscar
un término". Los actores también pueden hacer preguntas sobre el estado de la
aplicación, como verificar el estado de la pantalla de resultados.

Figura 18.- Flujo de habilidades que los actores pueden utilizar

Fuente: http://serenity-bdd.info/docs/articles/screenplay-tutorial.html

Algunas características de Serenity BDD

 Facilita la escritura, la ejecución y el informe de las pruebas de aceptación

automatizadas en términos como este, con los cuales se pueden relacionar los
licenciados y evaluadores, así como los desarrolladores.
 Estructura las pruebas de aceptación automatizadas en pasos y sub pasos. Esto
tiende a hacer que las pruebas sean más claras, más flexibles y más fáciles de
mantener.
 Cuando se ejecutan las pruebas, Serenity produce informes ilustrados, basados
en historias, requerimientos, características.
Serenity BDD también le brinda una imagen más amplia, que lo ayuda a ver dónde
encajan los escenarios individuales en el conjunto general de requisitos del producto. Le
ayuda a ver no solo el estado actual de las pruebas, sino también los requisitos que se
han probado (y no se han probado).

El informe de agregación Serenity BDD se puede organizar mediante el uso de

características, historias, pasos, escenarios/pruebas. Cuando usas diferentes frameworks
con Serenity BDD es posible que las mismas cosas tengan diferentes definiciones. Por
ejemplo, los ejemplos en JBehave/Cucumber tienen casi el mismo significado que los
Datos de prueba en Junit, o el escenario en JBehave/Cucumber es el mismo que la
prueba en JUnit. También Test es un sinónimo de Criterios de Aceptación.

29
El siguiente ejemplo contiene 2 características (features) con algunas historias. Cada
historia puede contener uno o más escenarios, cada escenario consta de uno o más pasos
y algunos ejemplos.

Feature:Definition
Story: Look for definition
Scenario (or Test, or Acceptance Criteria): Looking for
definition: pass
examples: 3
steps: 3
Scenario: Looking for definition with incorrect
symbols: @Ignore
examples: 4
steps: 3
Scenario: Looking for not existed definition: failed
examples: 2
steps: 3
Story: Update a definition
Scenario: Updating a definition: some internal error
examples: 5
steps: 3

Feature:Petstore
Story: Remove a pet
Scenario: Removing a pet: @Skip
steps: 5
Scenario: Removing multiple pets: @Pending
steps: 6
Story: Update a pet
Scenario: Updating a pet: @Ignore
steps: 4
Story: Add a pet
Scenario: Adding a pet: pass
steps: 3

Después de ejecutar todas estas pruebas (no importa si usa JBehave, Cucumber o JUnit)
se recibirá un informe de agregación, que se verá similar a la estructura de las pruebas:

Figura 19.- Resultados de prueba de todos los escenarios ejecutados

Fuente: thucydides.info/docs/serenity-staging

30
Entre la información general, se puede encontrar información sobre las características
proporcionadas/historias de componentes en esta prueba. También representa
estadísticas de pruebas aprobadas/ignoradas/omitidas/fallidas según su cantidad.
El informe se genera en el directorio de target/site/serenity en un archivo Html.

Se puede destacar que Serenity report está muy relacionado con las siguientes
características:
Requerimientos
Información detallada sobre estadísticas basadas en características, historias y criterios
de aceptación
Características (Features)
Tabla resumen de todas las características
Historias (Stories)
Tabla resumen con estadísticas de historias

Figura 20.- Ciclo para analizar los que se debe automatizar en BDD Serenity
Fuente: http://www.thucydides.info/

Ahora que se ha hablado en forma general lo que ofrece Serenity report, además en
cuanto a BDD testing, se puede mostrar revisar también las diferentes pestañas que
genera un reporte de Serenity.

 Resultados de la pestaña de la “Resultados de pruebas”

Aquí se puede encontrar casi toda la información sobre las pruebas ejecutadas. Consiste
en las siguientes sub-pestañas:

o Recuento de pruebas
Página de resumen de todas las estadísticas e información generales,
según la cantidad de escenarios y ejemplos utilizados.

31
 o Pruebas ponderadas
Página de resumen de todas las estadísticas generales e información,
ponderada por el tamaño de los escenarios en pasos.

Figura 21.- Resultados del reporte BDD de serenity, pestaña de pruebas ponderadas
Fuente: http://thucydides.info/docs/serenity-staging/

 Resultado de la pestaña “Requerimientos”

En esta pestaña todos los resultados de las pruebas están organizados como requisitos:

32
 Figura 22.- Reporte Serenity BDD para la estructura de prueba en la pestaña con
Requisitos, Fuente: http://thucydides.info/docs/serenity-staging/

3.- Resultados de la pestaña “Características”(Features)

En esta pestaña todos los resultados de las pruebas están organizados como
características. En nuestro ejemplo tenemos 2 características.

Figura 23.- Reporte Serenity BDD para la estructura de prueba en la pestaña

Características (Features)
Fuente: http://thucydides.info/docs/serenity-staging/

33
  Resultado de la pestaña Historias (Stories)
Hay historias en esta pestaña. En este ejemplo, hay 5 historias. Y dentro de estas, la
notación correspondiente a BDD.

Figura 24.- Reporte Serenity BDD para la estructura de prueba en la pestaña

Historias(Stories), Fuente: http://thucydides.info/docs/serenity-staging/

Allure: Informes impulsados por el comportamiento (BDD)

Allure también tiene facilidades para reportes de comportamiento, Podemos agrupar las
pruebas con las anotaciones @Epic, @Feature y @Stories.

Figura 25.- Reporte Allure que corresponde a un comportamiento BDD

Fuente: https://docs.qameta.io/allure/#

34
5. Características de un reporte de automatización de pruebas

La obligación de un tester de automatización, es atrapar excelentes informes y

presentarlos al grupo de administración. A continuación, se detallan las funciones más
interactivas que proporciona el informe de extensión y necesitamos saber:

Figura 26.- Características básicas de un reporte de automatización

Fuente: http://qavalidation.com/2016/10/selenium-html-result-reporting-using-
extentreports-3-x.html/
Se pueden mencionar a continuación las características que hacen del reporte un
informe enriquecido y explicativo para la buena interpretación de la misma.

1.- El estado se mostrará en forma de gráfico PIE.

2.- Se puede reemplazar el informe existente con el nuevo informe y agregar nuevo
estado al informe existente.
3.- Se puede cambiar el orden de presentación de la prueba (es decir, la prueba más
antigua en la parte superior, la más reciente al final o la más nueva en la parte superior,
la más antigua al final).
4.- Se puede generar informes en línea o fuera de línea.
5.- Se puede dar nuestro nombre al método (es decir, puede cambiar el nombre del
método de prueba en el informe).
6.- Se puede generar información de registro paso a paso en el informe.
7.- Se puede segregar la prueba usando Categorías de pruebas.
8.- Se puede dar el nombre del autor para mostrar en el informe.
9.- Se puede agregar un nodo de prueba como un hijo (child) de otra prueba.
10.- Se puede insertar HTML personalizado en los registros mediante el uso de una
etiqueta HTML.

35
11.- Se puede mostrar las capturas de pantalla en el informe donde sea que lo
necesitemos.
12.- Se puede agregar registro de las ejecuciones de prueba en el informe.
13.- Se puede agregar información expandida en el informe.
14.- Se puede dar nuestro propio nombre al informe HTML.
15.- Se proporcionará la información del sistema en el informe (es decir, el nombre de
host y el sistema operativo utilizados para ejecutar el conjunto de pruebas).

Cómo el reporte es un complemento de los reportes: Para superar el tipo de

problemas de informes anteriores, sería bueno sugerir el uso de un extent report, que
proporciona informes HTML muy buenos y completos. Al usar estos informes, estos
también darán el estado en forma de PIE Charts, tablas, vista de lista y modo mixto.

Características principales del reporte: En pruebas de automatización, la importancia

de los informes es muy alta. El formato del informe varía de etapa a etapa. Puede ser de
categoría, tipos de pruebas involucradas o en forma individual, representación gráfica
del informe mejor y fácil de entender.

Además de contar con las características que se puede mostrar en la primera imagen de
este subtema, se pueden tener las siguientes cualidades en la versión comunity que es
libre para quien lo requiera:
 ExtentHtmlReporter: informe interactivo en HTML
 Soporte para Pruebas Estándar y BDD
 Agregar capturas de pantalla a las pruebas
 Soporte para enviar correos después de las ejecuciones de prueba

Cuadro Comparativo.-

Después de resaltar las características de estos tipos de reportes, como son Extent
report, Allure Report y Serenity report, se tiene el siguiente cuadro comparativo entre
las cualidades de los mismos.

Característica Extent Report Allure Serenity

Informe interactivo en HTML X X X

Generación de informes en línea o fuera X X X

de línea
Generación de Categorías de pruebas X X

Soporte para Pruebas Estándar y BDD X X X

36
Vistas agregadas de los resultados de las X
pruebas por requisitos
Agregar capturas de pantalla a las X X X
pruebas
Opciones sobre las capturas de pantalla X
de las pruebas
Soporte para enviar correos después de X
las ejecuciones de prueba
Plugin de integración con Jenkins X X X

6. Conclusiones

 Por todo lo visto y analizando, se puede notar que un reporte de ejecución de

pruebas es de vital importancia para la información adecuada de este tipo de
pruebas, ya sea TDD o BDD, los reportes están presentes para facilitarnos las
pruebas, como respaldo de cada ejecución que se realiza.

 Hay diversas formas de generar un reporte de automatización de pruebas, que

pueden adecuarse a los requerimientos de un proyecto de automatización, solo
requiere de un poco de investigación para enriquecer los reportes.

 La automatización de pruebas nos facilitan el trabajo del testing manual, nos

ahorran tiempo y dinero, pero el respaldo que se utiliza y se requiere son
siempre un reporte de acuerdo a las necesidades del proyecto, y lo que se
necesita saber de ellas.

 Se puede recomendar que un reporte debe ser lo más detallado posible, es

importante que los resultados se reflejen en gráficos interactivos, logs detallados
de los tests que fallen, como también un resumen de los test que se ejecutan.

 Según el cuadro comparativo se puede concluir que el reporte adecuado estándar

recomendado para una ejecución TDD de pruebas es extent report, en cuanto a
BDD se puede concluir y recomendar serenity report, por todas las cualidades ya
mencionadas.

37
7. Bibliografía

1. Test Automation Best Practices - George Ukuru

https://books.google.com.bo/books?id=OCpoBgAAQBAJ&printsec=frontcover
&dq=automation+testing&hl=es-
419&sa=X&ved=0ahUKEwjLx6yPjL7dAhVxtlkKHfD3C3AQ6AEILjAB#v=on
epage&q=automation%20testing&f=false
2. Software Automation Testing Secrets Revealed - Narayanan Palani
https://books.google.com.bo/books?id=AK44DwAAQBAJ&printsec=frontcover
&dq=automation+testing&hl=es-
419&sa=X&ved=0ahUKEwjYvJzdx9LdAhUJ0FMKHePDBLwQ6AEILTAB#v
=onepage&q=automation%20testing&f=false
3. BDD in Action- Behavior-Driven Development for the Whole Software
Lifecycle - John Ferguson Smart
4. https://www.swtestacademy.com/allure-testng/
5. https://docs.qameta.io/allure/#
6. http://serenity-bdd.info/docs/articles/screenplay-tutorial.html
7. http://thucydides.info/docs/serenity-staging/#fig-aggregate-report

38