JMeter Éléments et composants : Groupe de fils, Échantillonneurs

⚡ Résumé intelligent

JMeter Les éléments sont les briques de base de chaque plan de test : les groupes de threads créent des utilisateurs virtuels, les échantillonneurs envoient les requêtes, les écouteurs affichent les résultats et les éléments de configuration fournissent les valeurs par défaut et les données nécessaires à ces requêtes.

  • (I.e. Groupe de discussion : Chaque thread représente un utilisateur virtuel pilotant l'application testée.
  • ☑️ Échantillonneurs : Déterminez le protocole de la requête : FTP, HTTP, JDBC, SMTP, etc.
  • Les auditeurs: Afficher les résultats sous forme de graphique, d'arbre, de tableau ou de fichier journal.
  • 🧪 Éléments de configuration : Définissez les valeurs par défaut et les variables que les échantillonneurs réutilisent tout au long d'un test.
  • Exécutions basées sur les données : Le fichier CSV Data Set Config attribue des identifiants différents à chaque utilisateur simulé.
  • | Équivalents modernes : L'échantillonneur BSF a été abandonné ; les versions actuelles prennent en charge les scripts jusqu'à JSR223 et Groovy.

JMeter Éléments : Groupe de threads, Échantillonneurs, Écouteurs et Éléments de configuration

Qu'est-ce que l'élément dans JMeter?

Les différents composants de JMeter sont appelés Éléments. Chaque élément est conçu dans un but spécifique.

La figure ci-dessous donne quelques éléments communs dans JMeter et montre comment ils se placent sous un groupe de fils de discussion.

JMeter Diagramme hiérarchique des éléments avec le groupe Thread au-dessus des échantillonneurs, des contrôleurs logiques, des écouteurs, des éléments de configuration, des assertions, des temporisateurs et des processeurs.

Étudier tous les éléments d'un coup, c'est s'exposer à la confusion et à l'ennui. Nous allons donc aborder ici les éléments essentiels à connaître avant de commencer. vers les tests in JMeter.

Les autres composants seront abordés au fur et à mesure de leur utilisation dans les tutoriels suivants. Les éléments traités dans ce tutoriel sont listés ci-dessous.

Groupe de discussion

Un groupe de threads est un ensemble de threads. Chaque thread représente un utilisateur de l'application testée. Concrètement, chaque thread simule une requête utilisateur réelle adressée au serveur.

Les commandes d'un groupe de threads vous permettent de définir le nombre de threads pour chaque groupe.

Par exemple, si vous définissez le nombre de threads à 100, JMeter créera et simulera 100 requêtes utilisateur vers le serveur testé, comme l'illustre le diagramme ci-dessous.

Diagramme d'un JMeter Groupe de threads simulant les utilisateurs 1 à 100, chacun envoyant une requête à l'application testée

Le panneau Groupe de threads comporte également une période de montée en puissance, qui répartit le démarrage de ces threads dans le temps au lieu de lancer tous les utilisateurs en même temps.

Échantillonneurs

Comme nous le savons déjà, JMeter prend en charge les tests HTTP, FTP, JDBC et de nombreux autres protocoles.

Nous savons également que les groupes de threads simulent les requêtes des utilisateurs au serveur.

Mais comment un groupe de threads sait-il quel type de requête (HTTP, FTP, etc.) il doit effectuer ?

La réponse est Samplers.

La requête de l'utilisateur peut être une requête FTP, HTTP, JDBC, etc. La figure ci-dessous présente les exemples abordés dans ce tutoriel.

Liste des diagrammes arborescents JMeter Échantillonneurs : requête FTP, requête HTTP, requête JDBC, échantillonneur BSF, échantillonneur de journal d’accès et échantillonneur SMTP

Demande FTP

Imaginons que vous souhaitiez tester les performances d'un serveur FTP. Vous pouvez utiliser un échantillonneur de requêtes FTP dans JMeter pour accomplir cette tâche. Ce contrôleur vous permet d'envoyer une requête FTP de « téléchargement de fichier » ou de « téléchargement de fichier » à un serveur FTP.

Diagramme montrant JMeter envoi d'une requête FTP à un serveur FTP pour télécharger ou téléverser un fichier

Par exemple, si vous souhaitez télécharger un fichier « Test.txt » depuis un serveur FTP en cours de test, vous devez configurer certains paramètres dans JMeter comme dans la figure ci-dessous.

Exemple de panneau de requête FTP avec ftp.example.com comme serveur, port 21, Test.txt comme fichier distant et connexion anonyme

Le panneau configure le serveur pour ftp.example.com, le port 21, le fichier distant Test.txt et l'option get(RETR), donc JMeter envoie une commande FTP à ce serveur et télécharge le fichier.

Requête HTTP

Cet échantillonneur vous permet d'envoyer une requête HTTP/HTTPS à un serveur Web.

Prenons l'exemple ci-dessous. JMeter envoie une requête HTTP à Google site web et en récupère des fichiers HTML ou des images.

Diagramme de JMeter envoi d'une requête HTTP à Google Sites et réception de code HTML et d'images en retour

Dans le tutoriel JMeter Test de performanceNous allons vous expliquer plus en détail cette requête HTTP. Il s'agit de l'échantillonneur le plus utilisé. tests d'applications Web Le travail dépend de.

Requête JDBC

Cet échantillonneur vous permet d'exécuter une base de données Test de performance. Il envoie une requête JDBC (une requête SQL) à une base de données.

Diagramme de JMeter envoyer une requête SQL à un serveur de base de données et recevoir le résultat

Par exemple, un serveur de base de données possède un champ `test_result` stocké dans une table nommée `test_tbl`. Vous souhaitez interroger ces données sur le serveur de base de données ; vous pouvez donc configurer… JMeter envoyer un SQL interroger ce serveur pour récupérer les données.

Panneau de requête JDBC avec le type de requête défini sur « Instruction SELECT » et la requête « select test_result from test_tbl where id = 1 ».

Le type de requête est ici une instruction SELECT et la requête se lit comme suit : select test_result from test_tbl where id = 1. Un élément de configuration de connexion JDBC doit fournir le pool vers lequel pointe le champ Nom de la variable.

Échantillonneur BSF

Cet échantillonneur vous permet d'écrire un échantillonneur en utilisant un BSF langage de script.

Voici un exemple d'échantillonneur BSF dans JMeter, avec des champs pour le langage de script, les paramètres transmis au script et soit un script intégré, soit un fichier de script externe.

Panneau BSF Sampler avec des champs pour le langage de script, les paramètres, un fichier de script externe et le corps du script intégré

Note de dépréciation : La famille d'éléments BSF a été dépréciée au profit des éléments JSR223 et n'apparaît plus dans le JMeter référence du composantSur les versions actuelles, utilisez Échantillonneur JSR223 au Groovy, qui compile le script et offre de bien meilleures performances en charge. Le panneau ci-dessus est conservé car il figure encore dans les anciens plans de test.

Accéder à l'échantillonneur de journaux

Cet outil vous permet de consulter les journaux d'accès et de générer des requêtes HTTP. Les entrées du journal peuvent contenir des images, du HTML, du CSS, etc.

Panneau d'échantillonnage du journal d'accès affichant les champs serveur et port par défaut, la classe du plugin TCLogParser et l'emplacement du fichier journal

Le champ Analyseur syntaxique a pour valeur par défaut : org.apache.jmeter.protocol.http.util.accesslog.TCLogParser, et le champ Emplacement du fichier journal JMeter au niveau du journal que vous souhaitez relire.

Échantillonneur SMTP

Pour tester un serveur de messagerie, vous pouvez utiliser l'échantillonneur SMTP. Cet échantillonneur permet d'envoyer des messages électroniques via le protocole SMTP.

Panneau d'échantillonnage SMTP avec paramètres du serveur, adresses e-mail, options d'authentification et de sécurité, et paramètres de messagerie

Le panneau regroupe les paramètres du serveur, les adresses e-mail, l'authentification et les paramètres de messagerie, et il affiche les ports par défaut à côté du champ Port : SMTP 25, SSL 465 et StartTLS 587.

Les auditeurs

Les écouteurs affichent les résultats de l'exécution du test. Ils peuvent présenter ces résultats sous différents formats, tels qu'un arbre, un tableau, un graphique ou un fichier journal.

Diagramme illustrant un écouteur distribuant les résultats sous forme de graphiques, d'arbres, de tableaux et de rapports.

Le Résultats du graphique Le programme d'écoute affiche les temps de réponse du serveur sur un graphique, avec le nombre d'échantillons, la moyenne, l'écart, le débit et la médiane imprimés en dessous.

Graphique des résultats : affichage des temps de réponse avec les données, la moyenne, la médiane, l’écart et les séries de débit

Afficher l'arbre des résultats affiche le résultat de chaque requête utilisateur au format HTML de base, avec un onglet de résultat Sampler indiquant le temps de chargement, la latence, la taille et le code de réponse.

Afficher l'arborescence des résultats avec une liste de requêtes à gauche et l'onglet de résultat de l'échantillonneur affichant le code de réponse 200.

Afficher les résultats dans le tableau affiche un résumé du résultat du test sous forme de tableau, une ligne par échantillon.

Afficher les résultats dans un tableau avec des colonnes pour le numéro d'échantillon, l'heure de début, le nom du thread, l'étiquette et l'heure de l'échantillon

Un fichier journal enregistre le même résumé sous forme de texte, c'est ce que vous conservez lorsqu'un test est exécuté sans interface graphique.

Ligne récapitulative du journal agrégé listant les étiquettes des échantillonneurs avec le nombre d'échantillons, les moyennes et un TOTAL

Meilleure pratique : Les écouteurs d'interface graphique consomment de la mémoire et faussent les résultats ; il est donc conseillé d'exécuter les tests de charge réels en mode non graphique et d'ouvrir ensuite le fichier de résultats enregistré.

Éléments de configuration

Les éléments de configuration définissent les valeurs par défaut et les variables qui seront utilisées ultérieurement par les échantillonneurs.

La figure ci-dessous montre quelques éléments de configuration couramment utilisés dans JMeter.

Diagramme arborescent de JMeter Éléments de configuration : configuration de l’ensemble de données CSV, gestionnaire de cookies HTTP, élément de configuration de connexion, paramètres par défaut des requêtes HTTP et paramètres par défaut des requêtes FTP

Configuration de l'ensemble de données CSV

Supposons que vous souhaitiez tester un site web auprès de 100 utilisateurs se connectant avec des identifiants différents. Inutile d'enregistrer le script 100 fois : vous pouvez le paramétrer pour qu'il saisisse différents identifiants de connexion. Ces informations (nom d'utilisateur et mot de passe, par exemple) peuvent être stockées dans un fichier texte. JMeter Ce fichier texte contient un élément permettant de lire différents paramètres. Il s'agit de « Configuration du jeu de données CSV », qui sert à lire les lignes d'un fichier et à les répartir dans des variables.

JMeter Arborescence du plan de test avec la configuration de l'ensemble de données CSV sélectionnée sous un contrôleur de connexion, à côté des valeurs par défaut des requêtes HTTP.

Voici un exemple de données CSV. Il s'agit d'un fichier texte contenant les noms d'utilisateur et les mots de passe utilisés pour se connecter à votre site web cible.

Fichier texte csv_data.txt contenant quatre lignes séparées par des virgules, chacune contenant un nom d'utilisateur, un mot de passe et la longueur du cookie.

Gestionnaire de cookies HTTP

Comprenons cela avec un exemple.

Vous avez utilisé votre navigateur (Firefox, Chrome et ainsi de suite) pour naviguer www.google.com.

Vous vous connectez avec votre nom d'utilisateur et votre mot de passe.

Votre nom d'utilisateur et votre mot de passe seront stockés sur votre ordinateur sous forme de cookies.

La prochaine fois, lors de votre visite www.google.comVous n’avez pas besoin de vous reconnecter, car votre navigateur utilisera vos cookies comme données d’utilisateur pour vous connecter.

Le gestionnaire de cookies HTTP possède la même fonctionnalité qu'un navigateur web. Si une requête HTTP est envoyée et que la réponse contient un cookie, le gestionnaire de cookies enregistre automatiquement ce cookie et l'utilise pour toutes les requêtes ultérieures adressées à ce site web.

Valeurs par défaut des requêtes HTTP

Cet élément vous permet de définir les valeurs par défaut utilisées par vos contrôleurs de requête HTTP.

Par exemple,

Vous envoyez 100 requêtes HTTP au serveur google.com.

Vous devrez saisir manuellement le nom du serveur google.com pour les 100 requêtes.

Vous pouvez également ajouter un seul élément HTTP Request Defaults avec le champ « Nom du serveur ou adresse IP » défini sur google.com, comme indiqué ci-dessous.

Panneau des paramètres par défaut des requêtes HTTP avec google.com comme nom de serveur, port 80 et délais d'attente de connexion et de réponse

Inutile de le saisir 100 fois. Cet élément sera expliqué en détail dans le tutoriel. JMeter Test de performance.

Élément de configuration de connexion

L'élément de configuration de connexion vous permet d'ajouter ou de remplacer les paramètres de nom d'utilisateur et de mot de passe dans les échantillonneurs.

Par exemple, vous souhaitez simuler la connexion d'un utilisateur au site web. www.facebook.com avec un nom d'utilisateur et un mot de passe. Vous pouvez utiliser l'élément de configuration de connexion pour ajouter ces paramètres de nom d'utilisateur et de mot de passe à une requête utilisateur.

Panneau de configuration de connexion avec guru99 saisi comme nom d'utilisateur et un champ de mot de passe masqué

L'élément de configuration de connexion par rapport à la configuration de l'ensemble de données CSV

Élément de configuration de connexion Configuration de l'ensemble de données CSV
Utilisé pour simuler la connexion d'un utilisateur Utilisé pour simuler plusieurs connexions utilisateur
Convient uniquement aux paramètres de connexion (nom d'utilisateur et mot de passe). Convient à un grand nombre de paramètres

Ensemble, ces deux éléments couvrent presque tous les scénarios de vérification d'identité que vous pourriez rencontrer. outils de test de performances .

FAQ

Cela dit JMeter Combien de temps faut-il attendre avant que tous les threads soient opérationnels ? Dix threads, avec un temps de montée en puissance de 100 secondes, démarrent à dix secondes d'intervalle. Un temps de montée en puissance trop court surcharge le serveur et provoque des erreurs qu'aucun utilisateur réel ne causerait.

Des temporisateurs insèrent une pause entre les requêtes afin que la charge simulée ressemble à une navigation réelle et non à un afflux massif. Des assertions vérifient chaque réponse et signalent un échec si le code d'état, le texte ou la durée ne correspondent pas aux valeurs spécifiées.

Ils regroupent et ramifient les requêtes qui en dépendent. Un contrôleur de boucle répète ses enfants, un contrôleur « si » les exécute de manière conditionnelle, et un contrôleur de transaction présente l'ensemble du groupe comme une seule étape chronométrée dans les résultats.

Non. Les écouteurs comme View Results Tree mettent en mémoire tampon chaque échantillon et déforment les valeurs qu'ils affichent. Exécutez le test en mode non graphique, enregistrez les résultats dans un fichier, puis chargez ce fichier dans un écouteur une fois l'exécution terminée.

Les éléments de configuration et les préprocesseurs sont appliqués en premier, puis l'échantillonneur s'exécute, suivi des postprocesseurs, des assertions et des écouteurs. La portée est également importante : un élément placé au niveau du plan s'applique à toutes les requêtes qui lui sont subordonnées.

Cet outil est utile pour repérer les tendances. L'analyse d'un fichier de résultats par un assistant permet de détecter beaucoup plus rapidement les étiquettes les plus lentes, les regroupements d'erreurs et les tendances des temps de réponse qu'en lisant les lignes. Il est impératif de toujours confirmer les résultats à partir des données brutes avant d'agir.

Oui. Il y a des brouillons. Groovy pour extracGestion des valeurs, construction des charges utiles et définition des variables dans un élément JSR223. Vérifiez chaque suggestion, car elles font souvent appel à l'API BeanShell obsolète ou à des variables qui JMeter ne révèle pas.

Un groupe de threads et un échantillonneur. Le reste est optionnel. En pratique, un écouteur est ajouté pour visualiser les résultats, et des valeurs par défaut ou un fichier de données sont ajoutés lorsque les mêmes valeurs se répètent d'une requête à l'autre.

Résumez cet article avec :