Escenarios en JMeter armados a la LoadRunner

Para los que no conocen mi historia, soy oriundo de Load Runner. Es decir que mi carrera de scripter de pruebas de carga comenzó y se desarrolló en su mayoría con esa herramienta.

Cuando comencé a trabajar con JMeter me enamoré de sus funcionalidades. Pero sufrí al tratar de generar escenarios un poco más complejos en el modo en el que LoadRunner lo hacía sin mucho problema. Incluso, LoadRunner maneja la parte de creación de escenarios en una herramienta completamente separada de la herramienta usada para creación de el script.

Lamentablemente JMeter no divide claramente esto pues en la misma interfaz maneja todo. Tanto como la creación de el (o los) script(s), el armado de escenario y la ejecución, todo en el mismo programa.

Esta diferencia me causó problemas al tener que hacer pruebas con más de 5 casos de prueba simultáneos. Se veía ya caótico con 5 scripts, llegar a 10 o incluso 15 iba a ser un enorme contratiempo manejarlos desde la misma herramienta. Sin mencionar el mantenimiento se puede volver complejo y difícil de distribuir con un equipo de scripters.

¿ Cómo le hago ? #

Mi primer impulso fue usar la herramienta como viene. Sin hacer nada fuera de lo que ya trae. Y como mencione arriba, la ejecución se volvió rápidamente un infierno de crear, mantener y trabajar con ella.

Después de luchar con este problema me di por vencido y decidí intentar algo. Guiándome por lo que conocía del mundo de LoadRunner intenté mimetizar un poco el modo de crear escenarios simplemente jalando scripts para editar cada uno por separado.

Después de algunos ajustes tuve éxito armándolos de este modo. Así que ahora comparto con ustedes como lograr esto en simples pasos con explicaciones que pueden facilitar la vida de un equipo de pruebas de carga. En especial cuando diferentes personas trabajan en diferentes automatizaciones para el mismo escenario y no tienen un ambiente cloud.

Paso 1 #

Lo primero es tener un archivo JMX por cada proceso de negocio que nuestra prueba de carga va a ejecutar. No hacer copias ni pegados de otras automatizaciones juntando múltiples procesos en el mismo archivo. Solo un test case en cada uno.

Pero a diferencia de pasos tradicionales aquí vamos a poner todos los pasos de nuestra automatización bajo un TEST FRAGMENT. Nada de thread controller ni nada. Tratemos de poner limpios los pasos Y al grano con lo que vamos.

Solo agregamos los componentes HTTP referentes a cada uno. Los REQUEST DEFAULTS y HTTP COOKIE MANAGER deben ser agregados y configurados en caso de ser necesarios.

Paso 2 #

Otro paso importante para que esto funcione es declarar los “think time” de un modo global para ser aplicado por igual en los pasos pertinentes separado en cada script. Pero primero para esto debemos crear un USER PARAMETER con el cual vamos a trabajar.

Le vamos a llamar variable de Think Time o tiempo de pensamiento. En ella podemos asignar un número fijo (expresado en milisegundos) o un número aleatorio alrededor de ese número fijo. Es recomendable el aleatorio para no tener tiempos de espera iguales y arriesgarnos a perder realismo en la prueba.

Paso 3 #

Ahora, en cada paso en el que tenemos que agregar el Think Time (no todos los pasos deben de llevarlo) agregamos un CONSTANT TIMER al final pero dentro de cada HTTP REQUEST.

Una vez agregado el CONSTANT TIMER, simplemente le asignamos el nombre de el USER PARAMETER que creamos en el paso 2. Es decir ponemos en el Thread Delay - “${ThinkTime}”. O el nombre que se haya asignado para la variable.

Al final repetimos agregar esto en cada HTTP REQUEST que debe llevar el think time. De este modo simplemente modificamos el USER PARAMETER y todo lo demás será actualizado.

Una vez completados estos pasos para cada paso en cada uno de nuestros procesos de negocio, ahora si pasamos a armar el escenario. Podemos cerrar los scripts.

Paso 4 #

Para crear el escenario vamos a comenzar con un proyecto vacío de JMeter. Lo primero que vamos a agregar es lo que necesitemos de Listeners y reporteadores. Les recomiendo tener al menos el VIEW RESULTS TREE asi como el BACKEND LISTENER (o JSR233) que utilicen para enviar los resultados a alguna plataforma como InfluxDB.

Ahora, por cada script que queremos tener en nuestro escenario, vamos a agregar un THREAD GROUP y por sanidad mental vamos a nombrar cada uno como nombramos nuestro proceso de negocio.

A cada THREAD GROUP le asignaremos los settings necesarios por cada proceso de negocio como el ramp up o la duración y el número de threads para cada uno.

Paso 5 #

Dentro de cada uno vamos a agregar 3 elementos:

• USER PARAMETERS
• INCLUDE CONTROLLER
• FLOW CONTROL ACTION Cada uno de estos va a cumplir diferentes funciones.

El elemento de USER PARAMETER lo vamos a utilizar para definir algunos RTS (Run Time Settings) estilo LoadRunner. Dentro de él vamos a declarar como mínimo la cantidad de tiempo a esperar entre cada iteración. Como es recomendable no tener valores fijos de nuevo asignamos máximos y mínimos para nuestro random.

Recomiendo no irnos muy fuera de rango y respetar una variación de un 5 o 10%. Es decir si necesitamos un pacing de 5 segundos, podemos poner máximos y mínimos de 4.5 y 5.5 segundos. Recuerden poner todo en milisegundos.

Como se puede ver en la imagen, le cambie el nombre a el USER PARAMETER por RTS. Esto lo hago simplemente para identificar mas facil cuando estoy trabajando con ellos. O incluso si alguien externo necesita modificar el escenario, el nombre lo hace más indicativo.

Paso 6 #

Ahora en el INCLUDE CONTROLLER simplemente vamos a enlazarlo con el vinculo a la ubicación de nuestro script.

Recomiendo ampliamente agregar ubicaciones de carpetas compartidas o públicas. Incluso si los scripts están en la máquina local es mejor tener todo como carpeta compartida para evitar problemas de alcance o que nuestro escenario quede limitado a correr en una sola máquina. Podemos así mover el archivo del escenario y correrlo desde donde se nos venga en gana (siempre y cuando la carpeta compartida sea alcanzable).

Con esto cuando ejecutemos el escenario, JMeter va a cargar los pasos y los va a ejecutar de un modo más limpio y sencillo de organizar.

Paso 7 #

Ahora procedemos a el FLOW CONTROL ACTION que agregamos al final de cada uno. Este es el que va a ejecutar el tiempo de espera en iteraciones. Es por esa razón que lo he puesto al final, para que el tiempo de espera suceda después de que el script complete sus pasos en una iteración.

Recomiendo llamarlo “Pace” para que sea evidente lo que hace este paso. Vamos a seleccionar el radio button de pausa “Pause” para indicar que cada elemento se debe detener ahí. Después en la parte de duración (Duration) vamos a agregar el siguiente código que automáticamente va a randomizar la duración de la pausa:

                  ${__Random(${RndPaceMin},${RndPaceMin})}

Con esto va a jalar los valores que definimos antes en los RTS. Eso basta para que quede configurado nuestro Pacing. No es necesario seleccionar nada más en ese elemento.

Paso 8 #

Al completar el primero THREAD, se puede optar por duplicarlo para crear cada thread y después configurar solo lo indicado en cada elemento. Cuidado, esto puede prestarse a errores de olvidar poner la configuración correcta.

Ya si es uno muy diligente se pueden repetir los pasos por cada script. Es importante asegurarse que cada THREAD tenga los elementos descritos.

Listo #

Con estos pasos felices podrán ejecutar escenarios complejos y felices y ser felices ingenieros de prueba de carga. Felices scripteos amigos! Besos <3