Assurances dans les réponses de JMeter

Pourquoi ça devrait importe? #

Chacun de nous qui travaille avec JMeter et les tests de performance sait l’importance d’ajouter des validations aux requêtes HTTP principales. Des validations, des assertions, quelque chose qui vous informe automatiquement si la réponse est OK ou s’il y a un problème. Si vous n’êtes pas convaincus par cette idée, imaginez que vous obtenez des temps de réponse super rapides dans votre test de charge et que vous génerez une rapport à votre client ou à votre manager disant que le site ne fonctionne pas, mais qu’il est en train de voler. Imaginez maintenant que, malgré ces excellents résultats, la page du serveur indique “site fermé, veuillez revenir plus tard.” Et je vous dirai encore plus, tous ceux qui ont joué avec l’application de test de concurrency ont expérimenté le même problème : les pages des serveurs indiquent une erreur en réponse à un code de retour 200. Oui! Un code de retour 200 signifie “OK”, donc il n’y a pas de problème. Curieux, non? C’est-à-dire que nous ne pouvons pas compter uniquement sur le code de retour pour savoir si la réponse est correcte ou s’il y a un problème.

Dans ce sens, les valuations ne sont pas seulement une façon de confirmer que le serveur répond comme prévu, mais elles servent également à vérifier que le script que nous développons fonctionne comme il devrait et simulate la comportement des utilisateurs selon l’architecture prévue.

Par exemple, si notre script affecte l’impact sur le système en créant un enregistrement dans la base de données, nous devons assurer que, après exécuter le script, l’enregistrement n’est pas créé, et que le script indique qu’il a réussi sans problèmes.

Ces sont des exemples de choix faibles d’assertion ou de validation dans nos demandes.

En effet, ce dont nous avons besoin est d’éviter les fausses négatives et les fausses positives.

Évitant les faux positifs et les faux négatifs #

D’accord, voici ce que ces concepts signifient :

• Faux Positif : Le test dit qu’il y a une erreur, mais il n’y en a pas réellement, donc nous perdons du temps à chercher le cause de l’erreur jusqu’à ce que nous réalisons que la faute était dans le test, l’environnement, les données, etc.
• Faux Négatif : Il y a des bugs, et nous sommes si calmes ! Confiant qu’ils sont couverts par les tests, qu’ils sont en cours de vérification, donc bug-free (Attention à ce point!)

Cela signifie que si il y a une erreur, le script doit montrer un échec ; si le système fonctionne correctement, le script doit dire qu’il n’y a pas d’erreurs et nous devons être en mesure de faire confiance à cela.

Comment choisissons-nous des assertions de qualité ?

Définir des assertions bons pour nos Demandes HTTP #

La réalité est que nous n’avons pas trouvé de guide clair sur la façon de définir les assertions pour chaque Demande HTTP, et puisque c’est quelque chose dont nous devons toujours expliquer à nos nouveaux testeurs de performance recrutés ou formés, nous avons créé notre propre guide.

C’est pourquoi je vous partagerais les méthodes et critères qui ont été les plus efficaces pour nous lors de la sélection des éléments à valider dans le résultat d’une simulation de charge sur un serveur avec JMeter (comme mentionné dans ce checklist pour améliorer les scripts de JMeter).

1.- Vérifier un login #

Typiquement, après authentification à une système, nous voyons des textes comme “Bienvenue Utilisateur” ou notre nom apparaît quelque part sur la fenêtre, indiquant que l’authentification a été réussie. Par conséquent, dans ces cas-là, il s’agit d’un élément excellent à valider.

Rappelez-vous que dans JMeter, on peut spécifier une variable en validant. Donc, dans les cas où le nom d’utilisateur est paramétré (lire depuis un fichier CSV ou défini comme une variable utilisateur), je peux valider la texte ${UserName} et JMeter remplacera la variable par sa valeur à l’exécution.

2.- Vérifier la contenance de la fenêtre #

Quand nous faisons une demande qui renvoie un document HTML, nous pouvons choisir le texte ou les titres que devraient apparaître dans cette réponse. Par exemple, si je visite la page du site JMeter ( http://jmeter.apache.org/), nous pouvons voir ce qui suit :

Nous savons que si ce site se charge correctement, le titre “Qu’est-ce que je peux faire avec ça ?” devrait apparaître en réponse à la demande faite au site. Donc, c’est une bonne assertion de validation qu’on nous reçoit l’attente page. Le défi avec cette type de validation est de valider le contenu afin que nous sachions que, dans le cas d’un échec, ce texte ne s’affiche pas en réponse. Pour cela, on peut se tourner aux développeurs pour cette information.

3.- Considérez les étapes futures de la scénario #

Si nous savons que l’action suivante à effectuer est d’aller cliquer sur le bouton X, ou d’accéder au lien Z, ou de sélectionner l’option A dans le combo box B, une stratégie très bonne consiste à valider que la réponse du requête inclut l’élément dont nous voulons acter en la suite. Par exemple, si après avoir chargé la page JMeter, nous souhaitons sélectionner l’option “Télécharger les versions” qui se trouve dans le menu déroulant B, nous pouvons valider cette texte et assurer la continuité du flux. Pour cela, nous utilisons la capture de la réponse du serveur et vérifions comment cet option est présentée dans l’HTML, en voici un exemple :

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

Et nous créons la validité avec >Download Releases< :

4.- Vérifiez les valeurs à extraire #

Parfois, nous extrayons des variables d’une réponse HTTP en utilisant des expressions régulières (Add->Post Processors->Extract Variable) avec l’intention de les utiliser dans une requête ultérieure. C’est ce que nous faisons lorsque nous parlons de la mappage des variables.

Nous pouvons ensuite valider que cette variable apparaît dans la réponse du serveur. Pour cela, nous pouvons utiliser des validations qui utilisent les expressions régulières. Par exemple :

Ceci est la façon de ce que le régulier ne correspond pas à la réponse reçue, nous aurons une erreur de validité.

5.- Precautionnez-vous avec les caractères spéciaux #

Vous devez être prudent lorsque vous écrivez l’assertion dans JMeter car le texte n’est pas toujours reçu de la même façon que lorsqu’il est affiché sur la page. Par exemple, si je voulais valider le titre Apache JMeter™, je ne peux pas le répéter exactement car la réponse du serveur apparaît comme Apache JMeter&trade; et non tel qu’elle se trouve sur la page. Si nous ne l’utilisons pas de la même façon que dans HTML, les assertions (ainsi que les expressions régulières) ne trouveront pas ce texte.

6.- Le nombre correct de vérifications #

JMeter vous permet d’ajouter autant de vérifications que le utilisateur souhaite, donc chaque vérification mentionnée ci-dessus peut être accompagnée de vérifications supplémentaires comme les titres HTML (<title>...</title>), pour ajouter une robustesse à la validation.

Lors de l’ajout d’autres assertions, il faut être prudent que le script ne devienne pas trop chargé. C’est pourquoi il n’est pas recommandé d’ajouter plus de deux assertions par demande. Par conséquent, nous devons s’assurer que les qui choisissons sont décisives lorsqu’on définit la validité de la réponse.

Comment allez-vous valider vos réponses ? #

Nous espérons que cette liste est utile lorsque vous ajoutez des assertions. En somme, je souhaiterais que vous conservez cela à l’esprit :

• Ajoutez entre une assertion et deux pour chaque requête HTTP importante dans le flux que vous testez.
• Choisissez de valider ce que vous voulez : les titres, la texte, les valeurs ou les éléments que vous interagissez dans les étapes suivantes du flux. Le point important est que si le script échoue, c’est parce que le système échoue, et si le système échoue, le script échoue (donc évitant ainsi des faux positifs et des faux négatifs). Si vous avez d’autres idées, je serais ravi de les partager afin que nous puissions continuellement améliorer la façon dont nous faisons nos tests de charge.

À propos de ce post #

Nous avons préparé ce post quelques années auparavant en anglais avec plusieurs collègues à Abstracta, mais il demeure pertinent. Il s’agit d’une compréhension des meilleures pratiques pour valider une requête HTTP dans JMeter. L’article original en anglais peut être consulté ici. Je le dis encore pertinent car l’HTTP est assez stable et que JMeter aussi, donc les meilleures pratiques autour de ce sujet n’ont pas changé beaucoup.

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