JMeter V. Ejecución de escenarios de prueba

Continuando con los pasos de iniciación de JMeter, tras los capítulos dedicados a la grabación, parametrización y modificación de scripts y código, incluimos ahora un capítulo dedicado a la ejecución de pruebas de carga con el código grabado y depurado.

Como hemos comentado, el plan de pruebas sirve para planificar el momento de inicio de la prueba, su duración, el escalonamiento en la entrada de los usuarios y su salida

A continuación, describimos los elementos de configuración del elemento “Grupo de Hilos” (Thread Group) relacionado con el lanzamiento de pruebas.

Configura el funcionamiento ante fallos ,permite

• Continuar ante el error
• Para hilo (sólo el hilo que causó el fallo)
• Parar test : Para toda la prueba

El “Grupo de hilos corresponde al concepto de “script”, refleja los pasos de la navegación,así como la concurrencia a alcanzar en la misma	Definimos la concurrencia (número de hilos) el incremento de la carga (periodo de subida) a lo largo de dicho periodo y el número de iteraciones (Contador del bucle)
	Se ha de habilitar esta opción para tener acceso a la configuración del planificador Fecha y hora de inicio .Formato YY/MM/DD hh:mm:ss Fecha y hora de fin .Formato YY/MM/DD hh:mm:ss Duración en segundos. Se puede poner un valor fijo o referenciar a una variable Tiempo de espera desde el inicio hasta que empieza a generar carga

Tabla 1. Configuración del planificador de lanzamiento de plan de pruebas JMeter

Esta configuración permite lanzar el plan de prueba con el entorno gráfico de JMeter habilitado. Esto es útil en cuanto que nos permite una mayor flexibilidad a la hora de para y detener la prueba. También permitiría incrementar o detener la carga inyectada, estableciendo varios grupos de hilos que se podrían detener deshabilitando los grupos de hilos que consideremos oportuno para reducir la carga

Ilustración 1. Habilitar y deshabilitar elementos plan de prueba

Sin embargo, la experiencia muestra que para el lanzamiento de pruebas, por cuestiones de consumo de memoria y CPU, el uso del entorno gráfico de JMeter es una idea que podemos clasificar como “no muy buena”. La configuración de JMeter permite el consumo de memoria hasta de un máximo de 2 GB en un sistema operativo de 32 bit, aunque, al menos hasta la versión 2.4 sólo permitía llegar hasta los 1,5 GB

Lanzar y detener planes de prueba

La ejecución del plan de pruebas en modo gráfico, se realiza seleccionando del menú de JMeter “Lanzar” ->”Arrancar” o bien por atajo de teclado CTRL + R

Ilustración 2. Arrancar y detener desde menu JMeter

La parada se realiza seleccionando, dentro del mismo menú la opción Parar (Atajo de teclado CTRL + ,).

Monitorización de los resultados

La comprobación de los resultados que se obtienen durante la prueba se realiza incluyendo listener. Aparte del ya citado para depuración “Ver resultados en árbol” , existen varios listener que nos proporcionan datos instantáneos del estado de la prueba, con métricas familiares a ti, lector avezado con experiencia en pruebas de carga, tales como

• Througput
• Tiempo de respuesta por petición
• Transacciones por segundo ejecutadas
• % de errores en las peticiones

Debemos destacar que los listener proporcionados por la herramienta, parecen dar en ocasiones información contradictoria. No obstante, el uso de JMeter y los comentarios obtenidos por los autores a lo largo de varias pruebas de distintas aplicaciones, han mostrado que los listener que se pueden considerar como más fiables son

1. Informe agregado. Un clásico de la monitorización en JMeter

2. Ver Árbol de Resultados. Permite localizar los pasos que dan error

3. Escritor de datos simples.

Una consideración que debemos tener en cuenta es el ámbito de los listener. Podemos hacer que los listener recojan información específica desde el “grano fino” a el total de peticiones lanzadas en un plan de pruebas, dependiendo de la rama de la que desciendan

• Petición HTTP
• Transacción definida ej:(T0_Login) “Controlador de transacción simple”
• Grupo de hilos.
• Plan de pruebas

a)Listener de Informe agregado

Ilustración 3. Listener Informe Agregado	Nombre y comentarios: De libre descripción
	Escribir datos a archivo: Salvar los resultados a un fichero.
	Casillas de opciones: escribir sólo los resultados fallidos/correctos
	Configurar: Permite seleccionar los campos del formato a salvar
	Label: El nombre de la petición/controlador de transacción que se ejecuta
	Muestras :Nº ejecuciones efectuadas
	Media, mediana, Linea 90% Min, max: valores estadísticos de tiempo de respuesta en milisegundos
	%Error: porcentaje de la petición fallida
	Rendimiento: nº de peticiones por segundo
	Kb/seg: Througput respuestas servidor

b) El listener de “Ver Resultados en Árbol”, recoge las muestras ejecutadas a lo largo de la prueba, indicando el número de petición (“muestra”), el momento de inicio (“start time”), el nombre del grupo de hilos y el número del hilo que ejecuta (“Thread name”) , la etiqueta o nombre de la petición o controlador “Label”, el tiempo de respuesta , el resultado de la petición y el tamaño en bytes de la petición

Ilustración 4. Listener Ver Resultados en Árbol

Los datos muestreados obtenidos por los listener citados, permiten tener datos en el instante. Sin embargo, no permiten tener una visión global de la prueba, sino como medias alcanzadas. Para poder ver la evolución de la carga a lo largo de la misma, se deben tratar los datos obtenidos a lo largo de la misma. El mecanismo que proporciona JMeter para ello es el “escritor de datos simple”.

c) El escritor de datos simples salva en un fichero los datos de muestreo correspondientes al ámbito del muestreador del que dependa

Ilustración 5. Listener Escritor de datos simple

Como opciones más importantes a destacar en el listener, señalaremos

• Nombre de archivo: Ruta al fichero donde volcará los resultados. Admite incluir variables o funciones en el nombre ,para crear rutas con fecha y hora
• Casillas “Escribir en log sólo errores “ – “Sucesses”. Indicamos que sólo salve las peticiones que generen errores o las que sean correctas.
• Botón “Configurar”: Aquí se especifican los campos a salvar en el fichero

Ilustración 6. Configuración datos a salvar por escritor datos simples

Aunque dependerá del uso que le queramos dar, nuestra habilidad para el bricolaje de datos o sencillamente, lo que nos queramos complicar la existencia.

Desde nuestra experiencia, los campos más interesantes son los que aparecen marcados en el gráfico

Guardar código de respuesta	Código HTTP recibido
Guardar Etiqueta	Nombre de la petición
Guardar etiqueta de tiempo	Tiempo en el que se efectúa la petición
Guardar Nombre de campo	La primera fila del fichero de resultados es el nombre de campo
Guardar datos de muestreador
Guardar Nombre de hilo	Nombre del Grupo de hilo y número de thread
Save URL	URL sobre la que se realiza la petición
Save Active thread count	Número de threads activos en el instante
Guardar resultados de aserción	¿La aserción dio por válida la respuesta a la petición http?
Guardar tiempo	Tiempo de respuesta en milisegundos
Save byte count	Througput de respuesta en bytes

Tabla 2. Campos de configuración de la escritura de datos a archivo

El fichero de resultados contiene estos campos separados por comas, con lo cual pueden ser usados como entrada a una macro de hoja de cálculo o a algún gestor de base de datos, que traten estos valores, agrupándolos de manera que puedan sacarse conclusiones sobre los mismos…pero eso ya es al gusto o conocimiento del usuario.

JMeter IV .Depurando el código

Continuando con la entrada anterior,los scripts de JMeter permiten incluir código de control del flujo con sentencias clásicas de la programación , tales como

• Sentencias condicionales (if …then)
• Sentencias de decisión (switch ..case)
• Sentencias de repetición (while ..do, for …)

También ,mediante el Beanshell script, podemos incluir código de control u operativo para que actúe en el flujo.

Para las pruebas más habituales de rendimiento, al ser mayoritariamente ciclos sencillos, podemos utilizar el código que nos proporciona JMeter. No obstante, hemos de recordar que la herramienta tiene limitaciones en el manejo y mantenimiento de estructuras complejas.

Sentencia condicional IF

Un caso práctico sería incluir una sentencia condicional IF sobre un extractor de expresiones regulares

Ilustración 7. Sentencial condicional IF

Cada paso de ejecución en un script de JMeter, utiliza una variable genérica ${JMeterThread.last_sample_ok} Esta variable refleja el valor booleano del paso previo ejecutado

Si la condición se cumple, seguirá la “rama” del árbol de decisiones que cuelga de ella. En este caso

Ilustración 8. Flujo de decisión de sentencia Continuará

En este caso, podemos ver como ,en el caso que no se cumpla la condición evaluada en el IF (que hemos llamado LOGIN?), salte a la rama marcada con el controlador simple T2_Logout.

JMeter (III). Depurando scripts

JMeter (III).Depuración del script
Continuando con la serie ,tras los pasos de grabación y modificación de planes de prueba con JMeter, procedemos a explicar otra parte más del proceso de creación de pruebas de prestaciones con esta herramienta de carga.

En este momento es cuando se tiene que empezar a plantear introducir las validaciones de las respuestas obtenidas. Para ello, podemos hacer uso de los listener, un elemento de configuración del plan de prueba, que nos permite observar la respuesta obtenida y aplicarle un gestor, de manera que

· Compruebe la validez de la respuesta ,bien sea por comparación con respecto a un valor o por seguimiento de un patrón

· Dirija el flujo de ejecución a través de código por el script.

Depuración

Otro elemento necesario para la depuración del script es el Listener de “Ver Árbol de Resultados”. Este elemento permite ver la petición efectuada, con la instaciación de las variables, y las respuestas obtenidas entre otros formatos

• Texto
• XML
• Expresión regular
• HTML
• Modo gráfico HTML

Ilustración 1. Listener Ver Árbol de Resultados

Esta capacidad debe ser usada sólo durante la depuración del script, dado el elevado uso de recursos de CPU y memoria que realiza.

Describimos a continuación las opciones más usadas habitualmente

Ilustración 2. Opciones del listener Ver Árbol de Resultados

• Resultado del muestreador, permite observar la respuesta por la petición HTTP
• Petición, que muestra el envio de la petición, con las variables instanciadas que use
• Datos de Respuesta , que muestra en diferentes formatos la respuesta y sobre la que se puede aplicar búsquedas, bien de texto libre (si utilizamos la opción del desplegable “Text”) ,bien por expresiones regulares (Opción “Regular Expr.” Del mismo desplegable)

También permite ver la salida en formato similar al de la página web, con las limitaciones inherentes a un seudo navegador…

Validación de la respuesta

Una vez realizada la petición, se debe poder validar que dicha respuesta es correcta. Esto puede hacerse desde dos puntos de vista

• Respuesta del servidor web
• Respuesta en la lógica de la aplicación

La primera opción valida el código http devuelto, comprobando si es un código considerado válido (200 OK, 302 en caché), mientras que las respuestas de la famila 400 (404 Not Found, 401 Unauthorized, 403 Forbidden…) y la familia 500 serían consideradas a priori como fallidas

La respuesta en la lógica de la aplicación comprueba por el contenido de la misma o por el significado del valor . Así ,un servidor http que funcione correctamente ,pero que muestre errores del middleware o el backend (agotamiento de los threads, timeout en la respuesta del middleware, caída de la base de datos..etc) devuelve un código 200, aunque el contenido de lo que muestre sea un mensaje de error de la BBDD.

Para ambos casos usamos una aserción de respuesta, que permite realizar ambos tipos de validación, utilizando distintos tipos que ofrece JMeter. Para incluirlas se selecciona con el botón derecho del ratón sobre una petición http, se añade una aserción y entre las disponibles, escoger la “Aserción de Respuesta”

Ilustración 3. Añadir Aserción de Respuesta a petición HTTP

Existe dentro de la variedad de aserciones disponibles, algunas que permiten verificar el tamaño de la respuesta, la duración en milisegundos de la misma, aserción HTML, XML…etc. Dependiendo de la necesidad puede ser usada una u otra, incluso pudiendo combinar varias para una respuesta.

Un ejemplo de las opciones que se incluyen se muestran el la siguiente imagen

Ilustración 4.Aserción de respuesta en JMeter

Podemos ver que se están usando variables en el nombre de la aserción. Esto es útil a la hora de detectar con qué valores o situaciones se encuentra un fallo

También podemos ver que la aserción puede aplicarse bien al flujo http devuelto por el servidor directamente a la petición o a las peticiones subsecuentes

Como ya se indicó, la validación puede aplicarse a la respuesta textual, en el código http de respuesta, en las cabeceras de la respuesta (para evitar realizar un trabajo de búsqueda sobre un cuerpo de un gran tamaño).

Las reglas de Coincidencia de Patrones permiten indicar si la respuesta debe ser exactamente el patrón a probar, debe estar contenido en la respuesta o si debe ser una cadena textual. Lo habitual es utilizar la opción de “contiene” ,habilitando la casilla de “No” ,para indicar que no debe aparecer en la respuesta esperada, Es decir, podemos usarlo como lógica inversa, a la hora de validar un mensaje que sabemos de partida que es indicador de fallo.

Una validación que sirve para capturar una respuesta es el muestreador de expresiones regulares. Con esta utilidad se consigue un efecto similar a la correlación de la herramienta Loadrunner. Se basa en el mismo concepto, esto es, definir un patrón de búsqueda en las respuestas a una petición, de manera que se capturen valores dinámicamente. Dichos valores pueden ser usados como validación de un paso o reutilizarse como variables o datos necesarios para seguir con la lógica del proceso

Ilustración 5. Extractor de expresiones regulares

Para verificar que le expresión regular o patrón de búsqueda que estamos usando para localizar un valor en la respuesta es correcto, es muy útil usar la opción “Ver datos de respuesta” del listener “Ver Árbol de Resultados”, seleccionando como formato de salida el de la expresión regular.

Ilustración 6. Expresiones regulares en respuesta capturada por "Ver Árbol de Resultados"

En la casilla marcada como “Regular expression”, podemos incluir el patrón a buscar y ,pulsando el botón “Test”, validaríamos el número de respuestas que corresponden con el mismo.

La siguiente entregá continuará incluyendo código para manejar el flujo de comportamiento. ¡No se lo pierdan!

Si quieres saber más de como depurar scripts visita nuestra nueva entrada

Visión General de las Pruebas de Rendimiento (II)

El siguiente paso a dar, es conocer bien la arquitectura del sistema que se pretende probar, esto es importante, aunque no sea experto en arquitectura de sistemas, para que al momento de la ejecución de las pruebas, sepamos situar el problema ó cuello de botella.

El conocer el modelo o arquitectura del sistema nos llevará a un análisis mas profundo de las pruebas y determinar la forma de lanzamiento de las pruebas, es decir, desde que capas vamos a atacar.

No existe una formula matemática para calcular la cantidad de carga que vamos a inyectar a algún sistema, pero existen los modelos de uso que nos permiten saber cual es la carga aceptada por el sistema (basados en estadísticas de producción, si el sistema está ya implementado. Cuando el sistema es nuevo es necesario que, una vez que se ha determinado desde que capa de la arquitectura se va a lanzar las pruebas, es necesario hacer pruebas distintas (carga en vacío, estrés, estabilidad) con el objeto de obtener mediciones y poder determinar que niveles de carga acepta el sistema.).

Es importante que al momento de realizar estas pruebas, se comience a monitorizar los sistemas o elementos afectados (por los cuales pasa la pruebas, o los que sean de interés).

Continuará…

(Próximamente: Mejores prácticas de HP LoadRunner VUGen)

JMeter (II). Casos de Prueba

Continuando con la entrada anterior, seguimos describiendo el proceso de preparación de un caso de prueba.Ahora con la parametrización de un script.
 

Cada petición que se incluye en el script, puede ser modificada para:

· Cambiar los parámetros con los que hace la invocación al servidor

· Parametrizar las peticiones de manera que use un fichero para cada ejecución

· Especificar un servidor Proxy para acceder a direcciones externas

· Indicar timeout de petición

El cambio de parámetros dependerá de si están incluidos en la URL de invocación

O, si se capturan en la sección correspondiente 

En este caso, el parámetro mediador_Aceptacion.aceptacion.nif, tomará el valor definido en la variable ${NIF}. Esta variable puede estar definida como un Elemento de configuración: Variables definidas del plan de prueba o bien como una variable de un CSV Dataset

Ilustración 1. Configuración variables definidas por el usuario

Ilustración 2. Configuración fichero CSV Dataset

La invocación a las variables se realiza con el formato ${NOMBREVARIABLE}. Las variables tienen ámbito global dentro del plan de pruebas, por lo que pueden ser referenciadas a cualquier nivel dentro del mismo. Habitualmente, para pruebas de carga, se usan variables definidas dentro de un fichero 

Ilustración 3. Ventana de configuracion de fichero de parámetros (CSV DATASET)

Nombre descriptivo del fichero Campo de texto libre Ruta al fichero CSV(separado por carácter) Variables (una por cada columna) Caracter delimitador entre campos Permite datos entrecomillados Reinicia al llegar al final del fichero

Las peticiones admiten también el uso de funciones para el paso de parámetros. JMeter proporciona una ayuda –aunque no muy extensa- sobre el uso de las funciones. Para ello, en las opciones del menú gráfico, seleccionamos el elemento “Diálogo de Ayuda de Función”

Ilustración 4. Opción de menú funciones

Seleccionando esta opción, podemos insertar, dentro del elemento muestreador o declaración de variables esta invocación a función.

Por ejemplo, podemos crear una variable con la fecha formateada para usarla en diferentes operativas dentro de la lógica de la navegación –como un parámetro de envio de una petición HTTP – o bien dentro del manejo del propio script –un fichero de resultados que contenga ese campo de tipo fecha en el nombre o en alguno de los registros que capture-

Ilustración 5.Diálogo de Ayuda de función

Una declaración de función para generar una fecha en formato año/mes/dia y que la volcara a una variable FECHA, la crearíamos así

${__time(YMD,FECHA)}

Podemos invocar a la llamada a dicha función dentro de los parámetros de una petición HTTP, sustituyendo el valor que tuviera capturado durante la grabación, por el nombre de la función, marcando la casilla de “¿Codificar?” del parámetro
 

Ilustración 6.Invocación a función

Esta opción haría que en cada invocación, se ejecutara la función dando la fecha en el momento. En el caso de que se utilizara ${FECHA} en la invocación tendría el valor del momento en el que se invocara explícitamente a la función.

En el caso de la función de tiempo, los valores por defecto que proporciona JMeter son el tiempo en milisegundos dede el 1 de Enero de 1970. Para cambiar el formato que utiliza la función es necesario modificar el fichero que está en la ruta de instalación del JMeter->directorio “bin” y que responde por jmeter.properties En concreto la sección # Timestamp format - this only affects CSV output files # legitimate values: none, ms, or a format suitable for SimpleDateFormat #jmeter.save.saveservice.timestamp_format=ms Por esta opción jmeter.save.saveservice.timestamp_format=yyyy/MM/dd HH:mm:ss.SSSS

Se puede especificar que las peticiones http se redirijan a través de un Proxy específico
 

Ilustración 7. Configuración red de muestreador HTTP

Se configuran los parámetros de nombre o servidor IP del Proxy ,el puerto ,así como los datos de usuario y clave necesarios para validarse en dicho Proxy (si aplica)

Otro campo interesante es es el de Embebbed URLs. En este apartado, podemos especificar el dominio o “patrón” de las URL desde las que se quiere mantener comunicación ,ya sea de envío o recepción.

Otros elementos útiles para la correcta ejecución funcional del script o grupo de hilos, son:

· Gestor de autorización http: Permite el envio de pares usuario/contraseña a una URL de autenticación

· Gestor de cabecera http: Permite definir la cabecera común a todas las peticiones http, salvo que se defina una cabecera específica para alguna en particular

· Gestor de Cookies http: Permite que JMeter gestione de manera automática las cookies que envia el servidor para la identificación de sesión

· Gestor de caché http. Simula el comportamiento de la caché de navegador.

Continuará…