problème dans un Include Controller en mode remote

3 views
Skip to first unread message

Eudes Elie

unread,
Mar 17, 2009, 1:19:17 PM3/17/09
to JMeter en français
hello,

dans un test en charge en mode remote, l'avantage est d'avoir en local
les testcases jmx pour les exécuter sur les injecteurs distants.
Dans un de mes testCases j'inclus un autre JMX (usecase
d'authentification utilisé ici comme une fonction) via un include
controller.

Le problème est qu'à l'exécution, j'ai une erreur : <The system cannot
find the file specified>

Y a t il une autre solution que de synchroniser tous les include &
autres fichiers utiles (genre les fichier CSV) entre tous les
injecteurs ?

Merci

Milamber

unread,
Mar 18, 2009, 3:16:18 AM3/18/09
to jmet...@googlegroups.com
Bonjour,

Je ne connais pas de solution 'native' dans Jmeter.

Parmi les solutions possibles :
* le partage NFS ou Windows entre ton contrôleur et tes injecteurs

* inclure dans ton script principal, une première étape de récupération
sur ton contrôleur des différents fichiers (jmx, csv, etc) nécessaires.
Avec plusieurs échantillons HTTP ou FTP (+ beanshell d'écriture de
fichier) et bien sur un petit serveur web ou ftp sur le contrôleur.

* n'avoir qu'un seul fichier script JMX (all in one) et aller chercher
ses données dans une base de données via requêtes JDBC. Il faut la
dernière version de JMeter (depuis le SVN) la possibilité d'enregistrer
dans des variables les données d'un SELECT est possible depuis peu.

A+
Milamber

Le 17.03.2009 17:19, Eudes Elie a ecrit :

Eudes Elie

unread,
Mar 18, 2009, 4:05:14 AM3/18/09
to JMeter en français
L'idée derrière un include est d'agréger les testcases (comme des
poupées russes)
Dans mon cas d'utilisation, je n'écris l'authentification qu'une fois
(en tant que testcase), puis j'extrais tout le 'gras' non souhaité
(les listeners par exmple) afin de l'enregistrer à part comme une
'fonction' => facilité de maintient dans le temps.

Du coup l'idée du partage est tentant car multiplatforme aussi :-)

La récupération automatique ajouterai une complexité non nécessaire au
testcase

Un seul fichier JMX est pas mal pour les petits tests / campagnes de
test mais pas dans le cadre de gros tests

Merci,
Eudes

Milamber

unread,
Mar 18, 2009, 8:47:59 AM3/18/09
to JMeter en français
Bonjour,

Tiens cela ressemble bien à l'idée de "couches", ou du moins à la
séparation des choses.

Effectivement un seul gros fichier jmx est bien pratique pour un test
avec quelques scénarios fonctionnels avec peu de campagnes. Le délai
de mise en place / mise en oeuvre est plus rapide (all in one) que si
on souhaite faire des séparations / inclusions.

Quand tu parles de "gros projets", tu pourrais nous donner un peu plus
de détails ?
Tu as prévu de faire un tir de perf chaque jour/nuit ou heure ? ou/et
c'est 10000 accès par secondes à simuler ? ou/et c'est super complexe
(150 scénarios avec 20 requêtes minimun chacun) ?
(je ne suis pas de la police ;-), c'est juste pour connaître (et
comprendre) la problématique.

Merci

A+
Milamber

Eudes Elie

unread,
Mar 18, 2009, 11:34:27 AM3/18/09
to jmet...@googlegroups.com
oui l'idée de couche est bien là :
réaliser les tests élémentaires / unitaire pour chaque webservice : testcases avec uniquement les paramètres obligatoire, puis on ajoute un paramètres optionnel etc. jusqu'à faire tous les paramètres. Après il est aussi intéressant de traiter les cas d'erreur etc.

De ces test élémentaire on peut extraire un 'test pseudo fonction' qui pourra être utilisé dans des tests fonctionnel (nécessité de doc par contre pour avoir pour chaque 'test pseudo fonction' le résumé avec les entrées sortie)

Puis finir par des tests end to end qui regroupent une succession de tests fonctionnel ...

bref ca représentent du travail ^_^


Je souhaite donc utiliser Jmeter comme une vrai solution de test fonctionnel et de charge.
Le tout avec ant histoire de se simplifier un peu la vie pour les rapports & exécutions automatiques ...

Par gros projet, j'entends le test d'une api webservice comportant à peu près 100 opérations. Ce n'est pas énorme mais quand on veut mettre un joli process autour (l'histoire des testU servant aux tests fonctionnels etc.) ... ca devient assez lourd (mais j'espere efficace une fois en place)

Il faut juste ne pas se louper sur la premiere marche :p

Eudes.

Milamber

unread,
Mar 24, 2009, 3:04:01 AM3/24/09
to jmet...@googlegroups.com
Bonjour,

Merci pour ton retour. C'est effectivement du travail.
Il serait intéressant à la fin d'avoir le ratio : temps de développement (codage + tests de mise au point) / temps de création du test fonctionnel Jmeter.

L'idée est de voir l'effort moyen à fournir pour avoir un test fonctionnel automatisé.

Je précise que pour moi, ce que tu décris ne sont pas des tests unitaires (à la junit) mais des tests unitaires fonctionnels (ce qui pose plus le problème de jeux de données initiales, car la mise en place de mock objects semblent plus délicate) (dis moi si j'ai tord)

Sinon, il faudrait aussi surveiller le temps de mise à jour des scripts entre chaque itération (en particulier,si jamais vous êtes dans une démarche orientée agile).
La question est : est ce que l'effort d'automatiser vaut le coup sur ton projet ?

J'ajoute pour finir, qu'il faut surveiller le temps d'exécution global, notamment dans le cas d'exécution "de nuit", car si il faut plus de 4 heures pour le tout, il va falloir parallélisé ou autres.

A+
Milamber

Le 18.03.2009 15:34, Eudes Elie a ecrit :
Reply all
Reply to author
Forward
0 new messages