...
| Sommaire |
|---|
Installer Jmeter
https://jmeter.apache.org/download_jmeter.cgi
...
| Bloc de code |
|---|
jmeter -n -t my_test.jmx -l log.jtl |
Le
...
plan de test
Le script plan de test est un fichier JMeter (extension .jmx) contient plusieurs scénarios créés par enregistrement d'une navigation. JMeter de test et les paramétrages qui permettent de les lancer. Un scénario est une suite de requêtes lancées par l'outil. Pour bâtir ces scénarios JMeter permet d'enregistrer une navigation web et se comporte alors comme un serveur proxy et enregistre toutes les requêtes appelée https://jmeter.apache.org/usermanual/get-started.html#template
Le plan de test fournit propose plusieurs scénarios :
- Navigation anonyme, c'est à dire une navigation sans authentification
- Authentification, c'est à dire affichage de la page d'accueil puis authentification
- Accès à l'emploi du temps, c'est à dire authentification puis accès au service "Emploi du temps"
- Navigation authentifiée, c'est à dire authentification puis accès à plusieurs services
Configuration
Le plan de test se configure dans le composant User Defined Variables grâce aux variables suivantes :
- host : Adresse de la PWA
- host-back : Adresse du back-end
- scheme : http/https
- user : Identifiant
- password : Mot de passe
- authToken : token obtenu après authentification. Il est renseigné par le script (voir le paragraphe dédié à l'authentification)
- serviceTicket : Service Ticket CAS. Il est renseigné par le script (voir le paragraphe dédié à l'authentification)
- currentDate : forcer une date du jour pour avoir des données significatives pour les emplois du temps. (voir le paragraphe dédié au test de l'EDT)
- asUser : login d'un utilisateur à forcer pour les EDT.(voir le paragraphe dédié au test de l'EDT)
- host-directus Adresse du CMS Headless pour récupérer les assets directement
- directus-key : Clé du CMS Headless (ne sert pas ?)
- user-file : Fichier csv qui liste des identifiants utilisateurs pour tester la charge avec des utilisateurs différents (voir le paragraphe dédié à l'utilisation d'un fichier de logins)
- log-root : Chemin où seront déversés les logs
L'authentification
Pour jouer l'authentification l'appel de la route /auth dans les scripts on force dans le body de la requête l'utilisation du ${user} et ${password}
| Bloc de code |
|---|
{"username":"${user}","password":"${password}"} |
Ensuite l'utilisation d'un composant JSON Extractor permet d'extraire de TGT CAS reçu en retour et de le positionner dans la variable ${authToken}
On peut utiliser ce TGT pour demander des ST CAS (afin d'éviter à un utilisateur de se ré-authentifier lorsqu'il est redirigé vers un service CAS) en appelant la route /sso-service-token
| Bloc de code |
|---|
{"service":"${scheme}://mdw.univ-lorraine.fr/login/cas","authToken":"${authToken}"} |
Ensuite l'utilisation d'un composant Regular Expression Extractor permet d'extraire de ST CAS reçu en retour et de le positionner dans la variable ${serviceTicket}
On peut enfin rédiriger vers le service en utilisant la variable ${serviceTicket} comme dans l'exemple suivant
Test de l'emploi du temps
Le service emploi du temps s'appelle sur la route /schedule.
Pour permettre des tests de charge représentatifs des paramêtres ont été ajouté. On peut donc passer en POST le body suivant
| Bloc de code |
|---|
{"authToken":"${authToken}","startDate":"${startDate}","endDate":"${endDate}","asUser":"${asUser}"} |
où ${startDate} et ${endDate} permettent de positionner une dans de début et une date de fin et où ${asUser} permet d'indiquer l'identifiant d'un autre utilisateur que celui connecté.
${asUser} est indiqué dans les User Defined Variables et les ${startDate} et ${endDate} sont calculées à partir de ${currentDate} également déclaré dans User Defined Variables grâce au script Pré-Processeur BeanShell situé à la racine du projet.
Ce script propose d'autres variables comme ${schedulStarMonth} et ${schedulEndMonth} qui peuvent être utilisée pour tester la vue "mois" et des ${scheduleStartDatePlusx} pour tester la navigation dans l'EDT.
| Développer | ||
|---|---|---|
| ||
|
Utilisation d'un fichier de logins
Pour faire des tests de charge réalistes avec des utilisateurs différents il est possible d'utiliser un fichier CSV qui contiendra une liste de login. Dans l'exemple fournit ces comptes doivent avoir un mot de passe identique mais il est possible de l'adapter pour utiliser un fichier contenant login et mot de passe.
Le chemin vers le fichier doit être indiqué dans la variable ${user-file} de User Defined Variables
Ensuite il faut activer le composant CSV Data Set Config situé à la racine du projet JMeter
Dans cet exemple, les valeurs de login trouvées dans le CSV surchargeront la variable ${user} et écraseront la valeur positionnée dansUser Defined Variables
Si on voulait également insérer les mot de passe via le fichier CSV il faudrait mettre une seconde colonne et "user, password" dans le champs Variable Names.
Lancement d'un test
Pour lancer un test, activer (clique droit Enable) le composant Thread Group correspondant.
Les paramétrages du test se trouvent à ce niveau et se configurent comme suit :
Pour plus d'explication :
https://jmeter.apache.org/usermanual/component_reference.html#Thread_Group
https://dev.to/rusydy/thread-group-in-jmeter-understanding-its-components-and-use-cases-42be
Lancer le test à l'aide du bouton "Play" situé dans la barre supérieur
Les résultats s'afficheront dans les composants :
- Summary Report : Rapport consolidé
- Agregate Graph : Graphique agrégé
- Graph Results : Graphique de résultats
Pour aller plus loin...
... et créer ou compléter le script.
...




