detail description jmeter components
Examen des composants Jmeter (Partie-II):
=> Ceci fait partie de la série de formation JMeter. Consultez la liste de tous les tutoriels de cette série ici .
J'espère que vous avez tous dû traverser Introduction et installation de JMeter maintenant. Alors que nous continuons avec le suivant de la série, il est fortement recommandé que vous deviez tous installer JMeter et vous entraîner côte à côte.
Dans ce didacticiel, les lecteurs se familiariseraient avec tous les composants de JMeter et comment les utiliser dans le plan de test pour couvrir tous les scénarios de test de performance possibles pour tester l'AUT (Application Under Test).
Les éléments de Jmeter avaient été répertoriés dans l'article précédent.
Ce que vous apprendrez:
- Composants de JMeter
Composants de JMeter
Rédigez à nouveau pour votre référence:
- Plan de test
- ThreadGroup
- Échantillonneurs
- Les auditeurs
- Table de travail
- Assertions
- Élément de configuration
- Contrôleurs logiques
- Minuteur
Tous les principaux composants de Jmeter tels que le groupe de threads, les échantillonneurs, les écouteurs et les éléments de configuration sont expliqués en détail plus loin dans l'article.
Veuillez vous référer au diagramme ci-dessous pour comprendre chaque composant et leur relation avec des modules spécifiques de JMeter.
Nous allons maintenant commencer à toucher chaque composant de Jmeter avec des cas d'utilisation juste pour savoir comment cela fonctionne et comment les testeurs peuvent les implémenter dans leurs tests. Veuillez noter que nous ne couvrirons pas tous les échantillonneurs, auditeurs dans cet article. Nous travaillerons sur les plus utilisés et prendrons du repos dans le prochain article lorsque nous créerons des plans de test en temps réel.
Plan de test
Tout comme un simple plan de test dans Software Testing comprend toutes les étapes qui exécutent le script, le plan de test de JMeter a le même objectif. Tout ce qui est inclus dans un plan de test est exécuté dans une séquence qui est de haut en bas ou selon la séquence définie dans le plan de test.
Le plan de test peut être aussi simple que possible, avec Just ThreadGroup, Sampler et Listener et cela commence à devenir plus complexe dès que vous commencez à ajouter plus d'éléments comme des éléments de configuration, des préprocesseurs ou des contrôleurs.
Comme nous le savons tous, JMeter mesure les performances en générant des utilisateurs virtuels ou des threads qui atteignent le serveur testé comme si de vrais utilisateurs envoyaient des requêtes à un serveur. Par conséquent, chaque plan de test doit avoir des utilisateurs virtuels ou un groupe de threads comme nous les appelons dans les termes de JMeter.
Points importants sur le plan de test:
- Le plan de test doit être enregistré avant l'exécution
- Les fichiers Jmeter ou les plans de test sont enregistrés sous la forme de. Fichiers d'extension JMX
- Vous pouvez également enregistrer des parties du plan de test en tant que sélection différente. Par exemple, Si vous souhaitez enregistrer l'échantillonneur de requête HTTP avec l'écouteur, vous pouvez l'enregistrer en tant que fragment de test afin qu'il puisse également être utilisé dans d'autres scénarios de test.
- Les éléments de WorkBench ne sont pas enregistrés avec le plan de test
Groupe de threads
Thread Group est un groupe d'utilisateurs qui frapperont le serveur testé simultanément ou selon une séquence prédéfinie. Le groupe de threads peut être ajouté au plan de test en cliquant avec le bouton droit sur le plan de test. JMeter est tout 'un clic droit', vous obtenez toutes les options sur le clic droit.
Vous pouvez renommer le nom du groupe de threads en votre nom. Changez simplement le nom et cliquez n'importe où en dehors de la fenêtre Plan de test, vous verriez le nom changer.
Veuillez voir la capture d'écran ci-dessous pour ajouter des groupes de threads
(Remarque: Cliquez sur n'importe quelle image pour une vue agrandie)
Il est très important de configurer votre groupe de threads selon les conditions de test.
Par exemple, si vous souhaitez tester le comportement d'un serveur Web lorsque 100 utilisateurs le rencontrent simultanément, vous pouvez définir le groupe de threads comme suit:
Fondamentalement, il existe trois paramètres principaux qui doivent être configurés pour générer une charge réelle ou des utilisateurs virtuels:
- Nombre de threads (utilisateurs) - Il définit le nombre d'utilisateurs virtuels. À des fins de test, nous ne devrions générer qu'une quantité limitée de charge car générer un volume énorme à la fois signifierait consommer beaucoup de threads, ce qui peut finalement conduire à une utilisation élevée du processeur.
- Période de montée en puissance - Ce champ est très important pour contrôler la génération de charge. La période de montée en puissance a défini la durée pendant laquelle la charge totale sera générée.
Exemple 1:
- Cela signifie que les 10 utilisateurs toucheront les serveurs simultanément dès qu'un test est exécuté
Exemple 2:
- Vous devez tous avoir remarqué la case à cocher 'Planificateur' dans la capture d'écran ci-dessus. Si vous souhaitez que votre test s'exécute à une heure précise plus tard, vous pouvez définir les horaires comme vous pouvez également le voir dans la capture d'écran ci-dessous. Cela signifie que toutes les 1 s, un nouvel utilisateur frappera le serveur. Le chargement ne sera pas simultané mais sera par incréments. Par le 10edeuxièmement, tous les utilisateurs auraient répondu à la demande.
- Nombre de boucles - Il définit le nombre d'exécutions du groupe de threads. Si vous cochez la case Forever, votre test s'exécutera indéfiniment, sauf si vous l'arrêtez manuellement. Cela peut être utilisé pour tester quelque chose comme 'Si votre serveur ne plante pas en charge continue pendant quelques minutes'.
Échantillonneurs
Alors, comment un Jmeter sait-il quel type de requête a été envoyé au serveur ???
- C'est via Samplers. Les échantillonneurs sont indispensables à ajouter à un plan de test, car il est le seul à pouvoir indiquer à Jmeter quel type de requête doit aller à quel serveur et avec des paramètres prédéfinis ou non. Les demandes peuvent être HTTP, HTTP (s), FTP, TCP, SMTP, SOAP, etc.
Les échantillonneurs ne peuvent être ajoutés au groupe de threads pas directement sous le plan de test, car les groupes de threads doivent utiliser un échantillonneur pour envoyer une demande à l'URL du serveur sous test. L'échantillonneur peut être ajouté par chemin Groupe de threads -> Sampler -> Requête HTTP.
convertir youtube en fichier wav gratuitement
Requêtes HTTP
Ce sont les requêtes les plus courantes envoyées aux serveurs. Dire, par exemple, nous voulons que 100 utilisateurs frappent https://www.google.com simultanément, cela peut être fait comme décrit dans la capture d'écran ci-dessous:
- Le chemin est la navigation à l'intérieur du site Web principal. Par exemple, si nous voulons accéder à http://www.google.com/gmail, nous pouvons définir '/ Gmail' dans le chemin et le reste reste le même
- Il n'est pas nécessaire de taper «www» dans le nom du serveur
- Le numéro de port est utilisé si vous utilisez un serveur proxy
- Timeout Connect and Response peut être défini si vous souhaitez avoir une référence sur le temps de connexion et le temps de réponse de votre serveur. Votre demande échouera si votre serveur met plus de temps à envoyer une réponse que celle configurée
- Vous pouvez également configurer les paramètres à envoyer avec votre demande. Par exemple: Dans certains cas, vous devrez peut-être envoyer un jeton d'autorisation avec votre demande, vous les avez donc ajoutés dans la requête HTTP comme ci-dessous:
Demandes FTP
Chemin-> Plan de test-> Groupe de threads-> Échantillonneur-> Demande FTP
FTP signifie File Transfer Protocol et il est utilisé pour télécharger ou télécharger un fichier à partir du serveur. Les threads de JMeter envoient des demandes aux serveurs FTP pour télécharger ou télécharger des fichiers à partir de là et mesurent les performances.
- Le fichier local est l'emplacement où vous devez enregistrer le fichier téléchargé
- Utilisez l'option GET si vous téléchargez à partir d'un serveur FTP
- Option POST utilisateur si vous téléchargez un fichier sur un serveur FTP
Nous avons beaucoup d'auditeurs qui seront couverts lorsque nous passerons en revue de vrais plans de test comprenant des échantillonneurs, des écouteurs, des éléments de configuration, etc.
Les auditeurs
Donc, jusqu'à présent, nous avons vu peu d'échantillonneurs envoyer des requêtes au serveur mais n'ont pas encore analysé la réponse. Les tests de performances consistent à analyser les réponses du serveur sous diverses formes, puis à les présenter au client.
Les écouteurs sont utilisés pour afficher les résultats de l'exécution des tests afin que les testeurs apprennent à connaître les statistiques. Nous avons environ 15 écouteurs dans Jmeter, mais les plus utilisés sont les tables, les arbres et les graphiques.
Afficher les résultats dans le tableau:
C'est la forme d'auditeur la plus couramment utilisée et la plus facilement compréhensible. Il affiche le résultat sous forme de tableau avec quelques paramètres de performance importants.
Les auditeurs peuvent être ajoutés directement sous Plan de test ou sous un échantillonneur. La différence est que lorsque vous ajoutez un auditeur sous un échantillonneur, il affiche uniquement les résultats de cet échantillonneur. Si nous ajoutons un échantillonneur directement sous le plan de test, il affiche le résultat pour tous les échantillonneurs dans la hiérarchie.
La capture d'écran ci-dessous pour votre référence:
Vous voyez les résultats quelque chose comme affiché ci-dessous:
- Latence : C'est l'heure à laquelle la première information est reçue, c'est-à-dire que le premier octet de données est reçu
- Temps de connexion : C'est le temps nécessaire pour établir la connexion avec le serveur
- Temps d'échantillonnage : C'est le temps nécessaire pour recevoir des données complètes
- Échantillon - Séquence du numéro d'échantillon
- Octets - Taille des données reçues.
Afficher les résultats dans l'arborescence:
Il s'agit d'un autre écouteur le plus couramment utilisé et fournit des informations détaillées avec demande et réponse. On peut également afficher la page HTML rendue en réponse en dehors de l'affichage de Json, XML, Text, RegEx.
Il est très utile car les testeurs peuvent mettre des affirmations sur la réponse reçue pour s'assurer que le test a réussi. Les résultats Jmeter affichent toujours «Réussi» même si la réponse n'est pas souhaitée.
Par exemple: Dites, nous répondons à une requête HTTP sur n'importe quel site Web www.xyz.com et en réponse, nous attendons XYZ ou en termes simples, lorsque nous accédons à cette page, la page d'accueil de l'entreprise s'ouvre avec son nom. Si nous n'avons pas mis d'assertion, Jmeter affichera toujours les résultats puisque le hit est allé sur le serveur.
Veuillez voir ci-dessous pour connaître le format des résultats:
Pour afficher la page HTML en réponse, cliquez sur la liste déroulante dans le volet de gauche, puis sélectionnez «HTML», accédez à l'onglet de réponse et vérifiez la page qui est renvoyée en tant que réponse du serveur.
Table de travail
Un atelier est un endroit où vous pouvez stocker les éléments qui ne sont pas utilisés dans votre plan de test actuel mais qui peuvent y être copiés ultérieurement. Lorsque vous enregistrez le fichier JMeter, les composants présents dans l'atelier ne sont pas automatiquement enregistrés. Vous devez les enregistrer séparément en faisant un clic droit et choisissez l'option «Enregistrer sous».
Vous pensez peut-être tous à quoi sert Workbench, de toute façon, il est facile d’ajouter un composant directement à un plan de test Jmeter.
La raison d'avoir Workbench était que l'utilisateur pouvait faire des expériences et essayer de nouveaux scénarios. Comme nous le savons déjà, les éléments de Workbench ne sont pas enregistrés, de sorte qu'un utilisateur peut littéralement utiliser n'importe quoi, puis les jeter. Cependant, certains «composants non testés» ne sont disponibles que dans WorkBench.
Ils sont listés ici:
- Serveur miroir HTTP
- Enregistreur de script de test HTTP (s)
- Affichage de la propriété
L'enregistreur de script de test HTTP (s) est l'élément non-test le plus important utilisé dans JMeter. Il aide les testeurs à enregistrer le script, puis à configurer la charge pour chaque transaction.
Jmeter enregistre uniquement la demande envoyée au serveur. Ne vous méprenez pas avec la fonctionnalité «Enregistrer et lire» de QTP / Selenium. Toutes les requêtes sont enregistrées et les testeurs peuvent leur appliquer la charge souhaitée pour voir le comportement.
Cet élément est très important pour les scénarios où les testeurs ne savent pas ce que toutes les requêtes se produisent à partir de leur application. Ils peuvent utiliser l'enregistreur de script Http (s) pour enregistrer l'application en cours de test.
Les tests de performance des applications mobiles peuvent également être effectués de cette manière en configurant le proxy JMeter, puis en enregistrant les demandes que notre application mobile envoie au serveur. La procédure étape par étape pour les tests de performances mobiles sera expliquée dans le prochain article.
Assertions
Jusqu'à présent, nous avons couvert comment JMeter frappe le serveur et comment les réponses sont affichées via les écouteurs. Pour nous assurer que la réponse reçue est correcte et conforme aux attentes, nous devons ajouter des assertions. Les assertions sont simplement des validations que nous devons mettre sur les réponses pour comparer les résultats.
Voici les types d'assertions couramment utilisés:
- Assertion de réponse
- Assertion de durée
- Assertion de taille
- Assertion XML
- Assertion HTML
Assertion de réponse
Dans Assertion de réponse, nous pouvons ajouter nos propres chaînes de modèle, puis les comparer avec les réponses reçues d'un serveur. Par exemple, vous savez tous que le code de réponse est 200 lorsqu'une demande renvoie une réponse avec succès. Donc, si nous ajoutons la chaîne de modèle «Code de réponse = 202», le scénario de test devrait échouer.
Veuillez vous référer aux captures d'écran ci-dessous pour ajouter l'assertion du code de réponse.
Maintenant, lorsque le test s'exécute, il affiche le résultat avec une couleur rouge indiquant que les résultats d'assertion ont échoué.
Assertion de durée
L'assertion de durée est très importante et valide le fait que le serveur a répondu dans un laps de temps donné. Cela peut être utilisé dans des scénarios où nous devons échantillonner 100 demandes et nous assurer que chaque réponse est reçue dans la limite de référence.
Cas : 10 utilisateurs accèdent simultanément au serveur 'google.com' et l'assertion de durée est définie sur 1 000 ms.Veuillez consulter les captures d'écran ci-dessous:
L'assertion XML valide si les données de réponse contiennent un document XML correct et l'assertion HTML vérifie la syntaxe HTML de la réponse reçue d'un serveur.
Éléments de configuration
Les requêtes envoyées au serveur peuvent être davantage paramétrées à l'aide de certains éléments de configuration qui sont exécutés avant la requête réelle. Un exemple simple pourrait être la lecture des valeurs d'une variable à partir d'un fichier CSV pour lequel CSV Data Set Config est utilisé.
Vous trouverez ci-dessous certains des éléments de configuration importants utilisés dans les tests de performances des applications Web et mobiles
- Configuration de l'ensemble de données CSV.
- Variables définies par l'utilisateur
- Requêtes HTTPS par défaut
- Gestionnaire de cache HTTPS
- Gestionnaire de cookies HTTPS
Configuration de l'ensemble de données CSV
La configuration de l'ensemble de données CSV aide Jmeter à sélectionner les valeurs de certains paramètres à partir d'un fichier CSV plutôt que de transmettre des paramètres différents dans chaque requête distincte. Par exemple, si nous devons tester la fonctionnalité de connexion avec un ensemble différent d'utilisateurs et de mots de passe, nous pouvons créer deux colonnes dans un fichier CSV et y entrer les valeurs afin que JMeter puisse en choisir une pour chaque demande envoyée au serveur.
Vous trouverez ci-dessous le flux d'utilisation de l'ensemble de données CSV de la configuration pour tester l'API météo pour différentes villes de l'Inde.
- Ajout d'un élément de configuration d'ensemble de données CSV au plan de test
- Création d'un fichier CSV
- Passer la variable dans le paramètre de demande. Le paramètre APPID peut être généré dynamiquement à partir de http://openweathermap.org/appid
- Exécution du test et affichage des résultats.
Variables définies par l'utilisateur
Cela aide Jmeter à choisir des valeurs à partir d'une variable prédéfinie. Par exemple, prise en charge dont vous avez besoin pour créer un plan de test dans lequel vous devez ajouter de nombreuses requêtes HTTP sur la même URL et il peut y avoir un scénario dans lequel le client envisage de le migrer ultérieurement vers une URL différente.Ainsi, pour éviter de mettre à jour l'URL dans chaque requête nous pouvons dire à JMeter de choisir l'URL à partir d'un UDV (variable définie par l'utilisateur) qui peut être mis à jour ultérieurement pour gérer toutes les demandes d'URL mise à jour.
Ainsi, pour éviter de mettre à jour l'URL dans chaque demande, nous pouvons dire à JMeter de choisir l'URL à partir d'une UDV (variable définie par l'utilisateur) qui peut être mise à jour ultérieurement pour gérer toutes les demandes d'URL mise à jour.
Valeurs par défaut des requêtes HTTP
Cet élément de configuration est très utile pour spécifier les valeurs par défaut des requêtes https. Pour vous guider davantage, prenez un exemple où nous devons répondre à 50 requêtes différentes sur le serveur google.Dans ce scénario, si nous ajoutons une requête HTTP par défaut, nous n'avons pas besoin de spécifier un nom de serveur, un chemin ou toute autre propriété comme le numéro de port, la connexion propriétés de temporisation. Tout ce qui est spécifié dans l'élément de configuration par défaut de la requête HTTP est hérité par toutes les requêtes HTTP.
Dans ce scénario, si nous ajoutons une requête HTTP par défaut, nous n'avons pas besoin de spécifier un nom de serveur, un chemin d'accès ou d'autres propriétés telles que le numéro de port, les propriétés de délai de connexion. Tout ce qui est spécifié dans l'élément de configuration par défaut de la requête HTTP est hérité par toutes les requêtes HTTP.
Veuillez voir ci-dessous comment ajouter la requête HTTP par défaut et spécifier le serveur et le chemin.
Gestionnaire de cache HTTP et Gestionnaire de cookies HTTP sont utilisés pour faire en sorte que JMeter se comporte comme un navigateur en temps réel. Le gestionnaire de cache HTTP peut vider le cache après chaque requête tandis que l'autre peut gérer les paramètres des cookies.
Contrôleurs logiques et minuteries
Les contrôleurs logiques et les minuteries aident Jmeter à contrôler le flux des transactions. Les minuteries assurent le retard dans chaque thread si besoin de tester un serveur. Par exemple, si nous avons besoin d'une requête FTP pour attendre 5 secondes après la fin de la requête HTTP, nous pouvons y ajouter une minuterie.
Les contrôleurs logiques sont utilisés pour définir le flux de requêtes envoyées au serveur. Il peut également vous permettre de stocker les demandes pour chaque module séparément, telles que la connexion et la déconnexion.
Conclusion
À présent, vous devez tous vous être familiarisé avec les composants de JMeter et avoir essayé de l'utiliser et vous devez être confronté à des problèmes. Dans le prochain article, nous couvrirons certains scénarios de test de performance en temps réel couvrant le domaine de la mobilité afin que vous obteniez tous plus de connaissances pratiques sur JMeter.
Restez à l'écoute! L'article suivant vous aidera à gérer vos demandes ainsi qu'à analyser les résultats et à les comparer avec les benchmarks des tests de performance.
=>Continuer la lecture de la partie III: Processeurs et contrôleurs JMeter
=> Cliquez ici pour les didacticiels JMeter: La formation gratuite complète sur JMeter (20+ vidéos)
lecture recommandée
- Comment atteindre la corrélation JMeter avec l'exemple
- Plan de test Jmeter et WorkBench
- Travailler avec une requête FTP dans JMeter
- Top 5 des plugins JMeter et comment les utiliser (avec des exemples)
- Minuteries JMeter: Minuterie aléatoire constante, BeanShell et Guassian
- Utilisation des requêtes HTTP dans JMeter
- Contrôleurs Jmeter Partie 1
- Contrôleurs Jmeter Partie 2