Conoce paso a paso cómo crear pruebas de performance con JMeter DSL a partir de scripts de Selenium. ¿Te perdiste mi charla en Selenium Conf 2023? En este artículo, resumo mi presentación, con el fin de que aprendas cómo reutilizar las pruebas de Selenium y verificar el correcto funcionamiento de un sitio, aún en momentos de alta demanda.
![¿Cómo crear pruebas de performance con JMeter DSL a partir de scripts de Selenium?](https://es.abstracta.us/wp-content/uploads/2024/04/pruebas-performance-jmeter-dsl-scripts-selenium-1024x575.png)
Selenium Conf 2023 brindó un espacio para compartir experiencias y profundizar sobre las mejores prácticas relacionadas con las pruebas automatizadas. El evento permitió valiosos intercambios y grandes aprendizajes, sumamente valiosos para el desarrollo de software de mejor calidad.
Con el fin de reforzar este propósito, comparto en este artículo el paso a paso de cómo crear pruebas de performance a partir de scripts Selenium. ¡Empecemos!
Frecuentemente, como testers, necesitamos reutilizar pruebas implementadas con Selenium para verificar que un sitio funciona correctamente aún en momentos de alta demanda.
¿Cómo reutilizamos esas pruebas? Hay muchas maneras de hacerlo. Hoy me voy a centrar en la forma en que lo presenté en el evento, a la cual considero sumamente útil para lograr este cometido.
En primer lugar, es necesario que agregues una dependencia de Maven y un pequeño código de inicialización a tu prueba de Selenium existente. Con este código incluido en la prueba de Selenium, corres la prueba para generar la prueba de performance, y luego ejecutas el test para evaluar el comportamiento de la aplicación.
Puedes encontrar el ejemplo compartido en mi presentación durante la Selenium Conf 2023 en este repositorio de código fuente. Te sugiero comprobar el README para más detalles. Me gustaría destacar que el repositorio contiene una aplicación para probar, una prueba de Selenium para la aplicación, un módulo para facilitar la generación de pruebas de performance a partir de pruebas de Selenium, infraestructura para recolección de estadísticas y presentación en dashboards, e instrucciones sobre cómo generar y ejecutar la prueba de performance.
Configuración de la grabación
El código de dependencia e inicialización implica el uso de una extensión JUnit, la cual inicia y detiene automáticamente el grabador JMeter DSL al comienzo y fin de una prueba Selenium.
Como parte de este código de inicialización, será necesario que especifiques la clase base de los page objects que se utilizan. ¿Cuál es el objetivo de esto? Generar una prueba de performance que pueda medir el tiempo empleado en cada página mientras se ejecuta una prueba de carga generada en paralelo con la prueba de Selenium existente.
De esta manera, podemos medir adecuadamente el impacto en la experiencia del usuario mientras se inyecta la carga en el sistema.
Además, el código de inicialización incluye la configuración de la grabadora como proxy del Selenium WebDriver. Esto permite que la grabadora capture cada solicitud y respuesta al servidor backend para, luego, crear la prueba de carga utilizando la API Java de JMeter DSL.
![Dependencia Maven](https://miro.medium.com/v2/resize:fit:630/1*8nxwxriAHHBrJYflBQgZjQ.png)
![Pruebas Selenium con código de inicialización](https://miro.medium.com/v2/resize:fit:630/1*EeL2IJF3FAu-PJN5XLh3rw.png)
Generación de pruebas de performance
En este momento, ya puedes ejecutar tu prueba de Selenium. El grabador de JMeter DSL generará una clase Java con un método de prueba de carga y uno principal. Te recomiendo revisar la prueba de carga generada para asegurarte de que las llamadas al servidor backend grabadas sean las que esperas. Si no es así, puedes ajustar la configuración del grabador para que se adapte a tus necesidades, como excluir URL o cabeceras que no son relevantes para tu prueba, y grabar la prueba de nuevo.
![Prueba de performance generada](https://miro.medium.com/v2/resize:fit:630/1*vBCSLycBHmTwt05VBEhdcQ.png)
Validación de pruebas de performance
En general, antes de generar una carga y ejecutar las pruebas de performance, es recomendable verificar que el plan de pruebas o cargas se ejecutan sin problemas y no es necesario realizar más ajustes, tales como la parametrización de solicitudes o la correlación de respuestas y solicitudes.
Con el fin de validar el plan de pruebas, puedes añadir un `resultsTreeVisualizer()` y ejecutar el método de prueba de carga, manteniendo la configuración del grupo de hilos en 1 hilo y 1 iteración, con el objetivo de ejecutar el plan de pruebas solo una vez.
![Visualizador del árbol de resultados](https://miro.medium.com/v2/resize:fit:630/1*UmvYzQ50dqXNVJrriOJc8w.png)
Ajuste de las pruebas de performance
En caso de que necesites alguna parametrización, dado que algunas peticiones fallan debido a datos dinámicos, puede que quieras definir reglas de correlación que no están cubiertas en la presentación. Si es así, te sugiero chequear el Read Me del repositorio, en el cual puedes obtener un ejemplo de cómo definirlas y utilizarlas.
También te recomiendo comentar el código donde se usa `influxDbListener`, lo cual no es relevante para esta validación.
Después de comprobar que todas las peticiones y respuestas han funcionado como esperabas, deberías eliminar `resultsTreeVisualizer()`.
Ahora es el momento de ajustar la configuración del grupo de hilos para generar la carga real en el backend del servicio probado. Para ello, puedes cambiar el número de hilos e iteraciones o utilizar el método `rampToAndHold, el cual proporciona una mayor flexibilidad sobre el perfil de carga a generar.
Te recomiendo comprobar que la duración total del perfil de carga coincida con el valor de Duration en el método principal de la clase, para que tanto el backend como el frontend se ejecuten durante el mismo tiempo, ya que por defecto está configurado para 5 minutos.
![Thread groups con algunos ramp ups](https://miro.medium.com/v2/resize:fit:630/1*pSRy1RaQuvEAL1HhWb_t6A.png)
Antes de ejecutar la carga de prueba, necesitarás realizar algunas configuraciones y limpiezas adicionales. En primer lugar, añadí las configuraciones adecuadas, para que las pruebas de performance puedan enviar las estadísticas recopiladas a InfluxDB con el fin de poder luego generar informes con Grafana. Para esto, te sugiero consultar el archivo Readme del repositorio.
En el caso de que hayan comentado el `influxDbListener`, descomentalo, y elimina la inicialización de la extensión del grabador JUnit de Selenium Test.
Ejecución de la prueba de performance
Ha llegado el momento de ejecutar la prueba de performance y revisar cómo se comporta el sistema. Para ello, basta con que ejecutes el método main de la clase generada por el grabador. Esto disparará la prueba de carga del backend, a la vez que se ejecuta la prueba de Selenium en un bucle durante el tiempo configurado.
Mientras se ejecuta el test, puedes comprobar en tu dashboard de Grafana cómo se está comportando el sistema, y cómo la carga en el backend está afectando al tiempo empleado por el test de Selenium en cada página. Recuerda que tu dashboard de Grafana debería haber sido configurado previamente, junto a InfluxDB. Puedes consultar más detalles en el fichero `docker-compose.yml` del repositorio.
![](https://es.abstracta.us/wp-content/uploads/2024/04/crear-pruebas-performance-jmeter-dsl-scripts-selenium-1024x519.png)
Escalado de la prueba de performance
Con frecuencia, generar carga con una sola máquina puede resultar insuficiente, y es posible que necesites utilizar un cluster de máquinas para generar suficiente carga y verificar el comportamiento adecuado de tu sistema bajo una carga significativa.
Para ello, puedes utilizar uno de los motores proporcionados por JMeter DSL, como BlazeMeter, Octoperf o DistributedJMeter, y ejecutar tu prueba de carga desde un clúster de máquinas con bastante facilidad.
![Dependencia Maven del motor BlazeMeter](https://miro.medium.com/v2/resize:fit:630/1*bsoQe7J4sF8GDhwUSYP6nw.png)
![Funcionamiento con el motor BlazeMeter](https://miro.medium.com/v2/resize:fit:630/1*F5B8xRzPrKFuN_nS5mzJAg.png)
Algunas consideraciones para el enfoque presentado
✅El proyecto proporcionado es un ejemplo de cómo puedes reutilizar las pruebas de Selenium y verificar el correcto funcionamiento de un sitio, aun en momentos de alta demanda mediante JUnit 5, Java 19, Selenium 4.8, Chrome 111. Además, cómo hacerlo midiendo el tiempo en las páginas de Selenium y comprobando los tiempos de creación de Page Object.
Recuerda que puedes utilizar el ejemplo para crear una integración similar para las versiones o tecnologías concretas que utilices en tu caso. Considera que JMeter DSL es independiente del framework de pruebas (JUnit, TestNG), es compatible con Java 8+, y no tiene relación directa con Selenium.
✅Aunque en este escenario se estén utilizando InfluxDB y Grafana, puedes optar por otras tecnologías para la generación de informes, tales como Elasticsearch, Prometheus, Kibana, etc.
¿Te gustaría escuchar mi charla completa? Te invito a hacerlo en nuestro canal de Youtube.
Si quieres saber más sobre JMeter DSL, te recomiendo revisar nuestros releases, el repositorio de cambios, el canal de discusión, y formar parte de la comunidad.
Entra a nuestra User Guide y despeja todas tus dudas sobre JMeter DSL.
¡Síguenos en LinkedIn, Twitter, Facebook, Instagram y YouTube para conocer más sobre nuestra cultura y ser parte de nuestra comunidad!
Posts Relacionados
Testing de performance, llave maestra para mejorar tu software
Fallas en sistemas y mal rendimiento ante alta demanda impactan en las tasas de retención y conversión, así como en la sostenibilidad y escalabilidad de las empresas. Descubre cómo el testing de performance ayuda a revertir esta situación.
¿Qué es el rendimiento en las pruebas de performance?
Las pruebas de performance buscan mejorar la eficacia y preparación de las aplicaciones de software. En el centro de este proceso, encontramos una métrica clave denominada “rendimiento”. Nos adentramos en los matices del rendimiento y su importancia.