Corrélation de Valeurs Dynamiques

Tous les gens ont entendu la phrase “Si la vie vous donne des limonades… vous faites de l’orange-squelette.” Motivément, cela signifie que si la vie nous offre une opportunité, il faut la prendre et qu’il n’y a pas d’obstacle qui ne puisse être transformé en quelque chose de plus utile. Logiquement, nous sommes dans un rapport où b implique a, “a→b”. Nous pouvons déterminer deux variables dans ce rapport où les deux peuvent prendre 2 valeurs comme suit:3

• Première variable: ${fruits}: peut prendre les valeurs : [Limonades, Orange]
• Deuxième variable: ${juice}: peut prendre les valeurs : [Orange-squelette, Oranges de jus]

Si nous couvrons toutes les combinaisons possibles de valeurs dans les deux variables, nous pouvons obtenir la suivante :

• Si la vie vous donne ${fruit} … ayez ${juice} :
  • Si la vie vous donne “lesquelles” … ayez “lemonade” : Succès
  • Si la vie vous donne “lesquelles” … ayez “eau de jus”: Succès
  • Si la vie vous donne “lesquelles” … ayez “eau de jus”: Échec
  • Si la vie vous donne “lesquelles” … ayez “lemonade”: Échec

Conservez la relation entre le Client et le Serveur et remplacez le mot “Vie” dans la relation par “Serveur”. Si le “Serveur” envoie uniquement les citrons, il est possible de faire quelque chose qui contient ces citrons “Limonade”, sinon cette relation serait échouée, par exemple lorsque le serveur envoie des citrons et comme réponse envoie “Orange juice”.

Translating this to a technical and software architecture level, si le serveur renvoie un SessionID avec la valeur “123abc”, le client peut seulement envoyer la même session ID “123abc” sinon la requête sera rejetée. De nombreux ces valeurs ont une comportement dynamique, elles sont générées automatiquement par le serveur, si nous utilisons n’importe quel outil pour capturer les trafic (Requests - Responses) comme JMeter, ces valeurs dynamiques (SessionID, Token, Key, ID, etc.) restent enregistrées, si nous ne faisons pas de corrélation avant d’exécuter le script, nous envoyerons ces variables avec les valeurs que prenaient lorsqu’il a été réalisé la capture du trafic et donc nous aurons des erreurs dans notre script à cause de l’envoi incorrecte de valeurs dynamiques.

La corrélation est le processus de capturer et d’enregistrer les valeurs dynamiques envoyées par le serveur et leur inclusion dans les demandes clients futures. Un élément est considéré comme dynamique lorsque la valeur retourne des données différentes pour chaque demande dans chaque itération. Chaque session utilisateur reçoit une série unique d’éléments. Le serveur attend que ces éléments soient reçus dans les demandes futures.

Le nom corrélation indique que les valeurs dynamiques dans les demandes sont liées aux valeurs correspondantes dans les réponses précédentes. Le but principal de la simulation de charge et de stress est d’effectuer des simulations qui reflètent le comportement d’une interaction utilisateur sur un serveur. Un objet virtuel utilisateur génère du trafic HTTP, contrairement à “les utilisateurs réels”, qui ne sont pas conçus pour exécuter JavaScript ou simuler correctement la comportement de navigateurs ; les objets virtuels ne mettent en œuvre aucune mécanique de corrélation. Au lieu de cela, ils reproduisent simplement le trafic tel qu’il a été enregistré. Par conséquent, la corrélation doit être effectuée manuellement ou par une méthode automatisée qui permette autocorrelation.

L’une des éléments les plus couramment utilisées pour extraire des valeurs dynamiques dans JMeter est Extracteur de régular expression, conçu pour extraire du contenu provenant des réponses des serveurs à l’aide de expressions régulières et qui fait partie de la famille des postprocessors. Il existe d’autres extracteurs comme Extracteur JSON Path, Extracteur XPath, et Extracteur CSS Selector. Tous ces extracteurs seront expliqués dans un autre post.

Les valeurs dynamiques couramment trouvées dans diverses applications web peuvent être :

• ID de session: Le serveur échange avec plusieurs clients simultanément à tout moment. En raison du manque de statut dans le protocole HTTP, le serveur ne peut pas déterminer qui a envoyé une requête particulière. Par conséquent, lorsqu’il se connecte à un client spécifique, le serveur génère un identifiant unique et ce ID doit être retourné sur toutes les demandes futures.
• Token et clé: Le processus d’authentification émet un token de sécurité qui est envoyé entre le serveur et le client, contenant des informations concernant les utilisateurs et les applications.
• Contexte de l’application ou état de l’application: Le contexte de l’application peut inclure diverses données sur l’activité utilisateur. Pour des raisons de scalabilité, il ne doit pas être stocké dans le serveur mais inclus dans toutes les demandes HTTP envoyées et reçues du serveur. Un exemple d’une valeur dynamique qui contient l’état de l’application est la variable “__ViewState” dans les applications ASP.NET. Ces paramètres peuvent varier en fonction des technologies ou des langages de programmation.
• Autres valeurs: Il existe également d’autres variables liées aux identifiants d’éléments que le serveur génère automatiquement. Par exemple, si nous testons une application web e-commerce, nous pourrions trouver des éléments tels que l’ID du produit, l’ID de la boîte à cadeaux, l’ID de la commande, etc.

Pour conclure à ce post, il est valide de spécifier la différence entre paramérisation et corrélation. Dans de nombreux cas, ils tendent à confondre l’un avec l’autre. Voyons un exemple simple :

• Nous avons enregistré une scénario d’une utilisation connectant à un application web. Pour rendre ce scénario plus réaliste, les données dynamiques qui varient dans différentes itérations de tests devraient remplacer les valeurs inscrites dans les champs de connexion liés à l’application web. La paramérisation remplace la valeur inscrite par des données dynamiques. Si nous voulions simuler 3 utilisateurs virtuels, nous aurions les valeurs suivantes :
• delvis1,mypassword1
• delvis2,mypassword2
• delvis3,mypassword3

Cependant, contrairement à la corrélation, cette dernière ne utilise pas les valeurs générées par le serveur; elle utilise plutôt des datasets prévus, de données aléatoires ou d’autres informations provenant du client, comme lorsqu’on utilise CSV Dataset Config dans JMeter.

Simulez le comportement réel dans nos tests de performances est une cible primordiale, quel que soit le cas de simuler des utilisateurs virtuels, du temps d’attente, ou de paramétrer et corriger dynamiquement les valeurs. Remarquez que si la serveur retourne à un moment spécifique, “les citrons” attendront uniquement pour faire de la confiture.

See you in a next post.