Conversemos de DevSecOps
En esta nueva sección de nuestro blog compartiremos la visión y experiencia de nuestro equipo de expertos en el ámbito del desarrollo de software y las tecnologías de información en general, quienes tocarán distintos temas relacionados con las tecnologías y metodologías utilizadas por Sovos para crear e implementar un mejor software, y entregarán tips y datos orientados a aportar valor a quienes deben trabajar en este ámbito, fundamental para las compañías que crean y utilizan soluciones para impulsar el negocio de sus clientes.
Pamela Ruiz, Senior QA Engineer
Utilización de Report Portal para monitoreo de pruebas funcionales
En la actualidad, cada vez poseemos más automatización en el área de pruebas funcionales, esto es, tests de API y End to End. Esto acelera el proceso de testing en regresiones y tiempo de user acceptance testing, entre otros, permitiéndonos avanzar en la implementación de CI/CD (continuous integration/continuous delivery).
Mientras mayor sea la automatización, menor será el tiempo de todo el proceso, por lo que se podrán entregar al cliente cambios de forma más rápida y segura.
La automatización genera algunos nuevos desafíos que necesitan un control; por ejemplo, pueden generarse falsos positivos, tests que fallan por inestabilidad, tests de mala calidad, etc. Por esta razón, es sumamente importante mantener un control sobre ellos.
La necesidad de mantener monitoreados los resultados de pruebas funcionales movió al equipo a realizar una investigación de herramientas disponibles.
Se encontró la herramienta de Report Portal y se llevó a cabo una prueba de concepto.
Lo primero que notamos fue su facilidad de instalación, al necesitar correr un único comando para instalar a través de Docker compose.
docker-compose -p reportportal up -d --force-recreate
Una vez ejecutado el comando, se chequean las imágenes de docker con el comando.
docker ps
En la imagen se observa la salida del comando docker ps.
Al levantar la aplicación de Report Portal por primera vez, y acceder a ella, nos encontramos con una pantalla de login:
Y para acceder, utilizamos las credenciales temporales provistas por Report Portal.
Una vez ingresados al sistema podemos crear dashboards, diferentes proyectos, analizar las ejecuciones, etc.
Los dashboards son completamente configurables. En la siguiente imagen podemos ver un ejemplo:
En este caso contamos con las estadísticas de todas las ejecuciones, dividiendo los tests en distintas posibles categorías.
Una de las propiedades más interesantes de esta herramienta es la posibilidad de ir aprendiendo en base a los análisis que realizamos (cuáles son fallos de productos, tests skippeados, fallos de ambiente, etc). Este aprendizaje está basado en inteligencia artificial.
Algunos de los problemas con los que nos enfrentamos al utilizar esta herramienta fueron los tipos de reportes soportados.
Report Portal soporta diferentes tipos de reportes, pero el de mejor visibilidad de datos fue JUnit. En nuestros tests automatizados generamos otros tipos de reportes, por lo que se realizaron scripts para adaptarlos al formato de JUnit aceptado por Report Portal:
Hay diferentes opciones de importación de datos hacia Report Portal, incluyendo la instalación de agentes, el envío de datos en tiempo real (durante la ejecución de tests), y otros.
Para evitar un aumento de tiempos en la ejecución de tests y la instalación de agentes, optamos por realizar la carga importando los reportes a través de la API de Report Portal. Desarrollamos un script para este propósito.
Lo primero es importar el archivo del reporte, ya adaptado a Junit, y comprimido en un archivo .zip:
Luego necesitábamos agregar información de la ejecución -como el número de build- y linkear al job de Jenkins ejecutado:
Obtenemos el ID del archivo importado y agregamos la información que necesitamos incluir en los atributos y descripción del launch.
Cada nuevo reporte genera en Report Portal algo llamado launch, que es similar a una nueva ejecución. Para que la herramienta tome el historial de ejecuciones de cada test, el launch debe tener un mismo nombre. Si este se modifica, se crean nuevas versiones cada vez.
Por ejemplo, inicialmente importábamos los reportes con el número de build en su nombre,
lo que generaba el siguiente gráfico de trend:
Luego extrajimos el número de build del nombre y pudimos obtener un gráfico con el historial.
También nos permite ver el historial de cada test case.
En conclusión, hasta ahora la herramienta de Report Portal nos sirve para mantener un constante monitoreo sobre todo tipo de pruebas funcionales, incluyendo algunos unit tests.
Pudimos enseñarle a la herramienta a reconocer ciertos tipos de resultados para clasificar futuras ejecuciones, y podemos fácilmente observar los resultados desde los gráficos dispuestos en los dashboards.
En la forma en la que lo trabajamos nos resultó útil poder utilizar diferentes tipos de reportes, adaptarlos a la herramienta mediante un script e importarlos en Report Portal con la información necesaria, tanto de los tests, como el link hacia la herramienta de ejecución, que en este caso es Jenkins.
