La latence est définie sur le temps nécessaire pour se connecter.

Cet échantillonneur vous permet d'envoyer une requête HTTP/HTTPS à un serveur Web. Il vous permet également de contrôler si JMeter analyse ou non les fichiers HTML à la recherche d'images et d'autres ressources intégrées et envoie des requêtes HTTP pour les récupérer. Les types de ressources intégrées suivants sont récupérés :

• images
• applets
• feuilles de style (CSS) et ressources référencées à partir de ces fichiers
• scripts externes
• cadres, iframes
• images de fond (corps, table, TD, TR)
• fond sonore

L'analyseur par défaut est org.apache.jmeter.protocol.http.parser.LagartoBasedHtmlParser . Cela peut être changé en utilisant la propriété " htmlparser.className " - voir jmeter.properties pour plus de détails.

Si vous envisagez d'envoyer plusieurs requêtes au même serveur Web, envisagez d'utiliser un élément de configuration HTTP Request Defaults afin de ne pas avoir à saisir les mêmes informations pour chaque requête HTTP.

Ou, au lieu d'ajouter manuellement des requêtes HTTP, vous pouvez utiliser l' enregistreur de script de test HTTP(S) de JMeter pour les créer. Cela peut vous faire gagner du temps si vous avez beaucoup de requêtes HTTP ou des requêtes avec de nombreux paramètres.

Trois éléments de test différents sont utilisés pour définir les échantillonneurs :

Échantillonneur AJP/1.3

utilise le protocole Tomcat mod_jk (permet de tester Tomcat en mode AJP sans avoir besoin d'Apache httpd) L'échantillonneur AJP ne prend pas en charge le téléchargement de plusieurs fichiers ; seul le premier fichier sera utilisé.

Requête HTTP

cela a une liste déroulante d'implémentation, qui sélectionne l'implémentation du protocole HTTP à utiliser :

Java

utilise l'implémentation HTTP fournie par la JVM. Cela présente certaines limitations par rapport aux implémentations HttpClient - voir ci-dessous.

HTTPClient4

utilise Apache HttpComponents HttpClient 4.x.

Valeur vide

ne définit pas l'implémentation sur les échantillonneurs HTTP, s'appuie donc sur les valeurs par défaut de la requête HTTP si elles sont présentes ou sur la propriété jmeter.httpsampler définie dans jmeter.properties

Requête HTTP GraphQL

il s'agit d'une variante GUI de la requête HTTP pour fournir des éléments d'interface utilisateur plus pratiques pour afficher ou modifier GraphQL Query , Variables et Operation Name , tout en les convertissant automatiquement en arguments HTTP sous le capot à l'aide du même échantillonneur. Cela masque ou personnalise les éléments d'interface utilisateur suivants car ils sont moins pratiques ou non pertinents pour GraphQL sur les requêtes HTTP/HTTPS :

• Méthode : Seules les méthodes POST et GET sont disponibles conformément à la spécification GraphQL sur HTTP. La méthode POST est sélectionnée par défaut.
• Paramètres et onglets Post Body : vous pouvez afficher ou modifier le contenu des paramètres via les éléments d'interface utilisateur Requête, Variables et Nom de l'opération à la place.
• Onglet Téléchargement de fichier : non pertinent pour les requêtes GraphQL.
• Ressources intégrées à partir de la section Fichiers HTML dans l'onglet Avancé : non pertinent dans les réponses GraphQL JSON.

L'implémentation Java HTTP présente certaines limitations :

• Il n'y a aucun contrôle sur la façon dont les connexions sont réutilisées. Lorsqu'une connexion est libérée par JMeter, elle peut ou non être réutilisée par le même thread.
• L'API est mieux adaptée à une utilisation à un seul thread - divers paramètres sont définis via les propriétés du système et s'appliquent donc à toutes les connexions.
• Pas de prise en charge de l'authentification Kerberos
• Il ne prend pas en charge les tests de certificats basés sur le client avec Keystore Config.
• Meilleur contrôle du mécanisme Retry
• Il ne prend pas en charge les hôtes virtuels.
• Il ne prend en charge que les méthodes suivantes : GET , POST , HEAD , OPTIONS , PUT , DELETE et TRACE
• Meilleur contrôle sur la mise en cache DNS avec DNS Cache Manager

Si la demande nécessite une autorisation de connexion au serveur ou au proxy (c'est-à-dire lorsqu'un navigateur créerait une boîte de dialogue contextuelle), vous devrez également ajouter un élément de configuration HTTP Authorization Manager . Pour les connexions normales (c'est-à-dire lorsque l'utilisateur entre les informations de connexion dans un formulaire), vous devrez déterminer ce que fait le bouton d'envoi du formulaire et créer une requête HTTP avec la méthode appropriée (généralement POST ) et les paramètres appropriés à partir de la définition du formulaire. . Si la page utilise HTTP, vous pouvez utiliser le proxy JMeter pour capturer la séquence de connexion.

Un contexte SSL distinct est utilisé pour chaque thread. Si vous souhaitez utiliser un seul contexte SSL (pas le comportement standard des navigateurs), définissez la propriété JMeter :

https.sessioncontext.shared=true

httpclient.reset_state_on_thread_group_iteration=true

https.default.protocol=SSLv3

JMeter permet également d'activer des protocoles supplémentaires, en modifiant la propriété https.socket.protocols .

Si la requête utilise des cookies, vous aurez également besoin d'un HTTP Cookie Manager . Vous pouvez ajouter l'un ou l'autre de ces éléments au groupe de threads ou à la requête HTTP. Si vous avez plusieurs requêtes HTTP nécessitant des autorisations ou des cookies, ajoutez les éléments au groupe de threads. De cette façon, tous les contrôleurs de requête HTTP partageront les mêmes éléments du gestionnaire d'autorisations et du gestionnaire de cookies.

Si la requête utilise une technique appelée « réécriture d'URL » pour maintenir les sessions, consultez la section  6.1 Gestion des sessions utilisateur avec la réécriture d'URL pour des étapes de configuration supplémentaires.

Cet échantillonneur vous permet d'envoyer une requête JDBC (une requête SQL) à une base de données.

Avant de l'utiliser, vous devez configurer un élément de configuration de la configuration de la connexion JDBC

Si la liste des noms de variables est fournie, pour chaque ligne renvoyée par une instruction Select, les variables sont définies avec la valeur de la colonne correspondante (si un nom de variable est fourni) et le nombre de lignes est également défini. Par exemple, si l'instruction Select renvoie 2 lignes de 3 colonnes et que la liste de variables est A,,C , alors les variables suivantes seront configurées :

A_#=2 (nombre de lignes)
A_1=colonne 1, ligne 1
A_2=colonne 1, ligne 2
C_#=2 (nombre de lignes)
C_1=colonne 3, ligne 1
C_2=colonne 3, ligne 2

Si l'instruction Select renvoie zéro ligne, les variables A_# et C_# seraient définies sur 0 et aucune autre variable ne serait définie.

Les anciennes variables sont effacées si nécessaire - par exemple, si la première sélection récupère six lignes et qu'une seconde sélection ne renvoie que trois lignes, les variables supplémentaires pour les lignes quatre, cinq et six seront supprimées.

Cet échantillonneur vous permet de contrôler une classe Java qui implémente l' interface org.apache.jmeter.protocol.java.sampler.JavaSamplerClient . En écrivant votre propre implémentation de cette interface, vous pouvez utiliser JMeter pour exploiter plusieurs threads, le contrôle des paramètres d'entrée et la collecte de données.

Le menu déroulant fournit la liste de toutes ces implémentations trouvées par JMeter dans son classpath. Les paramètres peuvent ensuite être spécifiés dans le tableau ci-dessous - tels que définis par votre implémentation. Deux exemples simples ( JavaTest et SleepTest ) sont fournis.

L' échantillonneur d'exemple JavaTest peut être utile pour vérifier les plans de test, car il permet de définir des valeurs dans presque tous les champs. Celles-ci peuvent ensuite être utilisées par Assertions, etc. Les champs permettent d'utiliser des variables, de sorte que les valeurs de celles-ci peuvent être facilement vues.

Si vous envisagez d'envoyer plusieurs requêtes au même serveur LDAP, envisagez d'utiliser un élément de configuration des valeurs par défaut des requêtes LDAP afin de ne pas avoir à saisir les mêmes informations pour chaque requête LDAP.

Si vous envisagez d'envoyer plusieurs requêtes au même serveur LDAP, envisagez d'utiliser un élément de configuration des valeurs par défaut des requêtes étendues LDAP afin de ne pas avoir à saisir les mêmes informations pour chaque requête LDAP.

AccessLogSampler a été conçu pour lire les journaux d'accès et générer des requêtes http. Pour ceux qui ne connaissent pas le journal d'accès, il s'agit du journal que le serveur Web conserve pour chaque demande acceptée. Cela signifie que chaque image, fichier CSS, fichier JavaScript, fichier html, …

Tomcat utilise le format commun pour les journaux d'accès. Cela signifie que tout serveur Web qui utilise le format de journal commun peut utiliser AccessLogSampler. Les serveurs qui utilisent le format de journal commun incluent : Tomcat, Resin, Weblogic et SunOne. Le format de journal courant ressemble à ceci :

127.0.0.1 - - [21/Oct/2003:05:37:21 -0500] "GET /index.jsp?%2Findex.jsp= HTTP/1.1" 200 8343

À l'avenir, il pourrait être utile de filtrer les entrées qui n'ont pas de code de réponse 200 . L'extension de l'échantillonneur devrait être assez simple. Il y a deux interfaces que vous devez implémenter :

• org.apache.jmeter.protocol.http.util.accesslog.LogParser
• org.apache.jmeter.protocol.http.util.accesslog.Generator

L'implémentation actuelle d'AccessLogSampler utilise le générateur pour créer un nouveau HTTPSampler. Le nom du serveur, le port et les images get sont définis par AccessLogSampler. Ensuite, l'analyseur est appelé avec l'entier 1 , lui indiquant d'analyser une entrée. Après cela, HTTPSampler.sample() est appelé pour effectuer la requête.

samp = (HTTPSampler) GENERATOR.generateRequest();
samp.setDomain(this.getDomain());
samp.setPort(this.getPort());
samp.setImageParser(this.isImageParser());
PARSER.parse(1);
res = samp.sample();
res.setSampleLabel(samp.toString());

• setGenerator(Générateur)
• analyser (entier)

Les classes implémentant l'interface Generator doivent fournir une implémentation concrète pour toutes les méthodes. Pour un exemple d'implémentation de l'une ou l'autre interface, reportez-vous à StandardGenerator et TCLogParser .

Cet échantillonneur vous permet d'écrire un échantillonneur à l'aide du langage de script BeanShell.

Pour plus de détails sur l'utilisation de BeanShell, veuillez consulter le site Web de BeanShell.

L'élément de test prend en charge les méthodes d'interface ThreadListener et TestListener . Ceux-ci doivent être définis dans le fichier d'initialisation. Voir le fichier BeanShellListeners.bshrc pour des exemples de définitions.

L'échantillonneur BeanShell prend également en charge l' interface Interruptible . La méthode interrupt() peut être définie dans le script ou le fichier init.

L'échantillonneur JSR223 permet d'utiliser le code de script JSR223 pour effectuer un échantillon ou un calcul requis pour créer/mettre à jour des variables.

SampleResult.setIgnore();

Les éléments de test JSR223 ont une fonctionnalité (compilation) qui peut augmenter considérablement les performances. Pour bénéficier de cette fonctionnalité :

• Utilisez des fichiers de script au lieu de les intégrer. Cela obligera JMeter à les compiler si cette fonctionnalité est disponible sur ScriptEngine et à les mettre en cache.
• Ou utilisez le texte du script et cochez la propriété Script compilé en cache si disponible .
  Lorsque vous utilisez cette fonctionnalité, assurez-vous que votre code de script n'utilise pas de variables JMeter ou d'appels de fonction JMeter directement dans le code de script, car la mise en cache ne mettrait en cache que le premier remplacement. Utilisez plutôt des paramètres de script.
  Pour bénéficier de la mise en cache et de la compilation, le moteur de langage utilisé pour les scripts doit implémenter l' interface compilable JSR223 (Groovy en fait partie, java, beanshell et javascript ne le sont pas)
  Lorsque vous utilisez Groovy comme langage de script et que vous ne cochez pas le script compilé du cache s'il est disponible (alors que la mise en cache est recommandée), vous devez définir cette propriété JVM -Dgroovy.use.classvalue=true en raison d'une fuite de mémoire Groovy à partir de la version 2.4.6, voir :

  • GROOVY-7683
  • GROOVY-7591
  • JDK-8136353

jsr223.compiled_scripts_cache_size=100

L'échantillonneur TCP ouvre une connexion TCP/IP au serveur spécifié. Il envoie ensuite le texte et attend une réponse.

Si « Réutiliser la connexion » est sélectionné, les connexions sont partagées entre les échantillonneurs dans le même thread, à condition que la même chaîne de nom d'hôte et le même port soient utilisés. Différentes combinaisons hôtes/ports utiliseront différentes connexions, tout comme différents threads. Si " Réutiliser la connexion " et " Fermer la connexion " sont tous les deux sélectionnés, la prise sera fermée après l'exécution de l'échantillonneur. Sur le sampler suivant, un autre socket sera créé. Vous voudrez peut-être fermer un socket à la fin de chaque boucle de thread.

Si une erreur est détectée - ou " Réutiliser la connexion " n'est pas sélectionné - le socket est fermé. Une autre prise sera rouverte sur le prochain échantillon.

Les propriétés suivantes peuvent être utilisées pour contrôler son fonctionnement :

tcp.status.prefix

texte qui précède un numéro d'état

tcp.status.suffix

texte qui suit un numéro d'état

tcp.status.properties

nom du fichier de propriétés pour convertir les codes d'état en messages

tcp.handler

Nom de la classe TCP Handler (par défaut TCPClientImpl ) - utilisé uniquement s'il n'est pas spécifié sur l'interface graphique

Les utilisateurs peuvent fournir leur propre implémentation. La classe doit étendre org.apache.jmeter.protocol.tcp.sampler.TCPClient .

Les implémentations suivantes sont actuellement fournies.

• TCPClientImpl
• BinaryTCPCClientImpl
• LengthPrefixedBinaryTCPClientImpl

TCPClientImpl

Cette implémentation est assez basique. Lors de la lecture de la réponse, il lit jusqu'à l'octet de fin de ligne, si cela est défini en définissant la propriété tcp.eolByte , sinon jusqu'à la fin du flux d'entrée. Vous pouvez contrôler l'encodage du jeu de caractères en définissant tcp.charset , qui sera par défaut l'encodage par défaut de la plate-forme.

BinaryTCPCClientImpl

Cette implémentation convertit l'entrée de l'interface graphique, qui doit être une chaîne codée en hexadécimal, en binaire, et effectue l'inverse lors de la lecture de la réponse. Lors de la lecture de la réponse, il lit jusqu'à la fin de l'octet de message, si cela est défini en définissant la propriété tcp.BinaryTCPClient.eomByte , sinon jusqu'à la fin du flux d'entrée.

LengthPrefixedBinaryTCPClientImpl

Cette implémentation étend BinaryTCPClientImpl en préfixant les données du message binaire avec un octet de longueur binaire. Le préfixe de longueur par défaut est de 2 octets. Cela peut être modifié en définissant la propriété tcp.binarylength.prefix.length .

Gestion du délai d'attente

Si le délai d'attente est défini, la lecture sera terminée à son expiration. Donc, si vous utilisez un eolByte / eomByte , assurez-vous que le délai d'attente est suffisamment long, sinon la lecture sera terminée plus tôt.

Gestion des réponses

Si tcp.status.prefix est défini, le message de réponse est recherché pour le texte suivant jusqu'au suffixe. Si un tel texte est trouvé, il est utilisé pour définir le code de réponse. Le message de réponse est ensuite extrait du fichier de propriétés (s'il est fourni).

Utilisation du pré- et du suffixe ¶

Par exemple, si le préfixe = " [ " et le suffixe = " ] ", alors la réponse suivante :

[J28] XI123,23,GBP,CR

aurait le code de réponse J28 .

Les codes de réponse dans la plage " 400 "-" 499 " et " 500 "-" 599 " sont actuellement considérés comme des échecs ; tous les autres réussissent. [Cela doit être rendu configurable !]

JMS Publisher publiera les messages vers une destination donnée (sujet/file d'attente). Pour ceux qui ne connaissent pas JMS, il s'agit de la spécification J2EE pour la messagerie. Il existe de nombreux serveurs JMS sur le marché et plusieurs options open source.

L'abonné JMS s'abonnera aux messages d'une destination donnée (sujet ou file d'attente). Pour ceux qui ne connaissent pas JMS, il s'agit de la spécification J2EE pour la messagerie. Il existe de nombreux serveurs JMS sur le marché et plusieurs options open source.

Cet échantillonneur envoie et reçoit éventuellement des messages JMS via des connexions point à point (files d'attente). Il est différent des messages pub/sub et est généralement utilisé pour gérer les transactions.

request_only sera généralement utilisé pour charger un système JMS.
request_reply sera utilisé lorsque vous souhaitez tester le temps de réponse d'un service JMS qui traite les messages envoyés à la file d'attente des demandes car ce mode attendra la réponse sur la file d'attente des réponses envoyée par ce service.
parcourir renvoie la profondeur actuelle de la file d'attente, c'est-à-dire le nombre de messages dans la file d'attente.
read lit un message de la file d'attente (le cas échéant).
clear vide la file d'attente, c'est-à-dire supprime tous les messages de la file d'attente.

JMeter utilise les propriétés java.naming.security.[principal|credentials] - si elles sont présentes - lors de la création de la connexion à la file d'attente. Si ce comportement n'est pas souhaité, définissez la propriété JMeter JMSSampler.useSecurity.properties=false

• plutôt que d'utiliser l'interface de test de JMeter, il analyse les fichiers jar pour les classes étendant la classe TestCase de JUnit . Cela inclut toute classe ou sous-classe.
• Les fichiers jar de test JUnit doivent être placés dans jmeter/lib/junit au lieu du répertoire /lib . Vous pouvez également utiliser la propriété " user.classpath " pour spécifier où chercher les classes TestCase .
• L'échantillonneur JUnit n'utilise pas de paires nom/valeur pour la configuration comme Java Request . L'échantillonneur suppose que setUp et tearDown configureront le test correctement.
• L'échantillonneur mesure le temps écoulé uniquement pour la méthode de test et n'inclut pas setUp et tearDown .
• Chaque fois que la méthode de test est appelée, JMeter transmettra le résultat aux écouteurs.
• La prise en charge de oneTimeSetUp et oneTimeTearDown se fait en tant que méthode. Étant donné que JMeter est multi-thread, nous ne pouvons pas appeler oneTimeSetUp / oneTimeTearDown de la même manière que Maven le fait.
• L'échantillonneur signale les exceptions inattendues comme des erreurs. Il existe des différences importantes entre les exécuteurs de test JUnit standard et l'implémentation de JMeter. Plutôt que de créer une nouvelle instance de la classe pour chaque test, JMeter crée 1 instance par échantillonneur et la réutilise. Cela peut être changé avec la case à cocher " Créer une nouvelle instance par échantillon ".

public class myTestCase {
  public myTestCase() {}
}

public class myTestCase {
  public myTestCase(String text) {
    super(texte);
  }
}

L'échantillonneur de lecteur de courrier peut lire (et éventuellement supprimer) des messages électroniques à l'aide des protocoles POP3(S) ou IMAP(S).

Cet échantillonneur peut également être utile en conjonction avec le contrôleur de transaction, car il permet d'inclure des pauses sans avoir besoin de générer un échantillon. Pour les retards variables, réglez le temps de pause sur zéro et ajoutez un minuteur en tant qu'enfant.

L'action " Arrêter " arrête le thread ou le test après avoir terminé tous les échantillons en cours. L'action « Arrêter maintenant » arrête le test sans attendre que les échantillons soient terminés ; cela interrompra tous les échantillons actifs. Si certains threads ne s'arrêtent pas dans le délai de 5 secondes, un message s'affichera en mode GUI. Vous pouvez essayer d'utiliser la commande Stop pour voir si cela arrêtera les threads, mais si ce n'est pas le cas, vous devez quitter JMeter. En mode CLI, JMeter se fermera si certains threads ne s'arrêtent pas dans le délai de 5 secondes.

L'échantillonneur SMTP peut envoyer des messages électroniques à l'aide du protocole SMTP/SMTPS. Il est possible de définir des protocoles de sécurité pour la connexion (SSL et TLS), ainsi que l'authentification des utilisateurs. Si un protocole de sécurité est utilisé, une vérification sur le certificat du serveur aura lieu.
Deux alternatives pour gérer cette vérification sont disponibles :

Faire confiance à tous les certificats

Cela ignorera la vérification de la chaîne de certificats

Utiliser un truststore local

Avec cette option, la chaîne de certificats sera validée par rapport au fichier truststore local.

L'échantillonneur de processus du système d'exploitation est un échantillonneur qui peut être utilisé pour exécuter des commandes sur la machine locale.
Il devrait permettre l'exécution de toute commande pouvant être exécutée à partir de la ligne de commande.
La validation du code de retour peut être activée et le code de retour attendu peut être spécifié.

Notez que les shells du système d'exploitation fournissent généralement une analyse de ligne de commande. Cela varie d'un système d'exploitation à l'autre, mais généralement, le shell divisera les paramètres sur l'espace blanc. Certains shells étendent les noms de fichiers génériques ; certains ne le font pas. Le mécanisme de citation varie également entre les systèmes d'exploitation. L'échantillonneur ne fait délibérément aucune analyse ou gestion des citations. La commande et ses paramètres doivent être fournis sous la forme attendue par l'exécutable. Cela signifie que les paramètres de l'échantillonneur ne seront pas portables entre les systèmes d'exploitation.

De nombreux systèmes d'exploitation ont des commandes intégrées qui ne sont pas fournies en tant qu'exécutables séparés. Par exemple, la commande Windows DIR fait partie de l'interpréteur de commandes ( CMD.EXE ). Ces éléments intégrés ne peuvent pas être exécutés en tant que programmes indépendants, mais doivent être fournis en tant qu'arguments à l'interpréteur de commandes approprié.

Par exemple, la ligne de commande Windows : DIR C:\TEMP doit être spécifiée comme suit :

Commande:

CMD

Paramètre 1 :

/C

Paramètre 2 :

REP

Paramètre 3 :

C:\TEMP

Cet échantillonneur vous permet d'envoyer une requête à une MongoDB.

Avant de l'utiliser, vous devez configurer un élément MongoDB Source Config Configuration

Cet échantillonneur vous permet d'exécuter des requêtes Cypher via le protocole Bolt.

Avant de l'utiliser, vous devez configurer une configuration de connexion par boulon

Chaque demande utilise une connexion acquise à partir du pool et la renvoie au pool lorsque l'échantillonneur se termine. La taille du pool de connexion utilise les valeurs par défaut du pilote (~100) et n'est pas configurable pour le moment.

Le temps de réponse mesuré correspond à l'exécution "complète" de la requête, comprenant à la fois le temps d'exécution de la requête de chiffrement ET le temps de consommation des résultats renvoyés par la base de données.

Le contrôleur logique simple vous permet d'organiser vos échantillonneurs et autres contrôleurs logiques. Contrairement aux autres contrôleurs logiques, ce contrôleur ne fournit aucune fonctionnalité au-delà de celle d'un périphérique de stockage.

Si vous ajoutez des contrôleurs génératifs ou logiques à un contrôleur de boucle, JMeter les parcourra un certain nombre de fois, en plus de la valeur de boucle que vous avez spécifiée pour le groupe de threads. Par exemple, si vous ajoutez une requête HTTP à un contrôleur de boucle avec un nombre de boucles de deux et que vous configurez le nombre de boucles du groupe de threads sur trois, JMeter enverra un total de 2 * 3 = 6 requêtes HTTP.

Le contrôleur logique unique indique à JMeter de traiter le ou les contrôleurs à l'intérieur une seule fois par thread et de transmettre toutes les requêtes sous celui-ci lors d'itérations ultérieures dans le plan de test.

Le contrôleur Once Only s'exécutera désormais toujours lors de la première itération de tout contrôleur parent en boucle. Ainsi, si le contrôleur unique est placé sous un contrôleur de boucle spécifié pour boucler 5 fois, le contrôleur unique ne s'exécutera qu'à la première itération via le contrôleur de boucle (c'est-à-dire toutes les 5 fois).

Notez que cela signifie que le contrôleur Once Only se comportera toujours comme prévu s'il est placé dans un groupe de threads (s'exécute une seule fois par test et par thread), mais l'utilisateur dispose désormais d'une plus grande flexibilité dans l'utilisation du contrôleur Once Only.

Pour les tests nécessitant une connexion, envisagez de placer la demande de connexion dans ce contrôleur, car chaque thread n'a besoin de se connecter qu'une seule fois pour établir une session.

Si vous ajoutez des contrôleurs génératifs ou logiques à un contrôleur entrelacé, JMeter alternera entre chacun des autres contrôleurs pour chaque itération de boucle.

Le contrôleur logique aléatoire agit de la même manière que le contrôleur d'entrelacement, sauf qu'au lieu de parcourir ses sous-contrôleurs et échantillonneurs dans l'ordre, il en choisit un au hasard à chaque passage.

Le contrôleur d'ordre aléatoire ressemble beaucoup à un contrôleur simple en ce sens qu'il exécutera chaque élément enfant au plus une fois, mais l'ordre d'exécution des nœuds sera aléatoire.

Le contrôleur de débit permet à l'utilisateur de contrôler la fréquence d'exécution. Il existe deux modes :

• pourcentage d'exécution
• nombre total d'exécutions

Pourcentage d'exécutions

oblige le contrôleur à exécuter un certain pourcentage d'itérations dans le plan de test.

Total des exécutions

provoque l'arrêt de l'exécution du contrôleur après un certain nombre d'exécutions.

Le contrôleur d'exécution contrôle la durée d'exécution de ses enfants. Le contrôleur exécutera ses enfants jusqu'à ce que le ou les temps d' exécution configurés soient dépassés.

Le contrôleur If permet à l'utilisateur de contrôler si les éléments de test situés en dessous (ses enfants) sont exécutés ou non.

Par défaut, la condition n'est évaluée qu'une seule fois lors de la saisie initiale, mais vous avez la possibilité de la faire évaluer pour chaque élément exécutable contenu dans le contrôleur.

La meilleure option (par défaut) consiste à cocher Interpréter la condition comme une expression variable ? , puis dans le champ condition vous avez 2 options :

• Option 1 : Utiliser une variable qui contient vrai ou faux
  Si vous voulez tester si le dernier échantillon a réussi, vous pouvez utiliser ${JMeterThread.last_sample_ok}

  
• Option 2 : Utiliser une fonction ( ${__jexl3()} est conseillé) pour évaluer une expression qui doit retourner vrai ou faux

  

"${maVar}" == "\${maVar}"

"${maVar}" != "\${maVar}"

Le contrôleur While exécute ses enfants jusqu'à ce que la condition soit " false ".

Valeurs de condition possibles :

• vide - quitte la boucle lorsque le dernier échantillon de la boucle échoue
• LAST - quitte la boucle lorsque le dernier échantillon de la boucle échoue. Si le dernier échantillon juste avant la boucle a échoué, n'entrez pas dans la boucle.
• Sinon - quittez (ou n'entrez pas) la boucle lorsque la condition est égale à la chaîne " false "

• ${VAR} - où VAR est défini sur false par un autre élément de test
• ${__jexl3(${C}==10)}
• ${__jexl3("${VAR2}"=="abcd")}
• ${_P(property)} - où la propriété est définie sur " false " ailleurs

Le contrôleur de commutateur agit comme le contrôleur d'entrelacement en ce sens qu'il exécute l'un des éléments subordonnés à chaque itération, mais plutôt que de les exécuter en séquence, le contrôleur exécute l'élément défini par la valeur du commutateur.

Si la valeur du commutateur est hors plage, il exécutera l'élément zéro, qui agit donc comme valeur par défaut pour la casse numérique. Il exécute également l'élément zéro si la valeur est la chaîne vide.

Si la valeur n'est pas numérique (et non vide), alors le contrôleur de commutateur recherche l'élément portant le même nom (la casse est significative). Si aucun des noms ne correspond, alors l'élément nommé " default " (casse non significative) est sélectionné. S'il n'y a pas de valeur par défaut, aucun élément n'est sélectionné et le contrôleur n'exécutera rien.

Un contrôleur ForEach parcourt les valeurs d'un ensemble de variables associées. Lorsque vous ajoutez des échantillonneurs (ou contrôleurs) à un contrôleur ForEach, chaque échantillon (ou contrôleur) est exécuté une ou plusieurs fois, où à chaque boucle la variable a une nouvelle valeur. L'entrée doit être composée de plusieurs variables, chacune prolongée par un trait de soulignement et un nombre. Chacune de ces variables doit avoir une valeur. Ainsi, par exemple, lorsque la variable d'entrée porte le nom inputVar , les variables suivantes doivent avoir été définies :

• entréeVar_1 = wendy
• entréeVar_2 = charles
• inputVar_3 = peter
• inputVar_4 = jean

Remarque : le séparateur " _ " est désormais facultatif.

Lorsque la variable de retour est donnée comme " returnVar ", la collection d'échantillonneurs et de contrôleurs sous le contrôleur ForEach sera exécutée 4 fois consécutives, la variable de retour ayant les valeurs ci-dessus respectives, qui peuvent ensuite être utilisées dans les échantillonneurs.

Il est particulièrement adapté à l'exécution avec le post-processeur d'expressions régulières. Cela peut "créer" les variables d'entrée nécessaires à partir des données de résultat d'une requête précédente. En omettant le séparateur " _ ", le contrôleur ForEach peut être utilisé pour parcourir les groupes en utilisant la variable d'entrée refName_g , et peut également parcourir tous les groupes dans toutes les correspondances en utilisant une variable d'entrée de la forme refName_${C }_g , où C est une variable compteur.

Le contrôleur de module fournit un mécanisme pour substituer des fragments de plan de test dans le plan de test actuel au moment de l'exécution.

Un fragment de plan de test se compose d'un contrôleur et de tous les éléments de test (échantillonneurs, etc.) qu'il contient. Le fragment peut être situé dans n'importe quel groupe de threads. Si le fragment se trouve dans un groupe de threads, son contrôleur peut être désactivé pour empêcher l'exécution du fragment sauf par le contrôleur de module. Ou vous pouvez stocker les fragments dans un groupe de threads factice et désactiver l'ensemble du groupe de threads.

Il peut y avoir plusieurs fragments, chacun avec une série différente d'échantillonneurs sous eux. Le contrôleur de module peut ensuite être utilisé pour basculer facilement entre ces multiples cas de test simplement en choisissant le contrôleur approprié dans sa liste déroulante. Cela permet d'exécuter facilement et rapidement de nombreux plans de test alternatifs.

Un nom de fragment est composé du nom du contrôleur et de tous ses noms parents. Par exemple:

Plan de test/protocole : JDBC/contrôle/contrôleur d'entrelacement (module 1)

Tous les fragments utilisés par le contrôleur de module doivent avoir un nom unique , car le nom est utilisé pour trouver le contrôleur cible lorsqu'un plan de test est rechargé. Pour cette raison, il est préférable de s'assurer que le nom du contrôleur est modifié par défaut - comme indiqué dans l'exemple ci-dessus - sinon un doublon peut être créé accidentellement lorsque de nouveaux éléments sont ajoutés au plan de test.

Le contrôleur inclus est conçu pour utiliser un fichier JMX externe. Pour l'utiliser, créez un fragment de test sous le plan de test et ajoutez les échantillonneurs, contrôleurs, etc. souhaités en dessous. Enregistrez ensuite le plan de test. Le fichier est maintenant prêt à être inclus dans d'autres plans de test.

Pour plus de commodité, un groupe de threads peut également être ajouté dans le fichier JMX externe à des fins de débogage. Un contrôleur de module peut être utilisé pour référencer le fragment de test. Le groupe de threads sera ignoré pendant le processus d'inclusion.

Si le test utilise un gestionnaire de cookies ou des variables définies par l'utilisateur, celles-ci doivent être placées dans le plan de test de niveau supérieur, et non dans le fichier inclus, sinon leur fonctionnement n'est pas garanti.

Si le fichier est introuvable à l'emplacement indiqué par préfixe + nom de fichier , le contrôleur tente d'ouvrir le nom de fichier relatif au répertoire de lancement JMX.

Le contrôleur de transaction génère un échantillon supplémentaire qui mesure le temps total nécessaire pour effectuer les éléments de test imbriqués.

Il existe deux modes de fonctionnement :

• un échantillon supplémentaire est ajouté après les échantillons imbriqués
• un échantillon supplémentaire est ajouté en tant que parent des échantillons imbriqués

Le temps d'échantillonnage généré inclut tous les temps pour les échantillonneurs imbriqués à l'exception par défaut (depuis 2.11) des temporisateurs et du temps de traitement des pré/post processeurs sauf si la case " Inclure la durée du temporisateur et des pré-post processeurs dans l'échantillon généré " est cochée. En fonction de la résolution de l'horloge, elle peut être légèrement plus longue que la somme des échantillonneurs individuels et des temporisateurs. L'horloge peut faire tic tac après que le contrôleur a enregistré l'heure de début, mais avant le début du premier échantillon. De même à la fin.

L'échantillon généré n'est considéré comme réussi que si tous ses sous-échantillons sont réussis.

En mode parent, les échantillons individuels peuvent toujours être vus dans le Tree View Listener, mais n'apparaissent plus comme des entrées séparées dans d'autres Listeners. De plus, les sous-échantillons n'apparaissent pas dans les fichiers journaux CSV, mais ils peuvent être enregistrés dans des fichiers XML.

Le contrôleur d'enregistrement est un espace réservé indiquant où le serveur proxy doit enregistrer les échantillons. Pendant le test, il n'a aucun effet, similaire au contrôleur simple. Mais pendant l'enregistrement à l'aide de l' enregistreur de script de test HTTP(S) , tous les échantillons enregistrés seront par défaut enregistrés sous le contrôleur d'enregistrement.

Le contrôleur de section critique garantit que ses éléments enfants (échantillonneurs/contrôleurs, etc.) seront exécutés par un seul thread car un verrou nommé sera pris avant d'exécuter les enfants du contrôleur.

Les écouteurs peuvent être configurés pour enregistrer différents éléments dans les fichiers journaux de résultats (JTL) à l'aide de la fenêtre contextuelle Config, comme indiqué ci-dessous. Les valeurs par défaut sont définies comme décrit dans la documentation de configuration par défaut de l'écouteur . Les éléments avec ( CSV ) après le nom s'appliquent uniquement au format CSV ; les éléments avec ( XML ) s'appliquent uniquement au format XML. Le format CSV ne peut actuellement pas être utilisé pour enregistrer des éléments qui incluent des sauts de ligne.

Notez que les cookies, la méthode et la chaîne de requête sont enregistrés dans le cadre de l' option " Sampler Data ".

L'écouteur Graph Results génère un graphique simple qui trace tous les temps d'échantillonnage. Au bas du graphique, l'échantillon actuel (noir), la moyenne actuelle de tous les échantillons (bleu), l'écart type actuel (rouge) et le débit actuel (vert) sont affichés en millisecondes.

Le nombre de débit représente le nombre réel de requêtes/minute traitées par le serveur. Ce calcul inclut tous les retards que vous avez ajoutés à votre test et le temps de traitement interne de JMeter. L'avantage de faire le calcul comme celui-ci est que ce nombre représente quelque chose de réel - votre serveur a en fait traité autant de requêtes par minute, et vous pouvez augmenter le nombre de threads et/ou diminuer les délais pour découvrir le débit maximum de votre serveur. Alors que si vous faisiez des calculs qui excluaient les retards et le traitement de JMeter, il serait difficile de savoir ce que vous pourriez conclure de ce nombre.

Le visualiseur des résultats d'assertion affiche l'étiquette de chaque échantillon prélevé. Il signale également les échecs de toutes les assertions faisant partie du plan de test.

Il existe plusieurs façons d'afficher la réponse, sélectionnables par une liste déroulante en bas du panneau de gauche.

Nombre de matchs : 74
Match[1]=#fonctions
Match[2]=#what_can_do
Correspondance[3]=#où
Correspondance[4]=#comment
Correspondance[5]=#function_helper
Match[6]=#fonctions
Correspondance[7]=#__regexFonction
Correspondance[8]=#__regexFunction_parms
Match[9]=#__compteur
… etc …

Nombre de matchs : 26
Match[1][0]=JMeter - Apache JMeter</title>
Correspondance[1][1]=Jmètre
Match[2][0]=JMeter" title="JMeter" border="0"/></a>
Correspondance[2][1]=Jmètre
Match[3][0]=JMeterCommitters">Contributeurs</a>
Match[3][1]=JMeterCommitters
… etc …

image/
l'audio/
vidéo/

Faire défiler automatiquement ? l'option permet d'afficher le dernier nœud dans la sélection de l'arbre

Avec l'option Rechercher , la plupart des vues permettent également de rechercher les données affichées ; le résultat de la recherche sera mis en surbrillance dans l'affichage ci-dessus. Par exemple, la capture d'écran du panneau de configuration ci-dessous montre un résultat de la recherche de " Java ". Notez que la recherche s'effectue sur le texte visible, vous pouvez donc obtenir des résultats différents lors de la recherche dans les vues Texte et HTML.
Remarque : L'expression régulière utilise le moteur Java (pas le moteur ORO comme la vue Regular Expression Extractor ou Regexp Tester).

Si aucun type de contenu n'est fourni, le contenu ne sera affiché dans aucun des panneaux de données de réponse. Vous pouvez utiliser Enregistrer les réponses dans un fichier pour enregistrer les données dans ce cas. Notez que les données de réponse seront toujours disponibles dans le résultat de l'échantillon, elles sont donc toujours accessibles à l'aide des post-processeurs.

Si les données de réponse sont supérieures à 200 Ko, elles ne seront pas affichées. Pour modifier cette limite, définissez la propriété JMeter view.results.tree.max_size . Vous pouvez également enregistrer l'intégralité de la réponse dans un fichier à l'aide de Enregistrer les réponses dans un fichier .

Des moteurs de rendu supplémentaires peuvent être créés. La classe doit implémenter l'interface org.apache.jmeter.visualizers.ResultRenderer et/ou étendre la classe abstraite org.apache.jmeter.visualizers.SamplerResultTab , et le code compilé doit être disponible pour JMeter (par exemple en l'ajoutant à la lib/ répertoire ext ).

Le débit est calculé du point de vue de la cible de l'échantillonneur (par exemple le serveur distant dans le cas des échantillons HTTP). JMeter prend en compte le temps total pendant lequel les requêtes ont été générées. Si d'autres échantillonneurs et minuteries se trouvent dans le même thread, ceux-ci augmenteront le temps total et réduiront donc la valeur de débit. Ainsi, deux échantillonneurs identiques portant des noms différents auront la moitié du débit de deux échantillonneurs portant le même nom. Il est important de choisir correctement les noms des échantillonneurs pour obtenir les meilleurs résultats du rapport agrégé.

Le calcul des valeurs de la médiane et de la ligne de 90 % (90 ^e centile ) nécessite de la mémoire supplémentaire. JMeter combine maintenant des échantillons avec le même temps écoulé, donc beaucoup moins de mémoire est utilisée. Cependant, pour les échantillons qui prennent plus de quelques secondes, il est probable que moins d'échantillons auront des temps identiques, auquel cas plus de mémoire sera nécessaire. Notez que vous pouvez utiliser cet écouteur par la suite pour recharger un fichier de résultats CSV ou XML, ce qui est la méthode recommandée pour éviter les impacts sur les performances. Voir le rapport de synthèse pour un récepteur similaire qui ne stocke pas d'échantillons individuels et nécessite donc une mémoire constante.

• Étiquette - L'étiquette de l'échantillon. Si « Inclure le nom du groupe dans l'étiquette ? » est sélectionné, le nom du groupe de threads est ajouté en tant que préfixe. Cela permet aux étiquettes identiques de différents groupes de fils d'être assemblées séparément si nécessaire.
• # Samples - Le nombre d'échantillons avec la même étiquette
• Moyenne - Le temps moyen d'un ensemble de résultats
• Médiane - La médiane est le temps au milieu d'un ensemble de résultats. 50 % des échantillons n'ont pas pris plus de temps ; le reste a pris au moins autant de temps.
• 90% Line - 90% des échantillons n'ont pas pris plus de temps. Les échantillons restants ont pris au moins aussi longtemps que cela. (90 ^e centile )
• 95% Line - 95% des échantillons n'ont pas pris plus de temps. Les échantillons restants ont pris au moins aussi longtemps que cela. (95 ^e centile )
• 99% Line - 99% des échantillons n'ont pas pris plus de temps. Les échantillons restants ont pris au moins aussi longtemps que cela. (99 ^e centile )
• Min - Le temps le plus court pour les échantillons avec la même étiquette
• Max - Le temps le plus long pour les échantillons avec la même étiquette
• % d'erreur - Pourcentage de requêtes comportant des erreurs
• Débit - le débit est mesuré en requêtes par seconde/minute/heure. L'unité de temps est choisie de manière à ce que le taux affiché soit d'au moins 1,0. Lorsque le débit est enregistré dans un fichier CSV, il est exprimé en requêtes/seconde, c'est-à-dire que 30,0 requêtes/minute sont enregistrées sous la forme 0,5.
• Received KB/sec - Le débit mesuré en kilo-octets reçus par seconde
• Sent KB/sec - Le débit mesuré en kilo-octets envoyés par seconde

Les temps sont en millisecondes.

Par défaut, il n'affiche que les échantillons principaux (parents) ; il n'affiche pas les sous-échantillons (échantillons enfants). JMeter a une case à cocher " Child Samples? ". Si cette option est sélectionnée, les sous-échantillons sont affichés à la place des échantillons principaux.

Le visualiseur de messagerie peut être configuré pour envoyer des e-mails si une exécution de test reçoit trop de réponses d'échec du serveur.

Le BeanShell Listener permet l'utilisation de BeanShell pour le traitement des échantillons pour la sauvegarde, etc.

Pour plus de détails sur l'utilisation de BeanShell, veuillez consulter le site Web de BeanShell.

L'élément de test prend en charge les méthodes ThreadListener et TestListener . Ceux-ci doivent être définis dans le fichier d'initialisation. Voir le fichier BeanShellListeners.bshrc pour des exemples de définitions.

Le débit est calculé du point de vue de la cible de l'échantillonneur (par exemple le serveur distant dans le cas des échantillons HTTP). JMeter prend en compte le temps total pendant lequel les requêtes ont été générées. Si d'autres échantillonneurs et minuteries se trouvent dans le même thread, ceux-ci augmenteront le temps total et réduiront donc la valeur de débit. Ainsi, deux échantillonneurs identiques portant des noms différents auront la moitié du débit de deux échantillonneurs portant le même nom. Il est important de choisir correctement les étiquettes de l'échantillonneur pour obtenir les meilleurs résultats du rapport.

• Étiquette - L'étiquette de l'échantillon. Si « Inclure le nom du groupe dans l'étiquette ? » est sélectionné, le nom du groupe de threads est ajouté en tant que préfixe. Cela permet aux étiquettes identiques de différents groupes de fils d'être assemblées séparément si nécessaire.
• # Samples - Le nombre d'échantillons avec la même étiquette
• Moyenne - Le temps écoulé moyen d'un ensemble de résultats
• Min - Le temps écoulé le plus bas pour les échantillons avec la même étiquette
• Max - Le temps écoulé le plus long pour les échantillons avec la même étiquette
• Std. Dév. - l' écart type du temps écoulé de l'échantillon
• % d'erreur - Pourcentage de requêtes comportant des erreurs
• Débit - le débit est mesuré en requêtes par seconde/minute/heure. L'unité de temps est choisie de manière à ce que le taux affiché soit d'au moins 1,0 . Lorsque le débit est enregistré dans un fichier CSV, il est exprimé en requêtes/seconde, c'est-à-dire que 30,0 requêtes/minute sont enregistrées sous la forme 0,5 .
• Received KB/sec - Le débit mesuré en kilo-octets par seconde
• Sent KB/sec - Le débit mesuré en kilo-octets par seconde
• Moy. Octets - taille moyenne de l'échantillon de réponse en octets.

Les temps sont en millisecondes.

Cet élément de test peut être placé n'importe où dans le plan de test. Pour chaque échantillon dans sa portée, il créera un fichier de données de réponse. Cela sert principalement à créer des tests fonctionnels, mais cela peut également être utile lorsque la réponse est trop volumineuse pour être affichée dans l' écouteur de l' arborescence des résultats . Le nom de fichier est créé à partir du préfixe spécifié, suivi d'un nombre (sauf si cette option est désactivée, voir ci-dessous). L'extension de fichier est créée à partir du type de document, s'il est connu. Si elle n'est pas connue, l'extension de fichier est définie sur ' inconnu'. Si la numérotation est désactivée et que l'ajout d'un suffixe est désactivé, le préfixe de fichier est considéré comme le nom de fichier complet. Cela permet de générer un nom de fichier fixe si nécessaire. Le nom du fichier généré est stocké dans l'exemple de réponse et peut être enregistré dans le fichier de sortie du journal de test si nécessaire.

L'échantillon actuel est enregistré en premier, suivi de tous les sous-échantillons (échantillons enfants). Si un nom de variable est fourni, les noms des fichiers sont enregistrés dans l'ordre d'apparition des sous-échantillons. Voir ci-dessous.

L'écouteur JSR223 permet d'appliquer le code de script JSR223 aux résultats d'échantillon.

# Définissez la propriété suivante pour démarrer automatiquement un récapitulatif avec ce nom
# (s'applique uniquement au mode CLI)
#summariser.name=résumé
#
# intervalle entre les résumés (en secondes) par défaut 3 minutes
#summariser.interval=30
#
# Écrire des messages dans le fichier journal
#summariser.log=true
#
# Écrire des messages dans System.out
#summariser.out=true

label + 16 in 0:00:12 = 1.3/s Moy : 1608 Min : 1163 Max : 2009 Err : 0 (0.00%) Actif : 5 Démarré : 5 Terminé : 0
label + 82 in 0:00:30 = 2.7/s Moy : 1518 Min : 1003 Max : 2020 Err : 0 (0.00%) Actif : 5 Démarré : 5 Terminé : 0
étiquette = 98 en 0:00:42 = 2,3/s Moy : 1533 Min : 1003 Max : 2020 Err : 0 (0,00 %)
label + 85 en 0:00:30 = 2,8/s Moy : 1505 Min : 1008 Max : 2005 Err : 0 (0,00%) Actif : 5 Démarré : 5 Terminé : 0
étiquette = 183 en 0:01:13 = 2,5/s Moy : 1520 Min : 1003 Max : 2020 Err : 0 (0,00%)
label + 79 en 0:00:30 = 2,7/s Moy : 1578 Min : 1089 Max : 2012 Err : 0 (0,00%) Actif : 5 Démarré : 5 Terminé : 0
étiquette = 262 en 0:01:43 = 2,6/s Moy : 1538 Min : 1003 Max : 2020 Err : 0 (0,00%)
label + 80 en 0:00:30 = 2,7/s Moy : 1531 Min : 1013 Max : 2014 Err : 0 (0,00%) Actif : 5 Démarré : 5 Terminé : 0
étiquette = 342 en 0:02:12 = 2,6/s Moy : 1536 Min : 1003 Max : 2020 Err : 0 (0,00 %)
label + 83 in 0:00:31 = 2.7/s Moy : 1512 Min : 1003 Max : 1982 Err : 0 (0.00%) Actif : 5 Démarré : 5 Terminé : 0
étiquette = 425 en 0:02:43 = 2,6/s Moy : 1531 Min : 1003 Max : 2020 Err : 0 (0,00 %)
label + 83 in 0:00:29 = 2.8/s Moy : 1487 Min : 1023 Max : 2013 Err : 0 (0.00%) Actif : 5 Démarré : 5 Terminé : 0
étiquette = 508 en 0:03:12 = 2,6/s Moy : 1524 Min : 1003 Max : 2020 Err : 0 (0,00 %)
label + 78 en 0:00:30 = 2,6/s Moy : 1594 Min : 1013 Max : 2016 Err : 0 (0,00%) Actif : 5 Démarré : 5 Terminé : 0
étiquette = 586 en 0:03:43 = 2,6/s Moy : 1533 Min : 1003 Max : 2020 Err : 0 (0,00 %)
label + 80 en 0:00:30 = 2,7/s Moy : 1516 Min : 1013 Max : 2005 Err : 0 (0,00%) Actif : 5 Démarré : 5 Terminé : 0
étiquette = 666 en 0:04:12 = 2,6/s Moy : 1531 Min : 1003 Max : 2020 Err : 0 (0,00 %)
label + 86 en 0:00:30 = 2,9/s Moy : 1449 Min : 1004 Max : 2017 Err : 0 (0,00 %) Actif : 5 Démarré : 5 Terminé : 0
étiquette = 752 en 0:04:43 = 2,7/s Moy : 1522 Min : 1003 Max : 2020 Err : 0 (0,00 %)
label + 65 en 0:00:24 = 2,7/s Moy : 1579 Min : 1007 Max : 2003 Err : 0 (0,00 %) Actif : 0 Démarré : 5 Terminé : 5
étiquette = 817 en 0:05:07 = 2,7/s Moy : 1526 Min : 1003 Max : 2020 Err : 0 (0,00%)

L'étiquette est utilisée pour regrouper les résultats des échantillons. Donc, si vous avez plusieurs groupes de threads et que vous souhaitez les résumer tous, utilisez la même étiquette - ou ajoutez le récapitulatif au plan de test (afin que tous les groupes de threads soient concernés). Différents regroupements de résumés peuvent être mis en œuvre en utilisant des étiquettes appropriées et en ajoutant les résumés aux parties appropriées du plan de test.

CSV Data Set Config est utilisé pour lire les lignes d'un fichier et les diviser en variables. Il est plus facile à utiliser que les fonctions __CSVRead() et __StringFromFile() . Il est bien adapté à la gestion d'un grand nombre de variables et est également utile pour tester avec des valeurs "aléatoires" et uniques.

La génération de valeurs aléatoires uniques au moment de l'exécution est coûteuse en termes de CPU et de mémoire, il suffit donc de créer les données avant le test. Si nécessaire, les données "aléatoires" du fichier peuvent être utilisées en conjonction avec un paramètre d'exécution pour créer différents ensembles de valeurs à partir de chaque exécution - par exemple en utilisant la concaténation - ce qui est beaucoup moins cher que de tout générer au moment de l'exécution.

JMeter permet de citer des valeurs ; cela permet à la valeur de contenir un délimiteur. Si « autoriser les données entre guillemets » est activé, une valeur peut être entourée de guillemets doubles. Ceux-ci sont supprimés. Pour inclure des guillemets dans un champ entre guillemets, utilisez deux guillemets. Par exemple:

1,"2,3","4""5" =>
1
2,3
4"5

JMeter prend en charge les fichiers CSV qui ont une ligne d'en-tête définissant les noms de colonne. Pour l'activer, laissez le champ " Noms des variables " vide. Le délimiteur correct doit être fourni.

JMeter prend en charge les fichiers CSV avec des données citées qui incluent de nouvelles lignes.

Par défaut, le fichier n'est ouvert qu'une seule fois et chaque thread utilisera une ligne différente du fichier. Cependant, l'ordre dans lequel les lignes sont passées aux threads dépend de l'ordre dans lequel elles s'exécutent, qui peut varier entre les itérations. Les lignes sont lues au début de chaque itération de test. Le nom de fichier et le mode sont résolus lors de la première itération.

Voir la description du mode Partager ci-dessous pour des options supplémentaires. Si vous souhaitez que chaque thread ait son propre ensemble de valeurs, vous devrez créer un ensemble de fichiers, un pour chaque thread. Par exemple test1.csv , test2.csv , …, test n .csv . Utilisez le nom de fichier test${__threadNum}.csv et définissez le " Mode de partage " sur " Thread actuel ".

Dans un cas particulier, la chaîne " \t " (sans guillemets) dans le champ délimiteur est traitée comme une tabulation.

Lorsque la fin du fichier ( EOF ) est atteinte et que l'option recycle est true , la lecture recommence à la première ligne du fichier.

Si l'option recycle est false et stopThread est false , toutes les variables sont définies sur <EOF> lorsque la fin du fichier est atteinte. Cette valeur peut être modifiée en définissant la propriété JMeter csvdataset.eofstring .

Si l'option Recycle est false et Stop Thread est true , atteindre EOF entraînera l'arrêt du thread.

L'élément DNS Cache Manager permet de tester les applications, qui ont plusieurs serveurs derrière des équilibreurs de charge (CDN, etc.), lorsque l'utilisateur reçoit du contenu de différentes adresses IP. Par défaut, JMeter utilise le cache DNS JVM. C'est pourquoi un seul serveur du cluster reçoit la charge. Le gestionnaire de cache DNS résout les noms de chaque thread séparément à chaque itération et enregistre les résultats de la résolution dans son cache DNS interne, qui est indépendant des caches DNS JVM et OS.

Un mappage pour les hôtes statiques peut être utilisé pour simuler quelque chose comme le fichier /etc/hosts . Ces entrées seront préférées au résolveur personnalisé. Utiliser un résolveur DNS personnalisé doit être activé si vous souhaitez utiliser ce mappage.

Le gestionnaire d'autorisations vous permet de spécifier une ou plusieurs connexions utilisateur pour les pages Web restreintes à l'aide de l'authentification du serveur. Vous voyez ce type d'authentification lorsque vous utilisez votre navigateur pour accéder à une page restreinte et que votre navigateur affiche une boîte de dialogue de connexion. JMeter transmet les informations de connexion lorsqu'il rencontre ce type de page.

Les en-têtes d'autorisation peuvent ne pas s'afficher dans l' onglet « Requête » de Tree View Listener . L'implémentation Java effectue une authentification préemptive, mais elle ne renvoie pas l'en-tête d'autorisation lorsque JMeter récupère les en-têtes. L'implémentation HttpComponents (HC 4.5.X) est par défaut préemptive depuis 3.2 et l'en-tête sera affiché. Pour désactiver cela, définissez les valeurs comme ci-dessous, auquel cas l'authentification ne sera effectuée qu'en réponse à un défi.

Dans le fichier jmeter.properties définissez httpclient4.auth.preemptive=false

Le gestionnaire de cache HTTP est utilisé pour ajouter une fonctionnalité de mise en cache aux requêtes HTTP dans son champ d'application afin de simuler la fonctionnalité de cache du navigateur. Chaque thread d'utilisateur virtuel a son propre cache. Par défaut, Cache Manager stockera jusqu'à 5000 éléments dans le cache par thread d'utilisateur virtuel, en utilisant l'algorithme LRU. Utilisez la propriété " maxSize " pour modifier cette valeur. Notez que plus vous augmentez cette valeur, plus HTTP Cache Manager consommera de la mémoire, veillez donc à adapter l' option -Xmx JVM en conséquence.

Si un échantillon réussit (c'est-à-dire qu'il a le code de réponse 2xx ), les valeurs Last-Modified et Etag (et Expired si pertinent) sont enregistrées pour l'URL. Avant d'exécuter l'exemple suivant, l'échantillonneur vérifie s'il existe une entrée dans le cache et, si c'est le cas, les en-têtes conditionnels If-Last-Modified et If-None-Match sont définis pour la demande.

De plus, si l'option « Utiliser l'en-tête Cache-Control/Expires » est sélectionnée, la valeur Cache-Control / Expires est vérifiée par rapport à l'heure actuelle. Si la demande est une demande GET et que l'horodatage est dans le futur, l'échantillonneur revient immédiatement, sans demander l'URL au serveur distant. Ceci est destiné à imiter le comportement du navigateur. Notez que si l'en- tête Cache-Control est " no-cache ", la réponse sera stockée dans le cache comme pré-expirée, donc générera une requête GET conditionnelle. Si Cache-Control a une autre valeur, le " max-age" L'option d'expiration est traitée pour calculer la durée de vie de l'entrée, si elle est manquante, l'en-tête d'expiration sera utilisé, si l'entrée manquante sera également mise en cache comme spécifié dans la section 13.2.4 de la RFC 2616 en utilisant l'heure de dernière modification et la date de réponse.

L'élément Cookie Manager a deux fonctions :
premièrement, il stocke et envoie des cookies comme un navigateur Web. Si vous avez une requête HTTP et que la réponse contient un cookie, le gestionnaire de cookies stocke automatiquement ce cookie et l'utilisera pour toutes les demandes futures adressées à ce site Web particulier. Chaque thread JMeter possède sa propre "zone de stockage des cookies". Ainsi, si vous testez un site Web qui utilise un cookie pour stocker les informations de session, chaque thread JMeter aura sa propre session. Notez que ces cookies n'apparaissent pas sur l'affichage du gestionnaire de cookies, mais ils peuvent être vus à l'aide de l' écouteur de l' arborescence des résultats .

JMeter vérifie que les cookies reçus sont valides pour l'URL. Cela signifie que les cookies inter-domaines ne sont pas stockés. Si vous avez un comportement buggé ou souhaitez que les cookies inter-domaines soient utilisés, définissez la propriété JMeter " CookieManager.check.cookies=false ".

Les cookies reçus peuvent être stockés en tant que variables de thread JMeter. Pour enregistrer les cookies en tant que variables, définissez la propriété " CookieManager.save.cookies=true ". De plus, les noms des cookies sont préfixés par " COOKIE_ " avant d'être stockés (ceci évite la corruption accidentelle des variables locales) Pour revenir au comportement d'origine, définissez la propriété " CookieManager.name.prefix= " (un ou plusieurs espaces). Si activé, la valeur d'un cookie portant le nom TEST peut être appelée ${COOKIE_TEST} .

Deuxièmement, vous pouvez ajouter manuellement un cookie au gestionnaire de cookies. Cependant, si vous faites cela, le cookie sera partagé par tous les threads JMeter.

Notez que ces cookies sont créés avec une date d'expiration lointaine dans le futur

Les cookies avec des valeurs nulles sont ignorés par défaut. Cela peut être modifié en définissant la propriété JMeter : CookieManager.delete_null_cookies=false . Notez que cela s'applique également aux cookies définis manuellement - ces cookies seront supprimés de l'affichage lors de sa mise à jour. Notez également que le nom du cookie doit être unique - si un deuxième cookie est défini avec le même nom, il remplacera le premier.

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, si vous créez un plan de test avec 25 contrôleurs de requêtes HTTP et que toutes les requêtes sont envoyées au même serveur, vous pouvez ajouter un seul élément HTTP Request Defaults avec le champ " Server Name or IP " rempli. Ensuite , lorsque vous ajoutez les 25 contrôleurs HTTP Request, laissez le champ " Server Name or IP " vide. Les contrôleurs hériteront de cette valeur de champ de l'élément HTTP Request Defaults.

Le gestionnaire d'en-têtes vous permet d'ajouter ou de remplacer les en-têtes de requête HTTP.

JMeter prend désormais en charge plusieurs gestionnaires d'en-tête . Les entrées d'en-tête sont fusionnées pour former la liste de l'échantillonneur. Si une entrée à fusionner correspond à un nom d'en-tête existant, elle remplace l'entrée précédente. Cela permet de configurer un ensemble d'en-têtes par défaut et d'appliquer des ajustements à des échantillonneurs particuliers. Notez qu'une valeur vide pour un en-tête ne supprime pas un en-tête existant, elle remplace simplement sa valeur.

Le composant Java Request Defaults vous permet de définir des valeurs par défaut pour les tests Java. Voir la requête Java .

L'élément Keystore Config vous permet de configurer la manière dont Keystore sera chargé et les clés qu'il utilisera. Ce composant est généralement utilisé dans les scénarios HTTPS où vous ne souhaitez pas prendre en compte l'initialisation du magasin de clés dans le temps de réponse.

Pour utiliser cet élément, vous devez d'abord configurer un Java Key Store avec les certificats clients que vous souhaitez tester, pour ce faire :

1. Créez vos certificats soit avec l'utilitaire Java keytool soit via votre PKI
2. Si elles sont créées par PKI, importez vos clés dans Java Key Store en les convertissant dans un format acceptable par JKS
3. Ensuite, référencez le fichier keystore via les deux propriétés JVM (ou ajoutez-les dans system.properties ):
   • -Djavax.net.ssl.keyStore=path_to_keystore
   • -Djavax.net.ssl.keyStorePassword=password_of_keystore

Pour utiliser PKCS11 comme source du magasin, vous devez définir javax.net.ssl.keyStoreType sur PKCS11 et javax.net.ssl.keyStore sur NONE .

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 qui utilisent le nom d'utilisateur et le mot de passe dans le cadre de leur configuration.

Le composant LDAP Request Defaults vous permet de définir des valeurs par défaut pour les tests LDAP. Voir la requête LDAP .

Le composant LDAP Extended Request Defaults vous permet de définir des valeurs par défaut pour les tests LDAP étendus. Voir la demande étendue LDAP .

La configuration de l'échantillonneur TCP fournit des données par défaut pour l'échantillonneur TCP

L'élément Variables définies par l'utilisateur vous permet de définir un ensemble initial de variables , comme dans le plan de test .

Les UDV ne doivent pas être utilisées avec des fonctions qui génèrent des résultats différents à chaque fois qu'elles sont appelées. Seul le résultat du premier appel de la fonction sera enregistré dans la variable. Cependant, les UDV peuvent être utilisés avec des fonctions telles que __P() , par exemple :

HÔTE ${__P(hôte,hôte local)}

qui définirait la variable " HOST " pour avoir la valeur de la propriété JMeter " host ", par défaut à " localhost " si elle n'est pas définie.

Pour définir des variables lors d'une exécution de test, voir Paramètres utilisateur . Les UDV sont traitées dans l'ordre dans lequel elles apparaissent dans le plan, de haut en bas.

Pour plus de simplicité, il est suggéré que les UDV soient placés uniquement au début d'un groupe de threads (ou peut-être sous le plan de test lui-même).

Une fois que le plan de test et tous les UDV ont été traités, l'ensemble de variables résultant est copié dans chaque thread pour fournir l'ensemble initial de variables.

Si un élément d'exécution tel qu'un préprocesseur de paramètres utilisateur ou un extracteur d'expressions régulières définit une variable portant le même nom que l'une des variables UDV, cela remplacera la valeur initiale et tous les autres éléments de test du thread verront la mise à jour. évaluer.

L'élément de configuration de variable aléatoire est utilisé pour générer des chaînes numériques aléatoires et les stocker dans une variable pour une utilisation ultérieure. C'est plus simple que d'utiliser des variables définies par l'utilisateur avec la fonction __Random() .

La variable de sortie est construite à l'aide du générateur de nombres aléatoires, puis le nombre résultant est formaté à l'aide de la chaîne de format. Le nombre est calculé à l'aide de la formule minimum+Random.nextInt(maximum-minimum+1) . Random.nextInt() nécessite un entier positif. Cela signifie que maximum-minimum - c'est-à-dire la plage - doit être inférieur à 2147483647 , mais les valeurs minimale et maximale peuvent être des valeurs longues tant que la plage est correcte.

Permet à l'utilisateur de créer un compteur qui peut être référencé n'importe où dans le groupe de threads. La configuration du compteur permet à l'utilisateur de configurer un point de départ, un maximum et l'incrément. Le compteur bouclera du début au maximum, puis recommencera avec le début, continuant ainsi jusqu'à la fin du test.

Le compteur utilise un long pour stocker la valeur, donc la plage est de -2^63 à 2^63-1 .

L'élément de configuration simple vous permet d'ajouter ou de remplacer des valeurs arbitraires dans les échantillonneurs. Vous pouvez choisir le nom de la valeur et la valeur elle-même. Bien que certains utilisateurs aventureux puissent trouver une utilisation pour cet élément, il est principalement destiné aux développeurs en tant qu'interface graphique de base qu'ils peuvent utiliser lors du développement de nouveaux composants JMeter.

Vous pouvez ensuite accéder à l'objet com.mongodb.DB dans Beanshell ou JSR223 Test Elements via l'élément MongoDBHolder en utilisant ce code

importer com.mongodb.DB ;
importer org.apache.jmeter.protocol.mongodb.config.MongoDBHolder ;
DB db = MongoDBHolder.getDBFromSource("valeur de la propriété MongoDB Source",
            "valeur de la propriété Nom de la base de données");
…
    

Le panneau de contrôle d'assertion de réponse vous permet d'ajouter des chaînes de modèle à comparer à divers champs de la demande ou de la réponse. Les chaînes de modèle sont :

• Contient , Correspond aux expressions régulières de style Perl5
• Equals , Substring : texte brut, sensible à la casse

Un résumé des caractères de correspondance de modèle peut être trouvé dans les expressions régulières ORO Perl5.

Vous pouvez également choisir si les chaînes doivent correspondre à l'intégralité de la réponse ou si la réponse ne doit contenir que le modèle. Vous pouvez attacher plusieurs assertions à n'importe quel contrôleur pour plus de flexibilité.

Notez que la chaîne de modèle ne doit pas inclure les délimiteurs englobants, c'est-à-dire utiliser Price: \d+ et non /Price: \d+/ .

Par défaut, le modèle est en mode multi-ligne, ce qui signifie que le méta-caractère " . " ne correspond pas à la nouvelle ligne. En mode multiligne, " ^ " et " $ " correspondent au début ou à la fin de n'importe quelle ligne n'importe où dans la chaîne - pas seulement au début et à la fin de la chaîne entière. Notez que \s correspond à la nouvelle ligne. Le cas est également significatif. Pour remplacer ces paramètres, on peut utiliser la syntaxe d'expression régulière étendue . Par exemple:

(?je)

ignorer la casse

(?s)

traiter la cible comme une seule ligne, c'est-à-dire " . " correspond à une nouvelle ligne

(?est)

les deux ci-dessus

(?i) tarte aux pommes (?-i)

correspond à « AppLe Pie », mais pas à « AppLe Pie »

(?s)Pomme.+?Tarte

correspond à Apple suivi de Pie , qui peut se trouver sur une ligne suivante.

Pomme(?s).+?Tarte

comme ci-dessus, mais il est probablement plus clair d'utiliser le (?s) au début.

L'assertion de durée teste que chaque réponse a été reçue dans un laps de temps donné. Toute réponse qui prend plus de temps que le nombre de millisecondes donné (spécifié par l'utilisateur) est marquée comme une réponse ayant échoué.

L'assertion de taille teste que chaque réponse contient le bon nombre d'octets. Vous pouvez spécifier que la taille soit égale, supérieure, inférieure ou différente d'un nombre d'octets donné.

L'assertion XML vérifie que les données de réponse consistent en un document XML formellement correct. Il ne valide pas le XML basé sur une DTD ou un schéma et n'effectue aucune autre validation.

L'assertion BeanShell permet à l'utilisateur d'effectuer une vérification d'assertion à l'aide d'un script BeanShell.

Pour plus de détails sur l'utilisation de BeanShell, veuillez consulter le site Web de BeanShell.

Notez qu'un interpréteur différent est utilisé pour chaque occurrence indépendante de l'assertion dans chaque thread d'un script de test, mais le même interpréteur est utilisé pour les invocations suivantes. Cela signifie que les variables persistent à travers les appels à l'assertion.

Toutes les assertions sont appelées à partir du même thread que l'échantillonneur.

Si la propriété " beanshell.assertion.init " est définie, elle est transmise à l'interpréteur en tant que nom d'un fichier sourcé. Cela peut être utilisé pour définir des méthodes et des variables communes. Il existe un exemple de fichier init dans le répertoire bin : BeanShellAssertion.bshrc

L'élément de test prend en charge les méthodes ThreadListener et TestListener . Ceux-ci doivent être définis dans le fichier d'initialisation. Voir le fichier BeanShellListeners.bshrc pour des exemples de définitions.

L'assertion MD5Hex permet à l'utilisateur de vérifier le hachage MD5 des données de réponse.

L'assertion HTML permet à l'utilisateur de vérifier la syntaxe HTML des données de réponse à l'aide de JTidy.

L'assertion XPath teste la bonne formation d'un document, a la possibilité de valider par rapport à une DTD ou de placer le document via JTidy et de tester un XPath. Si ce XPath existe, l'assertion est vraie. L'utilisation de " / " correspondra à tout document bien formé et constitue l'expression XPath par défaut. L'assertion prend également en charge les expressions booléennes, telles que " count(//*error)=2 ". Voir http://www.w3.org/TR/xpath pour plus d'informations sur XPath.

• //title[text()='Text to match'] - correspond à <title>Text to match</title> n'importe où dans la réponse
• /title[text()='Text to match'] - correspond à <title>Text to match</title> au niveau racine dans la réponse

L'assertion XPath2 teste la bonne formation d'un document. L'utilisation de " / " correspondra à tout document bien formé et constitue l'expression XPath2 par défaut. L'assertion prend également en charge les expressions booléennes, telles que " count(//*error)=2 ".

• //title[text()='Text to match'] - correspond à <title>Text to match</title> n'importe où dans la réponse
• /title[text()='Text to match'] - correspond à <title>Text to match</title> au niveau racine dans la réponse

L'assertion de schéma XML permet à l'utilisateur de valider une réponse par rapport à un schéma XML.

L'assertion JSR223 permet d'utiliser le code de script JSR223 pour vérifier l'état de l'échantillon précédent.

• bcmail-xxx.jar (SMIME/CMS de BouncyCastle)
• bcprov-xxx.jar (Fournisseur BouncyCastle)

Si vous utilisez l' échantillonneur de lecteur de courrier , assurez-vous de sélectionner « Stocker le message à l'aide de MIME (brut) », sinon l'assertion ne pourra pas traiter le message correctement.