Mostrando entradas con la etiqueta jmeter. Mostrar todas las entradas
Mostrando entradas con la etiqueta jmeter. Mostrar todas las entradas

jueves, 15 de diciembre de 2011

Ruta relativa de los ficheros desde JMETER

MERDE! Después de traducirlo y probarlo, resulta que la solución que pongo a continuación sólo funciona para ficheros de entrada y salida de los listeners, pero no para scripts externos en samplers. ¡SHIT! ¿Alguien sabe cómo se podría hacer también para samplers?

En los distintos sitios donde podamos hacer referencia a ficheros externos al plan de pruebas, las rutas de los mismos se pueden especificar de dos maneras distintas:
  • ruta absoluta
  • ruta relativa
Las rutas relativas se resuelven en base al directorio actual de trabajo (que por defecto es bin/, donde se encuentra el jmeter.sh o jmeter.bat). A partir de la versión 2.4 de JMeter (aleluya!), existe la posibilidad de utilizar rutas relativas al directorio que contiene el fichero correspondiente al plan actual de pruebas (el fichero JMX). Para ello, la ruta debe comenzar con "~/" (o lo que hayas definido en la propiedad jmeter.save.saveservice.base_prefix, que normalmente se encuentra comentada en el fichero bin/jmeter.properties). En ese caso, las rutas se asumirán como relativas a la localización del fichero JMX.

#jmeter.save.saveservice.base_prefix=~/

Si cambiamos la propiedad y tenemos pensado ejecutar el plan de pruebas en otras instalaciones de jmeter, tendremos que redefinir en ellas también dicha propiedad. Por lo que, por lo general, lo mejor es dejarla como está, para evitarnos quebraderos de cabeza en la portabilidad.

El texto original, que he traducido, se puede encontrar en la sección de listeners del manual de JMeter.

Tiene toda la lógica, y no se entiende que no se haya incluido desde el principio. Desde que apareció la posibilidad de añadir elementos externos al plan de pruebas, debía existir de referenciar esos elementos con relación al fichero de definición del plan y no al ejecutable de jmeter. Así puedo empaquetar y compartir los elementos propios de un plan de pruebas, sin necesidad de restringir la instalación de JMeter en los demás equipos donde quiera que se ejecute.

viernes, 15 de abril de 2011

JMETER - asignar a una variable el resultado de una operación matemática sobre otra variable

Si quiero que el valor de una variable en Jmeter (asignación en la interfaz gráfica del Jmeter, dentro de un elemento de configuración, como "User defined variables" o un elemento de pre-procesamiento como "User parameters") sea el resultado de una operación matemática sobre el contenido de otra variable de jmeter, puedo usar la función "__jexl", por ejemplo de la siguiente manera, para asignar a MI_VARIABLE el resultado de multiplicar por dos el contenido de la variable OTRA_VARIABLE_JMETER:
MI_VARIABLE --> ${__jexl(${OTRA_VARIABLE_JMETER}*2)}

Si OTRA_VARIABLE_JMETER no contuviera un valor numérico, por ejemplo su valor fuese "s", entonces el resultado de la operación anterior sería 0 (cero).

jueves, 14 de abril de 2011

Como probar un script BeanShell en un fichero desde consola

En JMETER tenemos la posibilidad de ejecutar scripts BeanShell localizados en ficheros externos.

Por ejemplo, en la asignación de una variable de usuario en un módulo de pre-procesamiento, puedo querer asignarle el resultado de un script BeanShell localizado en un fichero "fichero.bsh".

Para probarlos desde la consola de comandos podemos ejecutar el siguiente comando:
java -cp rutaBaseDeLaInstalacionDeJmeter/lib/bsh-2.0b5.jar bsh.Interpreter ficheroScriptBeanShell.bsh

Creo que si se tiene instalado el intérprete bsh, también podemos ejecutar directamente:
bsh ficheroScriptBeanShell.bsh

Referencia desde Jmeter


¡Importante!: La ruta relativa del fichero con el script, debe ser relativa al directorio del script que ha invocado jmeter. Si he ejecutado directamente dirJmeter/bin/jmeter.bsh o dirJmeter/bin/jmeter.bat, entonces la ruta deberá ser relativa a dirJmeter/bin/. Y si he invocado el script rutaMiScript/miScript.sh que a su vez internamente ha llamado al dirJmeter/bin/jmeter.sh, entonces la ruta del fichero con el script BeanShell que ponga dentro de Jmeter tendrá que ser relativa a rutaMiScript/.

En caso de que queramos asignarle a la variable el resultado de ejecutar todo el fichero con el script BeanShell tendríamos, dentro de JMeter, la asignación siguiente:
MI_VARIABLE --> ${__BeanShell(source("rutaFichero/ficheroScriptBeanShell.bsh");)}

También podemos, en vez de ejecutar todo el fichero, invocar un método concreto. Para ello, primero incluimos el script con la misma invocación que en el caso anterior y luego a continuación invocamos el método-

¡Importante! La llamada al método del script de BeanShell debe tener escapadas las comas.
MI_VARIABLE --> ${__BeanShell(source("../wsPlans/ficheroScriptBeanShell.bsh");miMetodo("parametroTextoA"\,"parametroTextoB"\,3\,"parametroTextoC");)}

lunes, 21 de marzo de 2011

Jmeter - Variables compuestas con counter

Si queremos utilizar variables propias cuyo valor, o parte de éste esté en función de la variable counter, deberemos declarar nuestras variables, en vez de como "Config element -> User defined variables", como "Pre processors -> User parameters". Al parecer es debido a que las "user defined variables" se inicializan antes que el counter y probablemente una única vez por instanciación del hilo, mientras que las variables definidas en el pre processador, se generan cada vez (yo por ejemplo las puse como pre proceso de un controlador, así que se generan en cada invocación del controlador). Y como como el counter se inicializa antes que los pre-procesos, éstos ya pueden obtener el su valor correctamente. El counter, como elemento de configuración, se instancia antes que los pre-procesadores, aunque el elemento vaya colocado en el mismo nivel del árbol, detrás de los susodichos pre-procesadores.

Así podremos tener variables compuestas, definidas como MI_VARIABLE_${VAR_COUNTER}.

Yo por ejemplo, lo utilice para poder generar una batería de test para un conjunto de de nombres de usuario, uno distinto para cada iteración.

Ejemplo



Definí los posibles valores de usuarios en el nodo de "User Defined Variables". Para ello, todas las variables que quería recorrer con el controlador For, tienen el mismo prefijo, en este caso 'lolaUser' y tras el separador (también podría no haber usado el separador), números consecutivos.:

jmeter for controllerY luego en el For Controller, hago referencia a dichas variables, por el prefijo que comparten "lolaUser". Como he usado el separador, también he tenido que marcar la opción correspondiente. El valor para cada iteración se guarda en la variable especificada en el controlador FOR, en el registro "output variable name", en éste caso la llamé PROFILE, a la que posteriormente podré acceder dentro de los distintos nodos dentro del bucle con ${PROFILE}:

jmeter for controller

jueves, 10 de marzo de 2011

JMeter - trucos del regular expression extractor

Al usar el "Regular Expression Extractor":

Para almacenar en la variable "kk" todos los matches, poner en "Match No." -1. De ésta forma, si tenemos 3 matches, cada uno se guardará en la variable "kk_1", "kk_2", "kk_3". Si hubiera N matches para el patrón que hayamos especificado, entonces se guardarían todos en "kk_1", "kk_2", ... "kk_N".
La variable "kk_matchNr" contendrá el número de matches (coincidencias) que se han obtenido/guardado.

Para ver todas estas cosas, añadiríamos "Debug Sampler" y el listener "View results tree", donde en la pestaña "Response data" de la ejecución de cada "Debug sampler" se puede ver el contenido de todas las variables de jmeter (y si lo indicamos en el debug sampler, también podemos ver las propiedades y las variables de sistema) existentes.