Creando un histórico de los resultados de Geb – Parte II

Introducción

En el post anterior Creando un histórico de los resultados de Geb – Parte I, vimos de donde se encontraban los resultados de las pruebas lanzadas con Geb y que datos podían ser interesantes de extraer para crear nuestro histórico.

En este caso vamos a tratar de hablar de como extraerlos y almacenarlos para poder explotarlos en un futuro.

Planificación de la extracción de datos

Si nos encontramos en un entorno de CI en el que disponemos de proyectos de automatización, es posible que lancemos las pruebas de forma planificada. Por ello lo más interesante sería poder lanzar el extractor de resultados una vez se hayan ejecutado las pruebas.

Ejemplo:

extractor

Disponemos de un servidor Jenkins en el que la ejecución de las pruebas funcionales se encuentran planificadas (Job 1).

  1. A la hora planificada se ejecuta el job 1, lanzando las pruebas funcionales.
  2. Cuando termine la ejecución de las pruebas funcionales el Job 1 llamará al Job 2, el extractor de datos.
  3. El extractor obtendrá los datos del fichero de resultados de las pruebas ejecutadas por el job 1.
  4. El extractor insertará los datos obtenidos en la base de datos.

Extractor de datos

El proyecto lo he desarrollado en Groovy, pero es posible desarrollarlo en otros lenguajes con las librerías adecuadas.

Como podemos ver en el método, extraer los datos del xml de resultados es muy sencillo.

  1. Mediante XmlParser procesaremos el fichero xml de resultados, con lo que podremos acceder a sus datos fácilmente:
    def results = new XmlParser().parse(url)
  2. Iteramos por cada test suite de tal forma que tenemos acceso a los datos del mismo. Es importante recalcar que para obtener el valor de un atributo utilizaremos @[atributo].
    results.testsuite.each { testsuite ->
    ...
    println "Parsing: ${testsuite.@name} "
    ...
    }
  3. Al igual que hemos iterado por cada test suite también debemos iterar por cada test case. En este caso comprobaremos la existencia de mensajes de “error” o “failures” .
    testsuite.testcase.each { testcase ->
    ...
    if(testcase.failure.size() != 0) {
    println "Status ${STATUS_KO} - Failure"
    println "Message: ${testcase.failure.@message}"
    }else if (testcase.error.size() != 0){
    println "Status ${STATUS_KO} - Error"
    println "Message: ${testcase.error.@message}"
    }
    ...
    }

Si estáis interesados en conocer mejor como procesar los xml en groovy podéis visitar el siguiente enlance:

http://groovy-lang.org/processing-xml.html

Almacenar y explotar los datos

El donde y el como depende mucho del proyecto de automatización en el que nos encontremos y de las tecnologías de las que hagamos uso.

En mi caso los datos los almaceno en una base de datos relacional, creando así el histórico. He desarrollado una aplicación web sencilla en grails donde ver el histórico de los resultados y graficar los datos.

test suite resume

test cases

Lo importante es adaptar y diseñar correctamente el esquema de la base de datos en base a los datos que queramos extraer y explotar. Una vez que vamos almacenando el histórico de datos listarlos, graficarlos etc.

Conclusiones

Crear un histórico de los resultados de las pruebas automáticas nos aporta grandes beneficios en el análisis de los mismos. Teniendo esta fuente de conocimientos podremos hacer retrospectivas para ver si hemos ido ganando cobertura, si tenemos menos falsos positivos etc.

Lo principal es conocer la fuente de los datos y analizar los datos que nos aportan y los que nos interesa para nuestra finalidad. Buscar la mejor forma de procesar los datos y almacenarlos en una base de datos que podamos explotar puede ser la parte más compleja.

Enlaces a la serie de post

  1. Creando un histórico de los resultados de Geb – Parte I

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *