IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Développer un plan de test avec JMeter

Suite à l'article sur comment créer un plan de tests réaliste, regardons comment mettre en application ces conseils avec Apache JMeter.

Commentez Donner une note à l´article (4.5)

Article lu   fois.

L'auteur

Profil ProSite personnel

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. 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.

II. 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.

III. Fonctionnement de JMeter

Lorsqu'on lance JMeter, on se retrouve avec cet écran.


Image non disponible


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.


Image non disponible


Puis on ajoute des éléments/items qui vont composer nos scénarios.

III-A. Test plan

C'est l'espace de travail où on va mettre les éléments qui constituent notre plan de test.

III-B. Workbench

C'est un espace de travail temporaire.

Attention il n'est pas sauvegardé.

III-C. 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

III-C-1. Thread group

C'est l'élément de base pour un scénario.


Image non disponible


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).


Image non disponible


Depuis la version 2.5 de JMeter il existe 3 types de Thread Group.
Le "Thread Group" qui est le groupe d'unités "normal".
Le "setUp Thread Group" qui est lancé une seule fois au début d'un tir avant les "Thread Group".
Le "tearDownThread Group" qui est lancé une seule fois mais à la fin d'un tir apès les "Thread Group".

Image non disponible




III-C-2. Sampler

Permet de définir le type de requête échangé avec le serveur (HTTP, FTP, JDBC...) et de les émettre.


Image non disponible


III-C-3. Listeners

Permet de récupérer et d'afficher les résultats des tests (par exemple : fichiers, graphes).


Image non disponible


III-C-4. Logic controller

Permet de choisir l'ordre d'exécution des Samplers (par exemple : aléatoire, boucle, conditionnel).

Image non disponible

III-C-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.


Image non disponible


III-C-6. Post Processeurs

Permet d'effectuer des traitements après l'exécution d'une requête (ou plusieurs).


Image non disponible


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.

III-C-7. Préprocesseurs

Permet d'effectuer des prétraitements avant la requête, utile pour la préparation de données.


Image non disponible


III-C-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).


Image non disponible


III-C-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.


Image non disponible


Plus d'informations sur

http://blog.milamberspace.net/index.php/2009/02/08/jmeter-think-time-et-ordre-dexecution-les-bons-plans-212.html

III-C-10. Test Fragment

Depuis la version 2.5 de JMeter on a un nouvelle élément appelé "Test Fragment" qui permet de ne pas exécuter ses éléments fils par JMeter.

Image non disponible




III-C-11. 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.

III-C-11-a. 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.
III-C-11-b. 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

III-C-11-c. Flexible File Writer

Permet de mieux paramétrer le fichier CSV de sortie avec les résultats de JMeter.

Plus d'informations sur http://code.google.com/p/jmeter-plugins/wiki/FlexibleFileWriter

III-D. 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

IV. 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.

IV-A. Création des scénarios

Dans un premier temps, il faut créer les scénarios.

IV-A-1. Définition du scénario

Pour plus d'informations ici.

IV-A-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.


Image non disponible


IV-A-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...).

IV-A-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.


Image non disponible


IV-B. 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.
Par exemple

Image non disponible


V. 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 https://arodrigues.developpez.com/tutoriels/java/performance/plan-test-realiste/

V-A. 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.

V-A-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.

V-A-1-a. 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).


Image non disponible



Une option permettant de récupérer en parallèle les ressources associées à une page (script, css, images..) afin de mieux simuler les navigateurs actuels est apparu dans la version 2.5 de JMeter.

Image non disponible



V-A-1-b. 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.


Image non disponible


V-A-1-c. 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.


Image non disponible


V-A-1-d. 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 »


Image non disponible



Image non disponible

Cela permet par exemple de simuler un navigateur particulier en paramétrant le User-Agent.

Par exemple pour IE.


Image non disponible


Pour Firefox.


Image non disponible


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 ».


Image non disponible


Lors de l'enregistrement, on se retrouvera avec les informations nécessaires.


Image non disponible


V-A-2. Découper en action

Dans un premier temps nous allons découper le scénario en transactions/actions à l'aide de « Transaction controller »


Image non disponible


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.

V-A-3. Temps de réflexion

Afin d'être le plus réaliste possible, on va utiliser un temps variable.


Image non disponible


Plus d'informations sur https://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 ».


Image non disponible


Puis dans le champ « Constant Delay Offset » mettre ${T}.


Image non disponible


A la fin de l'enregistrement, on peut voir que des éléments « Uniform Random Timer » ont été créés avec la bonne valeur.


Image non disponible


V-A-4. Pacing

V-B. 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.

V-B-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


Image non disponible


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.


Image non disponible


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


Image non disponible


Les renommer.


Image non disponible


Modifier dans « HTTP Proxy Server » l'option « Target Controller » pour qu'elle pointe sur « Transaction Controller » nommé Accueil.


Image non disponible



Image non disponible


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.


Image non disponible


Comme on peut le voir dans JMeter, de nouveaux sous-items sont apparus.


Image non disponible


V-C. 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 https://arodrigues.developpez.com/tutoriels/java/performance/plan-test-realiste/#LV-A, https://arodrigues.developpez.com/tutoriels/java/performance/plan-test-realiste/#LV-B et http://blog.milamberspace.net/index.php/jmeter-pages/jmeter-variabilisation-de-donnees

V-C-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 ».


Image non disponible


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}


Image non disponible


Par exemple pour une recherche Google.


Image non disponible


Il est possible d'utiliser Benerator pour générer ce fichier CSV.

V-C-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.

V-D. 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 ».


Image non disponible


Puis il suffit de compléter avec le test voulu.


Image non disponible


V-E. 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

V-F. 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


Image non disponible


Ce qui nous permettra d'avoir dans l'onglet « Sampler Result » et « Response data », la réponse du serveur.


Image non disponible



Image non disponible


V-G. Simulation de plusieurs IP

Lors de certain tests, par exemple avec des Load Balancer/repartiteurs de charges, il peut être utile que les actions simulés par JMeter proviennent d'adresses IP différentes. Plus d'informations sur le blog de milamberspace

VI. 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


Image non disponible


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.

VII. Exécution du test

Maintenant que nous avons un plan de test de prêt, on peut lancer les tests.

VII-A. 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.

VII-B. 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.htmlet 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.

http://blog.milamberspace.net/index.php/2009/02/01/jmeter-suivre-un-tir-de-charge-en-mode-non-gui-avec-le-resume-statistique-200.html

VII-C. 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

VIII. 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.

Pour la sauvegarde des résultats dans un fichier CSV, on peut utiliser le plugin JMeter "Flexible File Writer"

IX. Exemples de scripts JMeter

IX-A. Scripts pour l'application PlantsByWebSphere livrée avec IBM WebSphere 8

IX-A-1. Script 1 : Simulation de visiteurs

IX-A-2. Script 2 : Simulation d'acheteurs

X. 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.

XI. Remerciements

Merci à Milamber pour sa relecture et son aide.
Merci à ClaudeLELOUP pour sa correction orthographique.

XII. Références

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

Copyright © 2011 Antonio Gomes Rodrigues. Aucune reproduction, même partielle, ne peut être faite de ce site ni 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.