JMeter est un logiciel de tests de montée en charge créé en 1998 par Stefano Mazzocchi, de la fondation Apache Software. Il est sous licence Apache et développé en Java, ce qui le rend multi-plateforme. Initialement prévu pour tester les performances du projet Apache JServ, JMeter a évolué et permet maintenant d’effectuer des tests de montée en charge de différents types, par exemple sur des Sites Web, des WebServices, des serveurs FTP,… Cet outil bénéficie d’une communauté active importante et de mises à jour régulières.
Remarque préliminaire : cet article décrit de manière succincte les étapes nécessaires à la réalisation technique d’un test de montée en charge avec JMeter. Les tests de montée en charge requièrent néanmoins une méthodologie qui se révèle bien plus importante que l’emploi d’un simple outil. Pour plus d’informations sur le sujet, n’hésitez pas à télécharger le livre blanc Osaxis « L’étude des performances : méthodologie et outils de tests de montée en charge Web ».
Présentation de JMeter
Présentation générale
JMeter 2.5.1 propose trois modules :
- Une application graphique pour définir et exécuter les tests ;
- Une application batch permettant d’exécuter les tests ;
- Un composant serveur batch.
Ce dernier est utilisé pour répartir la charge du test sur plusieurs machines et est contrôlé par une instance de JMeter (graphique ou batch) qui centralise les résultats.
De plus, JMeter intègre un système de plugins afin d’étendre les fonctionnalités de base.
Présentation de l’interface graphique
Il est facile de créer un plan de test à partir de l’application graphique. Celui-ci peut ensuite être exécuté depuis les applications batch ou graphique. L’interface de l’application graphique JMeter se présente sous la forme suivante :
Figure 1 : interface de l’application graphique JMeter – Cliquez sur l’image pour l’agrandir
La section Plan de test permet de définir les différents composants exécutés. La section Plan de travail est utilisée pour stocker temporairement des éléments qui ne sont pas pris en compte lors de l’exécution du plan de test. Ceci offre la possibilité de mettre de coté un élément du test sans avoir à le supprimer définitivement.
Le plan de test peut accueillir différents types de composants :
- Moteurs d’utilisateurs : ils définissent le niveau de charge à appliquer sur un ensemble de requêtes du test, le nombre d’utilisateurs, le temps de montée en charge, le nombre d’itérations. Cet élément peut lui-même englober d’autres composants.
- Contrôleurs logiques : ces éléments permettent de structurer le déroulement des tests.
- Fragments d’éléments : ce sont des éléments permettant de réutiliser à plusieurs endroits le même ensemble de composants.
- Configurations : les configurations permettent de définir des éléments de configuration communs à plusieurs composants.
- Echantillons : ce sont les éléments réalisant les opérations de tests, comme lancer des requêtes HTTP, FTP, …
- Compteurs de temps : les compteurs permettent d’ajouter un temps d’attente avant l’exécution d’un composant « Echantillon ».
- Pré-processeurs : appliqués avant les échantillons dans leur portée, ils permettent d’effectuer des opérations diverses.
- Post-processeurs : appliqués après les échantillons, ils permettent d’agir sur les résultats de ceux-ci.
- Assertions : ces éléments permettent de faire des vérifications sur la bonne exécution des tests.
- Récepteurs : ces éléments traitent les résultats des tests et les formatent.
Exemple de test de montée en charge
Cet exemple s’appuie sur un serveur de test hébergeant un moteur de blog. Ce moteur utilise des fichiers pour stocker le contenu, ce qui se traduit par la non utilisation d’un système de gestion de base de données.
Dans un premier temps, le test va porter sur la page d’accueil en utilisant une charge de 10 utilisateurs sur 10 itérations. Ensuite, nous affinerons le test en ajoutant divers composants.
Test sur une page d’accueil
Pour simplifier les appels HTTP, ajoutons tout d’abord un composant paramètres HTTP :
Figure 2 : écran de configuration des paramètres HTTP par défaut – Cliquez sur l’image pour l’agrandir
Ceci permet de spécifier les paramètres communs à toutes les requêtes HTTP effectuées. Il est à noter que tout composant a une portée d’application. Les paramètres s’appliquent à tous les composants définis après le composant de paramétrage, au parent direct et à ses descendants. C’est la règle pour la plupart des composants.
Ajoutons maintenant le groupe d’unités permettant de définir la charge à appliquer lors du test de la page. On définit alors les différents paramètres tels que le nombre d’utilisateurs, le temps de montée en charge et le nombre d’itérations, ainsi que la gestion des erreurs. Cette charge sera appliquée pour tous les descendants du groupe d’unités. Il est possible d’ajouter plusieurs groupes d’unités dans le plan de test, mais on ne peut pas imbriquer les groupes d’unités.
Figure 3 : définition des paramètres du groupe d’unités – Cliquez sur l’image pour l’agrandir
Ajoutons ensuite un échantillon de requête HTTP au groupe d’unité. L’adresse du serveur Web ayant déjà été remplie, il n’est pas utile de la spécifier. Il reste donc à indiquer le chemin de la page à appeler, ici « default.aspx » :
Figure 4 : configuration de la requête HTTP – Cliquez sur l’image pour l’agrandir
Il ne manque plus qu’un élément de restitution des résultats du test d’appel de la page d’accueil. Pour ce faire, on va ajouter un composant « Récepteur » de type « Tableau de résultats » :
Figure 5 : configuration du récepteur « Tableau de résultats » – Cliquez sur l’image pour l’agrandir
Placé en tant que fils de la requête HTTP, le tableau de résultats va afficher uniquement les données provenant de cet appel.
Le test étant désormais prêt à fonctionner, le lancement de celui-ci va lister les requêtes exécutées dans le tableau du récepteur. Nous obtenons le résultat suivant :
Figure 6 : tableau de résultats du test de montée en charge sur la page d’accueil – Cliquez sur l’image pour l’agrandir
Une sortie fichier peut être ajoutée et alimentée avec des indicateurs supplémentaires listés dans le menu accessible avec le bouton configurer.
D’autres récepteurs sont disponibles et permettent d’afficher ou exporter les données sous d’autres formes. Il est par exemple possible d’ajouter une sortie sous forme de graphique avec le récepteur « Graphique de résultats » :
Figure 7 : graphique de résultats du test de montée en charge sur la page d’accueil – Cliquez sur l’image pour l’agrandir
Etape d’identification
Nous allons ajouter au test une étape de connexion au site. Ce site étant en ASP.NET, des éléments supplémentaires sont à mettre en place. Le déroulement de l’identification se fait donc comme suit :
- Appel de la page d’identification en GET ;
- Récupération de la valeur des champs cachés EVENTVALIDATION et VIEWSTATE dans des variables ;
- Validation de la page d’identification en POST ;
- Vérification de la bonne redirection sur la page d’accueil en mode authentifié.
Pour maintenir la connexion, on va de plus employer le composant stockant les cookies.
Pour isoler le processus d’identification du reste de la chaîne, nous ajoutons un composant « Contrôleur simple » dans lequel nous ajoutons d’abord le composant « Gestionnaire de cookies HTTP ». Pour éviter de maintenir la connexion entre les itérations, l’option adéquate est activée :
Figure 8 : configuration du gestionnaire de cookies – Cliquez sur l’image pour l’agrandir
Dans cet élément de configuration, il est possible d’ajouter directement des valeurs de cookies. La présence de ce gestionnaire de cookies permet de transmettre les cookies à chaque requête HTTP.
Nous ajoutons alors l’appel HTTP vers la page d’identification :
Figure 9 : configuration de la requête d’appel de la page d’identification – Cliquez sur l’image pour l’agrandir
Cet appel est effectué pour respecter le principe de fonctionnement de l’ASP.NET et récupérer les valeurs de ViewState et d’EventValidation. Pour cela, nous allons utiliser deux composants Post-processeurs « Extracteur XPath » :
Figure 10 : configuration de l’extracteur XPath pour la récupération du ViewSate – Cliquez sur l’image pour l’agrandir
Figure 11 : configuration de l’extracteur XPath pour la récupération d’EventValidation – Cliquez sur l’image pour l’agrandir
Il est inutile de pré-définir les variables utilisées. En effet ces dernières sont créées à la volée et sont utilisables dans les étapes suivant leur création. Nous pouvons maintenant ajouter un appel HTTP en POST pour lancer le processus d’identification :
Figure 12 : configuration de la requête HTTP de validation de la page d’identification – Cliquez sur l’image pour l’agrandir
Nous envoyons bien ici les informations en POST concernant les informations d’identifiant / mot de passe, la valeur du bouton, ainsi que la valeur des deux champs cachés utilisés par l’ASP.NET. Pour ces deux champs, on fait référence aux variables créées dynamiquement à l’étape précédente.
Pour vérifier le bon déroulement de la connexion, nous ajoutons un composant Assertions « Assertion XPath », vérifiant la présence du texte « Welcome admin ! » dans la réponse de la requête HTTP POST :
Figure 13 : configuration de l’assertion validant l’identification – Cliquez sur l’image pour l’agrandir
Pour analyser les réponses, nous ajoutons enfin deux composants Récepteurs :
- Tableau de résultats.
- Arbre de résultats : celui-ci permet d’afficher en détail les sources des requêtes effectuées, et des réponses reçues.
Figure 14 : Arbre de résultat de la procédure d’identification – Cliquez sur l’image pour l’agrandir
Ce récepteur détaille le déroulement des requêtes en affichant les redirections qui ont eu lieu. Dans l’exemple ci-présent, une redirection est effectuée après l’envoi de la requête d’authentification.
Dans le cas où l’assertion de vérification est erronée, on obtient l’affichage suivant :
Figure 15 : échec de l’assertion d’identification – Cliquez sur l’image pour l’agrandir
L’échec d’une assertion ne provoque pas d’arrêt du test de charge, sauf si l’on modifie le paramétrage du groupe d’unité :
Figure 16 : configuration du comportement lors d’une erreur d’exécution – Cliquez sur l’image pour l’agrandir
Conclusion
JMeter permet de facilement mettre en place des campagnes de tests de montée en charge. Même si l’absence d’un éditeur de script peut paraître déroutante de prime abord, la gestion par l’interface graphique du scénario de test reste souple avec notamment la présence d’un système d’assertions pour valider le résultat d’une requête.
JMeter représente donc un outil complet et performant pour la mise en place de tests de montée en charge simples. Il convient également de préciser qu’il existe déjà de nombreux plugins pour améliorer les rapports de sorties ou ajouter le support d’échantillonneurs supplémentaires.