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 :
JMeter va être utilisé par plusieurs équipes qui travaillent sur des produits et donc des projets différents.
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).
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.
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 :
Auriez-vous des références pour se former ? Vidéo, livres, blog, etc ?
Comment faites-vous pour versionner ? Le fichier jmx fait partie du dépôt de code, mais :
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”.
En cas de conflit, comment, autrement que visuellement, comparer les différences entre 2 versions ?
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.
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 ?
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 ?
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…
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 ?
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” ?
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.
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
Documentation officielle de JMeter: C'est la base incontournable. Elle est très complète et couvre tous les aspects de JMeter : https://jmeter.apache.org/usermanual/get-started.html
Tutoriels vidéo: Il existe de nombreux tutoriels sur YouTube, notamment ceux de "BlazeMeter" et "JMeter Tutorials".
Livres: Le notre :
https://leanpub.com/maitriser-jmeter-du-test-de-charge-a-devops (en français mais existe aussi en anglais)
Blogs: "OctoPerf", "BlazeMeter" et "RedLine13" publient régulièrement des articles de qualité sur JMeter.
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.
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.
--
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/6689cb32-51b4-47b8-9acf-31e59791275dn%40googlegroups.com.
--
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
Pour afficher cette discussion, accédez à https://groups.google.com/d/msgid/jmeter-fr/2744c052-2237-44e4-8b83-46d84eb74f9an%40googlegroups.com.