Commençons par le plan de test : très simple, une requête avec en élément fils un extracteur d’expression régulière.

La requête HTTP est simplement la page d’accueil de ce blog.

On place un échantillon Débogage après la requête HTTP qui possède l’extracteur d’expression régulière, il permet d’afficher différentes informations internes à JMeter. Ici, on s’intéresse aux valeurs des variables de JMeter.

Ensuite (enfin) vient l’extracteur d’expression régulière, on commence par un « simple ».

Quelques explications :

• Champs réponse à cocher : Corps. La portée de l’extracteur regexp sera le corps de la réponse (le texte html en général)
• Nom de référence : le nom de la variable dans laquelle JMeter va déposer les données récupérée par l’expression régulière
• Expression régulière : ici « (milamber) », qui signifie : « je recherche le mot milamber, et je voudrais récupérer la valeur ». Il n’y a pas à proprement parler d’expression régulière ici, car aucun caractères de correspondance de caractères n’est utilisé (par exemple « * »).
• Canevas : $1$ correspondant au premier « couple » de parenthèses dans l’expression régulière. Donc ici « milamber »
• Correspond au num. : 0. Parmi « tous les milamber » qui vont être trouvés, JMeter en choisi un au hasard et le place dans la variable JMeter NOM_VARIABLE
• Valeur par défaut : correspond à la valeur que va prendre la variable NOM_VARIABLE si jamais l’expression régulière n’est pas trouvée (autrement si il n’y a pas de milamber dans le corps de la réponse)

On exécute (on lance) le test JMeter. Avec le récepteur Arbre de résultats, on peut déjà voir les données de réponse de la page d’accueil de ce site. On voit qu’il y a plusieurs occurrences de « milamber ».

Dans l’échantillon Débogage, dans l’onglet Données de réponse, on retrouve la variable NOM_VARIABLE.

Quelques explications sur les différents « NOM_VARIABLExxx » que l’on trouve.

• NOM_VARIABLE=milamber, correspond bien entendu à la valeur recherchée (et donc trouvée par JMeter) à partir de l’expression régulière
• NOM_VARIABLE_g=1, c’est le nombre de variables $x$ trouvées
• NOM_VARIABLE_g0=milamber, c’est la chaine correspondant à l’expression régulière entière
• NOM_VARIABLE_g1=milamber, correspond à ce qu’a trouvée l’expression régulière dans la partie entre parenthèses

Ici, la variable NOM_VARIABLE_g0 est la même que NOM_VARIABLE_g1 car l’expression régulière est (milamber), et est très simple. Dans le dernier exemple de ce billet, ce n’est pas le cas, voir plus bas.

Changeons l’expression régulière en mettant simplement un M majuscule à Milamber :

Le résultat dans l’échantillon Débogage, c’est « Milamber » en majuscule. Donc l’extracteur d’expression régulière est sensible à la casse.

Changeons l’expression régulière par (Milember), donc volontairement avec une faute.

Ici, comme il n’y a pas de mot Milember dans les données de réponse de la page HTML retournée, la valeur de NOM_VARIABLE est la valeur par défaut (ici le message d’erreur).

Revenons à (milamber) comme expression régulière. Comme je sais qu’il y a plusieurs « milamber » dans la page HTML, et que j’aimerais bien tous les retrouver, on change la valeur du champ Correspond au num par « -1 ». Cette valeur va indiquer à JMeter d’aller chercher toutes les occurrences de l’expression régulière.

Dans la vue données de réponses de l’échantillon Débogage, on a maintenant une suite de NOM_VARIABLE_x où x correspond au numéro de « milamber » trouvé. La variable NOM_VARIABLE se retrouve avec la valeur par défaut.

Quand on regarde à la fin des variables affichées par l’echantillon Débogage, on trouve une variable spéciale NOM_VARIABLE_matchNr = 195. Ce dernier correspond au nombre de « milamber » trouvé.

On a vu que l’extracteur d’expression régulière était sensible à la casse. Pour le rendre « insensible », il suffit de faire précéder l’expression régulière par « (?i) ».

Dans la liste des variables trouvées, on a maintenant à la fois des « milamber » et des « Milamber ».

La dernière expression régulière va indiquer que l’on recherche exclusivement les « milamber » suivi de quelque chose et suivi de « .net ». C’est à dire les milamber dans « milamberspace.net ».

Le « quelque chose » est symbolisé par « .+ »

Le suivi de « .net » est symbolisé par « ?\.net » où la barre oblique inversée (l’anti-slash) sert à désactiver la propriété particulière du point dans une expression régulière.

Dans les résultats, on a donc que les « milamber » dans la chaîne « milamberspace.net ».

Voici pour ce billet montrant quelques cas d’utilisation de l’extracteur d’expression régulière. Bien entendu, ce dernier n’est pas limité à ces cas, il ne tient qu’à vous de faire de belles expressions régulières pour extraire des chaînes à partir des réponses à vos requêtes.

Bonnes regexps !

Deux liens :

• La page du manuel JMeter sur l’extracteur d’expression régulière
• La page du manuel JMeter sur les expressions régulières

./

En effet, vous pouvez avoir l’idée ou l’envie de faire une série de test en jouant sur certains paramètres de votre scénario JMeter, le tout en ligne de commande. Par exemple, faire un test avec 1 utilisateur, puis le même test avec 10 utilisateurs, et le même avec 100 utilisateurs.

Bien évidemment vous pouvez les lancer depuis l’interface graphique de JMeter, à la suite, tout en modifiant le paramètre du nombre d’utilisateurs dans l’interface, mais c’est trop facile .

Donc pour le faire en ligne de commande, il faut d’abord passer par l’interface graphique JMeter. En effet, nous avons besoin d’utiliser une fonction JMeter qui va permettre de lire une propriété JMeter et renvoyer sa valeur. Cette fonction doit être appelée à la place de la valeur du champ correspondant au paramètre que l’on veut rendre « paramétrable »…

Le mieux est d’abord de voir la capture d’écran :

Les différents ${__P(xxx,yyy)} correspondent à notre fonction JMeter qui permet de lire une propriété JMeter, et qui la renvoie.

Donc ici, on vient d’utiliser la fonction __P() (avec deux caractères soulignés avant le P) pour définir trois paramètres :

• Le nombre d’unités d’exécution, qui prend soit la valeur de la variable JMeter nombreUnites ou si elle est inexistante, la valeur par défaut « 10 »
• La durée de montée en charge, qui prend soit la valeur de la variable JMeter dureeMontee ou si elle est inexistante, la valeur par défaut « 50 »
• La nombre d’itérations, qui prend soit la valeur de la variable JMeter nombreIterations ou si elle est inexistante, la valeur par défaut « 100 »

Comme vous l’aurez compris, la fonction __P() a deux paramètres, le premier pour indiquer la clé de la propriété à rechercher, lire et renvoyer, et le second (optionnel) étant la valeur par défaut si la clé n’existe pas.

Une fois que vous avez défini ainsi les différents champs que vous souhaitez « paramètriser », il ne reste plus qu’a lancer JMeter en ligne de commande avec la ou les valeurs.

Pour cela, on utilise l’option « -J » de JMeter. Celle-ci permet de définir un couple clé/valeur correspondant à une propriété JMeter. Pour notre exemple, la ligne de commande sera donc :

jmeter -n -l resultats.csv -t scenario.jmx -JnombreUnites=5 -JdureeMontee=10 -JnombreIterations=100

(Petit rappel : -n : mode non-gui, -l : fichier de résultats, -t : fichier scripts JMeter)

Voilà, maintenant vous pouvez jouer sur les valeurs de ces paramètres afin de faire plusieurs types de tests.

Plus d’infos sur les fonctions, voici la page réservée aux fonctions du manuel JMeter

./

Ce tutoriel a pour objectifs :

1. Rappeler l’utilisation de Requête JDBC pour accéder à une base de données, et récupérer dans un ensemble de variables les résultats de requête JDBC
2. Montrer comment effectuer l’ajout d’une fiche Utilisateur dans un serveur LDAP via une Requête LDAP étendue de JMeter
3. Montrer le fonctionnement du Contrôleur Pour chaque dans JMeter
4. Montrer un petit exemple de Pré-Processeur BeanShell

Voici le plan de de test final.

On observe deux sections :

1. Base de données : qui est un Contrôleur Simple regroupant les éléments nécessaires à la partie JDBC afin d’accéder à la base et faire la requête SQL qui va permettre de récupérer les utilisateurs à créer.
2. LDAP : qui est aussi un Contrôleur Simple regroupant les éléments permettant la connexion au serveur LDAP et effectuer la requête d’ajout dans le LDAP des utilisateurs.

Concernant la partie Base de données, je vous revois vers ce billet pour avoir plus de détails sur sa mise en place. Ci-dessous, je vais seulement commenter certains éléments de cette partie.

L’élément Requête JDBC correspond à la requête SQL que JMeter va effectuer pour obtenir une liste de noms et de prénoms qui seront utilisés dans la section LDAP.

• Le champ Nom de liaison fait référence au ‘pool’ JDBC configuré dans l’élément Configuration de connexion JDBC
• Le type de requête est Select Statement, on fait donc une requête SQL commençant par SELECT :
  • SELECT ID, NOM, PRENOM from BOXERS
• Dans le champ Noms des variables, on donne les variables (JMeter) qui vont recevoir les données. Pour nous, cela sera VAR_ID, VAR_NOM, VAR_PRENOM.

A l’exécution, la requête SQL retournera une liste de noms et les placera dans les variables correspondantes, avec un suffixe _X où X est le numéro de la ligne retournée.

Pour la section suivante, LDAP, on utilisera donc ces variables pour faire l’ajout dans le LDAP.

Ainsi voici la partie LDAP : le premier élément est une Requête LDAP étendue qui va permettre de faire la connexion avec le serveur LDAP.

Pour cela, on choisi le type de test « Unité liée », et on complète les différents champs nécessaires :

• Nom du serveur (ou adresse IP)
• Port : 389 (correspondant au port par défaut pour le protocole ldap)
• DN : nom du suffixe de l’annuaire
• Identifiant : un compte disposant des droits pour modifier l’annuaire (ici c’est l’administrateur LDAP)
• Mot de passe associé au compte ci-dessus
• Délai d’attente de connexion : paramètre optionnel qui permet de faire échouer l’échantillon (de connexion) si jamais la connexion n’est pas ouverte
• La case à cocher permet de faire une connexion via le protocole LDAPS (via SSL donc) (accompagné par le port 636 en général)

Ensuite, on en profite pour faire l’opération inverse de la connexion : la Déconnexion. Pour cela, on choisit tout simplement le type de test « Délier les unités ». Cette requête sera placée en fin du scénario.

Passons aux éléments qui vont nous permettre d’ajouter les fiches annuaires dans le LDAP.

Le contrôleur ci-dessus, Pour chaque va tout simplement (efficacement je dirais), parcourir une à une les variables VAR_NOM_x où x est le numéro de ligne des résultats de la requête SQL précédente. À chaque itération, il va affecter à la variable NOM la valeur de VAR_NOM_x. (on notera la correspondance entre VAR_NOM de la requête JDBC Select et le VAR_NOM_x du contrôleur)

Ici, on ajoute un Compteur JMeter qui nous permet de connaître (suivre) le numéro de ligne, afin que nous puissions l’utiliser dans la prochaine requête pour générer des variables.

Nous voilà dans la requête « costaude », il s’agit d’une Requête LDAP étendue qui va traiter l’ajout. Ainsi, on choisit le type de test « Add test ».

Puis le champ Entry DN nous permet d’indiquer l’identifiant unique de la fiche dans l’annuaire.

Le tableau suivant, permet d’ajouter les couples « clé: valeur » suivant le principe du fichier LDIF (importation de comptes LDAP).

On notera les points suivants :

• ${__V(VAR_PRENOM_${CPT})} permet de générer la variable « ${VAR_PRENOM_x} pour chaque itération du Contrôleur Pour chaque
• ${NEW_NOM} et ${NEW_PRENOM} sont des variables définies dans un Pré-processeur BeanShell (ci-dessous)

Dans la requête d’ajout, il est important de ne pas oublier les éléments « objectclass » qui vont définir la structure de la fiche annuaire.

En fils de la requête d’ajout, on place donc un Pré-processeur BeanShell, qui va permettre d’effectuer quelques actions (ou préparations) sur les données avant leur utilisation.

Tout d’abord, on récupère la variable CPT (via vars.get( »GET »)), puis avec une concaténation, on récupére la valeur de la variable VAR_PRENOM_x. On supprime les points et enlève les guillemets (car certains noms dans la base des boxers ont des pseudonymes entre guillemets). Puis on refait la même chose avec le NOM.

Pour finir, on génère l’adresse email via un petit passage en minuscule et une concaténation du domaine de messagerie.

A chaque fois, on utilise le vars.put pour déposer des nouvelles variables dans JMeter.

Ensuite, avec l’élément suivant, une Assertion Réponse, j’anticipe sur l’exécution et la vérification que tout s’est bien passé. En effet, si l’exécution de la requête d’ajout LDAP fonctionne correctement, le résultat contient « <responsemessage>Success</responsemessage> ». L’assertion sur ce texte va nous permettre de détecter rapidement les cas en erreur (si il y en a).

Après la requête d’ajout, on place une requête de recherche dans le LDAP (type de test : Search test). C’est optionnel, c’est juste pour faire une seconde vérification du bon ajout.

On notera :

• Le champ Search Filter qui est ici le « uid » inséré
• Le champ Scope est positionné à Effectuer une recherche ‘onelevel’ (on ne recherche pas dans les sous-éléments de l’arbre LDAP)
• Le champ Size limit pour limiter à 1 le résultat retourné (on fait une recherche unitaire)
• Le champ Limite de temps à 10000 (ms) pour faire échouer l’échantillon si le serveur LDAP est trop long à répondre
• Le champ Attributes (optionnel) qui permet de choisir les champs à récupérer, ici le CN, SN et Mail
• Et pour finir, la case à cocher Examiner les résultats de recherche ? va permettre d’avoir dans les résultats du test, les valeurs des champs récupérés afin notamment de faire (par exemple) une assertion.

Ensuite (enfin) on peut passer à l’exécution du scénario JMeter.

Pour cela, on grade la configuration par défaut du Groupes d’unités, à savoir : 1 unité qui monte en charge en 1 seconde et qui faire 1 itération (1-1-1).

(c’est le Contrôleur Pour chaque qui se charge des itérations sur les utilisateurs)

Voici l’arbre de résultats :

Si tout s’est bien passé, tout est vert. Dans les données de réponses, on voit les résultats des requêtes LDAP, avec la valeur Success.

On peut également vérifier dans les données de réponses que par exemple la génération des adresses email s’est bien déroulée.

Un récepteur Résultats d’assertion, configuré pour afficher uniquement les erreurs, permet de voir les utilisateurs qui ont eu un problème lors de l’exécution. Ici, il y a eu des soucis visiblement sur les noms de boxers qui ont un caractère accentué…

Et voilà, avec ce tutoriel, on découvre que JMeter sait faire d’autre chose qu’un test de charge Web.

Vous noterez que ce type de scénario, fait de JMeter une sorte d’ETL (Extract-Transform-Load). Ainsi, on peut même imaginer d’adapter ce scénario pour maintenir une synchronisation entre une base de données et un LDAP, le tout en exécutant JMeter en mode non-gui dans une tâche programmée ou un cron.

Je prépare une suite à ce tutoriel concernant la conversion automatisée des mots de passe stockés ici en clair dans le LDAP, vers des mots de passe stockés en SHA-1.

Bons scénarios.

En annexes :
A/ Un petit SELECT de ma base de données (histoire de montrer sa structure)

mysql> select * from BOXERS limit 10;
 +----+----------+------------+
 | ID | PRENOM   | NOM        |
 +----+----------+------------+
 |  1 | Muhammad | Ali        |
 |  2 | Lou      | Ambers     |
 |  3 | Vito     | Antuofermo |
 |  4 | Jorge    | Arce       |
 |  5 | Alexis   | Arguello   |
 |  6 | Henry    | Armstrong  |
 |  7 | Abe      | Attell     |
 |  8 | Monte    | Attell     |
 |  9 | Yuri     | Arbachakov |
 | 10 | Satoshi  | Aragaki    |
 +----+----------+------------+
 10 rows in set (0.03 sec)

B/ Le format LDIF d’exemple (qui permet de connaître les champs à ajouter dans la requête LDAP d’ajout, mais entendu, il faut l’adapter pour que cela colle avec le vôtre (serveur LDAP))

dn: uid=milamber,ou=Users,dc=milamberspace,dc=net
objectclass: organizationalPerson
objectclass: person
objectclass: top
objectclass: inetOrgPerson
uid: milamber
userPassword: jmeter2009
cn: milamber
mail: milamber@milamberspace.net
displayname: Milamber
givenname: Milamber
sn: Milamber

./

Soit le plan de test suivant :

Dans ce plan de test, on extrait avec l’extracteur d’expressions régulières des données de la page reçue, (ici un NOMBRE).

On ajoute ‘au passage’ une assertion de réponse qui est là pour s’assurer que l’expression regexp a réussie (on vérifier si on (re)trouve le NOMBRE précédemment cherché dans la page).

Et pour finir, on a un élément post-processeur BeanShell qui exécuter un bout de code Java pour faire l’enregistrement de la variable NOMBRE dans un fichier.

Le code du BeanShell (du Java donc) est le suivant :

if (prev.isSuccessful()) {
    String nombre = vars.get("NOMBRE");
    try {
        BufferedWriter out = new BufferedWriter(new FileWriter("/tmp/nombre.csv",true));
        out.write(nombre +"\n");
        out.close();
    } catch (IOException e) {}
}

Quelques commentaires :

• Le test sur le prev.isSuccessful() afin d’enregistrer seulement les échantillons réussis,
• Le vars.get(« NOMBRE »); pour récupérer dans une variable Java le contenu de la varialbe JMeter NOMBRE,
• Le reste pour écrire dans un fichier.

Et voilà.

Pré-requis : pour exécuter des scripts BeanShell avec JMeter, il faut récupérer le fichier JAR du BeanShell, et le déposer dans le répertoire jmeter_home/lib (ou dans le classpath)

Nota : JMeter propose d’une part la possibilité d’enregistrer directement dans le fichier CSV ou JTL de résultats (via la fonctionnalités des « samples_variables »), et d’autre part d’enregistrer l’ensemble des données de réponses (via le récepteur « Sauvegarder les réponses vers un fichier »), cependant, il est parfois intéressant de pouvoir récupérer quelques variables durant un test JMeter, faire des opérations dessus et/ou créer un fichier de données pré-formaté à la volée.

./