JMETER

JMeter's Classpath: JMeter automaticamente encuentra las clases de archivos jars en los siguientes directorios:

JMETER_RAIZ/lib – usado para utilidades: librerias, etc. Colocar los jars y Jmeter encontrá la utilidad automaticamente dentro del jar.

JMETER_RAIZ/lib/ext – componentes y add-ons desarrollados para Jmeter.

Los jars como JDBC,JMS implentaciones deben ser colocados en la carpeta lib.

1. Elementos del Plan de Pruebas

Un plan de pruebas en JMeter es un conjunto de elementos que configuran el comportamiento de los tests que se van a llevar a cabo sobre un software.Una vez definido el plan de pruebas los elementos dentro de dicho plan se incorporan mediante del menú contextual:

Para guardar un plan de pruebas completo tal cual lo creamos, seleccionamos “Save Test Plan as”. Notar que tambien podemos guardar elementos o partes del script que queramos. Estos scripts se guardan con extensión “.jmx”.

1. Grupo de hilo(Thread Group): Son el punto de comienzo de cualquier plan de pruebas. Todos los controladores (controllers) y muestradores (samplers) deben ser ubicados dentro del grupo de hilos. Otros elementos como los repectores(listeners) pueden ser ubicados directamente debajo del plan depruebas, en cuyo caso, se aplicará a todos los grupos de hilos.Cada hilo se ejecutará independientemente de los demás hilos. Mulitples hilos pueden utilizarse para simular conecciones concurrentes al servidor.El periodo de subida, le dira a JMeter en cuanto tiempo quiero que se carguen todos los usuarios especificados en el grupo.Con el “planificador” podemos configurar cuando se quiere empiece y termine una prueba. Entonces cuando ejecutamos la prueba, JMeter esperará si es necesario a que se cumpla la hora en que se planificó la prueba.

2.

Controladores(Controllers): Muestradores(Samplers) y Controlador logico(Logical Controllers). El muestrador le dice Jmeter que envíe una petición al servidor. El controlador logico maneja las desiciones que toma Jmeter a la hora de ejecutar la prueba.

2.1. Muestradores(Samplers): Envian peticiones al servidor y esperan una respuesta. Son ejecutadasen el orden que aparecen en el arbol. Los controladores pueden ser utilizados para modificar el numero de repeticiones de un muestrador. Los muestradores pueden ser:

HTTP Request JDBC Request Java object request LDAP Request SOAP/XML-RPC Request FTP Request WebService (SOAP) Request

Si vamos a enviar multiples peticiones del mismo tipo (por ejemplo HTTP Request) al mismo servidor, considerá usar un “Defaults Configuration Element”. Cada controlador tiene por lo menos uno. Tambien recordar agregar un Receptor para ver y guardar los datos de los resultados de la peticion.Agregar una asercion al muestrador para validar una respuesta. Por ej., en una prueba de stress, el servidor deberia devolver una respuesta satisfactoria “HTTP Response”. Poddiramos agregar una asercion para corroborar que ciertos tags HTML. Se pueden usar expresiones regulares.

Petición HTTP:

Este sampler permite enviar peticiones HTTP/HTTPS a un servidor.

Petición FTP: Este sampler permite enviar peticiones a un servidor FTP.

Petición JDBC: Este sampler permite enviar peticiones a una base de datos.

2.2.

Controladores logico: Nos permite decidir el flujo y las decisiones que tomará JMeter según cierta informaccón que nos devuelva la prueba.

Controlador Only Once: ejecutará todo lo que este debajo una sola vez.

Controlador Interleave: permite ejecutar un sampler intercalado con otros. Por ej., si una sampler1 esta en el mismo nivel del interleave, por cada sampler que este por debajo de este,se ejecutara el sampler1.

Controlador simple: permite organiza samplers y otros controladores lógicos. No proporciona ninguna otra funcionalidad. Su único objetivo es agrupar peticiones. JMeter maneja las peticiones de la misma forma que si no estuvieran dentro de un controlador simple.

Controlador bucle (Loop controller): Como su nombre indica, permite realizar iteraciones.

Random controller: Selecciona uno de los samplers hijo de formaaleatoria.

Runtime controller: Controla cuanto tiempo se ejecutan sus hijos.

If controller: Este controlador impone una condición para que se puedan ejecutar los elementos hijo que alberga.

3.

Receptores(Listeners): Nos muestra la información que nos va devolviendo la prueba. Todos los receptores nos devuelven los mismos datos, con la diferencia que cada uno la muestra de manera diferente. La vista “Ver Árbol de Resultados” nos muestra detalles acerca de peticiones y respuestas, y puede mostrar HTML y XML basico.

4. Temporizadores: Por default, JMeter envia peticiones sin pausar entre cada petición. Podemos agregar un “delay” por cada peticion con este elemento. Si no se añaden retrasos entre peticiones, JMeter puede sobrecargar un servidor. Un timer genera un retraso entre las distintas peticiones enviadas. Se procesan antes que los samplers que se encuentran en su alcance (scope). Si hay variossamplers en el mismo alcance, todos ellos se ejecutan antes que los samplers.

Cosntant Timer:

Gaussian Random Timer:

5. Aserciones: Nos sirve para corroborar que nuestro test devuelve la respuesta esperada. Podemos agregar una aserción a cualquier Sampler. Por ej., podemos agregar una aserción a una “Petición HTTP” que checkee que se encuentra el testo “</HTML>”. Si el texto no aparece, JMeter marcará que esta respuesta falló. Para ver los resultados de las aserciones, agregar el listener “Assertion Listener” al grupo de hilos.

De respuesta: Esta aserción comprueba que la respuesta coincide con un determinado patrón.

De

duración: Esta aserción comprueba que la respuesta se recibe en un determinado tiempo. Cualquier respuesta que tarde más de un número dado en milisegundos se marcará como respuesta fallida.

HTML: Permite al usuario comprobar la sintaxis HTML de la respuesta.

6. Elementos de configuración(Configuration Elements): El elemento de configuracion trabajará cerca de un muestrador. Un elemento de configuracion solo es accesible dentro de la rama del arbol donde se ubica el elemento. Estos elementos permiten definir una configuración por defecto que posteriormente se aplicará sobre samplers.

FTP Request Defaults: Permite definir parámetros de configuración por defecto para peticiones FTP. Cualquier sampler ftp puede asumir dichos parámetros como propios.

HTTP Request Defaults: Permite definir parámetros de configuración por defecto para peticiones HTTP. Cualquier sampler HTTP puede asumir dichos parámetros como propios.

HTTP Cookie Manager: La incorporación de este elemento permite a JMeter gestionar las cookies asociadas a una aplicación web.

HTTP Authorization Manager: Este elemento permite configurar uno o más procesos de login asociados a aplicaciones.

7. Pre-Procesors Elements: ejecuta alguna acción antes de que se ingrese a un muestrador. Suele utilizarse para modificar la condiguración de un sampler antes de ser corrido, o para actualizar las variables que no son extraídas de la respuesta.

8. Post-Procesors Elements:ejecuta alguna acción luego de que se ingresó a un muestrador.

9. Orden de ejecución:

0. Pre-Processors 1. Timers 2. Sampler 3. Post-Processors (unless SampleResult is null) 4. Assertions (unless SampleResult is null) 5. Listeners (unless SampleResult is null)

2. Uso de variables

Variables definidas por el Usuario(User defined variables(UDVs)): Se encuentra dento del TEST PLAN en “Elementos de configuración->Variables definidas por el Usuario”. 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 “Variables definidas por el Usuario” en alguna posición de nuestro TEST PLAN.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}.

Además de una variable en particular, podemos utilizar un vector de variables definiendo las variables del siguiente modo:

Donde ${inputVar} es un vector de variables que luego puede ser accedido con un foreach.

Propiedades(Propierties): Se encuentra dentro de BANCO DE TRABAJO en “Elementos NoDePrueba->Visualizador de Propiedades”. 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 “Visualizador de propiedades” al BANCO DE TRABAJO. Son referenciadas con las funciones:

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

La diferencia entre ambas es que la función "P" no permite asignar la propiedad a una variable, solodevuelve el valor de aquella al referenciarla, mientras que la funcion "property" si permite la asignación a una variable en la misma llamada a función. Por ejemplo:

${__property(abcd,ABCD,atod)}

asigna el valor de la propiedad abcd a la variable ABCD, y si no está definida esa propiedad, le asigna el valor atod. Son globales a todo el Test Plan, es decir, pueden referenciarse desde cualquier grupo de hilos. Se pueden actualizar con la función setProperty() en cualquier momento de la corrida. Para conocer más acerca de las funciones y como utilizarlas, podemos dirigirnos a la barra superior y en la pestaña “Opciones” seleccionar “Diálogo de Ayuda de Función”.

Parámetros de Usuario(User Parameters): Se encuentra dentro de PLAN DE PRUEBAS en “Pre Procesadores->Parámetros de Usuario”.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.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}.

3. Simular usuarios extraidos de archivo CSV

Un archivo CSV es un archivo que contiene datos separados por un “separador” definido por la persona quien creo el archivo, lo que da una estructura de filas y columnas, donde cada columna representa una información especifica del dato que representa la fila. Por ej., un archivo denominado usuariosCD.csv contiene:

Para levantar este archivo de usuarios en JMeter y luego utilizarlo para emular un usuario en cada hilo se puede realizar lo siguiente.Creamos un elemento de configuración CSV, para esto hacemos click derecho sobre el test plan y vamos a Añadir->Elemento de Configuracion->Configuración del CSV Data Set

Lo cual crea un elemento de configuracion para un archivo CSV. En este archivo podemos ver la siguiente configuración:*Nombre del archivo: ruta donde se encuentra el archivo CSV.*Codificacion del fichero: como esta codificado, lo dejamos vacio.*Nombre de Variables: aquí vamos a poner los nombres de las variables que luego vamos a utilizar separadas por coma.*Delimitador: es el delimitador que sse utilizó en el archivo CSV.*¿Permitir datos entrecomillados?: para permitir que los datos ingresados esten entre comillas.*¿Reciclar en el fin de archivo?: si seleccionamos true, cuando no haya más datos, comenzará nuevamente por el primer dato.

temporalusertest@gmail.com|1Temporaluser|1juan.zaragoza@teracode.com|123456aA|1cysadmin@cys.com.ar|1234aA|1hola@email.com|123412|1

Una vez hecho, por cada hilo que JMeter vaya creando a la hora de la ejecución utilizará un dato extraído del CSV. Para utilzar estos datos, por ej., en un formulario de login podemos hacer lo siguiente en una petición de login:

donde se ve que el campo email es rellenado con ${usuario} que es la variable nombrada en la Configuración del CSV Data Set.

4. Modular JMeter

Cuando las pruebas son muy largas o repetitivas podemos esctructurar la prueba en diferentes modulos para poder reutilizarlo.

Como un “Modulo” podemos utilizar un “Cotrolador simple”. Esto nos permite poner diferentes elementes dentro y darles determinada funcionalidad. En la imagen debajo, vemos un modulo llamado “A few things crouped together”.

Este modulo puede ser utilizado aunque sea deshabilitado. Luego creando un “Control de módulo” en otra región del test donde queramos usar esta pórción de código, pasandolo como “Module To Run” el “Controlador simple” creado anteriormente.

También, como se muestra en la figura, podemos crear un controlador simple que agrupe otros controladores para crear un paquete de modulos.

5. Correr Jmeter sin la interfaz grafica

Para un testeo no interactivo, podemos correr Jmeter sin la GUI.-n Especifica que Jmeter se va a correr sin la interfaz grafica.

-t [nombre del archivo JMX que contiene el Test Plan].

-l [nombre del archivo JTL para mostrar el log de resultados].

-j [nombre del archivo log].

-r corre el test en los servidores especificados por la propiedad de Jmeter “remote_hosts”.

-R [lista de servidores remotos] Corre el test en el servidor remoto especificado.

Al script tambien le podemos especificar la informacion del servidor firewall/proxy:

-H [direccion hostname o ip del servidor proxy] -P [puerto del servidor proxy]

Example : jmeter -n -t my_test.jmx -l log.jtl -H my.proxy.server -P 8000

6. Pruebas Distribuidas(Ejecuciones simultáneas desde diferentes máquinas)

Una vez generados los planes de prueba y tras ver cómo responde el servidor frente a ellos, quizá sedesee dar un paso más y ver cómo actúa el servidor frente a clientes provenientes de distintos orígenes.La opción más sencilla es lanzar la misma prueba desde varias máquinas a la vez, pero ¿y si se desea lanzar las pruebas a la vez para ver cómo responde el servidor frente a peticiones simultáneas desde diferentes máquinas? o ¿si la prueba dura relativamente poco y para cuando se lanza el segundo plan de pruebas desde otra máquina el primero ya ha terminado? Esta solución resulta un poco engorrosa y no representa una opción demasiado apetecible si desea probar la misma prueba desde un número elevado de máquinas.Pensando en este sentido, el Apache JMeter presenta un formato de ejecución remoto que permite lanzar una prueba desde distintas máquinas sincronizadamente. Esto permite realizar pruebas más completas y darles una connotación más real.

El proceso de ejecución remota lleva una serie de etapas:

1a Etapa. Iniciar los clientes remotos:Lo primero que se debe hacer es lanzar el Apache JMeter en todas las máquinas que se van a usar como clientes menos una, pero en lugar de ejecutar el fichero habitual se usará el jmeter-server | jmeter-server.bat (según sistema operativo). Con esto los clientes se quedarán esperando a recibir las instrucciones de la máquina que no se ha lanzado en ese modo.

2a Etapa. Especificar los clientes en modo servidor al cliente principal:El segundo paso es configurar la máquina que se usará para gestionar la prueba. A esta máquina le se le especifica las direcciones de las otras máquinas. Para hacer esto se edita el fichero de configuración jmeter.properties (que se encuentra en el directorio bin/) y se añade en el campo "remote_hosts" los sucesivos host’s de las máquinas que tenemos en espera.

3a Etapa. Iniciar las pruebas:Ahora ya se esta preparado para ejecutar el jmeter | jmeter.bat (según sistema operativo) en la máquina que gestionará las pruebas. Al cargar el entorno gráfico observaremos que el menú run (lanzar) tiene dos sub-menús remotos (arrancar y parar). En estos sub-menús ahora aparecen los host’s que antes se han añadido; estos host’s valdrán para controlar la ejecución del plan de prueba en esas máquinas de forma remota (según se lance o se pare el plan de prueba en esas máquinas).

7. Analisis gráfico

Veamos el siguiente gráfico creado por un plugin de JMeter que fue instalado externamente. Este plugin se encuentra en http://rubenlaguna.com/wp/wp-content/uploads/2007/01/stataggvisualizer.zip

Para instalarlo, lo descomprimimos y veremos una carpeta “lib”, el contendio de esta, lo copiaremos dentro de la carpeta “lib” del directorio raiz de nuestro JMeter. Luego, para agregar el grafico nos dirigimos a Añadir->Receptor->Statistical Aggregate Report y se nos agregará a nuestro Plan de Pruebas el gráfico mencionado.

En este gráfico notamos algo interesante: es mucho más fácil de leer que los gráficos que nos da pordefecto JMeter. Del lado izquierdo y en negro tenemos la curva que representa las “peticiones por unidad de segundo”, mientras que del lado derecho y en azul tenemos los tiempos de respuesta en “segundos”.

Si nos ponemos a analizar a grandes rasgos este gráfico podemos notar que hay una relación directaentre los tiempos de respuesta y las peticiones hechas. Al prinicipio del gráfico: tanto las peticiones como los tiempos de respuesta aumentan, esto es de esperarse ya que al arrancar la prueba se van cargando usuarios que realizan peticiones y por lo tanto aumentan los tiempos de respuesta del servidor debido a la carga de los mismos. Luego, vemos que hay un punto clave: en este punto las peticiones por segundo comienzan a bajar de manera considerable y los tiempos de respuesta comienzan a aumentar, lo cual indica que el servidor está tardando en devolver una respuesta y por lo tanto, JMeter no tiene peticiones que hacer hasta no recibir esas respuesta. Mas tarde, pasando la hora 13:11:30 vemos otro punto donde las pendientes cambian: vemos que la pendiente de los tiempos de respuesta disminuye y por lo tanto la caida de peticiones por segundo tambien disminuye. Despues de pasado un tiempo justo a las 13:12:00, vemos un minimo en los tiempos de respuesta y un máximo en peticiones por segundo: el test llego al máximo de peticiones y el sistema responde rapidamente; luego las peticiones bajan y el sistema demora en responder. Mirando el resto del gráfico podemos intuir el compartamiento del sistema frente a la intensidad y respuesta de las peticiones.