Pour ceux qui ne connaissent pas ma histoire, je suis originaire de LoadRunner. C’est là que s’est déroulée mon carrière d’ingénieur en charge des tests de charge et y est développée principalement avec ce logiciel.

Quand j’ai commencé à travailler avec JMeter, j’ai tombé amoureuse de ses fonctionnalités. Mais essayer d’élaborer des scénarios plus complexes dans le même style que LoadRunner aurait été une tâche difficile pour moi. De plus, LoadRunner gère la création du scénario comme si c’était un outil totalement différent de celui utilisé pour la création de scripts.

Désolé, JMeter ne sépare pas cela car il gère tout sur une même interface : de la création des scénarios (ou plusieurs scénarios), du réglage et de l’exécution de ces derniers.

Cette différence m’a causé des problèmes lorsque j’ai dû effectuer des tests avec plus de cinq cas simulés en même temps. Cela semblait déjà chaotique avec 5 scripts, et gérer jusqu’à 10 ou même 15 serait une immense tâche utilisant le même outil. Pas de maintenance ne devient complexe et difficile à distribuer avec un équipe de scripteurs.

Comment Faire ? #

Mon premier impulso était d’utiliser-le tel quel. Sans faire de choses hors du lot qui ne viennent pas avec ce qu’il fournit déjà. Et comme mentionné plus haut, l’exécution s’est rapidement transformée en une horreur de création, de maintenance et de travail avec.

Après avoir tenté de résoudre ce problème, j’ai abandonné et décidé d’essayer quelque chose. Guidée par ce que je savais du monde des LoadRunner, j’ai essayé de reproduire un peu la façon de créer les scénarios en simplement tirant des scripts et en modifiant chacun séparément.

Après quelques ajustements, j’ai réussi à atteindre cet objectif en faisant cela de cette manière. Ainsi maintenant je partage avec vous comment procéder dans des étapes simples avec des explications qui peuvent rendre la vie d’une équipe de tests de charge plus facile lorsque différentes personnes travaillent sur différents scénarios automatisés pour le même scénario et ne disposent pas d’un environnement cloud.

Étape 1 #

La première chose à faire est d’avoir un fichier JMX pour chaque processus de notre essai de charge qui sera exécuté. Ne copiez ni ne piquerez pas d’autres scripts d’automatisation et n’ajoutez pas plusieurs processus dans le même fichier. Il y a une seule casse de test dans chaque.

Mais contrairement aux étapes traditionnelles, ici nous mettrons toutes les étapes de notre automatisation sous un FRAGMENT DE TEST. Aucune contrôleur de thread ou rien du tout. Allons voir si on peut nettoyer les étapes et se concentrer sur ce que nous faisons.

Seuls ajoutez les composants HTTP liés à chaque un. Les CONFIGURATION DES COMMANDES HTTP et GESTION DES COOKIES HTTP doivent être ajoutés et configurés si nécessaire.

Étape 2 #

Un autre pas crucial pour que cela fonctionne est de déclarer “temps d’idéation” globalement afin qu’il puisse être appliqué de manière égale dans les étapes pertinentes dans chaque script. Mais avant tout, nous devons créer un PARAMÈTRE UTILISATEUR avec lequel nous travaillerons.

Nous l’appellerons la variable de temps de réflexion ou la variable d’attente de pensée. Nous pouvons attribuer un nombre fixe (exprimé en millisecondes) ou une approximation autour de ce nombre à cette variable. Il est recommandé d’utiliser le nombre aléatoire pour éviter les retards identiques et risquer de perdre la réalité dans le test.

Étape 3 #

Maintenant, pour chaque étape où nous devons ajouter le temps de réflexion (pas toutes les étapes doivent l’accompagner), nous ajoutons un TIMER CONSTANT à la fin mais dans chaque REQUEST HTTP.

Une fois que vous ajoutez le CONSTANT TIMER, simplement assignez le nom de la PARAMÈTRE USER créé dans le pas 2. Cela signifie d’ajouter “${ThinkTime}” au Delay des Threads - ou le nom que vous avez attribué à la variable.

À la fin, nous avons répété cela dans chaque Demande HTTP qui devrait inclure une durée de réflexion. De cette manière, nous avons simplement mis à jour le PARAMÈTRE UTILISATEUR et tout ce qui restait sera également mis à jour.

Après que ces étapes soient complétées pour chaque étape dans nos processus de business, nous pouvons commencer à construire la scénario. Nous pouvons fermer les scripts.

Étape 4 #

Pour créer le scénario, nous commencerons par un projet JMeter vide. Nous ajoutons d’abord ce dont nous avons besoin pour les Listeners et les reporters. Je recommande de posséder au moins la Vue des résultats ainsi que la Listener Backend (ou JSR233) pour envoyer les résultats vers un plateforme comme InfluxDB.

Maintenant, pour chaque scénario que nous voulons avoir, nous ajoutons un GROUP DE TÉLÉCHARGEMENT et par raison de bon sens, nous nommerons chacun d’eux comme nous l’appellerions notre processus de business.

Chaque groupe de thread ( THREAD GROUP) sera assigné les paramètres nécessaires pour chaque processus d’affaire, tels que la pêche ou le temps de ramp-up et le nombre de threads pour chacun.

Étape 5 #

Chacun d’entre eux ajoutera trois éléments :

• PARAMÈTRE UTILISATEUR
• INCLUDE CONTROLLER
• ACTION FLOW CONTROL Chacune de ces actions remplira un rôle différent.

L’élément PARAMÈTRE USER sera utilisé pour définir certaines RTS (Paramètres de Runtime) en style LoadRunner. À l’intérieur, nous déclarerons au moins le temps d’attente entre chaque itération. Comme il est recommandé de ne pas avoir des valeurs fixes, nous assignerons les maximums et minimums pour notre aléatoire.

Ne pas aller trop loin et respecter une variation de 5 ou 10%. Cela signifie que si nous avons besoin d’un rythme de 5 secondes, nous pouvons fixer des maximums et minimums de 4.5 à 5.5 secondes. Remarquez toujours d’ajouter tout en millisecondes.

Comme vous pouvez le voir dans l’image, j’ai changé le nom de la paramètre en RTS. C’est simplement fait pour faciliter l’identification lorsqu’on travaille avec eux. Even if someone external needs to modifier la scénario, le nom rend plus indicative.

Étape 6 #

Maintenant dans le Contrôleur Include, simplez-le à la localisation de notre script.

Suggérez d’ajouter des emplacements partagés ou publics. Even si les scripts sont sur le machine locale, c’est mieux de faire tout cela dans un dossier partagé pour éviter les problèmes de reachabilité ou limiter notre scénario à une exécution uniquement sur une machine. Nous pouvons donc déplacer le fichier du scénario et l’exécuter depuis où nous le trouvons (toujours que ce soit accessible via un dossier partagé).

Lorsque vous exécutez cette scénario, JMeter chargera les étapes et les exécutera de manière plus propre et simplifiée pour organiser.

Étape 7 #

Maintenant que nous procédons au Action de contrôle flux que nous avons ajoutée à la fin de chaque une. C’est celui qui exécute le temps d’attente dans les itérations. C’est pourquoi je l’ai mis en dernier, afin que le temps d’attente se produise après que la script ait terminé ses étapes dans une itération.

I recommander l’appeler “Pace” pour que cela soit clair de ce qu’il fait. Nous sélectionnerons le bouton radio “Pause,” appelé “Pause,” pour indiquer que chaque élément doit s’arrêter là. Ensuite, dans la section dure (Duree), nous ajoutons les codes suivants qui seront automatiquement aléatoires :

                  ${__Random(${RndPaceMin},${RndPaceMin})}

Cela extraîr les valeurs que nous avons définies plus tôt dans le RTS. C’est tout ce dont vous avez besoin pour configurer notre Pace. Vous n’avez pas besoin de sélectionner autre chose dans cet élément.

Étape 8 #

Une fois que la première filière est terminée, vous pouvez choisir de duplicer-la pour créer chaque filière et configurer uniquement ce qui est indiqué dans chaque élément. Soyez prudent, cela peut conduire à oublier d’ajouter les configurations correctes.

Si l’on est très dévoué, les pas peuvent être répétés pour chaque script. Il est important de s’assurer que chaque TÉLÉCHARGEMENT a les éléments décrits.

Termédit #

Avec ces étapes, ils peuvent exécuter des scénarios complexes et les tester heureux et les ingénieurs heureux ! Les amis de la scripture heureux ! Bises :)