Desde hace un tiempo venimos trabajando en entregar a nuestros clientes scripts de JMeter que les permita ejecutar de manera rápida y sencilla sus pruebas de performance con la ayuda de BlazeMeter.
Sabemos que muchas veces estos scripts son ejecutados por equipos que no necesariamente tienen un entrenamiento en JMeter pero aún así muchas veces desean tener la posibilidad de aplicar modificaciones y entender el script que les estamos entregando.
![]()
Para esto estamos, desde hace un tiempo, trabajando en construir scripts que resulten intuitivos y comprensibles para quien no es un experto en JMeter y que puedan sin mayor dificultad leer, entender y modificar nuestros scripts para luego ejecutarlos desde BlazeMeter.
Es así que a partir de este trabajo hemos construido una checklist la cual revisamos antes de entregar cualquier script. Esta checklist reúne una serie de buenas prácticas las cuales hoy queremos compartir con ustedes.
![]()
Observar que además estamos cumpliendo lo indicado en el punto 3.
Ejemplo: banners de publicidades traen cosas de Facebook, Google Analytics, Twitter, etc.
![]()
se puede habilitar la opción Follow Redirects que van a hacer esta tarea por nosotros.
![]()
De esta forma es más fácil manejar las redirecciones, el script queda más fácil de entender, despreocupándonos de las idas y vueltas que pueden llegar a haber luego de un pedido. De otro modo habría que parsear el header de la respuesta mediante el uso de expresiones regulares y creando un HTTP Request manualmente.
Buscar qué validar en una respuesta es todo un arte, no hay un manual que trate este tema, por lo que lo podemos dejar para discutir en un próximo post :). Lo importante aquí es que no puede faltar en ningún pedido HTTP Request el correspondiente Response Assertion.
Y ya que estamos con las validaciones, me gustaría además agregar un detalle que se da en los casos de redirección. Cuando se nos presenta un redirect, en el request padre (Darth Vader) debemos validar lo que sería la respuesta del último pedido que fue desencadenado por el redirect y no la respuesta del pedido padre. Esto es un detalle que JMeter lo valida así automáticamente, pero es mejor si sabemos cuál es el comportamiento ante estas situaciones.
Aún seguimos trabajando en esta checklist así que los animamos a que nos compartan sus experiencias y nos ayuden a mejorar esta lista. Esperamos que este artículo les haya sido de utilidad.
Sabemos que muchas veces estos scripts son ejecutados por equipos que no necesariamente tienen un entrenamiento en JMeter pero aún así muchas veces desean tener la posibilidad de aplicar modificaciones y entender el script que les estamos entregando.
Para esto estamos, desde hace un tiempo, trabajando en construir scripts que resulten intuitivos y comprensibles para quien no es un experto en JMeter y que puedan sin mayor dificultad leer, entender y modificar nuestros scripts para luego ejecutarlos desde BlazeMeter.
Es así que a partir de este trabajo hemos construido una checklist la cual revisamos antes de entregar cualquier script. Esta checklist reúne una serie de buenas prácticas las cuales hoy queremos compartir con ustedes.
1. Eliminar todos los elementos de log
Muchas veces agregamos en nuestro script elementos de log para poder debuggear cualquier error que pueda surgir en el proceso de construcción del script, pero una vez terminado el script, antes de entregarlo, conviene quitar estos elementos para que esto no impacte en la performance de la generadora de carga (máquina desde la cual se ejecuta la simulación de la carga, de los usuarios virtuales concurrentes con JMeter). Hay casos en los que el script de por sí utiliza muchos recursos de la máquina generadora de carga, pero si además le agregamos que esté siempre escribiendo en disco cada request y response agregamos una carga innecesaria.2. No agregar pedidos secundarios
Todos aquellos pedidos que se caracterizan por ser estáticos y que vienen como recurso embebido de un pedido primario (imágenes, archivos css, javascript, etc.), no son necesarios en los scripts. Esto es porque en JMeter, entre las opciones de un elemento HTTP Request correspondiente a un pedido primario, podemos habilitar la opción Retrieve All Embedded Resources que genera el siguiente comportamiento:- Se envía en pedido primario (el del HTTP Request en cuestión)
- Al obtener la respuesta (archivo HTML) se parsea y se buscan automáticamente todos los recursos embebidos en el HTML
- Para cada elemento reconocido se ejecuta un HTTP Request.
3. Agregar un nombre representativo al Thread Group.
El nombre con el que nombramos el elemento Thread Group debe ser representativo al caso de prueba o flujo que se está automatizando. Con esto ayudamos al cliente a analizar un script que no tiene un nombre que solo el tester entiende sino que lo puede entender cualquiera que esté involucrado con el caso de prueba.4. Agrupar por grupo de acciones.
Todo guión de prueba se compone de una serie de acciones de usuario, por ejemplo: Cargar el sitio, login, click en ofertas, seleccionar un artículo, comprar artículo, confirmar la compra. Todas estas acciones involucran un conjunto de pedidos HTTP que pueden ser agrupados en bloques mediante el uso de Transaction Controller al cual se le puede configurar un nombre de controlador.Recomendamos que ese nombre sea el mismo a la acción que está englobando para que el cliente pueda fácilmente tener trazabilidad entre el guión de pruebas y el script. Por ejemplo:
Observar que además estamos cumpliendo lo indicado en el punto 3.
5. Verificar la inclusión de pedidos a servidores externos.
Hay veces que, al realizar una acción en la aplicación, se desencadenan pedidos que no necesariamente son al host de la aplicación. En estos casos siempre conviene corroborar con el cliente si es de su interés analizar la performance de este host (o sea, si ese host también es parte del SUT - sistema bajo pruebas), porque en el caso que no lo sea ese pedido HTTP se puede omitir ya que no genera tráfico al servidor que se está queriendo evaluar y evitamos tener pedidos en nuestro script que no son necesarios.Ejemplo: banners de publicidades traen cosas de Facebook, Google Analytics, Twitter, etc.
6. No incluir redirecciones.
Los redirect son pedidos que son ejecutados por redirección de un pedido HTTP anterior a éste. Típicamente al ejecutar un pedido HTTP, el código de respuesta del pedido es un 301 o 302 que en el header de la respuesta viene un parámetro Location con la URL a la que se debe redirigir el pedido. En JMeter no es necesario generar un HTTP Request para estos pedidos ya que en el HTTP Request del pedido, llamémosle padre:
se puede habilitar la opción Follow Redirects que van a hacer esta tarea por nosotros.
De esta forma es más fácil manejar las redirecciones, el script queda más fácil de entender, despreocupándonos de las idas y vueltas que pueden llegar a haber luego de un pedido. De otro modo habría que parsear el header de la respuesta mediante el uso de expresiones regulares y creando un HTTP Request manualmente.
7. Incluir validaciones en todos los pedidos HTTP primarios
Las validaciones o Response Assertion en JMeter son la manera que tenemos de validar que la respuesta que estamos obteniendo del servidor es correcta. La herramienta solo verifica el código de respuesta, y si no es un error 5XX o 4XX dirá que fue correcta, pero tal vez se pierde de muchos otros problemas que puedan ocasionarse, con lo cual es necesario hacer una mínima validación que nos asegure que estamos siguiendo el flujo que queremos.Buscar qué validar en una respuesta es todo un arte, no hay un manual que trate este tema, por lo que lo podemos dejar para discutir en un próximo post :). Lo importante aquí es que no puede faltar en ningún pedido HTTP Request el correspondiente Response Assertion.
Y ya que estamos con las validaciones, me gustaría además agregar un detalle que se da en los casos de redirección. Cuando se nos presenta un redirect, en el request padre (Darth Vader) debemos validar lo que sería la respuesta del último pedido que fue desencadenado por el redirect y no la respuesta del pedido padre. Esto es un detalle que JMeter lo valida así automáticamente, pero es mejor si sabemos cuál es el comportamiento ante estas situaciones.
8. Usar HTTP Request Defaults
Todos los elementos de configuración HTTP Request tienen su espacio para configurar el server y el port, entre otros. Por un tema de practicidad nunca es bueno dejar este valor hardcode ya que si el script es extenso y nos cambian estos valores al momento de ejecutar, ya que es muy común que automaticemos en un ambiente de pruebas y luego ejecutemos en distintos ambientes, en pruebas, pre-producción, producción, en distintos entornos de diferentes clientes, etc, es una tarea engorrosa ir pedido por pedido cambiando estos valores. Para que se hagan una idea, en mi último proyecto teníamos 14 scripts con 40 a 50 requests cada uno. Para prevenir esta situación, hacemos uso de del elemento de configuración HTTP Request Defaults. En este elemento vamos a poder configurar el server y port por defecto al cual querramos que vayan los pedidos de nuestro script y de esta manera, si en todos los HTTP Request dejamos en blanco los valores de server y port el pedido se va a dirigir a los que se especifiquen en el HTTP Request Defaults. Es una manera sencilla para que luego el cliente sepa dónde configurar estos parámetros.Aún seguimos trabajando en esta checklist así que los animamos a que nos compartan sus experiencias y nos ayuden a mejorar esta lista. Esperamos que este artículo les haya sido de utilidad.
