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
