JMeter: User Defined Variables vs. Properties vs. Parameters


En esta nueva entrada vamos a ver el tema de las distintas definiciones de variables que tenemos en JMeter. Es importante tener en claro las diferencias entre los distintos conceptos para luego aplicarlos en nuestros escenarios de prueba según nos sea más beneficioso.

Las principales diferencias se encuentran en como se define su valor, su alcance y cuando pueden ser actualizadas.

User Defined Variables (UDVs)

Es el elemento más básico y estático de definición, y nos permite definir un conjunto inicial de variables. Se pueden definir utilizando la sección de variables en el elemento Test Plan o agregando un elemento de configuración “User Defined Variables” en alguna posición de nuestro Test Plan.

Test Plan - UDVs
Test Plan - UDVs
Elemento de Configuracion - UDVs
Elemento de Configuracion - UDVs

Se recomienda que se coloquen en el comienzo del grupo de hilos para una más fácil lectura del Test Plan. Al empezar a correr el test se procesan todos los UDVs del Test Plan y se envían a los hilos el grupo de variables iniciales. Se usan mas que nada para definir variables de la prueba que no necesitan ser actualizadas durante la ejecución como HOST, PORT, etc….

Son referenciadas de la forma ${nbreVariable}

¿Cuando se define su valor?

Sin importar donde estén ubicadas, se definen al arrancar el test en el orden en que aparecen en el test plan desde arriba hacia abajo.

¿Cuál es su alcance?

Su valor se comparte entre los distintos grupos de hilos (Thread Groups) del Test Plan.

¿Cuándo se puede actualizar?

Su valor se define al arrancar el test y luego no es actualizado, salvo que alguna de las variables UDVs tenga el mismo nombre que una variable definida en User Parameters o asignada por un elemento Regular Expression Extractor, lo que provoca que se actualice el valor inicial y todos los otros elementos de prueba del hilo pueden ver el valor actualizado.

Limitaciones

  • Si ponemos un elemento UDVs en un Loop o cualquier otro tipo de iteración en busca de  actualizar su valor, esto no ocurrirá (salvo la excepción ya detallada).
  • No pueden referenciarse antes de ser procesadas, es decir, no puedo hacer referencia a una variable definida en el mismo elemento de configuración UDV o en algun elemento de configuración UDV anterior al de referencia.

Properties

Este elemento se divide en 3 archivos que podemos encontrar en la carpeta bin: jmeter.properties, system.properties y user.properties. No son lo mismo que las variables, las variables son locales del hilo, las properties son comunes para todos los hilos.

Si queremos ver los valores de las properties desde la interfaz gráfica de JMeter, lo podemos hacer agregando el elemento “Property Display”.

Son muy útiles cuando necesitamos correr varias pruebas con distintos archivos .jmx o en pruebas de testing distribuido ya que son independientes del Test Plan que deseamos ejecutar.

Son referenciadas con las funciones:

  • ${__P(nbreProperty)}
  • ${__property(nbreProperty)}

¿Cuando se define su valor?

Se definen en el archivo propertie y su valor se setea cuando abrimos JMeter (ejecutamos jmeter.bat).

¿Cuál es su alcance?

Son globales a todo el Test Plan, es decir, pueden referenciarse desde cualquier grupo de hilos.

¿Cuándo se puede actualizar?

Se pueden actualizar con la función setProperty() en cualquier momento de la corrida.

Limitaciones

  • Como se definen al ejecutar JMeter, si abrimos JMeter por GUI,  y luego durante la edición del Test Plan cambiamos el user.properties(o el property que hayamos modificado) no vemos los cambios en las ejecuciones ya que para eso tendríamos que cerrar JMeter y volverlo a abrir.
  • Hay que tener cuidado cuando en nuestro Test Plan tenemos funciones del tipo setProperty() ya que en cada ejecución esas properties serán creadas y permanecerán creadas hasta que cerremos JMeter.

User Parameters

Nos permite definir valores de variables para cada hilo específico. En el caso en que existan más hilos de los definidos en la asignación de  valores por variable, JMeter empieza a tomar los valores desde el primer hilo nuevamente.

User Parameters
User Parameters

Es muy útil para cuando tenemos corridas con pocos usuarios y necesitamos que los mismos sean de distintos roles o ingresen distintos valores, es decir, es una misma corrida los distintos usuarios ejecutan el escenario con datos totalmente independientes entre sí. Se van agregando VUs y los valores correspondientes para cada una de las variables definidas.

Son referenciadas de la forma ${nbreVariable}

¿Cuando se define su valor?

Sin importar donde estén ubicadas, se definen al arrancar el test.

¿Cuál es su alcance?

Solo tienen visión de estas variables los elementos que se encuentran dentro del Grupo de Hilos.

¿Cuándo se puede actualizar?

Se pueden actualizar en cualquier lugar dentro del Grupo de Hilos y en cada nueva ejecución del grupo de hilos(en caso de que el mismo tenga Loops),  salvo que se active el check “Update Once Per Iteration” lo cual solo actualizara su valor en la primera iteración del grupo de hilos.

Limitaciones

  • No es muy útil para corridas con muchos usuarios o muchas variables ya que para esas situaciones es mucho más óptimo el funcionamiento y uso del CSV Data Set Config.

4 pensamientos en “JMeter: User Defined Variables vs. Properties vs. Parameters”

    1. Hola Neftaly,

      Selenium RC puede ser utilizado para pruebas de performance basadas en Tiempos de Respuesta ya que solo deberíamos codificar las funciones que nos midan los tiempos que tarda la aplicación en realizar determinadas actividades. Lo he utilizado y es muy útil para aquellas aplicaciones web que tienen muchos componentes JS y CSS que determinan el tiempo de renderizar la pantalla ya que podemos ver el tiempo real(tiempo de llegada del ultimo byte + tiempo que tarda en renderizar la pantalla) de espera para el usuarios final. Esto se puede combinar con JMeter si se busca jenerar carga de usuarios desde una maquina y ver otras metricas (como rendimiento, etc..) al mismo tiempo que se corren los scripts de Selenium RC para ver los tiempos de respuestas reales.

      Es un tema muy interesante ya que al mismo tiempo se pueden reutilizar los scripts de las pruebas automatizadas.

      Hoy en día empresas como Browsermob prestan servicios de performance testing con Selenium.

      Gracias por el valioso comentario.

      Saludos,

      José

      Me gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s