Dans cette entrée, nous présentons les meilleures pratiques proposées par deux experts dans le domaine de JMeter: Philippe Mouawad et Antonio Gómez Rodríguez. Ils sont auteurs d’un livre qui, selon moi, est l’un des meilleurs actuellement : Master Apache JMeter From load testing to DevOps. Je recommande le ebook. J’ai ajouté des commentaires et des exemples pour étendre ou clarifier certains concepts.

Obsolete documentation

Given que JMeter a été disponible depuis de nombreuses années, soyez prudent lorsqu’on consulte les blogs, vidéos et autres documents. Toute information publiée plus ou moins deux ans auparavant, ou qui fait référence à des versions antérieures 4.0, est probablement obsolète. La meilleure pratique est d’aller consulter la documentation officielle et le changelog via la versions différentes.

Un important source d’information est notre page en espagnol, JMeter en español, sur Slack et Facebook.

Performances #

La meilleure pratique est non de utiliser BeanShell ou JavaScript car cela dégrade significativement la performance du logiciel. La meilleure pratique est d’utiliser JSR223 qui utilise Groovy par défaut. Groovy est une langue moderne et puissante qui fonctionne avec les versions les plus récentes de Java.

Utilisez la mode non-graphique #

La meilleure pratique n’est pas de l’utiliser pour les tests de charge. Le mode graphique devrait être utilisé pendant le développement du script, mais il est recommandé d’effectuer une transition vers le mode non-graphique une fois que cette phase a été complétée.

Rapport HTML #

JMeter fournit de nombreuses alternatives pour la représentation des résultats dans le mode graphique. Cependant, la pratique à suivre est d’obtenir un rapport HTML au terme du test (en mode non-graphique):

jmeter -n -t [jmx file] -l [results file] -e -o [\Path to output folder]

Je recommande de visiter ce lien.

Si pour quelque raison il y avait un tableau qui n’était pas inclus dans le rapport HTML, assurez-vous toujours d’avoir l’option de charger les résultats du fichier dans la mode GUI après avoir terminé le test.

N’importe quelle modification directe du fichier XML où JMeter stocke le test (*.jmx) #

La meilleure pratique est de ne jamais y manipuler.

Maîtriser la notion d’exécution de l’ordre #

En bref, l’ordre d’exécution des éléments dans JMeter suit des règles spécifiques. Notre collègue Antonio présente les détails de l’ordre d’exécution dans ce publication.

Variables et Propriétés #

La meilleure pratique est de bien comprendre les différences entre des Variables et des Propriétés. Une Variable est une valeur dynamique qui est exclusivement à un thread ou utilisateur virtuel (VUser). Les variables sont généralement définies en utilisant l’élément Variables de plan utilisateur au niveau du plan lors de la phase d’exécution des tests. Le thread fait une copie locale de la variable, et peut modifier cette valeur sans affecter les autres threads dans le test. Cette utilisation est principalement limitée à des données utilisateur et aux règles de corrélation. Les variables sont accessibles via ${varName}. Notre collègue expérimenté Delvis illustre comment utiliser ces variables pendant la phase de processus de corrélation dans ce publication.

De plus, un propriété est une valeur dynamique qui est commune à toutes les threads et normalement utilisée pour définir des informations liées à l’environnement de la exécution. Vous pouvez accéder aux propriétés en utilisant la fonction __P(). Par exemple, la PropX sera lue via ${__P(PropX)}

Utilisation des Fonctions #

JMeter fournit une liste complète de fonctions qui vous permettent d’optimiser la création de scripts pour les tests. La meilleure pratique est de familiariser-vous avec et d’utiliser ces fonctions plutôt que de tenter de “reconstruire le rouleau”. Dans cette publication, notre collègue respecté Antonio présente certaines fonctions pour spécifier les valeurs de temps.

Si cela n’était pas suffisant, JMeter possède également un autre plugin qui fournit des fonctions supplémentaires.

Un exemple commun est d’utiliser la fonction UUID pour créer une base de données de noms d’emails aléatoires du type suivant :

{
    "email": "${__substring(${__UUID()}, 0, 8)}.${__substring(${__UUID()}, 25, 35)}@gmail.com", 
}

Modèles ouverts vs Modèles fermés #

La meilleure pratique est d’utiliser le modèle correct pour l’application testée. Dans un modèle ouvert, les utilisateurs arrivent à l’application de manière asynchrone, indépendamment du nombre de transactions en cours dans la SUT (système sous-test). La requête ici consiste en le produit des TPS (transactions par seconde) x unité de temps.

Exemples typiques de ce type de test sont les applications d’e-commerce.

De plus, dans un modèle fermé, le nombre de utilisateurs est fixe, donc la quantité de transactions est limitée par le nombre d’utilisateurs dans le système sous test (SUT). Un exemple typique est une centre de téléphone où le nombre de rappels acceptés est limité par le nombre d’opérateurs; si tous les opérateurs sont occupés, le système ne recevra pas plus de rappels. La requête ici est la nombre de utilisateurs simultanés (VUsers).