Correlación de valores dinámicos

Todos hemos oído alguna vez la frase “Si la vida te da limones… has limonada”. Motivacionalmente significa que si la vida nos da alguna oportunidad la debemos aprovechar, que todas las cosas que nos aparezcan podemos sacarle su jugo. Lógicamente hablando estamos ante la presencia de una relación donde a implica b, “a→b”. Podemos determinar dos variables en esta relación donde ambas pueden tomar 2 valores diferentes como se muestra a continuación:3

• Primera variable: ${fruta}: puede tomar los valores: [Limones, Naranjas]
• Segunda variable: ${jugo}:puede tomar los valores: [ Limonada, Naranjada]

Si cubrimos todas las posibles combinaciones de valores en ambas variables, podemos obtener lo siguiente.

• Si la vida te da ${fruta} … has ${jugo}:
  • Si la vida te da “limones” … has “limonada”: Succesfull
  • Si la vida te da “naranjas” … has “naranjada”: Succesfull
  • Si la vida te da “limones” … has “naranjada”: Failed
  • Si la vida te da “naranjas” … has “limonada”: Failed

Enfoquémonos en la relación Cliente-Servidor y sustituiremos la palabra “Vida” de la relación por “Servidor”. Si el “Servidor” envía limones solo es posible hacer algo que contenga esos limones “Limonada”, de lo contrario esta relación sería fallida, por ejemplo cuando el servidor envía limones y como respuesta se envía “Jugo de naranja”.

Traduciendo todo esto a un nivel técnico y de arquitectura de software, si el servidor devuelve un SessionID con el valor “123abc” el cliente solo podrá enviar de vuelta el mismo valor de la sessionID “123abc” de lo contrario el pedido será rechazado. Varios de estos valores tienen un comportamiento dinámico, son generados automáticamente desde el servidor, si usamos alguna herramienta para capturar tráfico (Pedidos - Respuesta) como JMeter, estos valores dinámicos (SessionID, Token, Key, ID, entre otros) quedan grabados, si no realizamos el proceso de correlación antes de ejecutar el script, estaremos enviado estas variables con los valores que tomaron cuando se realizó la grabación, y por consiguiente estaremos encarando errores en nuestro script, debido a que estamos enviando valores dinámicos que no son los correctos.

La correlación es el proceso de captura y almacenamiento de los valores dinámicos enviados desde el servidor y su inclusión en las peticiones desde el cliente. Un valor se considera dinámico cuando puede devolver datos diferentes para cada petición en cada iteración. Cada sesión de usuario recibe un conjunto único de valores. Luego, el servidor espera recibir estos valores en solicitudes posteriores.

El nombre correlación señala que los valores dinámicos en las solicitudes están relacionados con los valores correspondientes en las respuestas anteriores. El objetivo principal de las pruebas de carga y estrés es simular de manera realista el impacto de la interacción de los usuarios virtuales en un servidor. Un usuario virtual es un objeto que genera tráfico HTTP, a diferencia de “usuario real”, no están diseñados para ejecutar JavaScript o simular completamente el comportamiento del navegador, los usuarios virtuales no implementan mecanismos de correlación. En cambio, simplemente reproducen el tráfico tal como se registró. Por lo tanto, la correlación debe realizarse manualmente o implementarse a través algún mecanismo automatizado que permita la autocorrelación. Uno de los elementos más usado para extraer valores dinámicos a través de JMeter es Regular Expression Extractor este está diseñado para extraer contenido de las respuestas del servidor mediante expresiones regulares y forma parte de la familia de postprocesadores de JMeter. Existen otros extractores como JSON Path Extractor, XPath Extractor, CSS Selector Extractor. Todos estos serán expuestos en otro post.

Algunos valores dinámicos comunes que podemos encontrar en varias aplicaciones web pueden ser:

• SessionID: El servidor se comunica con múltiples clientes en cualquier momento dado. Debido a que el protocolo HTTP no tiene estado, el servidor no puede determinar qué cliente envió una solicitud particular. Por lo tanto, el servidor genera una identificación única cuando establece comunicación con un cliente en particular, y este debe devolver este ID en todas las solicitudes posteriores.
• Token y Key: El proceso de autenticación emite un token de seguridad que se envía entre el servidor y el cliente, estos contienen información sobre los usuarios y las aplicaciones.
• Contexto o estado de la aplicación: El contexto de la aplicación puede incluir varios datos sobre la actividad de los usuarios. Para fines de escalabilidad, es posible que el contexto de la aplicación no se almacene en el servidor, sino que se incluya en todos los viajes de ida y vuelta de HTTP. Un ejemplo de un parámetro dinámico que lleva el estado de la aplicación es el parámetro “__ViewState” en las aplicaciones ASP.NET. Estos pueden variar en dependencia de las tecnologías o lenguajes de programación.
• Otros valores: Existen otras variables relacionados con el ID de elementos que el servidor los genera automáticamente. Por ejemplo si estamos probando una aplicación web E-Commerce, podemos encontrar elementos como Id del producto, del carrito, de la compra, etc.

Para terminar con este post es válido especificar la diferencia con el término de la parametrización, ya que en muchas ocasiones tienden a confundirse con la correlación, veamos con un sencillo ejemplo:

• grabamos un escenario de prueba de un usuario logueandose a una aplicación web. Para simular dicho escenario de manera más realista, los datos dinámicos que varían en diferentes iteraciones de prueba deben reemplazar los valores registrados ingresados ​​en los campos relacionados con el login en la aplicación web, la parametrización reemplaza el valor registrado con datos dinámicos. Si quisiéramos simular 3 usuarios virtuales tendríamos lo siguientes valores:
  • delvis1,mypassword1
  • delvis2,mypassword2
  • delvis3,mypassword3

Sin embargo, a diferencia de la correlación, este último no utiliza valores generados desde el servidor, en su lugar, utiliza conjuntos de datos predefinidos, datos aleatorios u otra información originada desde el cliente, como cuando usamos CSV Dataset Config en el JMETER.

Simular un comportamiento realista en nuestras pruebas de performance es un objetivo primordial, ya sea desde la simulación de los usuarios virtuales, los thinktime, hasta la correlación y parametrización de valores dinámicos. Ten presente que si el servidor te devuelve en un momento determinado, “limones” solo estará esperando de ti limonada.

Nos vemos en un próximo post.