Exécution du ordre #

Peut-être l’un des problèmes les plus courants dans JMeter est une insuffisance de connaissance de l’ordre d’exécution. C’est particulièrement vrai lorsque vous essayez d’obtenir des résultats spécifiques par thread ou groupe de threads. Tout d’abord, nous devons comprendre que JMeter exécute le plan de test ou la scénario séquentiellement, mais dans cette séquence, il existe un ordre et une hiérarchie respectés sous forme de arbre.

L’exécution peut être trouvée dans ce référentiel, section 3.9 et est la suivante :

1. Éléments de configuration
2. Pré-processeurs
3. Temps d’attente
4. Saisies
5. Post-processeurs (si la réponse est null)
6. Assertions (si la réponse est null)
7. Listeurs de réception (si la réponse est null)

1.- Éléments de configuration #

Cela signifie que d’abord toute élément de configuration à la niveau test plan ou test plan sera exécutée, et de manière similaire comme le séquence descend dans les niveaux inférieurs du tronc.

2. - Pré-processeurs #

Deuxièmement, les pré-processeurs seront exécutés, bien que ces soient souvent liés à un échantillon car ils agrandissent ou modifient sa portée.

3.- Temps #

Troisième, nous avons les temps, et je dédie une paragraphe entier à cela car il est très commun de trouver un plan de test avec plus d’un timer. Bien que ce soit possible ou possible de avoir plusieurs timers, il n’est pas recommandé de les avoir au même niveau. Si vous voulez que le timer affecte uniquement un sampler, celui-ci doit être en dessous de lui-même. Si une ou plusieurs timers sont au même niveau, ces temps s’ajouteront et pourraient sérieusement affecter vos résultats.

4.- Échantillons #

Dans la quatrième position, nous avons les échantillonneurs, et c’est là que commencent à se voir des résultats dans les récepteurs, puisque ces sont les demandes que nous envoyons aux serveurs en utilisant le protocole sélectionné.

5.- Post-Processeurs #

Dans la position cinquième se trouvent les post-processeurs. À partir de cette position, le sampler doit fournir des données d’output; si elles sont nulles, il est probable que le sampler échoue. Tous les extracteurs utilisés pour effectuer les corrélations se trouvent ici, car ils nécessitent des informations pour extraire les valeurs qui seront utilisées ultérieurement.

6.- Déclarations #

Une fois que les informations requises ont été extraitées, la sixième et dernière étape est exécutée : les déclarations. Ces sont utilisés pour valider la réponse reçue en recherchant des valeurs spécifiques dedans et y agir.

7.- Receivers #

Dans la septième et dernière position se trouvent les receveurs, où nous pouvons examiner les demandes et les réponses. Le plus utile des receveurs pour ce qui concerne cela est le vue du arbre de résultats.

C’est très important d’être familiarisé avec et de comprendre cette séquence d’exécution, car elle sera répétée à chaque niveau du tronc. Certaines composantes héritent leurs valeurs des niveaux inférieurs, comme les timers, qui impactent les samplers à tous leurs sous-niveaux, comme nous le voyons dans l’image suivante:

Dans le cas précédent, nous avons une seule timer à niveau de groupe thread, ce qui ne se produira pas uniquement pour les requêtes HTTP 1, 4, 5 et “Debug” et “JSR223”, il affectera également les requêtes HTTP 2 et 3 situées dans “Transaction Controller”. C’est facile de vérifier cela car nous pouvons voir la durée totale d’exécution qui est de 36 secondes, et la timer a été configuré à 5 secondes, ce qui a été activé par les 7 simulateurs donnant une durée totale de 35 secondes de retard + 1 seconde de temps de réponse.

Aucune fois que vous avez plusieurs sous-niveaux, les timers continueront toujours d’adopter leurs valeurs. Deux exemples supplémentaires d’inherited serait le HTTP Header Manager et le HTTP Request Defaults. Dans le cas du header manager, nous pourrions placer un seul composant à niveau de test plan qui affecterait tous les groupes thread, ce qui utiliserait une seule valeur “User-Agent” pour toutes les requêtes HTTP ou HTTPS. De même, la requête par défaut remplace les valeurs de protocole et/ou IP adresse et/ou nom du serveur et/ou port que seront utilisées dans toutes les requêtes HTTP, si elles sont vides dans les simulateurs HTTP.

Dans l’avenir, je créerai un article spécifique pour discuter en détail les avantages de l’utilisation d’inherited dans une approche plus détaillée, surtout pour la réutilisation des scénarios dans différents environnements de tests.