esup-multi

Arborescence des pages

Comparaison des versions

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.

...

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}

Image Added

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}

Image Added

On peut enfin rédiriger vers le service en utilisant la variable ${serviceTicket} comme dans l'exemple suivant

Image Added

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}"}

${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
titleVoir le script
Bloc de code
import java.text.SimpleDateFormat;
import java.text.DateFormat;
import java.util.Calendar;


SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");

String currentDateStr = vars.get("currentDate");
Date currentDate = null;

if (currentDateStr == null || "".equals(currentDateStr)) {
	currentDate = new Date();
	vars.put("currentDate", sdf.format(currentDate));
} else {
	currentDate = sdf.parse(currentDateStr);
}

Calendar calendar = Calendar.getInstance();  
calendar.setTime(currentDate);

calendar.set(Calendar.DAY_OF_WEEK, calendar.getFirstDayOfWeek());
vars.put("scheduleStartDate", sdf.format(calendar.getTime()));

calendar.add(Calendar.DATE, 6);
vars.put("scheduleEndDate", sdf.format(calendar.getTime()));

calendar.add(Calendar.DATE, 1);
vars.put("scheduleStartDatePlus1", sdf.format(calendar.getTime()));

calendar.add(Calendar.DATE, 6);
vars.put("scheduleEndDatePlus1", sdf.format(calendar.getTime()));

calendar.add(Calendar.DATE, 1);
vars.put("scheduleStartDatePlus2", sdf.format(calendar.getTime()));

calendar.add(Calendar.DATE, 6);
vars.put("scheduleEndDatePlus2", sdf.format(calendar.getTime()));

calendar.add(Calendar.DATE, 1);
vars.put("scheduleStartDatePlus3", sdf.format(calendar.getTime()));

calendar.add(Calendar.DATE, 6);
vars.put("scheduleEndDatePlus3", sdf.format(calendar.getTime()));

calendar.add(Calendar.DATE, 1);
vars.put("scheduleStartDatePlus4", sdf.format(calendar.getTime()));

calendar.add(Calendar.DATE, 6);
vars.put("scheduleEndDatePlus4", sdf.format(calendar.getTime()));

calendar.setTime(currentDate);
calendar.set(Calendar.DATE, calendar.getActualMinimum(Calendar.DATE));
vars.put("scheduleStartMonth", sdf.format(calendar.getTime()));

calendar.set(Calendar.DATE, calendar.getActualMaximum(Calendar.DATE));
vars.put("scheduleEndMonth", sdf.format(calendar.getTime()));


calendar.setTime(currentDate);
calendar.add(Calendar.DATE, -12);
vars.put("startDate", sdf.format(calendar.getTime()));

calendar.setTime(currentDate);
calendar.add(Calendar.DATE, 9);
vars.put("endDate", sdf.format(calendar.getTime()));


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

Image Added

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 :

Image Added

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.

...