|
|
Développer un plan de test avec JMeter
Date de publication : 30 mars 2011.
Par
Gomes Rodrigues (arodrigues.developpez.com)
Suite à l'article sur comment créer un plan de tests réaliste, regardons comment mettre en application ces conseils avec Apache JMeter.
1. Introduction
2. Présentation de JMeter
3. Fonctionnement de JMeter
3-1. Test plan
3-2. Workbench
3-3. Description des éléments JMeter
3-3-1. Thread group
3-3-2. Sampler
3-3-3. Listeners
3-3-4. Logic controller
3-3-5. Config Element
3-3-6. Post Processeurs
3-3-7. Préprocesseurs
3-3-8. Assertions
3-3-9. Timers
3-3-10. Plugin JMeter
3-3-10-1. PerfMon
3-3-10-2. Stepping Thread Group
3-4. Ordre d'exécution des éléments
4. Processus de création d'un plan de test
4-1. Création des scénarios
4-1-1. Définition du scénario
4-1-2. Enregistrer/scripter
4-1-3. Variabiliser
4-1-4. Exécuter
4-2. Création du plan de test
5. Conception d'un scénario de test
5-1. Structure du scénario
5-1-1. Paramétrage des propriétés par défaut
5-1-1-1. Configuration du serveur cible
5-1-1-2. Gestion des cookies
5-1-1-3. Gestion du cache
5-1-1-4. Gestion des en-têtes HTTP
5-1-2. Découper en action
5-1-3. Temps de réflexion
5-1-4. Pacing
5-2. Création du scénario
5-2-1. Utilisation de l'enregistreur de requêtes
5-3. Variabilisation des données
5-3-1. Variable d'un fichier CVS
5-3-2. Expressions régulières
5-4. Ajout des points de contrôle
5-5. Test de fichiers téléchargés
5-6. Débogage
6. Création du plan de test
7. Exécution du test
7-1. Baseline
7-2. Désactivation de l'IHM
7-3. Test de charge distribué
8. Lire les résultats
9. Conclusion
10. Remerciements
11. Références
1. Introduction
Maintenant que nous savons comment créer des plans de tests de charge réalistes, regardons comment le faire avec l'outil JMeter.
Nous allons nous concentrer sur le test d'une application web.
2. Présentation de JMeter
Apache JMeter est un outil gratuit de test de charges permettant :
- de tester les performances d'une application en simulant des utilisateurs ;
- d'enregistrer les temps de réponse.
Pour cela il peut utiliser différents protocoles (HTTP, SOAP, LDAP, FTP...) afin de tester différents types d'applications (base de données, Webservice, application Web...).
Dans le cas des applications Web, JMeter possède un élément Proxy permettant d'enregistrer automatiquement le scénario afin de gagner du temps et de permettre son utilisation à un large public.
Tout cela en fait un outil assez complet.
Pour ceux qui sont habitués à des outils commerciaux (HP Mercury LoadRunner, MicroFocus SilkPerformer ou Neotys Neoload), JMeter demande un peu plus d'efforts et surtout le reporting et le monitoring y sont quasiment absents.
3. Fonctionnement de JMeter
Lorsqu'on lance JMeter, on se retrouve avec cet écran.
On remarque qu'on a deux espaces de travail : Test plan et Workbench. Sur chacun, on peut ajouter des éléments afin de construire notre plan de test.
Puis on ajoute des éléments/items qui vont composer nos scénarios.
3-1. Test plan
C'est l'espace de travail où on va mettre les éléments qui constituent notre plan de test.
3-2. Workbench
C'est un espace de travail temporaire.
Attention il n'est pas sauvegardé.
3-3. Description des éléments JMeter
Voilà une liste non exhaustive des éléments JMeter.
La liste complète des éléments se trouve sur http://jakarta.apache.org/jmeter/usermanual/component_reference.html
3-3-1. Thread group
C'est l'élément de base pour un scénario.
C'est ici qu'on configurera le nombre d'utilisateurs et d'itérations et la durée du ramp up (durée de montée en charge).
3-3-2. Sampler
Permet de définir le type de requête échangé avec le serveur (HTTP, FTP, JDBC...) et de les émettre.
3-3-3. Listeners
Permet de récupérer et d'afficher les résultats des tests (par exemple : fichiers, graphes).
3-3-4. Logic controller
Permet de choisir l'ordre d'exécution des Samplers (par exemple : aléatoire, boucle, conditionnel).
3-3-5. Config Element
Paramétrage des propriétés par défaut pour les requêtes HTTP, requêtes FTP, requêtes LDAP...
Il permet aussi de définir des variables et des jeux de données.
3-3-6. Post Processeurs
Permet d'effectuer des traitements après l'exécution d'une requête (ou plusieurs).
En particulier on peut utiliser pour extraire des données des résultats, des expressions régulières avec le « Regular Expression Extractor » qui utilise la syntaxe de Apache Jakarta ORO.
3-3-7. Préprocesseurs
Permet d'effectuer des prétraitements avant la requête, utile pour la préparation de données.
3-3-8. Assertions
Permet de contrôler les réponses du serveur (par exemple : temps de réponse, la réponse contient-elle une chaîne de caractères, taille, XML valide).
3-3-9. Timers
Permet d'ajouter des temps de pause entre chaque action (par exemple : temps constant, temps aléatoire).
Il faut faire attention à :
- ils doivent être placés en tant qu'enfant d'une requête pour que la pause soit exécutée avant l'exécution de la requête ;
- s'ils sont au niveau du Thread Group, ils s'appliqueront pour chaque requête.
Plus d'informations sur
3-3-10. Plugin JMeter
Afin de ne pas être limité par l'installation de base de JMeter, nous pouvons utiliser les plugins qui se trouvent à l'adresse http://code.google.com/p/jmeter-plugins/.
Cela permettra aussi à ceux qui sont habitués à HP Loadrunner de s'y retrouver plus facilement.
3-3-10-1. PerfMon
Il est important de superviser les serveurs cibles et les injecteurs. Pour cela on peut utiliser le plugin PerfMon.
Ce plugin permet de superviser :
- l'utilisation du CPU ;
- l'utilisation de la mémoire ;
- l'utilisation du swap ;
- le nombre d'accès disque ;
- l'activité du réseau.
3-3-10-2. Stepping Thread Group
Permet d'affiner la configuration du ramp up à la manière de HP Loadrunner.
Plus d'informations sur http://code.google.com/p/jmeter-plugins/wiki/SteppingThreadGroup
3-4. Ordre d'exécution des éléments
Il faut faire attention à l'ordre d'exécution.
Plus d'informations sur http://jakarta.apache.org/jmeter/usermanual/test_plan.html#executionorder
4. Processus de création d'un plan de test
Le plus simple pour la création d'un test avec JMeter est la façon décrite ci-dessous.
4-1. Création des scénarios
Dans un premier temps, il faut créer les scénarios.
4-1-1. Définition du scénario
Pour plus d'informations ici.
4-1-2. Enregistrer/scripter
La méthode la plus simple pour obtenir un script est d'utiliser le proxy de JMeter pour enregistrer les requêtes effectuées entre le navigateur et le serveur.
4-1-3. Variabiliser
Afin de rendre le scénario plus réaliste, ajouter des éléments non enregistrés par le proxy, éviter les effets de cache et d'ajouter la corrélation entre chaque actions/écrans, il faut utiliser un certain nombre d'éléments de JMeter (Timers, Pre processor...).
4-1-4. Exécuter
Une fois cela fait, il faut vérifier que le scénario est valide. Pour cela il suffit de l'exécuter une fois avec un seul utilisateur.
4-2. Création du plan de test
Une fois tous les scénarios réalisés, il faut les regrouper dans un ou plusieurs plans de test.
5. Conception d'un scénario de test
Avant de commencer tête baissée à scripter les scénarios il est important de prendre son temps afin de bien les choisir. En effet en fonction des scénarios de test, on peut obtenir de mauvaises performances avec n'importe quelle application en simulant un usage irréaliste ou au contraire avoir des performances acceptables. De même on peut se retrouver avec énormément de tests afin d'être le plus réaliste possible et donc afin de limiter ce problème, pensez à la loi de Pareto afin de faire le tri.
Plus d'informations sur http://arodrigues.developpez.com/tutoriels/java/performance/plan-test-realiste/
5-1. Structure du scénario
Afin de faciliter la lecture des résultats et du scénario, il est conseillé de structurer ses scénarios.
Voilà une des solutions possibles.
5-1-1. Paramétrage des propriétés par défaut
Dans un premier temps on va ajouter des éléments « Config Element » afin de définir un certain nombre de propriétés par défaut.
5-1-1-1. Configuration du serveur cible
Pour variabiliser le nom du serveur web, son port... il suffit d'ajouter un élément « HTTP Request Default » et de mettre les bonnes valeurs.
Le mettre en fils de « Test plan » ou « Thread Group » pour qu'il s'applique à l'ensemble des requêtes.
Cela permet de changer facilement le serveur qu'on teste (passage d'un serveur de développement à un serveur de test).
5-1-1-2. Gestion des cookies
De même en ajoutant l'élément « HTTP Cookie Manager », on activera la gestion des cookies.
Ne pas oublier de :
- cocher « Nettoyer les cookies à chaque itération » afin d'effacer les cookies entre chaque itération ;
- positionner Cookie Policy à compatibility pour la majorité des cas ;
- le mettre en fils de « Test plan » ou « Thread Group » pour qu'il s'applique à l'ensemble des requêtes.
5-1-1-3. Gestion du cache
De même en ajoutant l'élément « HTTP Cache Manager », on activera la gestion du cache afin de simuler le comportement d'un navigateur Web en matière de cache.
5-1-1-4. Gestion des en-têtes HTTP
Afin de paramétrer les en-têtes HTTP des requêtes envoyées, on peut ajouter un « HTTP Header Manager »
Cela permet par exemple de simuler un navigateur particulier en paramétrant le User-Agent.
Par exemple pour IE.
Pour Firefox.
Afin d'aider à trouver les bons paramètres et leurs valeurs, on peut utiliser le proxy de la manière suivante.
Activer « capture HTTP header » dans le « HTTP Proxy Server ».
Lors de l'enregistrement, on se retrouvera avec les informations nécessaires.
5-1-2. Découper en action
Dans un premier temps nous allons découper le scénario en transactions/actions à l'aide de « Transaction controller »
Notre scénario ressemblera à :
Thread group
Transaction controller 1
HTTP Request 1
HTTP Request 2
...
HTTP Request N
Transaction controller 2
HTTP Request 1
HTTP Request 2
...
HTTP Request N
...
Transaction controller N
HTTP Request 1
HTTP Request 2
...
HTTP Request N
Cela nous permettra d'avoir des KPI pour chaque transaction définie et ainsi faciliter la lecture des résultats.
5-1-3. Temps de réflexion
Afin d'être le plus réaliste possible, on va utiliser un temps variable.
Plus d'informations sur http://arodrigues.developpez.com/tutoriels/java/performance/plan-test-realiste/#LV-D
On peut capturer le temps de réflexion de l'utilisateur lors de l'enregistrement du script.
Pour cela il faut ajouter un élément « Uniform Random Timer » au « HTTP Proxy Server ».
Puis dans le champ « Constant Delay Offset » mettre ${T}.
A la fin de l'enregistrement, on peut voir que des éléments « Uniform Random Timer » ont été créés avec la bonne valeur.
5-1-4. Pacing
Plus d'information sur comment fixer la durée de répétition d'une requête sur
5-2. Création du scénario
Maintenant que nous avons tous les éléments, on peut passer à l'utilisation de l'enregistreur de requêtes par le proxy pour enregistrer le scénario.
Il faut faire attention au fait que le proxy va enregistrer toutes les communications sortantes/entrantes du navigateur Web et que donc il est important de désactiver tous les plugins/... afin de ne pas enregistrer de requêtes parasites.
5-2-1. Utilisation de l'enregistreur de requêtes
Pour cela, il faut commencer par ajouter l'élément « HTTP Proxy Server »
Clic droit sur Workbench et Add -> Non Test Elements -> HTTP Proxy Server
Sur cet écran il faut bien noter les paramètres du proxy car on les utilisera dans la suite pour configurer notre navigateur Web pour l'enregistrement du scénario.
Cocher le paramètre Add Assertions si on veut générer un élément Asssertions automatiquement.
Cocher le paramètre Add Assertions si on veut générer un élément Asssertions automatiquement.
Maintenant on va créer pour chaque action du scénario un « Transaction Controller » (on va prendre comme exemple, la recherche d'un mot-clé sur Google).
Clic droit sur HTTP Proxy Server et Add -> Logic Controller -> Transaction Controller
Les renommer.
Modifier dans « HTTP Proxy Server » l'option « Target Controller » pour qu'elle pointe sur « Transaction Controller » nommé Accueil.
Voila on est prêt à enregistrer le scénario, pour cela il faut :
- démarrer le proxy (bouton start dans l'élément HTTP Proxy Server) ;
- configurer votre navigateur web pour qu'il utilise ce proxy (on peut utiliser le plugin foxyproxy pour Firefox) ;
- configurer votre navigateur web pour qu'il n'utilise pas son cache (pensez à le vider avant) ;
- reproduire le scénario à l'aide du navigateur web ;
- arrêter le proxy une fois la capture du scénario fini.
Ne pas oublier de faire pointer le navigateur sur le proxy.
Par exemple sous IE.
Comme on peut le voir dans JMeter, de nouveaux sous-items sont apparus.
5-3. Variabilisation des données
Pour rendre le scénario plus réaliste et faire attention à la gestion du cache, il faut variabiliser un certain nombre de choses comme :
- l'identifiant et le mot de passe des utilisateurs ;
- les entrées utilisateurs dans les formulaires ;
- la sélection d'un lien ;
- etc.
Plus d'informations sur http://arodrigues.developpez.com/tutoriels/java/performance/plan-test-realiste/#LV-A, http://arodrigues.developpez.com/tutoriels/java/performance/plan-test-realiste/#LV-B et http://blog.milamberspace.net/index.php/jmeter-pages/jmeter-variabilisation-de-donnees
5-3-1. Variable d'un fichier CVS
Un choix simple et pertinent est d'utiliser un fichier CSV en entrée à l'aide de l'élément « Config Element->CSV Data Set Config ».
Les variables récupérées pourront être utilisées dans le reste du plan de test en utilisant la syntaxe suivante ${nom de la variable}
Par exemple pour une recherche Google.
Il est possible d'utiliser Benerator pour générer ce fichier CSV.
5-3-2. Expressions régulières
L'utilisation des expressions régulières nous permettra de corréler des actions/écran entre eux.
Par exemple pour récupérer la session id d'un utilisateur, choisir un objet dans une liste...
Plus d'informations sur http://blog.milamberspace.net/index.php/2009/12/31/quelques-cas-dutilisation-de-lextracteur-dexpression-reguliere-dans-jmeter-554.html.
5-4. Ajout des points de contrôle
Afin de vérifier la réponse du serveur à la requête envoyée, il peut être utile d'ajouter des Assertions (au moins pendant la phase de création des scénarios).
Afin d'avoir un élément Assertion automatiquement créé pour chaque action lors de l'enregistrement du scénario, on peut cocher le paramètre « Add Assertions » dans l'élément « HTTP Proxy Server ».
Puis il suffit de compléter avec le test voulu.
5-5. Test de fichiers téléchargés
Il est possible de tester les fichiers téléchargés à l'aide d'API Java.
Pour les PDF il y a PDFBox : http://theworkaholic.blogspot.com/2010/03/asserting-pdfs.html
Pour les fichiers Microsoft Office il y a Apache POI : http://theworkaholic.blogspot.com/2010/03/asserting-ms-office-formats.html
5-6. Débogage
Afin de faciliter le débogage du script, on peut utiliser un « View Results Tree ».
Pour cela, clic droit sur Workbench et Add -> Listener -> View Results Tree
Ce qui nous permettra d'avoir dans l'onglet « Sampler Result » et « Response data », la réponse du serveur.
6. Création du plan de test
Maintenant que nous avons un scénario de prêt, nous pouvons créer un plan de test.
Pour cela il faut ajouter dans « Test Plan », un « Thread Group ».
Clic droit sur Test Plan -> Add -> Thread Group
Puis il faut configurer le nombre d'utilisateurs et d'itérations et la durée du ramp up.
Faire de même avec les autres scénarios qui font partie du plan de test.
7. Exécution du test
Maintenant que nous avons un plan de test de prêt, on peut lancer les tests.
7-1. Baseline
Dans un premier temps il faut exécuter le test avec un seul utilisateur afin de :
- tester que l'application n'a pas de problèmes de performance avec seulement un utilisateur car dans ce cas, lancer la campagne de test ne sert à rien ;
- créer un baseline qui nous permettra d'avoir des KPI de référence.
7-2. Désactivation de l'IHM
Pour des gros tests il faut faire attention à :
- désactiver les listeners coûteux et ne garder que Summary Listener, Graph Listener, et Spline Listener ;
- limiter le nombre de listeners ;
- désactiver le mode graphique avec l'option –non-gui ;
- générer un fichier CSV .jtl ou XML.
Plus d'informations sur http://blog.milamberspace.net/index.php/2009/02/01/jmeter-pourquoi-executer-son-test-de-charges-en-mode-non-gui-sans-interface-graphique-192.html et http://blog.milamberspace.net/index.php/2009/11/15/envoyer-en-ligne-de-commande-des-parametres-a-votre-scenario-jmeter-534.html et http://blog.milamberspace.net/index.php/jmeter-pages/jmeter-test-de-charges-a-distance-distributed-testing.
Pour suivre ce qui se passe lorsqu'on est en mode non-gui.
7-3. Test de charge distribué
Si un seul injecteur ne suffit pas, faire un test de charge distribué (remote testing) sur plusieurs injecteurs afin de répartir la charge de test.
Plus d'information sur http://jakarta.apache.org/jmeter/usermanual/remote-test.html
8. Lire les résultats
Comme vous pouvez le constater, la partie reporting de JMeter n'est pas ce qui se fait de mieux.
La méthode la plus simple est de sauvegarder les résultats en CSV afin de les traiter avec un autre outil (Excel, outils de statistiques, outils BI...).
Par exemple avec OpenOffice.org, Access.
9. Conclusion
Comme on a pu le voir, JMeter permet d'appliquer les conseils donnés dans mon précédent article. Maintenant que nous connaissons la théorie et la pratique avec JMeter, nous verrons dans un prochain article un cas concret d'utilisation de JMeter.
10. Remerciements
Merci à Milamber pour sa relecture et son aide.
Merci à ClaudeLELOUP pour sa correction orthographique.
Merci à ClaudeLELOUP pour sa correction orthographique.
11. Références
Copyright © 2011 Gomes Rodrigues. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts. Cette page est déposée.
Copyright © 2000-2012 - www.developpez.com