Intégration du support de la JSR 223 dans JMeter
JMeter est un outil qui permet de faire du stress/load/performance testing sur différentes sortes d’applications dont des applications web, des applications de base de données, des web services, des annuaires LDAP, des applications de messagerie basées sur POP et IMAP. Il permet de simuler de la charge sur un serveur afin de tester la résistance et les performances de celui-ci selon différents types et quantités de charges.
Les principaux avantages de JMeter
- Possibilité de faire des tests de charge sur différents types d’applications : Web (HTTP, HTTPS), SOAP, Base de données (via JDBC), LDAP, JMS, mail (POP3 et IMAP).
- JMeter est écrit en Java : ce qui permet d’assurer la portabilité de l’application sur n’importe quelle plateforme disposant d’une JVM.
- Création de scénario de test de charge facile à prendre en main.
- Extensibilité : possibilité de personnaliser les scénarios de tests en utilisant des langages de scripts pour modifier le comportement des samplers dans le plan de test. On peut utiliser soit : le BeanShell, des langages compatibles avec BSF (Bean Scripting Framework) ou encore des langages compatibles avec les spécifications JSR223 qui est une nouvelle fonctionnalité que nous avons essayé d’intégrer.
Les spécifications JSR223 : Scripting dans Java
L’une des fonctionnalités les plus abouties de Java 6 consiste en la possibilité de pouvoir intégrer des langages de script avec la JVM. Désormais, il est possible d’importer des scripts écrits avec d’autres langages dans Java. Ceci inclut également la possibilité de passer des objets Java à des scripts et de pouvoir les manipuler. Les langages de scripts peuvent ainsi importer des classes Java, instancier des objets et les utiliser.
Actuellement, les langages supportés sont : Groovy, JRuby, Jython, Beanshell, browserjs, EJS, Freemarker, Jack, Jaskell, Java, Javascript, Jawk, Jelly, JEP, Jexl, JST, JudoScript, JUEL, OGNL, Pnuts, Scheme, Sleep, Velocity, XPath and XSLT.
Les spécifications JSR 223 permettent d’embarquer des langages de script dans des applications Java, et d’accéder et manipuler des objets Java depuis l’environnement de script.
Exemple d’utilisation des spécifications JSR223 avec Groovy
Dans cette partie, nous allons illustrer par un exemple, l’utilisation des spécifications JSR 223 avec le langage Groovy.
Pourquoi Groovy
Le choix de Groovy pour cette présentation n’est pas anodin. Groovy est un langage dynamique pour la plateforme Java avec des fonctionnalités inspirées d’autres langages tels que Ruby, Python ou Smalltalk, mises à disposition des développeurs en utilisant une syntaxe très proche de Java. De plus, c’est un langage facile à prendre en main surtout pour des développeurs Java.
JMeter étant purement écrit en Java, l’utilisation de Groovy s’imposait naturellement comme le choix le plus judicieux pour l’intégration et l’utilisation des fonctionnalités de scripting des extensions JSR223. En effet, nous disposons là d’un environnement purement Java qui permet de tirer pleinement partie de la puissance de la plateforme et de faciliter l’intégration et l’interaction des composants de l’application.
Scripting Groovy dans Java
Nous allons, tout d’abord, créer un mini-programme très simple en Groovy qui effectue une boucle de 1 à 10 et qui affiche à chaque tour, le numéro de la boucle.
-
1.upto(10){ i –>
-
if(i == 1)
-
println ‘1er tour de boucle’
-
else
-
println i + ‘ème tour de boucle’
-
}
Ensuite, nous allons créer un programme java depuis lequel nous effectuerons l’exécution de ce mini-programme groovy en utilisant les fonctionnalités offertes par les spécifications JSR223.
-
package illustration;
-
import javax.script.ScriptEngine;
-
import javax.script.ScriptEngineManager;
-
import javax.script.ScriptException;
-
public class Main {
-
public static void main(String[] args){
-
ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
-
ScriptEngine groovyScriptEngine = scriptEngineManager.getEngineByName(“groovy”);
-
String groovyCode = “1.upto(10){ i -> “ +
-
” if(i == 1)” +
-
” println ‘1er tour de boucle'” +
-
” else “ +
-
” println i + ‘ème tour de boucle’ “ +
-
“}”;
-
try {
-
groovyScriptEngine.eval(groovyCode);
-
} catch (ScriptException e) {
-
e.printStackTrace();
-
}
-
}
-
}
Explications
Pour l’exécution du script depuis l’environnement Java, la première étape consiste, à instancier un scriptEngineManager, qui implémente les fonctionnalités de recherche et d’instanciation de scriptEngine.
Puis, nous créons un scriptEngine en nous basant sur le nom du langage de script (dans notre cas : groovy). Ces deux points sont illustrés par les deux instructions ci-dessous.
-
ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
-
ScriptEngine groovyScriptEngine=scriptEngineManager.getEngineByName(“groovy”);
Enfin, la partie la plus importante, l’exécution du code groovy depuis java s’effectue en invocant la méthode eval()
depuis le scriptEngine, en lui passant en paramètre le code à exécuter.
-
// Code groovy à évaluer
-
String groovyCode = “1.upto(10){ i -> “ +
-
” if(i == 1)” +
-
” println ‘1er tour de boucle'” +
-
” else “ +
-
” println i + ‘ème tour de boucle’ “ +
-
“}”;
-
// Evaluation du code groovy par le script Engine
-
groovyScriptEngine.eval(groovyCode);
Dans notre cas, nous avons utilisé une variable String pour stocker notre mini-programme groovy. L’invocation de la méthode eval()
va provoquer l’évaluation du code fourni en paramètre et donner la sortie suivante :
1er tour de boucle 2ème tour de boucle 3ème tour de boucle 4ème tour de boucle 5ème tour de boucle 6ème tour de boucle 7ème tour de boucle 8ème tour de boucle 9ème tour de boucle 10ème tour de boucle
Intégration JSR 223 dans JMeter
Le support du JSR 223 dans JMeter permet de disposer de fonctionnalités de scripting dans plusieurs langages, ouvrant ainsi des possibilités pour disposer d’un environnement de test à la fois évolutif et souple. Le concepteur du plan de test a ainsi un large choix quant au langage de script qu’il veut utiliser.
Les langages de scripts ont aussi des avantages certains par rapport à Java :
- Ils sont interprétés (pas de phase de compilation), ce qui implique un gain de temps conséquent au développement.
- Ils sont nettement plus faciles et plus rapides à écrire (typage faible, syntaxe simple) que du code Java (typage fort, phase de compilation etc.)
Nous avons essayé d’intégrer le support du JSR 223 dans JMeter. Nous avons pour cela, ajouté dans les éléments de tests (TestElement) un préprocesseur JSR 223, un post processeur JSR 223 et un listener JSR 223.
Sampler, Préprocesseur et PostProcesseur dans JMeter
Un sampler est un élément de test JMeter. Il représente les requêtes qui seront effectivement exécutées par le logiciel lors du lancement du test. Un sampler renvoie un ou plusieurs résultats (Exemple : HTTP sampler pour simuler une requête http).
Un préprocesseur est un élément de test qui permet de modifier les comportements ou les éléments d’un sampler avant leur exécution. Comme son nom le suggère, il est exécuté avant le sampler. En général, il est utilisé pour modifier la valeur des variables dans les samplers (paramétrage dynamique des tests).
Un post processeur est un élément de test qui sera appliqué après l’exécution d’un sampler. La plupart du temps, il est utilisé pour le traitement des résultats reçus après que le sampler ait été exécuté.
Les paragraphes suivants décrivent la mise en place du support du JSR223 dans les éléments de Test de JMeter. Ils couvriront:
- La phase de préparation
- La phase d’implémentation des fonctionnalités des éléments de test : JSR223Preprocessor, JSR223PostProcessor et JSR223Listener.
- Et une illustration de l’utilisation des éléments de test avec Groovy
Phase de préparation
Installation des paquetages nécessaires
- Le scripting est une fonctionnalité de Java 6. Il est donc nécessaire d’installer cette version de Java.
- Le support de JSR 223 implique d’avoir les différents script engines des langages de script. Ces script engines sont disponibles en ligne dans un paquetage à l’adresse : (https://scripting.dev.java.net/files/documents/4957/37592/jsr223-engines.tar.gz)
- Les script engines sont extraits et placés dans un sous-répertoire du projet, par exemple lib/jsr-223-engine.
Un répertoire est disponible pour chaque langage de script pour lequel le support de jsr 223 est disponible. Chaque langage dispose des fichiers/répertoires suivants:
- bin/ : contient les fichiers de commandes pour lancer les interpréteurs de script
- build/ : contient le script engine jsr223-compliant
- lib/: ne contient rien pour le moment mais destiné à recevoir l’interpréteur de script
- LICENSE.TXT: la licence
- README.TXT : l’url qui permet de télécharger le jar de l’interpréteur de script à placer dans lib/
Par exemple pour Groovy :
- bin/ contient groovy.bat et groovy.sh
- build/ : contient groovy-engine.jar
- lib/: contient groovy-all.jar
Phase d’implémentation
Création de JSR223TestElement.java
Dans JMeter, les éléments de tests (sampler, préprocesseurs, postprocesseurs etc.) sont les composants qui permettent la conception des plans de tests. Tous les testElements héritent de la classe générique AbstractTestElement.java.
Le première étape est tout naturellement la création d’un TestElement « JSR223-compliant » qui sera la base de tous les éléments de test JSR223 et que nous appelerons JSR223TestElement.java. Cette classe étant un testElement, elle hérite de AbstractTestElement.java. Tous les éléments de test JSR223 hériteront ensuite de JSR223TestElement.java.
JSR223TestElement.java
Les trois méthodes les plus importantes à considérer sont celles héritées de AbstractTestElement.java, à savoir :
protected ScriptEngineManager getManager()
protected void initManager(ScriptEngineManager sem)
protected void processFileOrScript(ScriptEngineManager sem)
La méthode getManager()
permet de récupérer le scriptEngineManager. Le scriptEngineManager implémente les fonctionnalités de recherche et d’instanciation pour les scriptEngine. Il maintient également une collection de clé/valeur stockant les « états » partagées par les « engine » et créés par le manager.
Cette classe utilise le mécanisme de « service providing » pour énumerer les différentes implémentations de ScriptEngineFactory. Elle fournit une méthode qui permet de retourner ces factory et des méthodes utilitaires permettant la recherche des factory sur la base du nom du langage de script ou du type MIME.
-
protected ScriptEngineManager getManager() {
-
ScriptEngineManager sem = new ScriptEngineManager();
-
initManager(sem);
-
return sem;
-
}
La méthode initManager()
permet l’initialisation du manager. Elle permet de :
- récupérer le nom du langage de script à utiliser
- récupérer le nom du fichier de script à interpréter
- récupérer les paramètres à passer au script
- fixer les valeurs des objets qui seront passés au script via la méthode put() (ici les objets : args, ctx, vars, props, out, sampler…).
-
protected void initManager(ScriptEngineManager sem){
-
final String label = getName();
-
final String fileName = getFilename();
-
final String scriptParameters = getParameters();
-
// Use actual class name for log
-
final Logger logger = LoggingManager.getLoggerForShortName(getClass().getName());
-
sem.put(“log”, logger);
-
sem.put(“Label”, label);
-
sem.put(“FileName”, fileName);
-
sem.put(“Parameters”, scriptParameters);
-
String [] args=JOrphanUtils.split(scriptParameters, ” “);//$NON-NLS-1$
-
sem.put(“args”, args);
-
// Add variables for access to context and variables
-
JMeterContext jmctx = JMeterContextService.getContext();
-
sem.put(“ctx”, jmctx);
-
JMeterVariables vars = jmctx.getVariables();
-
sem.put(“vars”, vars);
-
Properties props = JMeterUtils.getJMeterProperties();
-
sem.put(“props”, props);
-
// For use in debugging:
-
sem.put(“OUT”, System.out);
-
// Most subclasses will need these:
-
Sampler sampler = jmctx.getCurrentSampler();
-
sem.put(“sampler”, sampler);
-
SampleResult prev = jmctx.getPreviousResult();
-
sem.put(“prev”, prev);
-
}
La méthode processFileOrScript()
exécute effectivement le script donné en paramètre via le fichier ou les instructions passées à JMeter par le biais de l’IHM.
-
protected void processFileOrScript(ScriptEngineManager sem) throws IOException, ScriptException{
-
ScriptEngine scriptEngine = sem.getEngineByName(getScriptLanguage());
-
if(scriptEngine == null){
-
log.warn(“Not supported scripting engine”);
-
setScriptLanguage(“groovy”);
-
scriptEngine = sem.getEngineByName(getScriptLanguage());
-
}else{
-
System.out.println(“Script engine found : “ + getScriptLanguage());
-
}
-
File scriptFile = new File(getFilename());
-
if(scriptFile.exists()){
-
BufferedReader fileReader = new BufferedReader(new FileReader(scriptFile));
-
String line;
-
while((line = fileReader.readLine()) != null){
-
scriptEngine.eval(line);
-
}
-
}else{
-
scriptEngine.eval(getScript());
-
}
-
}
Il prend en paramètre le ScriptEngineManager qui permet d’instancier le scriptEngine via les données récupérées depuis l’IHM.
-
ScriptEngine scriptEngine = sem.getEngineByName(getScriptLanguage());
Il effectue ensuite le traitement décrit par le fichier de script ou les instructions fournies dans l’IHM de JMeter en invoquant la méthode eval()
:
-
File scriptFile = new File(getFilename());
-
if(scriptFile.exists()){
-
BufferedReader fileReader = new BufferedReader(new FileReader(scriptFile));
-
String line;
-
while((line = fileReader.readLine()) != null){
-
scriptEngine.eval(line);
-
}
-
}else{
-
scriptEngine.eval(getScript());
-
}
-
}
Création des préprocesseur, postprocesseur et listener JSR223
La deuxième étape consiste à créer les éléments de tests JSR223 dont un préprocesseur, un postprocesseur et un Listener.
Préprocesseur JSR 223
Le préprocesseur JSR223 est un élément de test exécuté par JMeter avant un sampler (un http request par exemple). Il permet de modifier le comportement du sampler en lui injectant par exemple des valeurs de paramètres différentes entre les runs.
Etant un «modifier», il est placé dans le package org.apache.jmeter.modifiers
.
-
package org.apache.jmeter.modifiers;
-
import javax.script.ScriptEngineManager;
-
import org.apache.jmeter.processor.PreProcessor;
-
import org.apache.jmeter.testbeans.TestBean;
-
import org.apache.jmeter.util.JSR223TestElement;
-
import org.apache.jorphan.logging.LoggingManager;
-
import org.apache.log.Logger;
-
public class JSR223PreProcessor extends JSR223TestElement implements Cloneable, PreProcessor, TestBean
-
{
-
private static final Logger log = LoggingManager.getLoggerForClass();
-
private static final long serialVersionUID = 232L;
-
public void process(){
-
try{
-
ScriptEngineManager sem = getManager();
-
if(sem == null) { return; }
-
processFileOrScript(sem);
-
}catch (Exception e) {
-
log.warn(“Problem in JSR223 script “ + e);
-
}
-
}
-
}
La classe JSR223PreProcessor.java étant une élément de test JSR223, elle hérite de JSR223TestElement.java.
Tous les Préprocesseurs implémentent l’interface Preprocessor. Cette interface définit la méthode process()
que tout préprocesseur doit implémenter. Dans le cas de JSR223PreProcessor.java, l’implémentation de process()
récupère un scriptEngineManager et fait appel à la méthode processFileOrScript()
de la classe mère JSR223TestElement.java dont elle hérite et qui va effectivement exécuter le script passé en paramètre par l’IHM ou dans un fichier.
-
public void process(){
-
try{
-
ScriptEngineManager sem = getManager();
-
if(sem == null) { return; }
-
processFileOrScript(sem);
-
}catch (Exception e) {
-
log.warn(“Problem in JSR223 script “ + e);
-
}
-
}
Postprocesseur JSR 223
Le postprocesseur JSR223 est un élément de test exécuté par JMeter après un sampler (un http request par exemple). La plupart du temps, il est utilisé pour récupérer/extraire les éléments de résultats des samplers.
Etant un «extractor », il est placé dans le package org.apache.jmeter.extractor
;
-
package org.apache.jmeter.extractor;
-
import java.io.IOException;
-
import javax.script.ScriptEngineManager;
-
import javax.script.ScriptException;
-
import org.apache.jmeter.processor.PostProcessor;
-
import org.apache.jmeter.testbeans.TestBean;
-
import org.apache.jmeter.util.JSR223TestElement;
-
import org.apache.jorphan.logging.LoggingManager;
-
import org.apache.log.Logger;
-
public class JSR223PostProcessor extends JSR223TestElement implements Cloneable, PostProcessor, TestBean
-
{
-
private static final Logger log = LoggingManager.getLoggerForClass();
-
private static final long serialVersionUID = 232L;
-
public void process(){
-
ScriptEngineManager sem = null;
-
try{
-
sem = getManager();
-
}catch(Exception e){
-
e.printStackTrace();
-
}
-
if(sem == null) { return; & #125;
-
try{
-
processFileOrScript(sem);
-
}catch (Exception e) {
-
e.printStackTrace();
-
}
-
}
-
}
La classe JSR223PostProcessor.java étant une élément de test JSR223, elle hérite de JSR223TestElement.java exactement comme JSR223Preprocessor.java.
Tous les Postprocesseurs implémentent l’interface PostProcessor. Cette interface définit également une méthode process()
que tout Postprocesseur doit implémenter. Dans le cas de JSR223PostProcessor.java, l’implémentation de process()
récupère un scriptEngineManager et fait appel à la méthode processFileOrScript()
de la classe mère JSR223TestElement.java dont elle hérite et qui va effectivement exécuter le script passé en paramètre par l’IHM ou dans un fichier, de la même façon que dans JSR223Preprocessor.java.
-
public void process(){
-
ScriptEngineManager sem = null;
-
try{
-
sem = getManager();
-
}catch(Exception e){
-
e.printStackTrace();
-
}
-
if(sem == null) { return; }
-
try{
-
processFileOrScript(sem);
-
}catch (Exception e) {
-
e.printStackTrace();
-
}
-
}
Listener JSR223
Un listener JSR223 est un élément de test qui permet d’appliquer des traitements sur les résultats des samples via des langages de script « jsr223-compliant ».
Il est placé dans le package org.apache.jmeter.visualizers
-
package org.apache.jmeter.visualizers;
-
import javax.script.ScriptEngineManager;
-
import org.apache.bsf.BSFException;
-
import org.apache.bsf.BSFManager;
-
import org.apache.jmeter.samplers.SampleEvent;
-
import org.apache.jmeter.samplers.SampleListener;
-
import org.apache.jmeter.samplers.SampleResult;
-
import org.apache.jmeter.testbeans.TestBean;
-
import org.apache.jmeter.util.BSFTestElement;
-
import org.apache.jmeter.util.JSR223TestElement;
-
import org.apache.jorphan.logging.LoggingManager;
-
import org.apache.log.Logger;
-
public class JSR223Listener extends JSR223TestElement
-
implements Cloneable, SampleListener, TestBean, Visualizer {
-
// N.B. Needs to implement Visualizer so that TestBeanGUI can find the correct GUI class
-
private static final Logger log = LoggingManager.getLoggerForClass();
-
private static final long serialVersionUID = 234L;
-
public void sampleOccurred(SampleEvent event) {
-
try {
-
ScriptEngineManager sem = getManager();
-
if (sem == null) {
-
log.error(“Problem creating JSR 223 manager”);
-
return;
-
}
-
sem.put(“sampleEvent”, SampleEvent.class);
-
SampleResult result = event.getResult();
-
sem.put(“sampleResult”, SampleResult.class);
-
processFileOrScript(sem);
-
} catch (Exception e) {
-
log.warn(“Problem in JSR 223 script “ + e);
-
}
-
}
-
public void sampleStarted(SampleEvent e) {
-
}
-
public void sampleStopped(SampleEvent e) {
-
}
-
public void add(SampleResult sample) {
-
}
-
public boolean isStats() {
-
return false;
-
}
-
}
Comme tout autre élément de test, JSR223Listener.java hérite de JSR223TestElement.java. Elle implémente également l’interface SampleListener qui définit les méthodes que tout Listener doit implémenter; entre autre la méthode sampleOccured()
qu’un sampler a été exécuté et s’est terminé.
L’implémentation de la méthode sampleOccured()
par le JSR223Listener se charge de mettre à disposition de l’environnement du langage de script les éléments SampleEvent et SampleResults afin d’effectuer des traitements dessus. On retrouve ici la méthode put()
qui permet de faire cela.
-
sem.put(“sampleEvent”, SampleEvent.class);
-
SampleResult result = event.getResult();
-
sem.put(“sampleResult”, SampleResult.class);
Enfin, la méthode processFileOrScript()
est invoqué pour charger le script et exécuter les traitements.
-
processFileOrScript(sem);
Création des éléments d’IHM pour les composants (préprocesseur, postprocesseur, listener) JSR223
JMeter supporte nativement Bean Scripting Framework (BSF). C’est un framework qui permet de faire du scripting dans Java, de la même manière que les spécifications JSR223. Les paramètres qui doivent être fournis via l’IHM étant identiques, nous nous sommes basés sur les éléments d’interface BSF pour construire ceux des nouveaux composants JSR223.
Les composants BSF utilisent une classe abstraite BSFBeanInfoSupport pour la gestion générique des éléments d’IHM qui leur sont communs. Les éléments d’interfaces étant les mêmes, nous avons crée les classes JSR223PreProcessorBeanInfo (package modifiers), JSR223PostProcessorBeanInfo (package extractor), et JSR223ListenerBeanInfo (package visualizers) par héritage depuis la classe BSFBeanInfoSupport pour gérer respectivement les éléments d’interface des composants JSR223 : Preprocesseur, Postprocesseur et Listener.
Diagramme UML
Illustration de l’utilisation du support du JSR223 dans JMeter
Dans l’illustration qui suit, nous mettrons en place un plan de test qui permet de gérer dynamiquement un scénario qui envoie différentes valeurs de paramètres de recherche, via le pré processeur, vers Google et en utilisant Groovy. Le post processeur se chargera ensuite de récupérer les résultats des samplers.
Nous allons utiliser un simple HTTP sampler qui enverra une requête HTTP vers Google en modifiant à chaque run le « keyword ». Le keyword sera extrait depuis une liste décrite dans un fichier CSV et injecté par le script Groovy dans le sampler via le préprocesseur. Le postprocesseur se chargera ensuite d’extraire les résultats du sampler.
Explications
Une requête de recherche google est de la forme suivante :
http://www.google.fr/search?hl=fr&q=XXX&btnG=Recherche+Google&meta=&aq=f&oq=
où XXX est le mot-clé de la recherche.
Le httpSampler sera donc configuré de la manière suivante (cf écran ci-dessus) :
- Server name : http://www.google.com
- Path : /search
Et les paramètres de recherche :
- hl avec la valeur fr
- q auquel on a donné la valeur ${keyword} qui est une notation permettant à JMeter de savoir que c’est une variable qui lui est fourni par le biais d’une ressource externe (script par exemple).
- BtnG avec la valeur « Recherche+Google »
- meta sans valeur
- aq avec la valeur f
- oq sans valeur
Sous le sampler, dans la hiérarchie des éléments de tests, nous allons mettre un httpRequestManager. Cet élément de test permet à JMeter de spécifier certains éléments d’entêtes http dont par exemple le « user-agent » auquel nous donnerons la valeur « Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050512 Firefox » sans quoi Google considérera que notre requête vient d’un robot.
Nous allons définir dans un fichier CSV, que nous appellerons keyword.csv, les différents mots-clés (une par ligne) utilisés pour la recherche et nous spécifierons dans JMeter que ce fichier sera une ressource externe depuis laquelle il va extraire certaines données via l’utilisation de l’élément de test CSV data source :
Les éléments à configurer au niveau de cet élément de test sont :
- le nom du fichier csv
- le nom des variables à utiliser au sein de JMeter pour référencer les données récupérées depuis le fichier csv (ici k).
- le délimiteur utilisé dans le fichier csv
Ainsi, après chaque run, JMeter va extraire une donnée de la liste des mots-clés du fichier csv et la mettra dans la variable k.
Nous allons maintenant mettre en place un Préprocesseur JSR223 dans le Plan de test afin de gérer dynamiquement le chargement des différents mots-clés dans la requête envoyée par JMeter.
-
println “===PRE PROCESSING===”
-
vars.put(‘HOST’, ‘www.google.com’)
-
vars.put(‘KEYWORD’, ${k})
Ce script en Groovy permet de mettre la valeur de la variable k, récupérée depuis le fichier csv, et le mettre dans la variable KEYWORD qui sera référencée depuis JMeter par ${KEYWORD}. Cette dernière a été spécifiée ci-dessus comme étant l’un des « paramètres http» (le mot-clé pour google) à envoyer avec la requête JMeter. Ainsi, nous venons d’injecter une donnée depuis l’environnement de script vers JMeter.
Enfin, nous allons mettre en place un postprocesseur JSR223. Le postprocesseur se chargera de récupérer les résultats du sampler et de nous les afficher :
-
println “=== POST PROCESSING ===”
-
println “SAMPLING RESULTS”
-
println “Sampler data encoding : “ + prev.getDataEncodingWithDefault()
-
println “Sampler Data type : “ + prev.getDataType()
-
println “Sampler error count : “ + prev.getErrorCount()
-
println “Sampler media type : “ + prev.getMediaType()
-
println “Sampler data : “ + prev.getSamplerData()
-
println “Response Code : “ + prev.getResponseCode()
-
println “Request headers : “ + prev.getRequestHeaders()
-
println “Response data : “
-
println prev.getResponseDataAsString()
-
println “Response message : “ + prev.getResponseMessage()
-
println “Previous sample result : “ + (prev.isSuccessful() ? ‘the sampling of ‘ + prev.getUrlAsString() + ‘ [SUCCEEDED]’: ‘the sampling of ‘ + prev.getUrlAsString() + ‘ [FAILED]’ )
-
println “===END OF PRE PROCESSING===”
Ce petit script en groovy permet de récupérer les données de résultats du sampler. Par exemple : l’encodage utilisé, le type de données, le nombre d’erreur, le code de reponse, les entêtes de réponse.
Conclusion
L’intégration des fonctionnalités de scripting, telles que décrites par les spécifications JSR223, dans les applications Java ouvre de nombreuses perspectives pour les développeurs :
- simplicité d’intégration
- rapidité de codage
- choix du langage de script très étendu
- etc.
L’exemple de l’intégration des éléments de test JMeter que nous venons de voir en est l’exemple parfait.
L’extension JSR223 que nous avons greffé à JMeter permet notamment au concepteur de test de pouvoir :
- concevoir des scénarios de tests personnalisables et dynamiques. Ce qui permet d’affiner les possibilités en termes de paramétrages et de contrôle des résultats.
- interagir avec l’environnement du logiciel JMeter depuis son langage de script, et ceci d’une manière tout à fait transparente ou du moins très facile.
L’utilisation de Groovy dans JMeter a particulièrement été soulignée. En effet, JMeter étant écrit entièrement en Java, Groovy, de par sa conception même est le langage de script idéal dans ce contexte puisqu’en plus de bénéficier de la puissance de la plateforme Java sur laquelle il est bâti, il permet aussi une plus grande maniabilité de par les fonctionnalités qu’il offre (syntaxe simple, langage dynamique, etc).
Zenika a contribué [1] ce code au projet JMeter. Les chances d’intégration dépendent de la volonté à intégrer et à builder ce code tout en ne forçant pas l’utilisation du JDK 6 pour toute opération ne nécessitant pas ces nouveaux éléments. Sebastian Bazley, l’un des committers de JMeter, a noté sur le Bugzilla la possible utilisation d’Apache BSF3 qui ne nécessite pas de JDK 6.
Zenika a donc continué sur sa lancée en contribuant un autre patch permettant d’utiliser un PreProcessor, un PostProcessor, un Listener, mais aussi un Sampler et une Assertion directement en Groovy, sans passer par l’utilisation d’un ScriptEngine [2].
[1] https://issues.apache.org/bugzilla/…
[2] https://issues.apache.org/bugzilla/…