Pruebas de performance con Taurus en Integración Continua con Travis-CI

En este post voy a compartir parte del trabajo de los alumnos del curso de testing de la UCU en 2017, que expliqué el objetivo en este otro post. Esta vez comparto la sección dedicada a pruebas de performance, donde utilizaron Taurus en Integración Continua con Travis-CI.


La tarea se realizó utilizando el sitio Opencart a modo de sitio de prueba.

Se tuvieron en cuenta varias herramientas, pero al final se decidió proceder con Taurus por su simplicidad para integrar en un enfoque de CI/CD (en este post se puede ver cómo utilizar Taurus con Jenkins). El objetivo era simular múltiples usuarios accediendo al mismo tiempo y poder tomar medidas de los tiempos de respuesta y el throughput alcanzado, para irlo comparando en cada cambio que implique una ejecución del pipeline en Travis-CI.

Preparar script en Taurus

Para realizar un test en Taurus en primer lugar hay que crear el archivo con el script. Este archivo puede ser JSON o YML, la única diferencia entre estos es su sintaxis. Este archivo puede ser simple o complejo, gracias a que Taurus tiene muchas opciones resueltas por defecto que se pueden modificar. Incluso, se puede utilizar un script ya hecho en JMeter, Gatling u otras herramientas. En este caso, se decidió hacer el script directamente en Taurus.

Básicamente, en este script se enumeran las siguientes propiedades de la prueba:

  • execution – En esta sección se describen todas las propiedades de ejecución de la prueba, tales como la cantidad de usuarios que se quieren simular y la duración de la prueba, entre otras cosas.
  • scenario – Descripción de las acciones que deben realizar cada usuario virtual. Es el script en sí mismo con la serie de pasos a simular.
  • reporting – Se enumeran todos los módulos de reportes que se emiten durante la prueba, a su vez, en la sección criteria se definen los criterios de pass-fail.
  • settings – Allí se define qué herramienta utilizar para ejecutar la prueba. Por defecto se usa JMeter. (Se puede definir otro ejecutor como Gatling, Selenium, Locust, entre otros).

Para la tarea se realizaron dos scripts de pruebas de performance para poder seguir con el plan de ejecuciones (ver cómo definir un plan de ejecuciones de pruebas de performance).

En la primera se simuló a un único usuario que accede a la página de manera repetitiva durante un minuto. Esto se suele denominar “baseline“, ya que la prueba se utiliza para medir los mejores tiempos de respuesta que puede brindar la página, cuando no hay concurrencia.

En la segunda prueba de performance que se realizó se especificó realizar una simulación con 10 usuarios concurrentes. Estos 10 usuarios están activos conjuntamente durante un minuto, y tiene un período de ramp-up de 30 segundos (donde la cantidad de usuarios sube progresivamente hasta llegar a 10).

Para cada script, se describió la acción que realizan los hilos (para la tarea se hizo un script muy simple con un solo request a la página http://open-cart.azurewebsites.net/). Luego se enumeraron los módulos de reportes que se van a realizar, los cuales son el módulo de reportes de Taurus, la consola y el módulo de reportes de Blazemeter.

Por último, se definieron los criterios de aceptación de las pruebas. Estas pruebas se consideran fallidas si el tiempo promedio de respuesta supera los 8 segundos durante un tiempo determinado o si el percentil 90 asociado a los tiempos de respuesta supera los 13 segundos durante un tiempo determinado. Todo esto fue a modo de ejemplo.

Se pueden añadir muchas más especificaciones a las pruebas, en las referencias hay un link al manual de usuario de Taurus.

Ejecución de las pruebas

A continuación se presenta una captura de una prueba realizada como ejemplo. Allí se puede ver que la prueba falló porque el tiempo promedio de respuesta supera los 8 segundos.

Se puede apreciar que el tiempo promedio de respuesta para las pruebas de un usuario es de 7,50 segundos y para las pruebas de diez usuarios es de 10,50 segundos. El aumento del tiempo de respuesta cuando aumentan los usuarios fue del ~40%.

Integración de Taurus con Travis-CI

Para lograr la ejecución automática de las pruebas con Taurus desde Travis-CI, en primer lugar se añadieron las dos pruebas al repositorio Github. Una vez hecho esto se agregaron las dependencias requeridas (Java y Python) por el programa en la sección packages del archivo travis.yml.

Luego se procede con la instalación y la actualización del mismo, añadiendo los comandos en la sección before_install.

Por último se ejecutan las dos pruebas previamente añadidas al repositorio Github.

Se integra de una manera sencilla. Se instala de la misma forma que en cualquier plataforma con todas las dependencias correspondientes. Se colocan los tests en el repositorio y se ejecutan los tests de la misma forma que en cualquier consola:

bzt nombre-de-la-prueba.yml
Lo ideal es deshabilitar el reporte en pantalla de los tests realizados y que solamente brinde reportes mediante la consola. Si se coloca una restricción a los tiempos de respuesta (como se muestra en el ejemplo) y se viola dicha restricción, el test resulta fallido.

 

 

En el siguiente video se encuentra una demostración de como funciona:

 

One thought on “Pruebas de performance con Taurus en Integración Continua con Travis-CI

Leave a Reply

Your email address will not be published. Required fields are marked *