JMeter

 

JMeter

Jmeter
es una herramienta Java dentro del proyecto Jakarta, que permite realizar Pruebas
de Rendimiento y Pruebas Funcionales sobre Aplicaciones Web.

Existen un gran número de herramientas para realizar
pruebas, gratuitas (JUnit, JWebUnit) y de pago (LoadRunner), pero JMeter
destaca por su versatilidad, estabilidad y por se de uso gratuito.

 

En las siguiente direcciones podemos ver un buen resumen de
herramientas: http://www.softwareqatest.com/qatweb1.html

http://www.webtesttools.com/

 

Descarga:

 

http://jakarta.apache.org/jmeter/

 

 

Nos descargamos la aplicación pulsando en la opción
“Download Binary”:

 

Descomprimimos el paquete en el directorio que deseemos.

Ej.: C:\java\jakarta-jmeter-2.0.2

 

 

Necesitamos tener una Maquina Virtual Java 1.3 o superior
instalada en nuestro sistema operativo (Windows en nuestro caso).

En caso de problemas definir la variable JAVA_HOME apuntando
al path del JDK que tengamos instalado en nuestra máquina,

JAVA_HOME=C:\j2sdk1.4.1_02  , y añadir el directorio bin de
Java al path del sistema:

PATH=%JAVA_HOME%/bin;%PATH%

Antes de ejecutar el archive “jmeter.bat”, o bien editamos
el archivo y añadimos ambas líneas al principio del mismo.

Ejecutamos el archivo: jmeter.bat

 

JMeter permite realizar pruebas Web clásicas, pero también
permite realizar test de FTP, JDBC, JNDI, LDAP, SOAP/XML-RPC, y WebServices (en
Beta).

 

JMeter también permite la ejecución de pruebas distribuidas
entre distintos ordenadores, para realizar pruebas de rendimiento.

 

En caso de error los logs estarán en el archivo: jmeter.log

Ej: C:\java\jakarta-jmeter-2.0.2\bin\jmeter.log

 

Y definimos el “Test Plan” o “Plan de Pruebas”.

 

La parte izquierda representa la estructura o definición en
árbol del plan de pruebas, mientras que en la derecha se nos muestra un Form
que permite editar el elemento que tengamos seleccionado en la parte izquierda.

 

JMeter se basa en el concepto de “Elemento” (Element) y en
una estructura en “Arbol” (Tree). Cualquier parte o rama del árbol puede ser
guardada de forma independiente, para ser reutilizada en otras pruebas.

Los “elementos” nos van a permitir configurar y definir el
plan de pruebas.

• Elementos jerárquicos:
• Listeners (elementos en escucha)
• Config Elements (elementos de configuración)
• Post-processors (post-procesadores)
• Pre-processors (pre-procesadores)
• Assertions (afirmaciones)
• Timers (cronómetros)
• Elementos ordenados:
• Controllers (controladores)
• Samplers (agentes de pruebas)

 

Al crear el Plan de Pruebas se crea una “lista ordenada” de
peticiones (request http) utilizando “Samplers” que representa los pasos a ejecutar
en el plan. Normalmente, las peticiones se organizan dentro de “controllers”. 
Algunos tipos de “controllers” afectan el orden de ejecución de los elementos
que controlan.

 

A continuación mostramos un ejemplo de uso, para que sea más
fácil entender los conceptos que maneja JMeter.

 

Sobre el Test Plan, pulsando botón derecho Add->Thread
Group creamos un “Thread Group” o grupo de hilos de ejecución para definir el
número de usuarios a simular:

 

Podemos especificar el numero de threads (hilos de ejecución)
en paralelo, así como el tiempo de arranque de cada uno, y número de
iteraciones que hará cada uno de ellos (puede marcarse como infinito). También
podemos planificar (scheduler) la ejecución de la prueba indicando la hora de
arranque y parada, o la duración del test en segundos y el tiempo de arranque
del mismo. Otra cosa que debemos tener en cuenta es la acción a realizar en
caso de error en el Test por parte del thread (continuar la ejecución, parar el
thread o parar todos los threads del test).

 

JMeter posee dos tipos de Controllers:

• Samplers (agentes de pruebas): Permiten enviar peticiones
  a un servidor. Por ejemplo un “http Request Sampler” nos permite enviar
  peticiones http hacia un servidor. Los “Samplers” se pueden configurar
  utilizando “Configuration Elements”.
• Logical Controllers (controladores de lógica): Permite
  controlar el comportamiento de la prueba, y tomar decisiones en función de
  situaciones, valores, condiciones, etc. Por ejemplo, un controlador “If
  Controller” nos permite decidir si realizar o no una petición http en
  función de una condición. Cada controlador, puede tener uno o más “Default
  Elements”

 

JMeter, nos permite crear “Default http Request Properties”,
para definir las propiedades por defectos que tendrán nuestras peticiones http
representadas por “http Request Elements”. De esta forma cuando vayamos
definiendo las distintas request, no será necesario rellenar todos los campos
de información, ya que heredarán las propiedades por defecto definidas aquí.
Por ejemplo, el nombre del servidor, el puerto, el protocolo, y algún valor que
sea necesario siempre arrastrar en la  request (cosa no habitual). Para ello
seleccionamos el controlador “Peticiones Home”, y con el botón derecho elegimos
Add->Config Element->HTTP Request Defaults

 

En nuestro caso esta configuración por defecto, se aplicará
a todas las peticiones que cuelguen de la rama “Peticiones Home”.

 

Soporte para COOKIES: Las aplicaciones Web suelen
utilizar Cookies para guardar información sobre la navegación del usuario. Para
simular dicho comportamiento, JMeter también nos propociona un elemento de
soporte de Cookies. Basta con añadir un “http Cookie Manager” al “Thread Group”.

 

 

Esto nos permite controlar las cookies, pudiendo borrar la
cookie en cada iteración del test, o establecer los valores que deseemos para
las cookies.

 

Vamos a crear un controlador simple (“Simple Controller”)
para agrupar una serie de peticiones, y le damos un nombre: Add->Logic
Controller-> Simple Controller

 

Ahora vamos a definir una petición: Add->Sampler->HTTP
Request

Y le damos un nombre: Home

 

En esta pantalla, se nos permite controlar todos los
parámetros de una request http:

• Método: GET o POST
• Path del recurso a pedir
• Redirección automática
• Seguir las redirecciones indicadas por el resultado de la
  petición,
• Use KeepAlive: Mantener la conexión viva entre distintas
  peticiones
• Envío de parámetros en la request
• Envío de un fichero adjunto a la request

Además, los parámetros que no completemos (como Server Name,
Port Number, Protocol, incluso Path si no lo especificamos) serán heredados del
elemento de configuración “http Requests Defaults” que nos precede en la
jerarquía del árbol de definición del plan de pruebas, lo que hace más cómodo y
rápido la creación del test.

 

A continuación vamos a añadir un “Assertion” para comprobar
que la ejecución de la petición anterior es correcta. Para ello pulsamos sobre
la “http Request” HOME,  Add->Assertions->Response Assertion

Añadimos la condición de que Código de respuesta sea 200,
corresponde a una página servida correctamente.

Se pueden añadir los siguientes tipos de “Assertion” cómo:

• Response Assertion, para comprobar la respuesta. Puede
  comprobarse el texto, o la URL, o el código de respuesta, o el mensaje de
  respuesta, e indicar si coincide con una serie de patrones, o no.
• Duration Assertion, para indicar un tiempo máximo de
  ejecución
• HTML Assertion, para verificar que el HTML, XML o XHTML
  esté correctamente construido (utiliza Tiny).
• MD5Hex Assertion, para verificar que la suma MD5 es la especificada
• Size Assertion, para verificar que el tamaño es <,>,
  =, etc que uno especificado
• XML Assertion, para verificar que el resultado es un XML
  bien formado
• Beanshell Assertion, para programación de pequeños shell
  scripts que realizan verificaciones a medida.

 

También se pueden añadir preprocesadores que realicen
acciones antes de enviar la Request:

• Counter: Para crear una variable contador, que puede ser
  referenciada en cualquier parte del test
• User Parameters: parámetros definidos por el Usuario, que
  nos van a permitir definir una especie de constantes dentro del test.
• HTML Link Parser: Parsea la respuesta HTML del servidor, y
  extrae los links y forms.
• HTML Parameter Mask
• HTTP URL Re-Writing Modifier
• HTTP User Parameter Modifier

 

También se pueden añadir postprocesadores que realicen
acciones después de enviar la Request:

• Regular Expresión Extractor: Extrae cadenas de la
  respuesta (contenido o cabeceras) que cumplan una expresión regular
• Result Status Action Handler: Permite indica la acción a
  tomar después de que se produzca un error: continuar, parar el thread, o
  parar el test.
• Save Responses to a file: Permite almacenar en un fichero
  la respuesta obtenidas (todas o sólo las erróneas)
• Generate Summary Results: Resumen de información que se
  envía al stdot cada cierto tiempo (utilizado en modo batch)

 

Otra cosa que permite JMeter, es activar o desactivar una
parte del test, lo que es muy útil cuando se está desarrollando un test largo,
y se desea deshabilitar ciertas partes iniciales que sean muy pesadas o largas.

 

Se pueden encadenar las Request que se deseen, y mover los
elementos dentro del árbol:

 

En este caso, hemos creado una nueva http request, que
solicita otra página,

 

y hemos añadir una nueva “Response Assertion” llamada
“Assertion Guia” verificando el contenido de un texto,

Y hemos desplazado la “Response Assertion” que verificaba el
status = 200 al final del bloque, haciendo común esta “assertion” para las dos
peticiones “Home” y “Guía del Éxito”.

Ésta estructura en árbol, es lo que le da potencia a JMeter,
permitiendo que nuestra imaginación ponga los límites a la forma de diseñar el
Plan de Prueba.

 

Finalmente, si vamos a lanzar el test de forma interactiva,
necesitamos crear un listener dentro del “Thread Group”: Add-> Listener->Agrégate
Report”

 

 

Si ahora pulsamos CTRL+R o elegimos en el menú la opción
RUN->Stara,

Empezaremos la ejecución de nuestro Plan de Pruebas, en ese
momento se empezarán a ejecutar los threads que configuramos en “Thread Group”.
Si nos posicionamos con el ratón sobre “Aggregate Report” veremos la siguiente
información:

 

 

Otros tipos de informe que podemos generar son los
siguientes:

• Assertion Results: Muestra la URL de cada petición e
  indica los errores que se produzcan (Assertions que no se han cumplido) en
  el test.
• Graph Full Results: Simplemente muestra el tiempo
• Graph Results: Muestra un gráfico con los tiempos medio,
  desviación, throughput, etc. de la ejecución del plan de prueba.
• Mailer Visualizar: Permite enviar un e-mail si el plan de
  pruebas falla o no, o supera un determinado valor de fallos o éxitos.
• Monitor Results: Sólo funciona en Tomcat 5
• Simple Data Writer: Vuelca los resultados a un fichero.
• Spline Visualizer: Gráfico de tiempos como spline.
• Aggregate Report: Muestra una tabla con una fila por cada
  URL solicitada, indicando el tiempo min, max, medio, etc. Es una tabla que
  totaliza por URL.
• View Results in Table: Muestra una tabla con todas las
  respuestas, la URL, tiempo y resultado de ejecución de cada una de ellas.
• View Results in Tree: Muestra un árbol con todas las
  respuestas y sus tiempos.

 

Por último no olvidemos grabar el plan de pruebas: File
-> Save Test Plan

 

 

Generación automática del caso de prueba:

Otra forma que tiene JMeter de generar un caso de prueba es
a través de una navegación de usuario. Para ello, indicamos que Jmeter actué
como proxy, para capturar la navegación del caso de prueba. Pulsamos en
WorkBench con el botón derecho y elegimos “Non-Test Elements”-> http Proxy
Server.

 

Y arrancamos el servidor Proxy de JMeter

Podemos indicar que nos almacene sólo la primera “request”
de cada petición de la navegación. De esta forma descartamos las imágenes.

Una vez configurado, pulsamos el botón “Start” para arrancar
el Seridor Proxy.

 

Ahora nos vamos al navegador, y configuramos el proxy
(localhost, 8080)

 

y tecleamos la URL de la Web a probar. Ej: www.autentia.com

 

Automáticamente, Jmeter irá capturando las “request” que el
navegador realice al proxy de Jmeter, y de esta forma Jmeter se queda con una
copia del “response” de la web que estemos probando.

 

 

En nuestro caso pedimos las siguientes URLs:

http://www.autentia.com

http://www.autentia.com/guia.htm

http://www.autentia.com/guiafra.htm

 

y se nos irán grabando los elementos de cada “http Request”.

A continuación paramos el Proxy, pulsado “Stop”.

 

Podemos eliminar los que no nos interesen, y reorganizarlos
en el árbol.

Para ello creamos un “Thread Group”

 

Y un “Simple Controller” dentro del grupo:

 

Y movemos las “http Request” al “Simple Controller”,
arrastrando cada una con el ratón, y seleccionando “Add as Child”:

 

Y nos quedaría así:

 

Ahora eliminamos o modificamos los “http Head Manager” de
cada request, ya que de lo contrario el test puede que no funcione, al tener
grabado en la cabecera valores de otra sesión.

 

También es recomendable añadir un “http Cookie Manager”,
delante del controlador.

 

Ahora creamos un listener “Aggregate Report”, para ver los
resultados de la prueba:

 

Y ejecutamos la prueba, utilizando CTRL+R o la opción de
Menú:

 

 

Otra característica muy interesante de JMeter es que es
extensible, y ofrece la posibilidad de que el propio usuario desarrolle en Java
un “Controller” a medida, cumpliendo una interfaz Java, y depositando el .jar
correspondiente al desarrollo en el directorio “lib” de JMeter. Además
recordemos, que JMeter permite realizar pruebas distribuidas en distintos
ordenadores que actuarán como clientes, utilizando una especie de registro RMI.

 

Conclusiones:

Cómo hemos visto JMeter puede ser una herramienta muy útil,
para realizar pruebas funcionales, pero también para realizar pruebas de
regresión en nuestras aplicaciones, algo, que a veces es verdaderamente
complicado, según la aplicación, pero que es casi imprescindible en el
mantenimiento y evolución de las aplicaciones si queremos asegurar un nivel de
calidad adecuado en nuestras entregas de producto.

 

Sin duda, JMeter, es un producto a tener en cuenta si en
nuestro entorno de trabajo no disponemos de una herramienta comercial más
potente como puede ser “LoadRunner”, pero es una buena alternativa a esta
última.

 

Si actualmente no realizas pruebas de carga o de regresión,
deberías emplear algo de tiempo en preparar las pruebas de las partes
principales de tu aplicación. Al final te lo agradecerán y te lo agradecerás:
el tiempo invertido, es recuperado con creces, ya que detectarás los posibles efectos
laterales antes de tiempo, y podrás comprobar si esa nueva funcionalidad que te
han pedido soporta los 100 usuarios concurrentes que se especificaban en los
requisitos.