Quelques questions sur JMeter

26 views
Skip to first unread message

Hervé Thouzard

unread,
Sep 26, 2024, 3:36:55 AMSep 26
to JMeter en français

Bonjour,


La société pour laquelle je travaille (un éditeur de logiciels), en tant que “full stack developer” me propose de devenir le référent JMeter. Voilà un peu le contexte, puis quelques questions :


  1. JMeter va être utilisé par plusieurs équipes qui travaillent sur des produits et donc des projets différents.

  2. JMeter va être utilisé pour tester des APIs (développées en interne), et pas autre chose (j’entends par là, pas pour tester des pages web).

  3. Il n’est pas question de mettre en place des scénarios, comme par exemple d’ouvrir un compte sur un site web puis de modifier son profil mais de faire du test unitaire et du test de montée en charge. Donc au fur et à mesure du développement des APIs, il doit être mis en place des tests.

  4. Il n’est, pour l’instant, pas envisagé d’intégrer ces tests dans la PIC


Maintenant voilà les questions, sachant que j’ai déjà mis en place un fichier de tests, et que je vais prendre le cas d’un site de e-commerce :

  1. Auriez-vous des références pour se former ? Vidéo, livres, blog, etc ?

  2. Comment faites-vous pour versionner ? Le fichier jmx fait partie du dépôt de code, mais :

    1. Lors d’une merge request, on se retrouve avec plusieurs centaines voire plusieurs milliers de lignes (xml) différentes, c’est humainement impossible de tout “contrôler”.

    2. En cas de conflit, comment, autrement que visuellement, comparer les différences entre 2 versions ?

  3. Chaque développeur dispose, en local, de sa propre base de données, qu’il va utiliser pour faire ses tests durant le développement, mais des tests sur, par exemple un serveur de Tests Acceptation sont aussi nécessaires. La base de données contient différentes sociétés (de test) avec des noms et des identifiants de connexion différents. Il est, “à la limite”, possible de s’entendre sur des noms de sociétés et des identifiants pour les serveurs de tests.

    1. Est-ce qu’il est possible de paramétrer JMeter pour utiliser des fichiers de configuration propre à chaque développeur et aux différents serveurs de test ?

    2. Ou bien, est-ce qu’il est possible d’avoir une notion d’environnement, un peu comme les fichiers appsettings.json et appsettings.Development.json ?

  4. Nous avons mis en place plusieurs “User Defined Variables”, un premier pour définir les URL, ports et chemins lorsqu’on utilise JMeter pour du test en local et un deuxième pour les tests sur le serveur de TA. Nous activons ou désactivons l’un des 2 en fonction de la situation courante. Ma question rejoint un peu la précédente, est-ce qu’il est possible d’activer ou de charger la bonne configuration, en fonction de l’environnement ? Je précise que je travaille avec des collègues plutôt allergiques à la ligne de commande…

  5. Actuellement le fichier .jmx dont je dispose teste tous les endpoints des API, les uns à la suite des autres.Donc il se connecte au endpoint qui permet de récupérer un JWT, récupère le JWT puis réalise des appels aux différents tests. Toutefois, pour des raisons “d’efficacité”, nous activons et désactivons des portions de tests pour aller plus vite. Est-ce qu’un découpage par fichier Jmx est préférable ? Si je fais le parallèle avec un site de e-commerce, d’avoir un fichier jmx pour tester la création de compte, un fichier jmx pour la visualisation du panier,un fichier jmx pour le paiement en ligne, tout en centralisant et en rendant paramétrable au maximum les choses ?

  6. Est-ce qu’il y a une “norme” ou bonne pratique sur le nommage des tests ? Par exemple “Create account with success”, ou “Create account fail” ?

  7. Quelle pratique mettre en place pour le groupement les tests. Toujours avec l’exemple du site de e-commerce, est-ce que vous allez mettre en place un unique “transaction controller” pour le panier avec tous les cas qui sont censés marcher ET tous les cas qui ne sont pas censés marcher ? Par exemple, cas qui marchent, je suis connecté, j’ai bien choisi un produit et je l’ajoute au panier. Cas qui ne marchent pas, je ne suis pas connecté et j’ajoute un produit qui n’existe pas ?

Ou alors, à l’inverse, de grouper tous les cas qui sont censés marcher.

Ce qui pourrait donner ceci :

Première option :

  • Création d’un compte client :

    • Avec succès

    • Avec erreurs

  • Ajout d’un produit au panier :

  • Avec succès

  • Avec erreurs

Deuxième options :

  • Succès :

  • Création d’un compte

  • Ajout d’un produit au panier

  • Erreurs :

  • Création d’un compte 

  • Ajout d’un produit au panier


Voilà un peu ma liste de questions, pour démarrer.


D’avance merci pour votre aide.

Milamber

unread,
Sep 26, 2024, 4:23:02 AMSep 26
to jmet...@googlegroups.com
Salut Hervé,

Trop de texte et questions dans ton mail ;-)

Ci-dessous les réponses des IA Gemini et Claude revues et validées par moi (humain :-)) :


Réponse:

Félicitations pour cette nouvelle opportunité en tant que référent JMeter ! C'est un rôle clé pour assurer la qualité et la performance de vos applications. Voici quelques éléments pour répondre à vos questions et vous aider à démarrer dans ce nouveau rôle :

1. Ressources pour se former

2. Versionner les fichiers JMX

  • Le défi des fichiers JMX: Vous avez raison, la gestion de version des fichiers JMX est complexe en raison de leur format XML qui génère des conflits difficiles à résoudre.

  • Bonnes pratiques:

    • Utilisez un outil de diff adapté au XML comme XMLUnit (code java) ou xmldiff (sous linux) ou vimdiff (fournit avec VIM, linux/win/mac): Cela facilite la comparaison visuelle et la résolution des conflits.

    • Découpez vos fichiers JMX: En créant des fichiers JMX plus petits et modulaires, vous limitez les conflits et facilitez la maintenance.

    • Vous pouvez également explorer des outils comme jmeter-maven-plugin qui permettent de gérer les tests JMeter comme du code.


3. Gestion des environnements

  • Fichiers de propriétés: JMeter permet l'utilisation de fichiers de propriétés pour externaliser les configurations spécifiques à chaque environnement (URL, identifiants, etc.). Vous pouvez charger le fichier approprié au moment de l'exécution en utilisant la ligne de commande ou en paramétrant JMeter.

    • Utilisez la fonction __P{} de JMeter pour référencer ces propriétés dans vos tests.

    • Exemple : ${__P(host,localhost)} où "host" est défini dans un fichier de propriétés.

  • Variables d'environnement: Une autre option consiste à utiliser des variables d'environnement pour stocker les configurations spécifiques à chaque environnement. JMeter peut accéder à ces variables.

    • Activation de configurations selon l'environnement :

    • Créez des fichiers de propriétés pour chaque environnement (dev.properties, qa.properties, etc.).

    • Utilisez l'option -q de JMeter en ligne de commande pour spécifier le fichier de propriétés à utiliser.

  • Plugins: Il existe des plugins JMeter, comme le plugin "Custom Thread Groups", qui permettent de gérer plus facilement les environnements.

4. Structuration des tests

  • Découpage par fichier JMX: C'est une excellente pratique ! Cela améliore la lisibilité, la réutilisation et la maintenance de vos tests. Vous pouvez utiliser un "Test Fragment" pour centraliser les éléments communs (configuration, headers, etc.) et les inclure dans vos différents fichiers JMX.

  • Nommage des tests: Il n'y a pas de norme stricte, mais il est recommandé d'utiliser un nommage descriptif et cohérent. Par exemple :

    • [Nom du test] - [Scénario] - [Résultat attendu]

    • Créer un compte - Données valides - Succès

    • Créer un compte - Email invalide - Echec

    • ⇒ on peut aussi ajouter un système de codification du nom du test qui peut être ensuite utilisé comme référence dans d’autre supports, genre un fichier excel qui liste les tests par API : 001-CPT-CREATION-OK, 002-CPT-CREATION-FAIL, etc.

  • Groupement des tests:

    • Par fonctionnalité: C'est souvent la méthode la plus logique. Chaque "Transaction Controller" regroupe les requêtes liées à une fonctionnalité spécifique (ex: panier, paiement, etc.).

    • Par résultat attendu: Une autre approche consiste à grouper les tests en fonction du résultat attendu (succès, échec).

    • Utilisez des "Transaction Controllers" pour regrouper les étapes logiques d'un scénario.

    • Exemple :

        • Succès

            • TC_CreateAccount_Success

        •   TC_AddToCart_Succes

      • Échecs

      • TC_CreateAccount_Fail

      • TC_AddToCart_Fail

Le choix dépend de vos besoins et de la façon dont vous souhaitez organiser vos tests. L'important est d'avoir une structure claire et cohérente.

5. Autres conseils

  • Tests unitaires: JMeter n'est pas l'outil idéal pour les tests unitaires. Privilégiez un framework de test unitaire adapté à votre langage de développement pour ce type de tests.

  • Intégration continue: Même si vous n'intégrez pas encore vos tests JMeter dans votre pipeline CI/CD, c'est une évolution à envisager pour automatiser l'exécution de vos tests à chaque déploiement.

  • Collaboration: En tant que référent JMeter, la communication avec les différentes équipes est essentielle. Organisez des réunions régulières pour partager les bonnes pratiques, répondre aux questions et vous assurer que JMeter est utilisé efficacement.

N'hésitez pas à poser d'autres questions si vous en avez ! JMeter est un outil puissant et flexible, mais il peut être complexe à maîtriser. En prenant le temps de vous former et d'établir de bonnes pratiques, vous contribuerez grandement à la qualité et à la performance des applications de votre entreprise.

Bonne chance dans ce nouveau rôle !

A+
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "JMeter en français".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse jmeter-fr+...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/jmeter-fr/3924f357-44af-4721-a7ed-216cb75c07bfn%40googlegroups.com.

Vincent Daburon

unread,
Sep 27, 2024, 8:23:31 AMSep 27
to JMeter en français
Bonjour,
LE site avec de très nombreux liens autour d'Apache JMeter : https://github.com/aliesbelik/awesome-jmeter pour les liens vers les formations, vidéos et livres.

Pour configurer le test selon l'environnement, utilise des fichiers properties par environnement qui vont contenir l'url de l'environnement, le nombre de vusers pour les threads groups, la durée du test.
Cf : https://blog.octoperf.com/jmeter-properties-configurable-test-plans/

Tu lances JMeter en GUI ou en CLI avec le parametre jmeter.bat -q mon_fichier.properties -t script.jmx (

Les Test Fragment permettent de découper le script en bloc : authent, logout, accueil ... et avec un module controller on peut choisir le bloc à appeler.
Cf : https://blog.octoperf.com/modularisation-in-jmeter/

Je ne fais pas d'include de fichier JMX dans un script maître mais cela peut être une solution.

Pour lancer certains tests et pas d'autres, on peut définir un nombre de vusers = 0 pour ne pas lancer le thread group sur les tests de ce thread.

J'utilise le Http Simple Table Server comme moyen de communiquer et sauvegarder des informations entre les vusers ou les scénarios. ( je créé un  dossier, je sauve le numéro de dossier, puis un autre scénario recherche le dossier par son numéro par exemple).

On a défini également une arborescence type par compagne de test pour stocker, les scripts, les données, les fichiers de configuration externes properties, les résultats, les analyses, les rapports.
+ Règles de nommage des variables et properties, régles de nommages de pages appelées et des scénarios. SC01_P01_ACCUEIL, SC01_P02_LOGIN ...SC01_P15_LOGOUT (SCénario XX, page PYY _ FONCTIONNALITE)

Le chemin des répertoires de données et calculer par rapport au répertoire du script pour travailler sur des chemins relatifs et qui peuvent être différents selon le poste du testeur ou en Intégration Continue.
Au niveau du test plan :
SCRIPT_DIR ${__groovy(import org.apache.jmeter.services.FileServer; FileServer.getFileServer().getBaseDir();)}
puis les autres répertoires comme data = ${ SCRIPT_DIR}/../data

Un fichier de résultat au format CSV
Un fichier pour les erreurs au format XML uniquement les erreurs (case à cocher "Errors" cochée).

J'utilise aussi beaucoup des pom.xml pour lancer le tir et un autre pour faire l'analyse.
Ex :
pom_02_lance_tir.xml pour lancer le tir, utilise le plugin jmeter-maven-plugin
pom_04_analyse_resultat.xml pour créer les graphes et tableaux de résultats csv avec le plugin ( https://github.com/vdaburon/jmeter-graph-tool-maven-plugin) et l'utilitaire (https://github.com/vdaburon/JMReportCsvToHtml)
pom_05_compresse_index.xml pour compresser les résultats et générer une page index.html pour visualiser les images, tableaux html et les liens vers les fichiers de résultats ( utilitaire : https://github.com/vdaburon/CreateHtmlForFilesInDirectory)

Rq :
pom_01_reset (efface les résultats précedents)
pom_03_monitoring (récupère le monitoring (OS, JVM .. ))

Cordialement
Vincent DAB.

Hervé Thouzard

unread,
Sep 28, 2024, 5:36:37 AMSep 28
to jmet...@googlegroups.com
Merci Bruno !

Vous recevez ce message, car vous êtes abonné à un sujet dans le groupe Google Groupes "JMeter en français".
Pour vous désabonner de ce sujet, visitez le site https://groups.google.com/d/topic/jmeter-fr/gO-8SfOleJM/unsubscribe.
Pour vous désabonner de ce groupe et de tous ses sujets, envoyez un e-mail à l'adresse jmeter-fr+...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/jmeter-fr/62d1572a-569b-3adb-63d9-b26aeb035933%40gmail.com.

Hervé Thouzard

unread,
Sep 28, 2024, 5:40:20 AMSep 28
to jmet...@googlegroups.com
Bonjour,

Le awesome-jmeter sur Github est une vraie perle !
J'aurai dû y penser plus tôt.
Et les articles d'octoperf sont vraiment bien faits en plus d'être instructifs.
J'ai passé une bonne partie de ma soirée d'hier à lire tout ce que j'ai pu.

un grand merci.
Hervé

--
Vous recevez ce message, car vous êtes abonné à un sujet dans le groupe Google Groupes "JMeter en français".
Pour vous désabonner de ce sujet, visitez le site https://groups.google.com/d/topic/jmeter-fr/gO-8SfOleJM/unsubscribe.
Pour vous désabonner de ce groupe et de tous ses sujets, envoyez un e-mail à l'adresse jmeter-fr+...@googlegroups.com.

Hervé Thouzard

unread,
Nov 7, 2024, 7:48:19 AMNov 7
to jmet...@googlegroups.com
Bonjour,

J'ai progressé sur ma demande et mon organisation mais je rencontre un problème.
Pour rappel, je dois mettre en place une organisation qui permet de tester les APIs de différents produits.

Suite à la lecture de ce mail, j'ai organisé les choses comme cela (il y a plusieurs schémas à suivre)

1) Au lieu d'avoir 1 seul gros fichier .jmx qui teste toutes les routes de l'API, j'ai un fichier Jmeter par controller de l'API. Ce qui me permet, normalement, de réduire un peu les problèmes de versionnement (Git) des fichiers jmx.
2) Dans des fichiers .properties, j'ai mis les URLs des différents serveurs, le serveur local de TA, de TI et de préprod. J'ai aussi des fichiers .properties pour des infos propres à chaque dev.
3) Ces fichiers sont spécifiés sur la ligne de commande et importés dans un premier fichier "variables.jmx" (simple Test Fragments) qui les récupère et en crée d'autres à partir de Groovy
4) L'API nécessite d'utiliser une clé d'API qui permet de récupérer un JWT, donc j'ai un script Token.jmx qui comprend un "Include Controller" vers Variables.jmx et qui réalise toutes les tests nécessaires pour vérifier le bon fonctionnement de ce premier controller de l'API.
5) L'idée, après, est d'avoir autant de controller d'API (et donc de fichier jmx) que j'en ai effectivement dans mon API, mais comme chaque route a besoin du token récupéré à l'étape 4, je l'inclue.
Ce qui donne le schéma suivant :

image.png

L'idée est de permettre à chaque développeur de dupliquer un des fichiers de controller.jmx pour traiter un nouveau controller de l'API (une nouvelle route).
Cela permet aussi à plusieurs développeurs de travailler simultanément sur des controller différents de l'API.
Tout marche très bien jusqu'à l'étape 4, lorsque je charge le fichier token.jmx, toutes les variables sont bien construites et mes différentes requêtes POST vers /api/v1/token se font bien.
Par contre quand je suis dans un fichier de controller, le dernier niveau du graphique, j'ai systématiquement l'erreur suivante :

INFO o.a.j.c.IncludeController: loadIncludedElements -- try to load included module: Token.jmx
INFO o.a.j.s.SaveService: Loading file: Token.jmx
DEBUG o.j.r.p.TestPlanAnalyzer: Analyze test plan: Token.jmx
WARN o.a.j.c.IncludeController: No Test Fragment was found in included Test Plan, returning empty HashTree

Voilà des copies d'écrans des différents fichiers :

Variables.jmx :

image.png

Token.jmx

image.png

Un exemple de controller :

image.png


image.png

Des idées sur la source de l'erreur ?
Dans Token.jmx, tout est bien encapsulé dans un "Test fragment".

merci d'avance.

Hervé






Le ven. 27 sept. 2024 à 14:23, Vincent Daburon <vdab...@gmail.com> a écrit :
--

Vincent Daburon

unread,
Nov 8, 2024, 9:00:47 AMNov 8
to JMeter en français
De façon globale dans JMeter.
1) Au niveau du Test Plan (le plus haut) tu as des variables pour calculer le chemin des répertoires notamment data mais aussi le chemin pour stocker des résultats.
Dans le User Defined Variables :
SCRIPT_DIR ${__groovy(import org.apache.jmeter.services.FileServer; FileServer.getFileServer().getBaseDir();)}

DATA_DIR
${__P(relatif_data_dir,/../data/)}

RESULTAT_DIR
${__P(resultat_dir,${__groovy(import org.apache.jmeter.services.FileServer; FileServer.getFileServer().getBaseDir();)}/../resultat/${__time(yyyyMMdd_HHmm,)}/)}

RESULT_FILE_CSV
${__P(result_file_csv,rapport_summary.csv)} 
=> le fichier est
${RESULTAT_DIR}${RESULT_FILE_CSV} => <REPERTOIRE DU SCRIPT>../resultat/20241108_1420/apport_summary.csv
RESULT_FILE_ERROR_XML ${__P(result_file_error_xml,error.xml)}

2) Fils du Test Plan tu peux déclarer des variables dans un User Defined Variables
Ex :
K_TEMPS_COURT ${__P(temps_court,3000)} 3s
K_TEMPS_MOYEN
${__P(temps_moyen,5000)} 5s

K_TEMPS_LONG
${__P(temps_long,30000)} 30s

Pour initialiser des valeurs dynamiquement, on utilise un Thread Group spécial de type : "setUp Thread Group".
Tu peux déclarer des properties globales avec props.put("MY_PROP","value");

Pour le jeton, tu peux utiliser soit :
- un "setUp Thread Group" qui crée et envoi un jeton en utilisant un "jp@gc - Inter-Thread Communication PreProcessor", soit une properties (variable globale). https://jmeter-plugins.org/wiki/InterThreadCommunication/
- dans un Thread Group Standard tu peux aussi utiliser un "Once Only Controller" pour créer ton jeton ou utiliser un "jp@gc - Inter-Thread Communication PostProcessor" pour lire le jeton créer and le "setUp Thread Group"
Tu peux mutualiser le code ou les appels de création du jeton en mettant les appels dans un "Test Fragment" et appeler le code avec un "module Controller" https://jmeter.apache.org/usermanual/component_reference.html#Module_Controller

Un composant assez puissant est le "jp@gc - Parameterized Controller" cf https://jmeter-plugins.org/wiki/ParameterizedController/

Pour tes controllers pourquoi pas un "Include Controller" bien que je n'en utilise jamais.

Cordialement.

Vincent Daburon

unread,
Nov 8, 2024, 9:04:51 AMNov 8
to JMeter en français
Pour les cadences, j'utilise très souvent la notion de Pacing et maintenant les sampler "Pacing"
Dans le gestionnaire de plugins :
vdn@github - pacing-jmeter-plugin

Vendor: Vincent DABURON

Add Pacing to JMeter, compute a pause for the pacing duration since thread start iteration or since start time in a variable

Documentation: https://github.com/vdaburon/pacing-jmeter-plugin


On Thursday, November 7, 2024 at 1:48:19 PM UTC+1 herve.t...@gmail.com wrote:

Hervé Thouzard

unread,
Nov 8, 2024, 9:07:50 AMNov 8
to jmet...@googlegroups.com
Un grand merci !
Tout comme la première réponse, c'est très intéressant.

Encore merci.

Reply all
Reply to author
Forward
0 new messages