Pruebas de rendimiento en CI – Hazlo con Agile

Contenido

• 1.Introducción
• 2.¿Por qué deberíamos incluir pruebas de rendimiento en nuestro entorno de integración continua, sprint reviews o reuniones diarias?
  • 2.1. Evitar el descubrimiento tardío de problemas de rendimiento
  • 2.2. Hacer cambios antes cuando son más baratos
  • 2.3. Tener la oportunidad de refactorizar cuando tenemos una cantidad pequeña y no un código complejo
  • 2.4. Refactorizar código «fresco»
  • 2.5. Confianza
• 3. Para tener en cuenta
  • 3.1. Auto mantenimiento / Automatización
    • 3.1.1. Configurar el esquema de destino
    • 3.1.2. Inicie sesión y obtenga todos los encabezados de solicitud necesarios para realizar solicitudes hacia el back-end
    • 3.1.3. TearDown
  • 3.2. ¿Cuándo ejecutar el pipeline de una prueba de rendimiento?
  • 3.3. Incluyendo al miembro del equipo de control de calidad en las reuniones del comienzo de cada sprint
• 4. Conclusión

1. Introducción

Durante los últimos 10 años, cada vez más compañías están renunciando al antiguo enfoque en cascada para el desarrollo de software y están utilizando enfoques ágiles más flexibles. Las prácticas de desarrollo ágil están ayudando a cualquier equipo a lograr un tiempo de entrega más rápido, adaptándose constantemente a los cambios en los requisitos y proporcionando retroalimentación al final de cada sprint. Todos sabemos que el rendimiento es uno de los factores principales para que cualquier producto de software moderno sea un ganador en el mercado. Algunos de los beneficios del rendimiento y las pruebas de carga son saber cuánta carga puede cargar en su aplicación, si es necesario reconfigurar la red, si se debe optimizar el código o no, cómo se comporta el sistema en diferentes máquinas, etc.

Por lo tanto, en las siguientes secciones, veremos por qué incluir pruebas de rendimiento dentro de la integración continua mejora nuestros proyectos, nos ahorra tiempo y dinero y facilita la refactorización y la solución de problemas de rendimiento.

2. ¿Por qué deberíamos incluir pruebas de rendimiento en nuestro entorno de integración continua, sprint reviews o reuniones diarias?

• • • 2.1 Evitar el descubrimiento tardío de problemas de rendimiento
      Si hacemos una sola prueba de rendimiento al final del ciclo de desarrollo, y la prueba indica problemas, nos enfrentamos a dos dificultades:
      a) Al final del ciclo de desarrollo, los desarrolladores a menudo se ven presionados por los plazos y no tienen tanto tiempo para depurar y refactorizar. Lo que podría ser estresante.
      b) Navegando difícil hacia el problema: la ejecución de la prueba de rendimiento al final del ciclo de desarrollo puede indicar problemas, pero dado que se han aprobado tantas versiones, será más difícil para el equipo de desarrollo resolver estos problemas y mejorar el sistema. Entonces, ¿por qué no ejecutar la prueba de rendimiento al final de cada sprint? De esta manera, podemos detectar problemas temprano y depurarlos fácilmente porque sabemos que el problema ocurrió en el último sprint.
  • • 2.2 Hacer cambios antes cuando son más baratos
      Al trabajar con Agile, sabemos que el costo del cambio es menor y que cualquier equipo puede responder rápidamente a los cambios, pero aún así, somos conscientes de que el costo del cambio puede aumentar significativamente si tenemos que hacer refactorización o resolver problemas de rendimiento en un entorno de producción. Entonces, ¿por qué no incluir una prueba de rendimiento en el pipeline y ejecutarla en un determinado período de tiempo para detectar problemas durante la fase de desarrollo?
  • • 2.3 Tener la oportunidad de refactorizar cuando tenemos una cantidad pequeña y no un código complejo
      Tener que hacer refactorización al final del ciclo de desarrollo es más difícil porque el ciclo se está completando y debemos tener cuidado para no romperlo. O hacer que se desempeñe peor. Siempre es más fácil refactorizar un rompecabezas más pequeño e incompleto que uno grande y terminado.
  • • 2.4 Refactorizar código ‘fresco’
      Para los desarrolladores ágiles es realmente importante tener comentarios «ahora». Es un gran dolor para los desarrolladores verse obligados a refactorizar o depurar el código que escribieron hace meses. Siempre es mejor refactorizar una característica recién hecha. También es algo malo porque estos desarrolladores van a dedicar más tiempo a corregir el código antiguo en lugar de centrarse en las tareas actuales.
  • • 2.5 Confianza
      No importa qué herramienta de prueba de rendimiento vaya a utilizar, al final, siempre se generará un informe. Podemos archivar los informes de las pruebas y en un caso de problema o queja del lado del cliente como «hey, su aplicación está funcionando mal y lentamente, haga algo»: siempre puede mostrarles los informes de su back-end funcionando perfectamente o indicando problemas en la infraestructura del cliente (por ejemplo, un problema de red).

  3. Para tener en cuenta

  

  3.1. Auto mantenimiento / Automatización

  Lo primero que debe considerar al desarrollar una prueba de rendimiento para pipeline de CI es auto mantenimiento. Su prueba debe ser autosostenible y debe (por ejemplo):

  • • 3.1.1 Configurar el esquema de destino – Limpie la base de datos de destino y vuelva a llenarla con los datos que serán necesarios para que se ejecute la prueba.Como tendrá diferentes escenarios de prueba, necesitará un conjunto adecuado de datos en el esquema que utiliza. Además, es importante insertar una gran cantidad de filas para poner carga también en la base de datos y no solo en el back-end.
  • • 3.1.2 Inicie sesión y obtenga todos los encabezados necesarios para realizar solicitudes hacia el back-end – Considerando que cualquier API moderna debe tener un cierto nivel de seguridad, su prueba debe poder iniciar sesión en el sistema para que pueda hacer solicitudes más adelante en su flujo. Eso incluye todo, desde hacer una simple solicitud Http hasta obtener encabezados específicos, tokens y cualquier otra cosa requerida desde el back-end para que usted pueda realizar solicitudes.
  • • 3.1.3 TearDown – Cualquier prueba bien hecha debe ejecutar las funciones tearDown después de que la ejecución del escenario de prueba haya finalizado para «limpiar el desorden». Algunas herramientas de prueba nos brindan posibilidades de revertir para que podamos poner el esquema en el estado en que se encontraba antes de la prueba. Si no, la prueba debería al menos limpiar el esquema desordenado y muy cargado.

  3.2. ¿Cuándo ejecutar el pipeline de una prueba de rendimiento?

  • • ¿Cada noche?
    • ¿Con cada compilación de la rama de desarrollo?
    • ¿Al final de cada sprint?

  No importa lo que digan los demás, es una cuestión de preferencias del equipo decidir cuándo ejecutar la canalización de una prueba de rendimiento. Algunas personas prefieren establecer el tiempo de ejecución programado automático cada noche. Algunos dicen que es necesario hacerlo al final de cada sprint. Algunas de las personas están ejecutando las pruebas en cada compilación de la rama de desarrollo. Desde mi punto de vista, es suficiente programar el pipeline para que se ejecute al final de cada sprint, ya que si lo ejecutamos todos los días, debería haber una persona con la tarea de descargar los artefactos del informe y revisar cada día, lo que podría ser molesto e ineficiente.

  3.3. Incluyendo al miembro del equipo de control de calidad en las reuniones del comienzo de cada sprint

  Un factor realmente importante para la integración exitosa de las pruebas de desempeño en CI es involucrar al menos a un especialista en aseguramiento de la calidad en las primeras reuniones de cada sprint. De esta manera, se informará al evaluador de lo que se va a desarrollar y podrá escribir escenarios de prueba y describir los casos de prueba. Gracias a esto, el QA puede comenzar a escribir la implementación de la prueba.

  El problema aquí es que si está utilizando TDD y no confía en un equipo de pruebas para garantizar la calidad del producto, es necesario que haya un desarrollador que sepa cómo usar y escribir en al menos una herramienta para las pruebas de carga. Además, ese desarrollador debe estar familiarizado con las mejores prácticas para elaborar una prueba de rendimiento.

  4. Conclusión

  Al final, creo que vale la pena dedicar tiempo a desarrollar e integrar las pruebas de rendimiento en integración continua porque le brinda a tu equipo muchos beneficios como:

  • Encontrar problemas relacionados con el rendimiento del código del sistema.
  • Detectar problemas de infraestructura como problemas de red.
  • Localizar problemas de rendimiento de la base de datos en una carga más grande.
  • Dar a los desarrolladores la oportunidad de refactorizar el código cuando es menos complejo y fresco.
  • No luchar contra los problemas de rendimiento al final del ciclo de desarrollo, lo que ahorra dinero y tiempo.
  • Garantizar a los usuarios obtener nuevas features, no nuevos problemas de rendimiento.

   

  Cualquier equipo de desarrollo que esté trabajando con Agile puede incluir los resultados de la prueba de rendimiento en cada revisión de sprint o en reuniones diarias, haciendo uso de todos los datos que se generaron en el informe, vigilando semanalmente el rendimiento del sistema.

  Algunas de las herramientas principales para el rendimiento y la prueba de carga
  son Apache JMeter, Grinder framework , Gatling.