3. Éléments d'un plan de test

3.0 Plan de test ¶

L'objet Plan de test a une case à cocher appelée " Test fonctionnel ". Si cette option est sélectionnée, JMeter enregistrera les données renvoyées par le serveur pour chaque échantillon. Si vous avez sélectionné un fichier dans vos écouteurs de test, ces données seront écrites dans le fichier. Cela peut être utile si vous effectuez une petite exécution pour vous assurer que JMeter est correctement configuré et que votre serveur renvoie les résultats attendus. La conséquence est que le fichier grossira rapidement et que les performances de JMeter en souffriront. Cette option doit être désactivée si vous effectuez des tests de résistance (elle est désactivée par défaut).

Si vous n'enregistrez pas les données dans un fichier, cette option ne fait aucune différence.

Vous pouvez également utiliser le bouton Configuration sur un écouteur pour décider des champs à enregistrer.

3.1 Groupe de threads ¶

Les éléments du groupe de threads sont les points de départ de tout plan de test. Tous les contrôleurs et échantillonneurs doivent être sous un groupe de threads. D'autres éléments, par exemple les écouteurs, peuvent être placés directement sous le plan de test, auquel cas ils s'appliqueront à tous les groupes de threads. Comme son nom l'indique, l'élément groupe de threads contrôle le nombre de threads que JMeter utilisera pour exécuter votre test. Les commandes d'un groupe de threads vous permettent de :

• Définir le nombre de fils
• Définir la période de montée en puissance
• Définir le nombre de fois pour exécuter le test

Chaque thread exécutera le plan de test dans son intégralité et complètement indépendamment des autres threads de test. Plusieurs threads sont utilisés pour simuler des connexions simultanées à votre application serveur.

La période de montée en puissance indique à JMeter combien de temps il faut pour "monter en puissance" jusqu'au nombre total de threads choisis. Si 10 threads sont utilisés et que la période de montée en puissance est de 100 secondes, JMeter prendra 100 secondes pour que les 10 threads soient opérationnels. Chaque fil commencera 10 (100/10) secondes après le début du fil précédent. S'il y a 30 threads et une période de montée en puissance de 120 secondes, chaque thread successif sera retardé de 4 secondes.

La montée en puissance doit être suffisamment longue pour éviter une charge de travail trop importante au début d'un test, et suffisamment courte pour que les derniers threads commencent à s'exécuter avant la fin des premiers (à moins que l'on ne le veuille).

Commencez avec Ramp-up = nombre de fils et ajustez vers le haut ou vers le bas selon vos besoins.

Par défaut, le groupe de threads est configuré pour boucler une fois sur ses éléments.

Le groupe de threads permet également de spécifier la durée de vie du thread . Cliquez sur la case à cocher en bas du panneau Groupe de threads pour activer/désactiver des champs supplémentaires dans lesquels vous pouvez entrer la durée du test et le délai de démarrage Vous pouvez configurer Durée (secondes) et Délai de démarrage (secondes) pour contrôler la durée de chaque thread groupe et après combien de secondes il démarre. Lorsque le test est lancé, JMeter attend le délai de démarrage (secondes) avant de démarrer les threads du groupe de threads et s'exécute pendant la durée configurée (secondes) .

3.2 Contrôleurs ¶

JMeter a deux types de contrôleurs : les échantillonneurs et les contrôleurs logiques. Ceux-ci pilotent le traitement d'un test.

Les échantillonneurs indiquent à JMeter d'envoyer des requêtes à un serveur. Par exemple, ajoutez un HTTP Request Sampler si vous souhaitez que JMeter envoie une requête HTTP. Vous pouvez également personnaliser une demande en ajoutant un ou plusieurs éléments de configuration à un échantillonneur. Pour plus d'informations, voir Échantillonneurs .

Les contrôleurs logiques vous permettent de personnaliser la logique utilisée par JMeter pour décider quand envoyer des requêtes. Par exemple, vous pouvez ajouter un Interleave Logic Controller pour alterner entre deux HTTP Request Samplers. Pour plus d'informations, consultez Contrôleurs logiques .

3.2.1 Échantillonneurs ¶

Les échantillonneurs indiquent à JMeter d'envoyer des requêtes à un serveur et d'attendre une réponse. Ils sont traités dans l'ordre dans lequel ils apparaissent dans l'arborescence. Les contrôleurs permettent de modifier le nombre de répétitions d'un sampler.

Les échantillonneurs JMeter incluent :

• Requête FTP
• Requête HTTP (peut également être utilisée pour le service Web SOAP ou REST)
• Requête JDBC
• Requête d'objet Java
• Requête JMS
• Demande de test JUnit
• Requête LDAP
• Demande par courrier
• Demande de processus du système d'exploitation
• Requête TCP

Si vous envisagez d'envoyer plusieurs requêtes du même type (par exemple, une requête HTTP) au même serveur, envisagez d'utiliser un élément de configuration par défaut. Chaque contrôleur a un ou plusieurs éléments par défaut (voir ci-dessous).

N'oubliez pas d'ajouter un écouteur à votre plan de test pour afficher et/ou stocker les résultats de vos requêtes sur disque.

Si vous souhaitez que JMeter effectue une validation de base sur la réponse de votre requête, ajoutez une Assertion à l'échantillonneur. Par exemple, lors d'un test de résistance d'une application Web, le serveur peut renvoyer un code "Réponse HTTP" réussi, mais la page peut contenir des erreurs ou des sections manquantes. Vous pouvez ajouter des assertions pour vérifier certaines balises HTML, des chaînes d'erreur courantes, etc. JMeter vous permet de créer ces assertions à l'aide d'expressions régulières.

Échantillonneurs intégrés de JMeter

3.2.2 Contrôleurs logiques ¶

Les contrôleurs logiques vous permettent de personnaliser la logique utilisée par JMeter pour décider quand envoyer des requêtes. Les contrôleurs logiques peuvent modifier l'ordre des requêtes provenant de leurs éléments enfants. Ils peuvent modifier les requêtes eux-mêmes, forcer JMeter à répéter les requêtes, etc.

Pour comprendre l'effet des contrôleurs logiques sur un plan de test, considérez l'arborescence de test suivante :

• Plan de test
• Groupe de fils
• Une seule fois contrôleur
• Demande de connexion (une requête HTTP )
• Charger la page de recherche (échantillonneur HTTP)
• Contrôleur d'entrelacement
• Rechercher "A" (échantillonneur HTTP)
• Rechercher "B" (échantillonneur HTTP)
• Requête HTTP par défaut (élément de configuration)
• Requête HTTP par défaut (élément de configuration)
• Gestionnaire de cookies (élément de configuration)

La première chose à propos de ce test est que la demande de connexion ne sera exécutée que la première fois. Les itérations suivantes l'ignoreront. Cela est dû aux effets du Once Only Controller .

Après la connexion, le Sampler suivant charge la page de recherche (imaginez une application Web où l'utilisateur se connecte, puis se rend sur une page de recherche pour effectuer une recherche). Il s'agit d'une simple demande, non filtrée par un Logic Controller.

Après avoir chargé la page de recherche, nous souhaitons effectuer une recherche. En fait, nous voulons faire deux recherches différentes. Cependant, nous souhaitons recharger la page de recherche elle-même entre chaque recherche. Nous pourrions le faire en ayant 4 éléments de requête HTTP simples (load search, search "A", load search, search "B"). Au lieu de cela, nous utilisons le contrôleur d'entrelacement qui transmet une demande enfant à chaque fois tout au long du test. Il conserve l'ordre (c'est-à-dire qu'il n'en transmet pas un au hasard, mais "se souvient" de sa place) de ses éléments enfants. L'entrelacement de 2 requêtes enfant peut être exagéré, mais il aurait facilement pu y avoir 8 ou 20 requêtes enfant.

Notez les valeurs par défaut de la requête HTTPqui appartient au contrôleur d'entrelacement. Imaginez que "Recherche A" et "Recherche B" partagent les mêmes informations PATH (une spécification de requête HTTP inclut le domaine, le port, la méthode, le protocole, le chemin et les arguments, ainsi que d'autres éléments facultatifs). Cela a du sens - les deux sont des requêtes de recherche, frappant le même moteur de recherche principal (un servlet ou un script cgi, disons). Plutôt que de configurer les deux échantillonneurs HTTP avec les mêmes informations dans leur champ PATH, nous pouvons résumer ces informations dans un seul élément de configuration. Lorsque le contrôleur d'entrelacement "transmet" les requêtes de "Recherche A" ou "Recherche B", il remplit les blancs avec les valeurs de l'élément de configuration de requête HTTP par défaut. Donc, nous laissons le champ PATH vide pour ces requêtes, et placez ces informations dans l'élément de configuration. Dans ce cas, il s'agit au mieux d'un avantage mineur, mais cela démontre la fonctionnalité.

L'élément suivant dans l'arborescence est une autre requête HTTP par défaut, cette fois ajoutée au groupe de threads lui-même. Le groupe de threads a un contrôleur logique intégré et, par conséquent, il utilise cet élément de configuration exactement comme décrit ci-dessus. Il remplit les blancs de toute demande qui passe. Il est extrêmement utile dans les tests Web de laisser le champ DOMAIN vide dans tous vos éléments HTTP Sampler et, à la place, de placer ces informations dans un élément de requête HTTP par défaut, ajouté au groupe de threads. Ce faisant, vous pouvez tester votre application sur un serveur différent en modifiant simplement un champ de votre plan de test. Sinon, vous auriez à éditer chaque Sampler.

Le dernier élément est un gestionnaire de cookies HTTP . Un gestionnaire de cookies doit être ajouté à tous les tests Web - sinon JMeter ignorera les cookies. En l'ajoutant au niveau du groupe de threads, nous nous assurons que toutes les requêtes HTTP partageront les mêmes cookies.

Les contrôleurs logiques peuvent être combinés pour obtenir différents résultats. Voir la liste des contrôleurs logiques intégrés .

3.2.3 Fragments de test ¶

L'élément Test Fragment est un type spécial de contrôleur qui existe dans l'arborescence du plan de test au même niveau que l'élément Thread Group. Il se distingue d'un groupe de threads en ce qu'il n'est exécuté que s'il est référencé par un contrôleur de module ou un Include_Controller .

Cet élément est uniquement destiné à la réutilisation du code dans les plans de test

3.3 Auditeurs ¶

Les écouteurs permettent d'accéder aux informations que JMeter recueille sur les cas de test pendant l'exécution de JMeter. L' écouteur Graph Results trace les temps de réponse sur un graphique. L'écouteur "Afficher l'arborescence des résultats" affiche les détails des requêtes et des réponses de l'échantillonneur et peut afficher des représentations HTML et XML de base de la réponse. D'autres auditeurs fournissent des informations résumées ou agrégées.

De plus, les auditeurs peuvent diriger les données vers un fichier pour une utilisation ultérieure. Chaque écouteur de JMeter fournit un champ pour indiquer le fichier dans lequel stocker les données. Il existe également un bouton de configuration qui peut être utilisé pour choisir les champs à enregistrer et s'il faut utiliser le format CSV ou XML.

Les écouteurs peuvent être ajoutés n'importe où dans le test, y compris directement sous le plan de test. Ils ne collecteront des données qu'à partir d'éléments au niveau ou en dessous de leur niveau.

Plusieurs écouteurs sont fournis avec JMeter.

3.4 Minuteries ¶

Par défaut, un thread JMeter exécute des échantillonneurs en séquence sans pause. Nous vous recommandons de spécifier un délai en ajoutant l'un des minuteurs disponibles à votre groupe de threads. Si vous n'ajoutez pas de délai, JMeter pourrait submerger votre serveur en faisant trop de requêtes en très peu de temps.

Une minuterie obligera JMeter à retarder un certain temps avant chaque échantillonneur qui se trouve dans sa portée .

Si vous choisissez d'ajouter plus d'une minuterie à un groupe de threads, JMeter prend la somme des minuteries et s'arrête pendant ce laps de temps avant d'exécuter les échantillonneurs auxquels les minuteries s'appliquent. Des temporisateurs peuvent être ajoutés en tant qu'enfants d'échantillonneurs ou de contrôleurs afin de limiter les échantillonneurs auxquels ils s'appliquent.

Pour fournir une pause à un seul endroit dans un plan de test, on peut utiliser l' échantillonneur d'action de contrôle de flux .

3.5 Assertions ¶

Les assertions vous permettent d'affirmer des faits sur les réponses reçues du serveur testé. En utilisant une assertion, vous pouvez essentiellement "tester" que votre application renvoie les résultats que vous attendez.

Par exemple, vous pouvez affirmer que la réponse à une requête contiendra un texte particulier. Le texte que vous spécifiez peut être une expression régulière de style Perl et vous pouvez indiquer que la réponse doit contenir le texte ou qu'elle doit correspondre à la réponse entière.

Vous pouvez ajouter une assertion à n'importe quel Sampler. Par exemple, vous pouvez ajouter une assertion à une requête HTTP qui recherche le texte " </HTML> ". JMeter vérifiera alors que le texte est présent dans la réponse HTTP. Si JMeter ne trouve pas le texte, il le marquera comme une requête ayant échoué.

Pour afficher les résultats d'assertion, ajoutez un écouteur d'assertion au groupe de threads. Les échecs d'assertion s'afficheront également dans l'arborescence et les écouteurs de table, et seront pris en compte dans le pourcentage d'erreur, par exemple dans les rapports agrégés et récapitulatifs.

3.6 Éléments de configuration ¶

Un élément de configuration travaille en étroite collaboration avec un Sampler. Bien qu'il n'envoie pas de requêtes (à l'exception de HTTP(S) Test Script Recorder ), il peut ajouter ou modifier des requêtes.

Un élément de configuration est accessible uniquement depuis l'intérieur de la branche d'arborescence où vous placez l'élément. Par exemple, si vous placez un HTTP Cookie Manager dans un Simple Logic Controller, le Cookie Manager ne sera accessible qu'aux HTTP Request Controllers que vous placez dans le Simple Logic Controller (voir figure 1). Le Cookie Manager est accessible aux requêtes HTTP « Page Web 1 » et « Page Web 2 », mais pas « Page Web 3 ».

De plus, un élément de configuration à l'intérieur d'une branche d'arborescence a une priorité plus élevée que le même élément dans une branche "parente". Par exemple, nous avons défini deux éléments HTTP Request Defaults, "Web Defaults 1" et "Web Defaults 2". Puisque nous avons placé "Web Defaults 1" dans un Loop Controller, seule la "Page Web 2" peut y accéder. Les autres requêtes HTTP utiliseront "Web Defaults 2", puisque nous l'avons placé dans le groupe de threads (le "parent" de toutes les autres branches).

3.7 Éléments du pré-processeur ¶

Un pré-processeur exécute une action avant qu'une demande d'échantillonneur ne soit faite. Si un pré-processeur est attaché à un élément de l'échantillonneur, il s'exécutera juste avant l'exécution de cet élément de l'échantillonneur. Un préprocesseur est le plus souvent utilisé pour modifier les paramètres d'une demande d'échantillon juste avant son exécution ou pour mettre à jour des variables qui ne sont pas extraites du texte de la réponse. Voir les règles de portée pour plus de détails sur le moment où les pré-processeurs sont exécutés.

3.8 Éléments du post-processeur ¶

Un post-processeur exécute une action après qu'une demande d'échantillonnage a été faite. Si un post-processeur est attaché à un élément de l'échantillonneur, il s'exécutera juste après l'exécution de cet élément de l'échantillonneur. Un post-processeur est le plus souvent utilisé pour traiter les données de réponse, souvent pour en extraire des valeurs. Voir les règles de portée pour plus de détails sur le moment où les post-processeurs sont exécutés.

3.9 Ordre d'exécution ¶

0. Éléments de configuration
1. Pré-processeurs
2. Minuteries
3. Échantillonneur
4. Post-processeurs (sauf si SampleResult est null )
5. Assertions (sauf si SampleResult est null )
6. Écouteurs (sauf si SampleResult est null )

Par exemple, dans le plan de test suivant :

• Manette
• Post-processeur 1
• Échantillonneur 1
• Échantillonneur 2
• Minuterie 1
• Affirmation 1
• Pré-processeur 1
• Minuterie 2
• Post-processeur 2

Pré-processeur 1
Minuterie 1
Minuterie 2
Échantillonneur 1
Post-processeur 1
Post-processeur 2
Affirmation 1

Pré-processeur 1
Minuterie 1
Minuterie 2
Échantillonneur 2
Post-processeur 1
Post-processeur 2
Affirmation 1

3.10 Règles de portée ¶

L'arbre de test JMeter contient des éléments à la fois hiérarchiques et ordonnés. Certains éléments des arbres de test sont strictement hiérarchiques (Listeners, Config Elements, Post-Processors, Pre-Processors, Assertions, Timers), et certains sont principalement ordonnés (controllers, samplers). Lorsque vous créez votre plan de test, vous créez une liste ordonnée de requêtes d'échantillons (via des échantillonneurs) qui représentent un ensemble d'étapes à exécuter. Ces requêtes sont souvent organisées au sein de contrôleurs également commandés. Soit l'arbre de test suivant :

L'ordre des demandes sera, Un, Deux, Trois, Quatre.

Certains contrôleurs affectent l'ordre de leurs sous-éléments, et vous pouvez en savoir plus sur ces contrôleurs spécifiques dans la référence des composants .

D'autres éléments sont hiérarchiques. Une Assertion, par exemple, est hiérarchique dans l'arbre de test. Si son parent est une demande, alors il est appliqué à cette demande. Si son parent est un Controller, il affecte toutes les requêtes descendantes de ce Controller. Dans l'arbre de test suivant :

L'assertion n°1 s'applique uniquement à la première requête, tandis que l'assertion n°2 s'applique aux requêtes deux et trois.

Un autre exemple, cette fois en utilisant des minuteries :

Dans cet exemple, les requêtes sont nommées pour refléter l'ordre dans lequel elles seront exécutées. Le temporisateur #1 s'appliquera aux requêtes deux, trois et quatre (notez que l'ordre n'est pas pertinent pour les éléments hiérarchiques). L'assertion #1 ne s'appliquera qu'à la troisième requête. La minuterie #2 affectera toutes les demandes.

Espérons que ces exemples expliquent clairement comment les éléments de configuration (hiérarchiques) sont appliqués. Si vous imaginez que chaque requête est transmise dans les branches de l'arborescence, à son parent, puis au parent de son parent, etc., et qu'à chaque fois, elle collecte tous les éléments de configuration de ce parent, alors vous verrez comment cela fonctionne.

3.11 Propriétés et variables ¶

Les propriétés JMeter sont définies dans jmeter.properties (voir Mise en route - Configuration de JMeter pour plus de détails).
Les propriétés sont globales à jmeter et sont principalement utilisées pour définir certaines des utilisations par défaut de JMeter. Par exemple, la propriété remote_hosts définit les serveurs que JMeter tentera d'exécuter à distance. Les propriétés peuvent être référencées dans les plans de test - voir Fonctions - lire une propriété - mais ne peuvent pas être utilisées pour des valeurs spécifiques à un thread.

Les variables JMeter sont locales à chaque thread. Les valeurs peuvent être les mêmes pour chaque thread, ou elles peuvent être différentes.
Si une variable est mise à jour par un thread, seule la copie du thread de la variable est modifiée. Par exemple, le post-processeur de l'extracteur d'expressions régulières définira ses variables en fonction de l'échantillon lu par son thread, et celles-ci pourront être utilisées ultérieurement par le même thread. Pour plus de détails sur la façon de référencer des variables et des fonctions, voir Fonctions et variables

Notez que les valeurs définies par le plan de test et l' élément de configuration Variables définies par l'utilisateur sont mises à la disposition de l'ensemble du plan de test au démarrage. Si la même variable est définie par plusieurs éléments UDV, le dernier prend effet. Une fois qu'un thread a démarré, l'ensemble initial de variables est copié dans chaque thread. D'autres éléments tels que le pré-processeur des paramètres utilisateur ou le post-processeur de l'extracteur d'expressions régulières peuvent être utilisés pour redéfinir les mêmes variables (ou en créer de nouvelles). Ces redéfinitions ne s'appliquent qu'au thread actuel.

La fonction setProperty peut être utilisée pour définir une propriété JMeter. Celles-ci sont globales au plan de test, elles peuvent donc être utilisées pour transmettre des informations entre les threads - si cela est nécessaire.

3.12 Utiliser des variables pour paramétrer les tests ¶

Les variables n'ont pas à varier - elles peuvent être définies une fois, et si elles sont laissées seules, elles ne changeront pas de valeur. Vous pouvez donc les utiliser comme raccourci pour les expressions qui apparaissent fréquemment dans un plan de test. Ou pour les éléments qui sont constants au cours d'une exécution, mais qui peuvent varier d'une exécution à l'autre. Par exemple, le nom d'un hôte ou le nombre de threads dans un groupe de threads.

Lorsque vous décidez comment structurer un plan de test, notez quels éléments sont constants pour l'exécution, mais qui peuvent changer entre les exécutions. Décidez de certains noms de variables pour celles-ci - utilisez peut-être une convention de dénomination telle que les préfixer avec C_ ou K_ ou en utilisant uniquement des majuscules pour les distinguer des variables qui doivent changer pendant le test. Considérez également quels éléments doivent être locaux pour un thread - par exemple des compteurs ou des valeurs extraites avec le post-processeur d'expression régulière. Vous souhaiterez peut-être utiliser une convention de dénomination différente pour ceux-ci.

Par exemple, vous pouvez définir les éléments suivants sur le plan de test :

HÔTE www.exemple.com
FILS 10
BOUCLES 20

HÔTE ${__P(hôte,www.exemple.com)}
FILS ${__P(threads,10)}
BOUCLES ${__P(boucles,20)}

jmeter … -Jhost=www3.example.org -Jloops=13