viernes, 23 de septiembre de 2011

JMeter(I). Primeros Pasos



Jmeter (I). Primeros pasos

En esta serie de artículos, vamos a tratar sobre una de las herramientas más populares que se encuentran disponibles en la actualidad para las pruebas de carga. Las razones que la avalan son su disponibilidad, su amplio uso por la comunidad de técnicos y su flexibilidad.
Un poco de biografia.
Un breve vistazo a la página oficial (http://jakarta.apache.org/jmeter/index.html) nos cuenta que JMeter es una aplicación de código libre, basada en el lenguaje 100% compatible Java , diseñada para pruebas funcionales y medición de rendimiento. Inicialmente se usaba únicamente para pruebas de aplicaciones web, pero se ha extendido a otros entornos.
Soporta entre otros, los siguientes protocolos
· Web - HTTP, HTTPS
· SOAP
· Database via JDBC
· LDAP
· JMS
· Mail - POP3(S) and IMAP(S)
Asimismo, permite la inclusión de código ejecutable creado por el usuario basado en diferentes lenguajes de scripting a través de un módulo llamado Beanshell scripting. Esto permite realizar determinadas tareas en las pruebas, como validación de respuestas específicas, creación de flujos de control dependiendo de las respuestas recibidas, correlación…etc. Sin embargo, no es una tarea simple y su uso requiere de conocimientos avanzados de programación en los lenguajes de scripting y su adaptación al módulo de JMeter.
Instalación
La instalación de la herramienta es muy sencilla. Básicamente requiere de dos cosas
· En entorno de ejecución Java (JRE), que se puede obtener de http://java.sun.com
· El binario distribuido por la web disponible en (http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi)
· También se encuentra disponible el fuente de la aplicación, para compilarlo directamente en el equipo o, si uno tiene la capacidad y las ganas, realizarle modificaciones de acuerdo a la licencia GNU.
Es conveniente incluir las siguientes variables en el sistema
  • JAVA_HOME ;Indicando la ruta de instalación definida para la JRE.
  • JAVA_BIN ; Indicando la ruta JAVA_HOME/bin, para indicarle el binario.También se puede incluir en la variable de entorno PATH
  • JAVA_LIB ; Indicando la ruta JAVA_HOME/lib, para incluir las librerias
Las últimas versiones del JRE (al menos bajo Windows), crean este tipo de variables y actualizan el entorno para que sea transparente al usuario
Grabación de navegaciones
Como otras herramientas, el concepto de ciclo de navegación está presente en JMeter. Básicamente trataremos de reproducir la secuencia de navegación deseada, capturando las peticiones HTTP lanzadas por un navegador, modificándolas para parametrizarlas y tratar sus respuestas para comprobar su validez o reutilizarlas en peticiones siguientes.
Aunque la herramienta permite crear peticiones de manera directa, tecleando directamente la secuencia de URLs a probar, lo más común es utilizar un navegador y capturar dicha respuesta. Para ello utilizaremos dos elementos de JMeter:
· El Banco de Trabajo
· El plan de pruebas
El Banco de trabajo podemos considerarlo como la parte de configuración y grabación online de las navegaciones. Un detalle MUY IMPORTANTE es que lo que se añade a este elemento NO SE GRABA, estando sólo disponible mientras si se mantenga la instancia de JMeter abierta
El Plan de Pruebas podemos considerarlo como una mezcla entre “script” que reproduce la navegación y el escenario que los ejecuta.
Es muy útil hacer una planificación previa sobre lo que se va a grabar, dividiéndolo en pasos o subtransacciones, de manera que tengamos claro a qué paso pertenece cada petición. Esto nos permitirá no sólo tener un flujo de control sobre la navegación, sino que permitirá realizar mantenimientos sobre el script de manera más sencilla .
Hemos creado sobre un Thread Group/Grupo de Hilos Dos controladores de transacción (T0_Login y T1_Logout)
Primeros pasos de grabación
Como paso necesario para la captura de la navegación de un usuario a través de un navegador, debemos incluir un servidor Proxy http en el banco de trabajo.
El servidor Proxy es lo que se da en llamar un “Elemento No de Prueba”, que son las diferentes opciones que se pueden incluir sólo el banco de trabajo. Este elemento funciona como un Proxy /capturador de tráfico, que escuchará todo el flujo http que pase por el puerto configurado en sus opciones
Aquí se indica en qué puerto TCP estará escuchando. Se incluirá en la configuración de Proxy del navegador a usar como cliente para la navegación
En esta “rama” del plan de pruebas se graban y agrupan las peticiones correspondientes al paso

Indicamos elementos a excluir de la grabación, esto permite evitar llamadas a elementos estáticos (imágenes, textos..etc). Se pueden definir patrones de elementos a grabar/excluir siguiendo el formato de reglas usado por Perl para expresiones regulares.

Podemos especificar qué contenido queremos incluir/excluir explícitamente
Podemos indicar que no grabe peticiones fuera de dominio de prueba
A priori, es mejor dejar por defecto esta sección
Una vez que configuremos el navegador, pulsaremos en la pantalla del Servidor Proxy http el botón , con lo que empezará a grabar las solicitudes que le lleguen.
El procedimiento sobre el que hacemos hincapié es grabar cada paso, seleccionando en el controlador objetivo la transacción correspondiente. Pueden incluso añadirse subtransacciones de la transacción marcándolas como hijas de la que cuelgan

El resultado de la grabación de la actividad del navegador, será reflejada como una estructura en árbol de peticiones HTTP , como la que se observa en la siguiente imagen.







Ilustración 1. Resultado de la grabación de un ciclo simple de navegación
En este caso, podemos ver como una petición http de tipo GET sobre la URL https://www.prueba.es refleja el acto de la pulsación el botón “Aceptar”,junto con algunos parámetros .
En este caso, el campo “Nombre” y “Comentarios” son de texto libre y pueden ser usados para una descripción textual del paso (si procede)
El campo “Path”, refleja el camino relativo al dominio www.prueba.es, junto con determinados parámetros incluidos en la llamada.
Este script puede ser salvado con las opciones del menú típicas de cualquier entorno gráfico de ventanas y posteriormente ejecutado para ser depurado, incluyéndole modificaciones para variar su comportamiento según la respuesta y salvar sus resultados en un fichero para su análisis posterior.

2 comentarios:

  1. ¿Que se debe colocar en gestor de cabecera o gestor de cookies? ¿Me podrías ayudar entregando más especificación a los pasos que estás creando?

    ResponderEliminar
  2. Hola Robinson.

    El gestor de cabecera lo que manda es las caracteristicas de la petición HTTP siguiente o que esté en el ámbito del código donde la hayas puesto. Sirve por ejemplo para indicar qué tipo de contenido se está mandado y qué tipo de actuación o respuesta se espera .Por ejemplo, se envia un binario ,un comprimido , un archivo flash/shockwave..etc . También sirve para indicar la caducidad de la petición o si se puede usar la caché o no...etc. Te recomiendo que le des un vistzao a la documentación y un par de vistazos a las definiciones de cómo funciana el protocolo HTTP

    El gestor de cookies se encarga de la creación y eliminación de las cookies , sirve para mantener la coherencia de sesión de usuario (entre muchas cosas.)

    Espero que te sirva de ayuda .

    Saludos

    ResponderEliminar