Aserciones de las respuestas en JMeter

title

¿Por qué me debería importar?

Para quienes trabajamos con JMeter y con pruebas de performance sabemos de la importancia de agregar validaciones a los HTTP Request principales. Validaciones, assertions, algo que automáticamente te diga si la respuesta está OK o si tiene un error. Si te falta convencimiento con respecto a esta idea, pensemos por un momento que estás recibiendo tiempos de respuesta súper buenos en tu prueba de carga, generas un reporte a tu cliente o a tu manager diciendo que el sitio no corre, sino que vuela. Ahora imagina que como había algo mal en la prueba, en realidad las respuestas del servidor estaban enviándote una página que decía “sitio fuera de servicio, vuelva más tarde”. Y más te digo, a todos los que hemos jugado con probar concurrencia en aplicaciones nos ha pasado que el servidor nos avisa de un error en una página con código de respuesta 200. ¡Sí! 200, que significa “OK”, significa “no hay problema”. Curioso, ¿no? O sea, no nos podemos confiar solo en el código de respuesta, necesitamos hacer alguna mínima validación extra en cada paso que nos dé la tranquilidad que estamos simulando la prueba que queremos simular.

En este sentido, las validaciones no solo son una manera de corroborar que el servidor está respondiendo de manera esperada sino que nos sirven también para verificar que el script que estamos desarrollando está actuando como lo debe hacer, que está simulando el comportamiento de los usuarios tal como fue diseñado.

Por ejemplo, si el impacto de nuestro script en el sistema implica que se cree un registro en la base datos, nos tenemos que asegurar que no ocurra que luego de ejecutar el script no se haya creado el registro, y que el script diga que terminó sin problemas.
Estos son ejemplos de malas elecciones de assertions o validaciones en nuestro requests.

En otras palabras, lo que necesitamos es evitar falsos negativos y falsos positivos.

Evitar falsos positivos y falsos negativos

Veamos primero qué significan estos conceptos:

  • Falso Positivo: la prueba dice que hay error y no lo hay, entonces perdemos tiempo buscando la causa del error hasta que nos damos cuenta que el error estuvo en el test, en el ambiente, los datos, etc.
  • Falso Negativo: ¡hay errores y nosotros tan tranquilos! confiados que esas funcionalidades están cubiertas, que están siendo probadas, y por lo tanto que no tienen errores (¡cuidado con esto!)

Es decir, si hay un error, el script tiene que mostrar una falla, si el sistema está funcionando bien, el script tiene que decir que no hay errores y nosotros tenemos que poder confiar en ello.
Pero, ¿cómo hacemos para seleccionar buenos assertions?

Definiendo buenas assertions para nuestros HTTP Request

La realidad es que no hemos encontrado una guía clara de cómo definir los assertions para cada HTTP Request, y como es algo que siempre hay que explicar a los nuevos testers de performance que incorporamos, o que capacitamos, confeccionamos nuestra propia guía.

Por esto me gustaría compartir contigo los métodos y criterios que nos han dado más resultado a la hora de seleccionar qué validar en la respuesta de un servidor durante una prueba de carga con JMeter (tal como lo mencionamos en esta checklist para mejorar scripts de JMeter).

1.- Validar un login

Típicamente, luego de autenticarnos en un sistema nos aparece algún texto de “Bienvenid@ NombreUsuario” o aparece nuestro nombre por algún lado de la pantalla, indicando que el login fue exitoso, por lo que en estos casos es un excelente elemento para validar.

Recordemos que en JMeter en las validaciones podemos especificar una variable, entonces en los casos que el nombre del usuario está parametrizado (es leído de un archivo de tipo csv o definido como variable de usuario), puedo validar el texto ${NombreUsuario} y JMeter se encargará de reemplazar la variable por su valor al momento de ejecutar.

2.- Validar contenido de la ventana

Siempre que el request que hacemos nos devuelve una página HTML, podemos escoger textos o títulos que deban venir en esa respuesta. Por ejemplo, si accedo al sitio de JMeter (http://jmeter.apache.org/) podemos ver lo siguiente:

imagen1

Por lo que sabemos que si este sitio carga de forma correcta el título “What can I do with it?” debe venir como respuesta al pedido realizado al sitio. Entonces, es un buen assertion para agregar como validación de que estamos recibiendo la página esperada. El desafío en este tipo de validaciones está en validar contenido que sepamos que, en caso de haber un error, dicho texto no viene en la respuesta.
Para esto podemos recurrir a los desarrolladores para que nos aporten este tipo de información.

3.- Tener en cuenta próximos pasos del script

Si sabemos que la próxima acción a realizar es clic en un botón X, o acceder al link Z, o seleccionar la opción A del combobox B, una muy buena estrategia es validar que en la respuesta del request venga ese elemento sobre el que queremos accionar en el próximo paso. Por ejemplo, si luego de cargar el sitio de JMeter queremos seleccionar la opción de “Download Releases” podemos validar este texto y nos aseguramos la continuidad del flujo. Para esto recurrimos a la captura de la respuesta del servidor y comprobamos cómo está presentada esa opción en el HTML, en el ejemplo vemos esto:

Download</div><ul><li><a href="./download_jmeter.cgi">Download Releases</a>

Y luego creamos la validación en JMeter con >Download Releases< :

imagen2

4.- Validar valores a extraer

Hay veces que de la respuesta de un HTTP Request obtenemos variables a través del uso de expresiones regulares (Add->Post Processors->Regular Expression Extractor) con la intención de usar esa variable en un pedido posterior. Esto es lo que hacemos en lo que se conoce como la correlación de variables.

imagen3

Podemos entonces validar que dicha variable aparezca en la respuesta del servidor. Para esto podemos hacer uso de validaciones que utilicen expresiones regulares. Por ejemplo:

imagen4

De este modo, si la expresión regular no matchea en la respuesta recibida, vamos a obtener un error de validación.

5.- Cuidado con los caracteres especiales

Hay que tener cuidado a la hora de escribir el assertion en JMeter porque no siempre se recibe el texto en el mismo formato que se muestra en pantalla, por ejemplo si quisiera validar el título Apache JMeter™, no lo puedo escribir de manera textual porque en la respuesta del servidor viene como: Apache JMeter&trade;y no del modo que se ve en pantalla. Si no utilizamos el texto tal como aparece en el HTML, la validación (así como las expresiones regulares) no lo encontrarán.

6.- La cantidad adecuada de assertions

JMeter permite agregar tantos assertions como el usuario quiera, por lo que cada uno de los assertions que se nombraron antes pueden ir acompañados por otros assertions como por ejemplo los títulos de las respuestas de tipo HTML (<title>...</title>), con el fin de agregar robustez a la validación.

A la hora de agregar más assertions tenemos que tener cuidado que el script no quede muy cargado, es por esto que no se aconseja agregar más de dos assertions por cada request, por lo cual tenemos que asegurarnos que los que escojamos sean determinantes a la hora de definir la correctitud de la respuesta.

¿Cómo vas a validar tus respuestas?

Esperamos entonces que esta lista te sea de utilidad a la hora de agregar assertions. En resumen, me gustaría que te quedes con esto:

  • Agregá entre uno y dos assertions por cada HTTP Request importante en el flujo que estás probando
  • Elegí validar lo que quieras, títulos, textos, valores o elementos con los que vas a interactuar en los siguientes pasos del flujo, pero lo importante es que si el script falla sea porque el sistema falla, y si el sistema falla, que el script falle (evitando así falsos positivos y falsos negativos).
    Si tenés más ideas, me encantaría que las compartas y así mejoremos cada vez más la forma en la que hacemos nuestras pruebas de carga.

Acerca de esta publicación

Esta publicación la preparamos hace unos años en inglés con varios colegas de Abstracta, pero que no pierde nada de vigencia. Se trata de entender cómo validar un HTTP request en JMeter. El post original y en inglés lo puedes acceder acá. Digo que no pierde vigencia porque el protocolo HTTP es bastante estable, así como JMeter, así que las buenas prácticas en torno a esto no han cambiado mucho.

Federico Toledo
COO at www.abstracta.us
twitter.com/fltoledo
Bio: https://www.linkedin.com/in/federicotoledo/
Sitio: https://www.federico-toledo.com/

-Federico