RAPPORT DE STAGE TN10 - UTCTests logiciels sur Scenari > Introduction Merci enfin à tous les employés de Kelis pour leur aide, en particulier à Thibaut, Antoine, Samuel, Julie et

Kelis Conseil et Développement9 rue du Gros Buisson - 60150 Thourotte

Responsable de stage : Sylvain Spinelli

Léonard DumasGI6 – ICSISuiveur UTC : Stéphane Crozat

Tests logiciels sur ScenariRAPPORT DE STAGE TN10

Sommaire

Introduction................................................................................5A Présentation de Kelis...............................................................................................6

B Présentation de l'unité ICS......................................................................................6

C Présentation de Scenari...........................................................................................71. Contexte...........................................................................................................72. La suite logicielle.............................................................................................8

D Problématiques du stage.........................................................................................9

I Veille technologique................................................................10A Les tests logiciels...................................................................................................10

1. Généralités....................................................................................................101.1. Tests boîte blanche/noire...........................................................................................111.2. Tests unitaires/d'intégration/fonctionnels..................................................................111.3. Tests de performance................................................................................................131.4. Tests de non-régression.............................................................................................14

2. Conception.....................................................................................................142.1. Méthodologies classiques..........................................................................................152.2. Méthodologies alternatives........................................................................................15

3. Organisation..................................................................................................153.1. Intégration continue..................................................................................................163.2. Exploratory testing, context-driven testing, ad hoc testing........................................16

B Solutions envisagées pour Scenari........................................................................171. Stratégie générale de test.............................................................................172. Test vs. initialisation du contexte.................................................................19

II Tests fonctionnels...................................................................21A Mise en œuvre des "briques" d'initialisation........................................................21

1. Première méthode : externalisation.............................................................222. Seconde méthode : implémentation.............................................................24

B Implémentation d'un composant d'assertion........................................................27

C Exemples de tests..................................................................................................281. Tests des ateliers brouillon...........................................................................292. Tests des ateliers dérivés..............................................................................313. Stratégie générale de tests fonctionnels......................................................32

III Tests de performance............................................................34A Proxy JMeter et tests de performance...................................................................34

1. Enregistrement de scénarios parallèles.......................................................34

3

T es ts log ic ie l s sur Scenar i > Sommai re

2. Adaptation de l'implémentation du proxy....................................................36

B Application..............................................................................................................391. Description succincte....................................................................................392. Protocole........................................................................................................40

2.1. Scénario enregistré et post-traitements.....................................................................402.2. Jeux de données.........................................................................................................412.3. Déroulement..............................................................................................................41

3. Résultats........................................................................................................43

IV Conclusion.............................................................................47

Glossaire....................................................................................48

Annexes......................................................................................49

4

Introduction

La formation d'ingénieur à l'UTC amène les étudiants à se forger leurs premières expériences professionnelles en lien étroit avec les connaissances acquises à l'Université.

S'inscrivant dans la suite des enseignements de filière, le projet de fin d'études vise à mettre en pratique ses compétences tout en exerçant une responsabilité dans l'entreprise ; il s'agit aussi de découvrir un contexte de travail (activité de l'entreprise, relations de travail, etc.) afin de se donner une base de réflexion pour le futur de sa vie professionnelle.

Ayant suivi la filière ICSI (Ingénierie des Connaissances et des Supports d'Information) du Génie Informatique, j'ai eu de l'intérêt pour la question de gestion des contenus numériques (multimédia, documents numériques, indexation, etc.) et ai souhaité avoir une expérience de travail dans ce domaine.

Ce stage s'est déroulé du 6 février au 20 juillet 2012 au sein de la société Kelis, spécialisée dans l'ingénierie documentaire et menant le développement du logiciel Scenari. Il a eu lieu en collaboration avec l'unité ICS (Ingénierie des Contenus et Savoirs).

RésuméLe sujet de ce stage concerne la mise en place d'un environnement de tests automatisés sur Scenari.

Les tests logiciels sont une activité qui s'inscrit parallèlement au développement d'un système informatique ; ils visent à valider le fonctionnement du logiciel par rapport à un comportement attendu, ou encore à tester ses limites.

La réalisation de ce projet a comporté globalement trois parties :1. veille technologique sur la question des tests logiciels (types, organisation,

outils, particularités de Scenari, etc.) ;2. tests fonctionnels sur des services du noyau de Scenari ;3. tests de performance sur Scenari 4 DB.

RemerciementsAvant toute chose, je tiens à remercier mon responsable de stage Sylvain Spinelli pour sa disponibilité permanente, son aide et sa pédagogie qui m'ont été fort utiles pour réaliser ce projet.

Je remercie également Christelle Larrouy, gérante de Kelis, et Stéphane Crozat, mon suiveur UTC, pour m'avoir permis d'effectuer ce stage.

5

T es ts log ic ie l s sur Scenar i > In t roduc t ion

Merci enfin à tous les employés de Kelis pour leur aide, en particulier à Thibaut, Antoine, Samuel, Julie et Éric, ainsi qu'à toute l'équipe ICS qui m'a accueilli.

A Présentation de Kelis

Kelis Conseil & DéveloppementCréée en mai 2004, la société d'ingénierie documentaire Kelis assure le rôle du développement de Scenari ainsi que celui de création et d'intégration de chaînes éditoriales adaptées aux besoins de ses clients et partenaires.

L'équipe compte à ce jour 11 employés et est formée de directeurs de projet, de modélisateurs et formateurs Scenari, d'ingénieurs, d'un rédacteur technique et d'un doctorant.

Scenari est un logiciel libre : toute la suite logicielle est disponible sous 4 licences open source (MPL, GPL, LGPL, CeCILL, voir le site de présentation de Kelis1).

De plus, les 3 modèles documentaires suivant (voir la présentation de Scenari plus bas) sont reversés sous ces mêmes licences :

OptimOffice (bureautique) ; Opale (contenus pédagogiques) ; Dokiel (documentation logicielle).

L'activité de Kelis peut se résumer en 3 axes principaux : l'analyse des besoins des clients en termes de gestion documentaire

(utilisation/adaptation d'un des trois modèles libres, création d'un modèle spécifique, etc.) ;

la formation des auteurs et la maintenance des modèles et des logiciels Scenari ;

le développement du noyau de Scenari et l'ajout de nouvelles fonctionnalités (collaboration, etc.).

B Présentation de l'unité ICS

Unité d'innovation ICSL'unité ICS (Ingénierie des Contenus et Savoirs) a été créée en 2002 à l'UTC suite au développement de Scenari, débuté quant à lui en 1999.

Elle a notamment pour rôle de valoriser l'usage de Scenari à travers : des projets pédagogiques internes à l'UTC (Opale) ;

1 - http://www.kelis.fr/co/identite.html

6

http://www.kelis.fr/co/identite.html


l'animation de communautés d'utilisateurs (par exemple, scenari-sup2 pour l'enseignement supérieur) ;

des travaux de recherche sur le croisement des chaînes éditoriales, des fonctionnalités collaboratives de gestion de contenu et de l'intégration du multimédia (projet C2M3).

C Présentation de Scenari

1. Contexte

Logiciels bureautiques classiquesDans la plupart des outils informatiques de production de documents, l'utilisateur assure simultanément les fonctions de rédaction (aspects sémantiques et structurels) et de mise en forme du contenu (typographie et styles). Cette double démarche entraîne une dépendance entre le fond et la forme d'un document, qui se retrouvent ainsi mêlés dans son format de stockage.

Chaînes éditoriales XMLEn ingénierie documentaire, une chaîne éditoriale est un procédé technologique qui, en adoptant le principe de séparation fond/forme, vise à s’émanciper des logiciels bureautiques classiques. En effet, le contenu d'un document est saisi via une interface permettant l'enrichissement sémantique (l'usage de l'italique pour des termes techniques sera par exemple remplacé par l'information "terme technique") ainsi que de la structuration (inclusion de sous-parties à une partie, etc.). Les informations de mise en forme ne sont ajoutées au contenu que lors de l'étape de publication.

Les chaînes éditoriales sont instrumentées à l'aide des technologies XML, et ce à trois niveaux :

1. un schéma XML précise la structure logique du type de document en jeu ;2. une instance XML contient le contenu d'un document de ce type et doit être

valide par rapport à son schéma ;3. une feuille de transformation (XSLT) énonce les règles de publication à

appliquer sur le contenu pour générer le document final.

Intérêts des chaînes éditorialesTout d'abord, un des avantages de cette approche est celui de la publication multi-support : à un même contenu, on peut appliquer différentes feuilles de transformation et ainsi obtenir des documents aux mises en forme variées bien que traitant du même fond (par exemple, un rapport aux formats HTML pour une consultation sur le Web, et PDF pour une impression papier).

De plus, la structure logique définie en amont par le schéma permet la fragmentation

2 - http://scenari-platform.org/sup/co/00sc-sup.html3 - http://scenari.utc.fr/c2m/co/00accueil.html

7

http://scenari.utc.fr/c2m/co/00accueil.html

http://scenari-platform.org/sup/co/00sc-sup.html


d'un document : une partie peut par exemple être externalisée du document où elle est utilisée ; elle sera alors inscrite dans un autre fichier et appelée par référence. Ceci a pour intérêt la ré-utilisation de fragments documentaires : une même partie peut être référencée dans deux documents différents.

Dans les deux cas, un contenu publié sur plusieurs supports ou ré-utilisé n'est stocké qu'à un seul endroit, ce qui limite l'usage du copier/coller et les problèmes d'intégrité qui en découlent (en cas de modification du contenu notamment).

2. La suite logicielle

Scenari est une suite logicielle permettant de créer et d'utiliser des chaînes éditoriales. Elle se décline en plusieurs outils, dont la plupart sont détaillés ici.

Modèles documentairesUn modèle documentaire (format wsppack) permet de produire des documents spécifiques dans un contexte d'écriture et de lecture donné.

Prenons l'exemple d'une organisation qui produit deux types de rapport, avec des structures différentes mais aussi des "blocs" communs, devant être publiés sous les formats HTML et PDF ; le modèle documentaire correspondant sera constitué :

des schémas XML des deux types de rapport et des blocs communs ; des feuilles de transformation associées à chacun des schémas précédant ; de la logique applicative propre au processus rédactionnel (externalisation ou

non des blocs, fonctionnalités collaboratives, etc.).

SCENARIchainSCENARIchain est l'environnement auteur de Scenari : il permet de rédiger du contenu et de le publier sous forme de documents finaux.

Il est nécessaire d'importer un modèle documentaire pour pouvoir créer des documents spécifiques à ce modèle (cf. SCENARIbuilder).

SCENARIbuilderSCENARIbuilder est l'environnement de modélisation de chaînes éditoriales Scenari : il permet d'établir la structure logique de types de documents et de définir les règles de mise en forme des contenus en vue de leur publication. Le résultat d'une modélisation est un modèle documentaire au format wsppack, qui peut être importé dans SCENARIchain en vue de son utilisation par les auteurs.

Avec les nouvelles fonctionnalités collaboratives de la version 4, SCENARIbuilder permet aussi de paramétrer la logique applicative des modèles (lifecycle, gestion des rôles, etc.).

SCENARIclient et SCENARIserverCes deux outils se combinent dans les situations où plusieurs auteurs distants travaillent en collaboration sur les mêmes contenus : chacun d'eux installe un

8


SCENARIclient sur son poste, qu'il connecte à un SCENARIserver centralisé (le même pour tous). Scenari fonctionne alors comme une application client/serveur, à travers le protocole HTTP/REST.

D Problématiques du stage

Scenari 4Avec la version 4, Scenari évolue vers un outil d'écriture collaborative en proposant de nouvelles fonctionnalités telles que l'historique, le versionning, l'annotation, la dérivation, la définition de rôle, le lifecycle, etc.

De plus, un nouveau mode de stockage des contenus (DB*, qui vient s'ajouter à FS*, le mode de stockage classique de Scenari) est disponible avec cette version.

Tests des nouvelles fonctionnalitésLa nécessité d'effectuer des tests sur Scenari paraît importante étant donnée l'élargissement de son spectre applicatif ; en effet le risque de régression (cf. partie "Veille technologique") apparaît dès lors que "de plus en plus de fonctionnalités sont de moins en moins testées (manuellement) tous les jours".

Tests d'utilisation à grande échelleLe passage à l'utilisation collaborative de Scenari implique un changement d'échelle important (en termes d'utilisateurs parallèles et de volumétrie de contenus) qui n'était jusqu'à là jamais atteint. De plus, le mode DB apporte des risques de perte de données dont on doit pouvoir clairement déterminer les seuils.

Enjeu du stageL'intérêt n'est pas d'écrire des tests pour toutes les fonctionnalités critiques (en tout cas, pas dans un premier temps), mais de commencer par réfléchir à un environnement de tests qui puisse répondre aux besoins énoncés plus haut.

9

I Veille technologique

A Les tests logiciels

Cette partie regroupe les différentes notions relatives à la thématique des tests découvertes dans la première partie de ce stage.

La veille technologique s'est prolongée dans une étude plus poussée du logiciel de test JMeter, présenté dans des fiches (cf. annexe 1 page 47) en annexe de ce rapport.

1. Généralités

Intérêt des tests logicielsLes tests n'ont pas pour ambition de garantir l'absence de fautes dans le fonctionnement du logiciel ; en revanche, ils permettent d'en simuler de nombreux cas d'utilisation afin d'observer s'il a le comportement attendu, ou, le cas échéant, de trouver des fautes.

Les 4 dimensions possibles d'un testOn peut définir un test par les 4 aspects suivants :

son point d'entrée dans le logiciel, c'est-à-dire à quel niveau de l'architecture il se place (par exemple l'interface, la couche métier ou encore le code lui-même) ;

son scénario, qui correspond à la séquence d'instruction à exécuter au niveau du point d'entrée ;

son jeu de données, à savoir toutes les valeurs qui changent potentiellement dans le scénario ;

ses critères de réussite, basés sur des résultats d'assertions* et/ou des métriques*.

Types de testsLe vocabulaire des tests est très varié : tests unitaires, fonctionnels, d'interface, de performance, de couverture, de non-régression, boîte blanche/noire, etc.

Cependant, tous ces termes ne sont pas à mettre sur le même plan : il faut donc les définir par rapport à leur contexte d'emploi.

10

T es ts log ic ie l s sur Scenar i > Ve i l l e techno l og ique

1.1. Tests boîte blanche/noire

Test boîte blancheOn parle de boîte blanche lorsqu'un test est "conscient" du code qu'il couvre : il peut s'agir par exemple d'un test qui instancie directement les classes du logiciel, à l'image d'un test unitaire.

Test boîte noireA l'inverse, on parle de boîte noire lorsque le test n'observe que les réponses du logiciel, sans se préoccuper du code invoqué par les actions du scénario : par exemple, le test peut se faire sur les réponses aux requêtes HTTP dans le cas d'une application client-serveur, ou encore au niveau de l'interface.

Ces deux types de test n'impliquent donc pas le même point d'entrée : le testeur instrumentera les tests dans un cas au niveau du code du logiciel lui-même, dans l'autre cas à un niveau supérieur.

Couverture de codeCet indicateur permet de rendre compte du code exécuté lors des tests ("traçage" du code appelé). Il s'appuie sur plusieurs métriques, dont :

la couverture d'instruction, à savoir le pourcentage des lignes de code exécutées ;

la couverture de décision, à savoir le pourcentage des chemins (dès lors qu'on a une instruction conditionnelle) exécutés.

Bien que la couverture de code puisse être instrumentée dans les deux types de test précédant, elle se rapproche dans tous les cas d'une stratégie de boîte blanche, dans la mesure où on peut optimiser un test boîte noire en adaptant son scénario et/ou son jeu de données, afin qu'il ait une meilleure couverture : on devient donc "conscient" du code couvert.

1.2. Tests unitaires/d'intégration/fonctionnels

Cycle en VCe cycle met en correspondance les étapes d'un projet de développement avec différents niveaux de test.

11


On peut globalement identifier 3 étapes/niveaux :1. spécifications (le plus en amont)/tests fonctionnels (le plus haut niveau) ;2. conception/tests d'intégration ;3. codage (le plus en aval)/tests unitaires (le plus bas niveau).

On a donc 3 types de test : les tests unitaires au niveau d'un module ; les tests d'intégration pour la mise en relation des modules ; les tests fonctionnels pour le respect des spécifications.

Similitudes avec la distinction boîte blanche/noireLes tests unitaires, ayant une proximité à la fois temporelle et "matérielle" avec le code, sont traditionnellement des tests boîte blanche, tandis que les tests fonctionnels, plus attachés au comportement global du logiciel, sont de types boîte noire.

12

Cycle en V


1.3. Tests de performance

IntérêtsUn test de performance a pour but d'évaluer des métriques représentant les conditions dans lesquelles le logiciel s'exécute. On distingue entre autres :

des métriques temporelles (temps de réponse d'une requête dans une architecture client-serveur typiquement) ;

des métriques techniques : taux d'occupation de la CPU, mémoire vive utilisée, accès disque, etc.

Ce type de test est donc particulièrement intéressant pour des applications multi-utilisateurs, lorsque les temps de réponse, les problèmes d'accès concurrents et le comportement du système supportant le logiciel (plus d'utilisateurs signifie aussi plus de ressources allouées) sont des points critiques à évaluer.

Temps de réponse d'une requêteSous ce terme, on peut distinguer :

le temps de transmission sur le réseau entre le client et le serveur (dans les deux sens - requête puis réponse) ;

le temps du traitement de la requête du serveur ; la somme des deux temps précédant qu'on peut nommer "temps global de

réponse" ; le temps de traitement du client après réception de la réponse, qu'on peut

éventuellement ajouter au temps de réponse global.

TerminologieLe vocabulaire des tests de performance regroupe :

les tests de charge, où l'attention est portée sur les actions simultanées (et potentiellement concurrentes) d'un grand nombre d'utilisateurs parallèles ;

les stress-tests, qui essaient de déterminer les limites de l'application en charge (nombre d'utilisateurs) ;

les montées en charge, dont l'intérêt est de comparer les performances à différents paliers de charge ;

les tests de volumétrie, qui évaluent les performances en fonction du volume de contenus/données enregistré dans l'application.

1.4. Tests de non-régression

Notion de régressionLes régressions apparaissent potentiellement dès lors que le code du logiciel est sujet à des changements fréquents (ajout/modification d'un module, etc.).

Exemple à la dernière itération, le logiciel a été testé avec une suite de tests* A ; les changements du code peuvent en apparence ne pas avoir d'impact sur les

13


modules de l'itération précédente ; cependant, ces changements peuvent avoir altéré leur fonctionnement

(régression) ; ceci doit être mis en lumière par la suite de tests A, qui doit donc être rejouée ; s'il y a effectivement régression, on résout les problèmes et on établit

éventuellement une suite de tests A'.

Il n'y a donc pas à proprement parler de test de non-régression, cependant on vérifie la non-régression à l'aide de la stratégie de tests.

2. Conception

Limite : exhaustivité impossibleOn ne peut pas tester tous les cas possibles en termes de scénario et de jeu de données par exemple.

Exemples pour les jeux de donnéesPour une fonction prenant en entrée un paramètre appartenant à un domaine non-borné, on voudrait typiquement répéter le test sur un grand nombre de valeurs de ce domaine (à défaut de pouvoir tester pour un nombre infini de valeurs).

Mais cette approche augmente rapidement le temps d'exécution des tests (et donc l'effort de test).

Lorsqu'il y a plusieurs paramètres d'entrée, on a en plus un effet combinatoire qui renforce ce coût temporel ainsi que le coût de conception du test.

Cette limite entraîne la nécessité d'optimiser la conception des tests.

2.1. Méthodologies classiques

Analyse aux valeurs limitesEn termes de jeux de données, l'optimisation la plus classique consiste à former des classes d'équivalence en fonction du domaine d'entrée de la fonction à tester.

Par exemple pour un paramètre entier, on appellera la fonction (entre autres) avec MAX_INT, MIN_INT, MAX_INT+1 et MIN_INT-1 (les deux derniers appels devront générer une faute).

Couverture de codeLa couverture de code (présentée plus haut) permet également d'optimiser la conception d'un test : si un jeu de données ou un scénario permet d'atteindre un taux de couverture (d'instructions ou de branches) acceptable, il n'a pas besoin d'être étendu ou développé davantage.

14


2.2. Méthodologies alternatives

L'optimisation de la conception de tests fait aussi l'objet de recherches, dont deux exemples sont présentés succinctement dans cette partie.

Injection de fautesLes données d'entrée du test peuvent être générées aléatoirement (cf. Fuzz testing4) pour faire apparaître des fautes inattendus.

On peut encore créer des logiciel "mutants" (cf. Mutation testing5) sur lesquels les tests doivent échouer (sorte de "test par l'absurde" : les erreurs sont attendues) ; dans le cas contraire, il faudra affiner la conception des tests (seul les tests sur le "bon" logiciel doivent réussir).

Révélation de fautesLes stratégies suivantes se basent sur les fautes révélées par les tests :

sélection : on choisit de ne garder les tests qui génèrent le plus de fautes ; prioritization6 : on ordonne les tests de sorte que le pourcentage cumulé des

fautes détectées soit atteint le plus rapidement possible (cf. image ci-dessous).

3. Organisation

Les tests s'inscrivent plus globalement dans une démarche de développement bien précise selon les contextes. Ainsi, les deux organisations décrites succinctement dans cette partie sont intéressantes à comparer.

3.1. Intégration continue

L'intégration continue7 consiste en plusieurs pratiques de développement, dont les principales sont :

le stockage des sources dans un dépôt centralisé ;

4 - http://en.wikipedia.org/wiki/Fuzz_testing5 - http://en.wikipedia.org/wiki/Mutation_testing6 - http://www.cs.hku.hk/research/techreps/document/TR-2010-11.pdf7 - http://fr.wikipedia.org/wiki/Int%C3%A9gration_continue

15

Le deuxième ordonnancement des tests révèle plus rapidement les fautes - source : "XML-manipulating test case prioritization for XML-manipulating services" (Mei, Chan, Tse, Merkel)

http://fr.wikipedia.org/wiki/Int%C3%A9gration_continue

http://www.cs.hku.hk/research/techreps/document/TR-2010-11.pdf

http://en.wikipedia.org/wiki/Mutation_testing

http://en.wikipedia.org/wiki/Fuzz_testing

http://en.wikipedia.org/wiki/Fuzz_testing


des modifications du code et des déploiements fréquents (quotidiens) ; le lancement automatisé des tests pour faire remonter les fautes et empêcher la

régression.

Test Driven DevelopmentOn parle de Test Driven Development8 lorsque l'écriture d'un test unitaire est faite en parallèle de celle du code du module testé, voire lui est antérieure (on se base alors sur les spécifications uniquement). Cette organisation est employée, par exemple, dans la méthode agile Extreme Programming et s'articule bien avec le processus d'intégration continue.

Cette approche semble bien adaptée à de nombreux projets de développement, impliquant par exemple un grand nombre de développeurs, un spectre fonctionnel très large (progiciels de gestion intégré par exemple), une forte criticité et donc la nécessité de "bonnes pratiques" de codage et d'écriture de tests ; dans le contexte de développement de Scenari, ces critères ne sont pas réunis (essentiellement au niveau du nombre de développeurs) pour qu'une telle approche soit pertinente.

3.2. Exploratory testing, context-driven testing, ad hoc testing

Ces approches se veulent beaucoup moins directives que dans le type d'organisation précédant.

Voici quelques caractéristiques les résumant : le testeur doit se reposer sur son expérience, sa créativité, son intuition, etc. ; le test ne doit pas être écrit en vue de prouver quelque chose de planifié : son

issue est ouverte (Exploratory testing9) ; un test peut être écrit pour n'être exécuté qu'une fois seulement :

l'automatisation n'est donc pas rigoureusement nécessaire (Ad hoc testing10) ; il n'y a pas de "bonnes pratiques" à appliquer pour l'écriture d'un test (Context-

driven testing11).

Si ce type d'organisation permet de ne pas être "aveuglé" par la complexité du logiciel à tester en valorisant toute démarche de test, aussi spécifique soit-elle, il est difficile de pouvoir réfléchir à un réel processus de test (outils, automatisation, structure des tests, etc.) qui vaille pour tout un logiciel, ou, à défaut, à un problème localisé (tests fonctionnels d'une part et tests de performance de l'autre, par exemple).

8 - http://fr.wikipedia.org/wiki/Test_Driven_Development9 - http://en.wikipedia.org/wiki/Exploratory_testing10 - http://en.wikipedia.org/wiki/Ad_hoc_testing11 - http://context-driven-testing.com/

16

http://context-driven-testing.com/

http://context-driven-testing.com/

http://en.wikipedia.org/wiki/Ad_hoc_testing

http://en.wikipedia.org/wiki/Exploratory_testing

http://fr.wikipedia.org/wiki/Test_Driven_Development


B Solutions envisagées pour Scenari

A l'issue de cette veille technologique, les notions théoriques sur les tests présentées précédemment ainsi que les possibilités de l'outil JMeter ont dû être confrontées aux besoins/spécificités de Scenari en matière de tests. Une réunion a donc été organisée afin de :

présenter les résultats de la veille ; discuter des directions futures (choix de l'outil, des stratégies, etc.).

Cette partie résume les solutions ainsi envisagées.

1. Stratégie générale de test

Cinq paramètres pour la pertinence d'un testL'idée est de pouvoir évaluer l'utilité d'un test, quelque soit son type (unitaire, de performance, etc.) et l'outil qui l'instrumente (donc son point d'entrée), par la combinaison de ces 5 critères :

coût de création (un test enregistré automatiquement aura un faible coût typiquement) ;

durée de vie (est-ce que le test sera toujours valable sur la prochain version du logiciel ?) ;

criticité (quel est le degré d'importance de ce qui est validé/invalidé par le test ?) ;

couverture (quelle portion du logiciel le test couvre-t-il ?) ; temps de debug (une erreur/insatisfaction révélée par le test est-elle

facilement identifiable en vue d'être corrigée ?).

Différents niveaux de testLes problématiques de test ont été découpées en plusieurs niveaux :

tests unitaires de la couche Java - OrientDB ; tests des services REST (communication HTTP client-serveur) ; autres niveaux de test : interface graphique (XUL-Runner), réseaux d'agents

(items mobilisés lors des publications) et scripts de build (construction des applications Scenari dans les environnements Windows, Mac OS, Linux, etc.).

Selon ces niveaux, la question de la fréquence d'exécution des tests doit-elle se poser : au niveau de la compilation dans l'IDE ? au niveau de chaque commit d'une modification ? au niveau de l'outil de déploiement (Ant12 dans le cas de Scenari), à chaque

nightly/release ? le test vise-t-il a être rejoué durablement, voire même plus d'une fois ?

Premier niveau : tests unitairesPlusieurs de ces tests ont déjà été développés (avec JUnit) pour l'intégration d'OrientDB dans Scenari 4.

12 - http://ant.apache.org/

17

http://ant.apache.org/


Ils sont intégrés au processus de déploiement (lancement automatique lors des nightlies). Leur exécution est relativement rapide.

Les principales caractéristiques de ces tests sont : une criticité importante (risque de corruption de la base de données mettant en

défaut les contenus de l'application par exemple) ; un faible temps de debug, car ces tests unitaires sont assez ciblés (on est à un

échelle de classes et non de services), ce qui rend une erreur facilement localisable.

Second niveau : tests des servicesÉtant donnée l'architecture REST utilisée par Scenari, JMeter peut jouer le rôle de l'application cliente en envoyant des requêtes HTTP au serveur : l'outil est donc adapté aux tests des différents services de Scenari.

Deux orientations sont possibles pour ces tests : tests fonctionnels (validation/vérification du comportement d'un service sous un

certain scénario) ; tests de performance (observation des temps de réponse d'un service).

Note sur l'usage du terme "fonctionnel"Précédemment, le test fonctionnel était défini comme ayant pour rôle le respect des spécifications dans le cadre d'un cycle de développement en V.

Dans le paragraphe précédent et dans la suite du rapport, les tests fonctionnels mis en place avec JMeter désigneront les tests des différents services de Scenari, d'un point de vue "boîte noire" par rapport à l'implémentation de ces services (on peut dire qu'ils évaluent le respect des spécifications d'un service).

Dans le cadre de ce stage, seul le second niveau a été approfondi. La suite de ce rapport sera donc focalisée sur la mise en place de tests fonctionnels et de tests de performance avec JMeter.

2. Test vs. initialisation du contexte

IdéeDans le processus d'écriture d'un test, on retombe souvent sur des actions de mise en place d'un contexte, autrement dit la création des données de test, qui va ensuite servir de base à des actions propres au scénario de test (modifications, suppressions, etc.), elles-mêmes éventuellement complétées par des assertions.

On peut donc distinguer deux temps dans un test, un premier servant à l'initialisation et un second correspondant réellement au test.

L'idée est d'adopter une démarche d'écriture de tests dans laquelle ces deux temps sont rendus indépendants : ainsi, un même contexte initial peut servir pour plusieurs tests, et inversement, un même test peut se baser sur différents jeux de données.

18


Types de jeu de données dans ScenariL'usage de Scenari implique la manipulation de 3 entités :

un modèle documentaire (wsppack) ; un atelier (wsp), qui doit être d'un et d'un seul seul modèle ; un item, spécifique à modèle et stocké dans un atelier.

Création d'un modèle documentaire de test asémantiqueDans le cadre des tests fonctionnels (des services), les jeux de données doivent pouvoir refléter les schémas "classiques" de Scenari (inclusion d'une partie dans une autre, externalisation obligatoire/optionnelle d'une partie, etc.). Cependant, il n'a pas été jugé souhaitable de reprendre un des modèles documentaires existant (OptimOffice ou Opale par exemple) pour les tests, car la sémantique qu'ils rajoutent ne semble pas utile ici.

Ainsi, un modèle asémantique réalisé avec SCbuilder s'avère utile : il doit comporter simplement un schéma XML dans un premier temps, mais pourra être enrichi de générations et de fonctions collaboratives pour d'autres tests. Voici une proposition de schéma UML pour ce modèle (sur lequel les tests présentés dans la partie "Tests fonctionnels" se basent) :

ButsA l'issue de cette réflexion, l'enjeu est donc de pouvoir créer des "briques" JMeter paramétrables, dédiées à des actions d'initialisation de base, à savoir :

installation d'un wsppack (paramètre : chemin du fichier wsppack) ; ajout d'un nouvel atelier (paramètre : titre de l'atelier) ; création d'un nouvel item (paramètres : chemin du fichier de l'item et URI).

19


En étant indépendantes, ces briques sont réutilisables dans tous les tests et leur maintenance est facilitée.

20

II Tests fonctionnels

Dans cette partie, nous détaillerons tout d'abord comment a été mise en place l'idée de "briques" d'initialisation à l'aide de JMeter, avant de présenter un autre composant JMeter ayant été implémenté pour des besoins d'assertions ; enfin, nous donnerons quelques exemples de tests fonctionnels écrits avec ce dispositif.

NoteLes concepts relatifs à JMeter qui sont employés dans cette partie (externalisation, variabilisation, plugins, assertions, etc.) sont présentés dans les fiches situées en annexe (cf. annexe 1 page 47).

A Mise en œuvre des "briques" d'initialisation

Pour réaliser les briques d'initialisation, la première idée a été d'utiliser des scripts .jmx* externes et de se reposer sur le mécanisme de variables de JMeter.

Cependant, cette façon de faire ayant quelques limites, il a été préféré d'implémenter directement ces briques en tant que plugins de JMeter.

Mais avant d'aborder ces deux méthodes, il convient de détailler le processus d'initialisation propre à Scenari :

Processus d'initialisation et dépendances entre entitésVoici un schéma décrivant, pour chaque brique d'initialisation, les paramètres requis et les informations contenues dans les réponses aux requêtes HTTP :

21

Déroulement "classique" de l'initialisation

T es ts log ic ie l s sur Scenar i > Tes ts fonc t ionne ls

Comme on peut le voir, il existe des dépendances entre les différentes entités : un atelier a besoin des informations de son wsppack pour s'initialiser ; en contexte DB, un item a besoin de l'ID unique de son atelier, retourné par

Scenari après création de l'atelier.

1. Première méthode : externalisation

Idée généraleChaque test commence par initialiser son contexte en faisant appel aux .jmx des briques dédiées (wsppack, wsp et item) ; pour cela, il analyse un fichier d'initialisation (au format JSON) qui spécifie les données pour chaque brique (cf. image ci-dessous).

Cette initialisation doit se faire de manière hiérarchique étant données les dépendances des différentes entités (cf. schéma plus haut) ; cependant, une entité dépendant d'une autre peut aussi être initialisée seule (par exemple, on n'a besoin que d'un item, peu importent le modèle documentaire et l'atelier) : pour cela, chaque brique doit proposer une initialisation à une valeur par défaut.

ArchitectureLes briques sont représentées dans une arborescence de fichiers (cf. première capture d'écran ci-après). Chacune correspond à un dossier contenant (cf. seconde capture d'écran ci-après) :

un script .jmx (dans lequel on trouve la requête HTTP adéquate) ; des scripts de traitements intermédiaires appelés dans le .jmx ; le fichier d'initialisation par défaut ; éventuellement, un ou plusieurs fichiers (wsppack ou items typiquement) pour

l'initialisation des données par défaut.

22

Exemple de fichier d'initialisation


Ci-dessous sont résumées les actions du .jmx de chaque brique :

Brique "pack"1. un script met une valeur par défaut au chemin du wsppack s'il n'a pas été

précisé dans le fichier dans le fichier d'initialisation du test ;2. le wsppack est installé (requête HTTP) et son ID est extrait de la réponse ;3. une requête permettant de lister les informations sur les wsppacks installés est

appelée ;4. la réponse à cette requête contient des informations qui doivent être

enregistrées dans des variables pour permettre d'ajouter des ateliers de ce modèle plus tard (cf. brique "wsp").

Brique "wsp"1. idem que pour la brique "pack" avec une valeur par défaut au code de l'atelier ;2. l'atelier est créé (requête HTTP) grâce aux informations du dernier wsppack

installé (qui peut être le wsppack par défaut ou bien celui spécifié dans le fichier d'initialisation du test) ;

3. on tente de récupérer un ID de la réponse (si on est en contexte DB) ;4. la variable "wspCode" prend pour valeur l'ID (en contexte DB) ou reste égale au

titre de l'atelier (en contexte FS).

Brique "item"1. idem que pour la brique "pack" avec une valeur par défaut au chemin de l'item ;2. l'item est créé (requête HTTP) avec comme paramètre le code du dernier atelier

ajouté (qui peut être l'atelier par défaut ou bien celui spécifié dans le fichier d'initialisation du test).

A l'issue de cette initialisation, le test peut réutiliser les éléments installés/créés grâce aux variables qui ont été enregistrées : par exemple, la requête permettant de modifier le contenu d'un item initialisé plus tôt comporte des paramètres tels que le code de son atelier et son URI.

23


Limites de cette méthodeFonctionner à l'aide de briques externalisées comporte plusieurs inconvénients :

beaucoup de variables JMeter sont initialisées pour que l'architecture fonctionne ;

il y a également besoin de beaucoup de scripts pour gérer ces variables ; permettre l'initialisation par défaut introduit de la complexité (il faut envisager

de nombreuses combinaisons dans le fichier d'initialisation) ; l'externalisation morcelle le test en plusieurs fichiers.

Pour simplifier le processus d'initialisation de test, il parait donc plus intéressant de disposer de briques directement implémentées dans JMeter.

2. Seconde méthode : implémentation

Idée généraleIl s'agit d'implémenter 3 plugins dans le but de manipuler chaque brique comme un composant JMeter.

Chacun de ces composants est une spécialisation du HTTP Sampler ; cependant, le testeur ne renseignera aucune URL ni argument dans le composant, mais simplement les paramètres dont la brique d'initialisation a besoin (c'est le code du plugin qui construit l'URL adaptée).

Contrairement à la méthode précédente, il n'y a aucune initialisation par défaut de prévue (par exemple, une création d'item aura forcément besoin d'un atelier ajouté plus haut dans le plan de test).

Composant "Install pack"

Ce composant requiert simplement le chemin du wsppack à installer, qui est ajouté dans le corps de la requête à l'exécution.

Les informations relatives au wsppack sont sauvegardées dans une structure de données "PackInfos" comprenant les champs "id", "key", "lang", "uri", "version" et "title" (rappel : ces informations sont nécessaires pour l'ajout de tout atelier de ce modèle documentaire).

Deux variables JMeter sont créées à partir de cet objet, ayant respectivement pour nom :

le label du composant (valeur du champ "Name") ; "lastPack".

Les informations du wsppack installé seront donc accessibles via les syntaxes "${[nomDuComposant]}" et "${lastPack}".

24

Interface du composant "Install pack"


Cependant, chaque nouveau pack installé "écrase" la variable "lastPack" avec son propre objet "PackInfos".

Composant "Create wsp"

Ce composant requiert au minimum le titre de l'atelier à créer (champ "Wsp title".

Le champ "wspCreateParams" correspond à un des argument de la requête HTTP, dont la valeur est spécifique au contexte DB ou FS (la principale différence est qu'en contexte DB, il n'y a pas besoin de préciser de répertoire de stockage des contenus de l'atelier) ; à l'exécution, l'élément "[title]" sera remplacé par le titre renseigné.

Enfin, le champ "Wsppack key var" permet d'indiquer le nom d'une variable "PackInfos" ; si ce champ est laissé vide, cette variable sera "lastPack" par défaut.

Après l'exécution de la requête, un objet "WspInfos" est créé avec les champs "title", "code" et "pack" (un objet de type "PackInfos") ; la valeur du champ "code" sera égale à l'ID généré par Scenari et extrait de la réponse en contexte DB, ou simplement à celle du champ "title" en contexte FS.

Comme précédemment, deux variables JMeter sont initialisées avec cet objet, la première sous le label du composant, la seconde en tant que "lastWsp".

Composant "Put item"

Ce composant possède une interface un peu plus complexe : la partie haute concerne le contenu de l'item à créer ;

25

Interface du composant "Create wsp"

Interface du composant "Put item"


la partie basse permet de spécifier l'URI de l'item dans Scenari.Le contenu de l'item peut être importé de deux manières différentes :

1. soit en spécifiant uniquement le chemin d'accès au fichier de l'item ;2. soit en important le flux XML d'un fichier (affiché dans la grande zone de texte),

qui peut être modifié à la convenance du testeur.L'URI d'un item débute par le code de son atelier (ID/titre selon le contexte DB/FS), suivi du chemin de l'item : "[espace/][sous-espace/][...]/nomItem.extension". Elle peut elle aussi être spécifiée de de deux façons :

1. une variable "WspInfos" est précisée dans le champ "Wsp key var" pour que le code de l'atelier correspondant soit mis en début d'URI, tandis que le champ "Dist uri" se charge du reste de l'URI (chemin de l'item dans l'atelier) ;

2. plus simplement, toute l'URI peut être spécifiée de manière "brute" dans le champ "Raw uri".

Un objet "ItemInfos" est créé avec les champs "uri" et "id" (uniquement en contexte DB) ; comme précédemment, il est enregistré sous deux variables JMeter, dont "lastItem".

Fonction d'accès aux champs des objets "PackInfos", "WspInfos" et "ItemInfos"Les informations sauvegardées sur chaque entité initialisée doivent pouvoir être exploitées dans la suite du test ; cependant, JMeter ne semble pas disposer d'une syntaxe permettant l'accès aux champs d'un objet enregistré comme variable.

Pour cela, nous avons implémenté la fonction "getObjectField" qui : prend deux paramètres, un nom de la variable et un champ ; renvoie la valeur de ce champ pour l'objet contenu par cette variable.

Par exemple, la syntaxe "${getObjectField(lastWsp, code)}" permet d'obtenir le code du dernier atelier ajouté.

B Implémentation d'un composant d'assertion

Les tests fonctionnels sur Scenari doivent pouvoir comporter des assertions validant ou non les réponses aux requêtes envoyées par JMeter.

Nous présenterons ici l'implémentation d'un plugin visant à instrumenter un certain type d'assertion.

Assertion avec la requête GetSrcGetSrc (cf. annexe 2 page 54) est une requête particulièrement utile dans un test pour établir le résultat d'une assertion concernant un item ; en effet, elle renvoie des informations permettant de valider des comportements attendus, comme par exemple :

le passage d'un état de dérivation de l'item (drvState) à un autre suite à une action spécifique ;

26


idem dans le cadre d'un atelier brouillon (drfState) ; le statut de l'item dans un des deux cas précédant (atelier dérivé ou brouillon).

Le schéma ci-dessous détaille les étapes que peut suivre un scénario pour réaliser une assertion avec cette requête :

Cette combinaison (requête GetSrc, extracteur puis assertion) peut toutefois devenir un peu lourde si elle doit être utilisée de nombreuses fois dans un même scénario ; c'est pourquoi elle mériterait d'être "fusionnée" dans un seul composant JMeter dédié :

Plugin "Check states"

Ce composant requiert les 3 paramètres d'une requête GetSrc ; dans le troisième (champs à contrôler), la syntaxe "champ1=valeur1*champ2=valeur2*..." permet en plus de spécifier optionnellement les valeurs attendues pour chaque champ (précision : les champs sont séparés par le caractère '*').

Lors de l'exécution, ce composant renverra une erreur dès qu'une des valeurs d'un champ sera différente de la valeur attendue ; dans ce cas, un message accompagnant l'erreur spécifiera les champs concernés.

Malgré son usage, ce plugin est implémenté comme un HTTP sampler et non comme un "pur" composant d'assertion, puisqu'il doit envoyer une requête avant de retourner un résultat.

Usage pour plusieurs itemsDans ce composant, le paramètre des champs à contrôler est le même pour tous les items qu'on veut contrôler ; on ne peut donc pas spécifier deux items avec des valeurs

27

Déroulement "classique" d'une assertion avec une requête GetSrc dans JMeter

Interface du composant "Check states"


attendues différentes sur le même champ. Dans ce cas, il vaut donc mieux utiliser ce plugin pour un seul item à la fois.

C Exemples de tests

Cette partie présente des tests écrits pour deux fonctionnalités de Scenari 4 DB : les ateliers dérivés et brouillon (cf. annexe 3 page 54).

A l'heure de l'écriture de ce rapport, ces tests ne sont pas forcément finalisés et peuvent encore évoluer pour être éventuellement intégrés dans une routine de tests de non-régression, par exemple ; néanmoins, ils peuvent illustrer l'usage de JMeter et des plugins exposés précédemment.

Après avoir abordé chacun des deux tests, nous proposerons une stratégie de tests fonctionnels plus générale imaginée pour Scenari.

1. Tests des ateliers brouillon

Ce test s'appuie sur une "chaîne" d'ateliers brouillon (cf. tableau ci-dessous).

atelier référence (ref) brouillon (drf)

wsp0 aucun wsp1

wsp1 wsp0 wsp2

wsp2 wsp1 aucun

Tableau n°1 Exemple de chaîne de longueur égale à 2

Initialisation

Les étapes d'initialisation sont les suivantes :1. installation du wsppack (modèle asémantique dédié aux tests) ;2. ajout de l'atelier de référence (le nom est composé d'un préfixe - variable - et

d'un indice - 0 pour ce premier atelier) ;

28

Initialisation du test


3. création de deux items dans cet atelier ;4. création de la chaîne d'ateliers brouillon (script externe) dans une boucle (le

nombre d'itération est égal à la longueur de la chaîne, définie dans une variable).

Premier test - check states, delete, restore, etc.La séquence ci-dessous est appelée pour chaque atelier brouillon (ateliers dont le suffixe du titre est supérieur ou égal à 1) ; elle prend comme paramètres :

le code de l'atelier brouillon ; le code de son atelier de référence (atelier de l'indice qui précède - atelier 3

pour le brouillon 4 par exemple) ; les URIs des items du premier atelier de référence ("items de base"), c'est-à-

dire de l'atelier d'indice 0.

Le but est de vérifier le statut des items de base (-1 s'ils sont absents, 1 s'ils sont présents) dans un atelier brouillon et dans son atelier de référence après chaque action élémentaire (ici, supprimer et restaurer un atelier) :

statuts dans ref statuts dans drf

création de drf 1 (présent) 1

suppression de ref -1 (absent) -1

restauration de ref 1 1

suppression de drf 1 -1

restauration de drf 1 1

suppression de ref et de drf

-1 -1

restauration de ref et de drf

1 1

Tableau n°2 Statuts des items de base attendus après chaque action

29

Séquence d'actions du premier test


Second test - create item, check above/self/below, commitLe scénario est le suivant :

1. création d'un item dans un des ateliers brouillon, qu'on nommera "atelier courant" ;

2. vérification des états (statut et drfState) pour ce nouvel item dans : la partie "inférieure" du chaînage (atelier de référence de l'atelier courant,

et "au-dessus") ; l'atelier courant ; la partie "supérieure" du chaînage (atelier brouillon de l'atelier courant, et

"en-dessous").3. commit du nouvel item dans l'atelier courant ;4. l'indice de l'atelier courant est décrémenté (il devient son propre atelier de

référence), puis les étapes précédentes sont répétées jusqu'à ce qu'il vaille 0.Pour chaque itération de ce scénario, les états attendus pour le nouvel item sont les suivants :

statut drfState

partie inférieure -1 null

atelier courant 1 created

partie supérieure 1 notOverriden

2. Tests des ateliers dérivés

InitialisationCe test s'appuie sur le contexte suivant :

atelier master (msr) dérivation(s) (drv)

source(s) de dérivation (drvSrc)

wsp aucun drv1 aucune

drv1 wsp aucune aucune

drv2 wsp aucune drv1

drv3 wsp aucune drv1, drv2

30


TestLe tableau suivant résume les actions du scénario (colonne la plus à gauche) ainsi que les états de dérivation (drvState) ou statuts de l'item concerné dans les différents ateliers dérivés :

drv1 drv2 drv3

ajout de "item1" dans drv1

createdNew notOverriden notOverriden

ajout de "item2" dans drv2

(status=-1) createdNew notOverriden

modification de "item1" dans drv2

overridenNew notOverriden

dérivation achevée de "item1" dans drv2

createdNew overridenDone

modification de "item1" dans drv1

overridenDirty notOverriden

ArchitectureDans ce test, certains traitements sont externalisés avec les paramètres nécessaires, tels que :

la création d'un atelier dérivé ; le marquage d'une dérivation achevée ; la vérification des états de dérivation et statuts d'items de tous les ateliers

dérivés ayant pour source de dérivation un atelier spécifique (par exemple pour drv1, il s'agit de drv2 et drv3).

3. Stratégie générale de tests fonctionnels

Afin de savoir quelle stratégie adopter pour les tests fonctionnels, au delà des deux exemples précédant, il est intéressant d'essayer de structurer les différentes fonctionnalités, de repérer leurs points communs, leur niveau, etc.

Dans le cadre de tests sur les différents types d'ateliers (dérivé, brouillon) on pourrait identifier deux axes :

le contexte (atelier normal, dérivé ou brouillon) ; les actions (de base : copier un item, renommer, déplacer, supprimer, etc. ;

mais aussi liées à la collaboration : validation, gestion des droits, lifecycle, commentaires, etc.).

En effet, les actions sont transversales par rapport aux contextes, qui ont quant à eux

31


des façons singulières de les traiter (par exemple, il est impossible de renommer un item dans un atelier brouillon s'il existait déjà dans l'atelier de référence).

Certaines actions sont spécifiques à un contexte (ou ne valent pas pour tous) : par exemple, commit et revert ne concernent que les ateliers brouillon.

Voici un tableau résumant ce croisement possible entre les contextes et les actions :

Ateliers dérivés (drv)

Ateliers brouillon (drf)

Atelier normal

copier un item comportement général/spécifique ?

comportement général/spécifique ?


renommer un item

... ... ...

...

passage d'un état du lifecycle à un autre




...

commit (spécifique à drf)

comportement spécifique

...

32

III Tests de performance

Intérêts pour ScenariLe besoin en tests de performance (au sens large) sur Scenari concerne tout d'abord les situations où plusieurs utilisateurs interagissent sur le même SCENARIserver dans un contexte DB. En effet, si les scénarios d'usage simultanés se déroulent dans un même atelier (avec un travail potentiel sur les mêmes items), on peut rencontrer des problèmes d'accès concurrents.

De plus, le contexte DB met en jeu différentes techniques de stockage selon l'échelle du nombre d'items en jeu à des fins d'optimisation : par exemple, l'index des références entre les items a une structure de données tabulaire jusqu'à un certain seuil, puis arborescente au-delà. Ainsi, un autre objectif est de tester la validité de ce stockage sur des volumes de données variant, potentiellement très importants (plusieurs milliers d'items), et ce toujours en situation de travail collaboratif.

Enfin, les scénarios "intra-atelier" ont tout aussi intérêt à être rejoués en situation de montée en charge dans le cadre d'un test de stress : l'exécution en parallèle du même scénario à grande échelle peut en effet faire apparaître certaines limites de l'application serveur.

A Proxy JMeter et tests de performance

Dans cette partie, nous verrons en quoi le proxy JMeter semble bien adapté pour enregistrer des scénarios rejouables dans le cadre de tests de performance, avant d'expliquer l'adaptation nécessaire de son implémentation pour fonctionner avec Scenari 4 DB.

1. Enregistrement de scénarios parallèles

Dispositif d'enregistrementPlusieurs SCclients peuvent se connecter au même SCserver via le proxy. Dès lors, les requêtes sont enregistrées les unes à la suite des autres, indépendamment du client d'où elles sont envoyées.

33

T es ts log ic ie l s sur Scenar i > Tes ts de per fo rmance

Le scénario, bien que correspondant aux actions parallèles de plusieurs utilisateurs, se retrouve enregistré sous la forme d'un seul script. Cette solution semble assez avantageuse, car elle nous évite de devoir mettre en place une architecture de test distribuée.

En revanche, il faut bien préciser qu'un script JMeter, même s'il est obtenu par des actions simultanées de deux utilisateurs différents, correspond à une séquence de requêtes : deux requêtes ayant lieu strictement au même moment pendant l'enregistrement ne seront pas "parallélisées", mais l'une sera placée après l'autre (l'exécution parallèle est néanmoins possible dans JMeter, mais seulement au niveau des threads).

Durée d'un scénarioUn scénario de travail collaboratif sur Scenari se doit d'être "réaliste", au moins au niveau de la durée : en effet, dans le cadre d'une montée en charge par exemple, les scénarios doivent durer un certain temps (si leur exécution est quasi-instantanée, la montée en charge perd son sens). Pour répondre à ce besoin, il paraît important d'enregistrer les think-times des utilisateurs (le script résultant comportera donc des timers entre les requêtes) ; ainsi, le test rejoué durera autant de temps que le test manuel.

Enregistrer ou simuler un travail collaboratif ?En ce qui concerne le nombre d'utilisateurs parallèles à définir pour le scénario, deux méthodes sont envisageables :

1. soit le test est enregistré en situation réelle, c'est-à-dire à l'aide de plusieurs utilisateurs, chacun sur son poste et redirigeant les requêtes de son SCclient vers le proxy JMeter localisé sur un machine "centrale" (celle qui lance JMeter) ;

2. soit on "simule" la collaboration à l'aide d'un seul utilisateur, qui ouvre plusieurs SCclients (cf. précision plus bas) passant par le proxy JMeter situé sur le même poste (en localhost).

Si la première méthode a l'avantage d'être la plus réaliste et peut mieux refléter les

34

Proxy JMeter enregistrant les actions de 3 SCclients différents sur un même SCserver


situations de concurrence, elle est aussi plus coûteuse et incertaine quant au résultat obtenu. La seconde, bien que peu confortable pour l'utilisateur-testeur (qui doit "jongler" entre toutes ses fenêtres de SCclient), semble plus réalisable, au moins pour des tests "à la demande", pas très longs et n'impliquant pas plus de 3 ou 4 utilisateurs. C'est donc cette seconde méthode qui a été choisie pour le moment.

Ouvrir plusieurs SCclients sur un même posteScenari étant une application XUL (au même titre que Mozilla Firefox par exemple), on peut la lancer avec un profil utilisateur spécifique. Ainsi, en créant autant de profils que le nombre d'utilisateurs souhaité (via le gestionnaire de profils), on parvient à lancer le bon nombre d'instances de SCclient sur le même poste.

Les paramètres de la ligne de commande à utiliser (-p -no-remote) sont spécifiés dans ce tutoriel : Lancer Firefox avec différents profils13 (à appliquer de la même manière pour SCclient.exe).

Problème des think-times dans la méthode d'enregistrement par simulationAvec cette méthode, la simultanéité des actions des utilisateurs est moins bien représentée, puisque le seul utilisateur-testeur ne peut agir que sur un SCclient à la fois. Pour corriger ce temps de latence entre le passage d'une fenêtre à une autre et se rapprocher d'un scénario quasi-parallèle, la solution adoptée est de "lisser" le temps entre chaque requête en imposant une valeur maximale de 5 secondes au think-time enregistré.

2. Adaptation de l'implémentation du proxy

La différence entre les contextes FS et DB joue un rôle important dans l'enregistrement des tests manuels sur Scenari : si dans le contexte FS, on peut utiliser le proxy JMeter tel qu'il a été implémenté, le contexte DB ne nous le permet pas, d'où la nécessité d'adapter son implémentation à nos besoins. Prenons un exemple simple de scénario pour illustrer cette différence : l'utilisateur ajoute un atelier ayant pour titre "rapportTN10", dans lequel il créé un item.

En contexte FSLa requête d'ajout de l'atelier est enregistré avec le titre "rapportTN10" en paramètre.

L'URL de la requête de création de l'item comportant le code de l'atelier, qui dans ce contexte correspond au titre, est également enregistrée avec "rapportTN10".

Le test rejoué fonctionnera tant qu'il y a bien correspondance entre les deux occurrences de ce code/titre (pour l'ajout de l'atelier et la création de l'item dans cet atelier) : on peut très bien remplacer chaque occurrence par "rapportTN09" ou encore par une variable "${titreAtelier}" initialisée auparavant.

13 - http://www.sevenforums.com/tutorials/208070-firefox-create-run-multiple-profiles.html

35

http://www.sevenforums.com/tutorials/208070-firefox-create-run-multiple-profiles.html


En fait, la validité de la syntaxe de la requête de création d'item ne dépend que d'un paramètre d'envoi (le titre de l'atelier ajouté), et en aucun cas d'une réponse du serveur.

En se basant sur ce raisonnement, un test enregistré en contexte FS est rejouable sans problème.

Rejouer un test enregistré en contexte FSDans le contexte FS, il n'est pas permis d'avoir plusieurs ateliers du même code/titre. Ainsi, un même test joué deux fois de suite sans retour à l'état initial (aucun atelier par exemple), rencontrera une erreur. Une solution est de supprimer l'atelier à la fin du test enregistré manuellement.

En contexte DBContrairement au contexte FS, chaque atelier ajouté ou item créé entraîne la génération d'un ID unique par le serveur. Dans l'exemple de l'atelier "rapportTN10", l'ID retourné correspond au code dont on a besoin dans la requête de création de l'item.

Entre l'enregistrement du test manuel et sa ré-exécution par JMeter, les IDs (celui non-seulement de l'atelier mais aussi de l'item), auront changé, tandis que l'ID original de "rapportTN10" reste codé "en dûr" dans le script de test.

Ainsi, pour être rejoué de manière cohérente, un scénario doit pouvoir remplacer dynamiquement chaque ID original par son équivalent généré au moment du test ; cette adaptation de l'implémentation du proxy a fait l'objet d'une surcharge du proxy JMeter original, détaillée ci-après.

Surcharge du proxy JMeterL'idée principale de ce proxy adapté est d'assurer le remplacement dynamique des IDs d'atelier ou d'item grâce au mécanisme de variabilisation de JMeter. Ceci est réalisé en plusieurs étapes :

1. dès que le proxy enregistre une requête d'ajout d'atelier/d'item, l'ID doit être extrait de la réponse : de cette même requête s'il s'agit d'un atelier (réponse au format XML) ; de la prochaine requête GetSrc sur l'URI de la ressource demandant la

valeur du champ srcId s'il s'agit d'un item (réponse au format JSON) - cf. plus bas ;

2. chaque ID extrait est sauvegardé dans une liste ;3. un composant Regex extractor (post-traitement, cf. plus bas) est ajouté comme

élément enfant de la requête ayant permis d'extraire l'ID (requête d'ajout de l'atelier pour un atelier, requête GetSrc pour un item) : c'est ainsi que les IDs pourront être extraits dynamiquement et enregistrés comme variables lors des prochaines exécutions des tests ;

4. à chaque requête, un traitement se charge de remplacer dans les différentes propriétés du composant HTTP Sampler (URL, arguments POST, etc.) les occurrences des ID sauvegardés dans la liste par leur "équivalent variable" (l'ID est entouré de "${" et de "}").

36


Les 3 premières étapes ont lieu de manière synchrone (lors de l'enregistrement de la requête dont la réponse contient l'ID), tandis que la dernière a lieu indépendamment des 3 autres.

Rôle de la requête GetSrcDans la plupart des cas, une création/modification d'item est suivie de l'envoi automatique du client d'une requête GetSrc (cf. annexe 2 page 54) demandant le srcId : l'extraction de l'ID de l'item se fait donc de manière quasi-synchrone avec sa création lors de l'enregistrement par le proxy surchargé.

Rôle du composant Regex extractorCe composant permet d'appliquer une expression régulière à la réponse d'une requête, et d'en sauvegarder le résultat dans une variable JMeter.

Dans le cas du proxy surchargé, le Regex extractor ajouté (cf. plus haut) cherche à extraire l'ID et à le sauvegarder dans une variable du nom de l'ID original.

B Application

Le proxy JMeter surchargé a été utilisé pour créer et exécuter un test de performance sur Scenari 4 DB ; cette partie correspond au rapport de test qui en a résulté.

37

Schéma récapitulatif du fonctionnement du proxy surchargé en contexte DB


1. Description succincte

Ce test a pour but d'évaluer les performances de Scenari 4 DB pour 250 utilisateurs (voire plus) en parallèle.

Les fonctionnalités testées sont l'import d'un fichier .scar (archive Scenari) de 50 Mo, ainsi que diverses actions d'affichage et de lecture.

Le scénario commence sur une base de données vide puis est répété plusieurs fois pour atteindre une volumétrie conséquente.

MétriquesLes métriques à analyser sont :

les temps de réponse utilisateur ; le taux d'activité de la CPU sur le serveur ; la mémoire vive de la JVM utilisée par l'application sur le serveur.

OutilsLes outils utilisés sont :

JMeter pour l'enregistrement et l'exécution du test ; Java VisualVM pour la visualisation d'informations de la JVM (CPU et mémoire

vive) ; un SCserver et 3 instances de SCclient qui y sont connectées.

Les caractéristiques du serveur sont les suivantes : processeur Intel Core i5-2300 (vitesse : 2801.000 MHz ; cache : 6144 KB ;

nombre : 4) ; RAM de 16 GB ; carte mère Intel Desktop Board DH67VR14 ; OS : Ubuntu 10.04 ; disque dûr de 2 TB Seagate ST2000DM001-9YN1 (pas en RAID) ; version de SCserver : 4.0.311, nightly 20120719-0552

Résultats attendusL'enjeu est de savoir si les temps de réponse des deux fonctionnalités testées (import du .scar et actions d'affichage/de lecture) restent raisonnables sous ces conditions de charge et de volumétrie. Si ces temps de réponse deviennent anormalement long à partir d'un certain palier, une limite de charge/volumétrie pourra être établie par rapport à ces fonctionnalités.

Remarque sur l'import de fichier .scarBien que la montée en charge la sollicite de nombreuse fois, cette fonctionnalité n'est utilisée en réalité que peu fréquemment ; cependant, elle permet d'atteindre un niveau de volumétrie suffisamment élevé afin d'observer le comportement de requêtes bien plus fréquentes (lecture de contenus typiquement).

14 - http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/desktop-board-dh67vr.html

38

http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/desktop-board-dh67vr.html


2. Protocole

2.1. Scénario enregistré et post-traitements

On enregistre le scénario suivant à l'aide de JMeter (timers inclus) :1. connexion de 3 utilisateurs ;2. création d'un atelier par un seul utilisateur ;3. import d'un .scar par un seul utilisateur ;4. actions de lecture du contenu (ouverture d'items) par tous les utilisateurs

simultanément - aucune action d'écriture.

Élimination des requêtes "adminWsp - List"Le scénario enregistré contient quelques requêtes de ce type (dont le rôle est de retourner la liste des ateliers disponibles sur le serveur).

Dans les usages actuels de Scenari, le nombre d'ateliers par serveur est inférieur à une centaine. Cependant, dans un contexte réel avec plusieurs milliers d'ateliers, le temps de réponse de cette requête est très long ; il sera nécessaire de modifier l'implémentation actuelle pour éviter le chargement sur le client d'une telle liste d'ateliers.

Ainsi, pour ne pas perturber le test qui aboutit à plus de 6000 ateliers créés, cette requête a été désactivée dans le script.

Allongement de la durée du test et estimationLa durée du scénario enregistré est de 4 minutes environ (3 min 54 s). Avec la montée en charge (cf. plus bas), cela signifierait qu'un .scar est importé toutes les 12 minutes par un utilisateur (3 utilisateurs x 4 min), ce qui paraît beaucoup trop fréquent (cf. "Remarque sur l'import de fichier .scar" plus haut).

Pour rendre cette fréquence plus raisonnable, deux optimisations sont possibles : allonger la durée du test ; estimer que le scénario représente plus d'utilisateurs parallèles.

On commence par augmenter la somme des think-times en regroupant toutes les actions de lecture ayant lieu après l'import du .scar dans une boucle, dont le nombre d'itérations est choisi pour atteindre la durée de 25 minutes (on estime pour cela la durée de l'import à 1 minute et l'exécution de chaque requête à 200 ms).

Après cela, la moyenne des think-times est d'environ 1,7 secondes ; si on considère que 10 utilisateurs agissent en parallèle, on arrive à une moyenne d'une action toutes les 17 secondes, ce qui paraît réaliste.

La fréquence d'import de .scar par utilisateur (10 x 25 min = 4 h 10 min) devient alors plus raisonnable.

39


2.2. Jeux de données

Modèle documentaireLe modèle utilisé pour le test est OpaleRing 3.3.1.00 (version d'Opale pour Scenari 4).

Le déroulement du scénario est dépendant de cette donnée, car le fichier .scar importé (cf. plus bas) est constitué exclusivement de contenus Opale.

Fichier .scarL'archive a été constituée à partir de contenus Opale 3.2 migrés vers la version 3.3.

Elle correspond à un atelier comportant 338 items ainsi que 71 espaces et sous-espaces, ce qui équivaut à peu près à 50 Mo.

2.3. Déroulement

Le test est réalisé à l'aide du plugin JMeter Stepping thread group15, dans lequel on fixe le maximum de montée en charge à 25 threads ; chaque thread représentant 10 utilisateurs (cf. estimation précédente), on simule donc bien jusqu'à 250 utilisateurs en parallèle.

Montée en chargeLes threads sont lancées une à une à une minute d'intervalle. Après le début de la dernière, toutes les threads sont maintenues pendant encore 25 minutes (pour correspondre à peu près à la durée d'exécution d'un scénario), avant d'être arrêtées à raison d'une toute les 5 secondes.

Lorsqu'une thread se termine, elle boucle sur elle-même tant que le durée où toutes les threads sont maintenues n'est pas écoulée : au final, il y aura donc plus d'ateliers créés que le nombre de threads prévu (25 ici).

Mises à niveau de la volumétrieOn fixe les paliers de volumétrie avec comme unité le nombre d'ateliers présents sur la base.

A chaque palier atteint, le test est lancé, puis on complète le nombre d'ateliers nécessaires pour arriver au prochain palier.

15 - http://code.google.com/p/jmeter-plugins/wiki/SteppingThreadGroup

40

Montée en charge pour un test de 25 threads

http://code.google.com/p/jmeter-plugins/wiki/SteppingThreadGroup


Voici le tableau récapitulatif des paliers de volumétrie pour ce test de performance :

Nombre d'ateliers

Nombre d'items et d'espaces

Nombre de threads du test

2100 881751 25

2300 938603 25

2500 1020403 25

3100 1265723 25

3300 1347114 25

3500 1428914 25

4100 1674314 25

4300 1756114 25

4500 1837914 25

5000 2042005 35

5500 2246505 45

6000 2449778 55

Tableau n°3 Paliers de volumétrie

On notera que les 3 derniers tests se font respectivement 35, 45 et 55 threads, et ce afin de déterminer si le serveur se comporte encore normalement à ces niveaux-là.

41


3. Résultats

Temps de réponseVoici, pour exemple, les courbes des temps de réponse de chaque couple (service, cdaction) pour le test au premier palier (2100 ateliers) :

On remarque deux choses : le temps de réponse (par nombre de threads actives) de l'import du .scar,

représenté par la courbe violette ("import - Import" dans la légende) est bien celui dont la moyenne est la plus élevée ;

les autres courbes, celles des actions de lecture, montrent des temps négligeables (1000 ms au maximum).

Voici les résultats à tous les paliers (rappel : les 3 derniers paliers ont une montée en charge de respectivement 35, 45 et 55 threads) :

Palier (nombre

d'ateliers)

Moyenne par nombre de

threads actives (en ms) pour l'import

d'un .scar

Centile 80 (en ms) pour l'import d'un

.scar, approximatif

Maximum des autres actions de

lecture par nombre de threads actives

(en ms), approximatif

2100 10157,8 12000 1000

2300 8499,5 12000 2500

2510 9553,9 16000 3000

3100 6989,6 8000 1000

3300 8267,2 11000 750

3500 7959,9 10000 1000

4100 7888,9 11000 500

4300 8064,4 12000 500

42

"Response times vs. threads" à 25 threads et sur une volumétrie de 2100 ateliers


4500 8238,2 11000 750

5000 9294,9 13000 1000

5500 8529,9 10500 2500

6000 10908,9 14000 2000

Tableau n°4 Temps de réponse pour les différents paliersCes résultats ne laissent pas entrevoir d'anomalies majeures dans les temps de réponse ; on peut donc conclure que :

1. le temps d'import de .scar reste raisonnable (10 secondes environ) sur une grande volumétrie (jusqu'à 6000 ateliers et plus de 2 millions d'items et d'espaces) et sous une charge allant entre 250 et 550 utilisateurs ;

2. ni cette fonctionnalité, ni les conditions de charge et de volumétrie précédentes ne semblent avoir d'impacts majeurs sur les actions "normales" de lecture.

"Deadlock" au 3ème palierDans les résultats précédant, la volumétrie du 3ème palier vaut 2510 et non 2500 comme évoqué précédemment ; ceci est dû au fait qu'un deadlock (interblocage) a eu lieu entre 2500 et 2510 ateliers (où le test a été arrêté).

Remarque sur le temps réel d'import d'un .scarOn voit que l'import d'un .scar n'a pas dépassé 16 seconde (en centile 80) : l'estimation précédente (1 minute) était donc peu exacte ; cela n'est pas d'une très grande importance, car la durée du scénario n'est pas trop affectée (environ 24 min, 15 s au lieu de 25 min).

Informations de la JVMVoici, pour exemple, les courbes du taux d'occupation CPU et de la RAM utilisée pour le test au premier palier :

43

Taux d'occupation CPU à 25 threads et sur une volumétrie de 2100 ateliers


A titre de comparaison, voici les mêmes courbes au dernier palier :

On remarque que la RAM utilisée dépasse à peine 900 MB au premier palier, alors qu'elle atteint quasiment 1750 MB au dernier palier.

En conclusion, on constate que les limites de CPU et de RAM ne sont pas atteintes sur ce test.

Conclusion globaleLes résultats de ces tests permettent de valider les capacités de montée en charge de Scenari 4 DB, sous ces conditions de charge et de volumétrie ainsi qu'avec ce scénario (services appelés) et ce jeu de données.

44

Mémoire vive utilisée à 25 threads et sur une volumétrie de 2100 ateliers

Taux d'occupation CPU à 55 threads et sur une volumétrie de 6000 ateliers

Mémoire vive utilisée à 55 threads et sur une volumétrie de 6000 ateliers

IV Conclusion

Au final, ce stage a été une expérience très enrichissante : il m'a d'abord permis de découvrir le domaine des tests logiciels, avant d'élaborer une discussion autour des outils et des stratégies de tests adaptés à Scenari et de réaliser quelques développements pour "optimiser" la conception des tests. J'ai notamment apprécié la dimension "projet", qui je pense manquait un peu lors de mon premier stage.

Les tests logiciels sont un domaine très vaste et on peut rencontrer des opinions variées sur ce sujet, parfois partisanes de démarches "universelles" applicables partout, ou bien favorables à l'idée que chaque point à tester est à observer dans son propre contexte. Après cette prise de recul, je vois le travail de l'ingénieur comme celui de la recherche de processus comme compromis entre ces deux extrêmes, où l'efficacité de la technique répétable et la prise en compte d'un contexte toujours nouveau sont en éternelle discussion.

45

Glossaire

Assertion p. 10Une assertion a pour rôle de comparer la réponse attendue du logiciel suite à une action du scénario de test, à sa réponse réelle (valeur de sortie).Les assertions sont généralement utilisées dans le cadre de tests unitaires ou fonctionnels.

Métrique p. 10Une métrique est une mesure permettant de prendre une décision sur le degré de satisfaction du test.Les métriques sont plutôt utilisées dans le cadre d'un test de performance (temps de réponse, taux d'occupation CPU, etc.) ou d'un test de couverture (taux de couverture d'instructions, etc.).

Mode DB p. 9DB = DataBase. Les ateliers et les items sont stockés à l'aide d'un système de base de données orientée graphe (OrientDB). Dans ce contexte, Scenari repose sur le mécanisme d'ID unique.

Mode FS p. 9FS = File System. Les ateliers et les espaces sont stockés sous la forme de dossiers et les items en tant que fichiers. Dans ce contexte, Scenari repose entièrement sur le mécanisme d'URI.

Script .jmx (JMeter) p. 21Format d'enregistrement des tests JMeter. Le script contient toutes les informations (threads, requêtes, pré- ou post-traitements de réponse, assertions, timers, visualiseurs, etc.) nécessaires pour que le test puisse être rejoué à l'identique.

Suite de tests p. 13Ensemble de tests visant à être lancés en séquence et/ou servant à valider une même fonctionnalité/un même module (test suite en anglais).

46

Annexes

Annexe 1 Fiches JMeter

Le logiciel de test JMeter16 (version 2.6) est un projet open source sous licence Apache17.

Les parties suivantes visent à présenter JMeter et à insister sur certaines de ses caractéristiques.

1. Interface

Voici une description succincte de l'interface de JMeter :

1. dans l'arborescence du test, le Test plan contient le scénario tandis que le Workbench sert d'espace de "brouillon" (il permet notamment d'enregistrer des scénarios à l'aide du proxy HTTP) ;

2. la fenêtre de composant affiche les informations relatives au composant sélectionné dans l'arborescence ;

3. le menu contextuel d'un Thread group (composant parent d'un scénario) permet d'ajouter les composants de test (cf. détails plus bas) ;

4. le test peut être lancé avec ce bouton.L'utilisateur ajoute les composants du scénario (3) dans l'arborescence (1) et spécifie leurs données dans la fenêtre correspondante (2).

16 - http://jmeter.apache.org/17 - http://www.apache.org/licenses/

47

Copie d'écran de l'interface de JMeter

http://www.apache.org/licenses/

http://www.apache.org/licenses/

http://jmeter.apache.org/

T es ts log ic ie l s sur Scenar i > Annexes

Composants JMeterLes différents types de composants d'un script sont :

les Samplers (requête HTTP typiquement) ; les Logic controllers (boucles, conditions, etc.) ; les Assertions (test sur la réponse d'une requête) ; les Config Elements (déclaration de variables, etc.) ; les Processors (enregistrement/modification d'une variable en fonction de la

réponse à une requête par exemple) ; les Listeners (visualisation des résultats).

2. Exécuter un plan de test JMeter

Il existe (au moins) 3 manières d'exécuter un plan de test (fichier .jmx) avec JMeter : via l'interface graphique ; uniquement en ligne de commande ; avec une tâche Ant écrite pour JMeter.

Interface graphiqueLe plan de test édité dans l'interface peut à tout moment être exécuté (bouton Run).

Les résultats peuvent être vu en temps réel grâce aux visualiseurs (Listeners) ajoutés au plan de test.

Cependant, JMeter nécessite beaucoup de ressources pour l'instanciation de ses composants graphiques, ce qui peut affecter ses performances dans certains cas (on préférera alors l'exécution en ligne de commande).

Ligne de commande uniquement (non-GUI)L'ajout de l'option -n à la commande de lancement de JMeter permet d'exécuter un test sans passer par l'interface graphique.

Pour cela, un fichier .jmx doit être impérativement spécifié à l'aide de l'option -t.

Tâche AntLa tâche Ant JMeter18 permet d'intégrer l'exécution de tests à un script Ant et ainsi de les combiner à des tâches de compilation par exemple.

ComparaisonL'exécution via l'interface graphique est particulièrement adaptée pour le debug du script de test, tandis que la ligne de commande et la tâche Ant conviennent mieux pour des scripts finalisés et/ou entrant dans un processus automatisé (compilation des nightlies par exemple).

18 - http://www.programmerplanet.org/pages/projects/jmeter-ant-task.php

48

http://www.programmerplanet.org/pages/projects/jmeter-ant-task.php


Résultats du testL'option -l (ou l'attribut resultlog dans le cas de la tâche Ant) est utilisée pour spécifier le fichier dans lequel seront sauvegardés les résultats du test au format XML (extension .jtl). Ce fichier peut être exploité après l'exécution du test pour visualiser les résultats :

dans JMeter (import d'un .jtl dans un Listener par exemple) ; à l'aide d'un autre outil permettant de générer des rapports de test (Jenkins par

exemple).

3. Variabilisation

SyntaxeDans les champs de propriété des composants JMeter, le flux textuel peut être de la forme "${...}" où "..." est un contenu qui sera remplacé dynamiquement lors de l'exécution du script. Ce contenu peut être soit un nom de variable, soit un nom de fonction appelée éventuellement avec des paramètres.

On peut donc généraliser cette syntaxe sous la forme : "${[nomDeVariable|nomDeFonction(params)]}".

Exemples1. le champ "Server name or IP" d'un HTTP sampler peut avoir la valeur "$

{nomDeDomaine}" si la variable "nomDeDomaine" est initialisée au préalable ;2. on peut également faire usage des fonctions usuelles19 proposées par JMeter.

IntérêtCe mécanisme, qu'on peut placer sous le concept de "variabilisation," permet de rendre dynamique le contexte d'exécution du script : ainsi, on peut mieux séparer les données de test du scénario en lui-même.

4. Modularisation et externalisation

Il peut être utile d'isoler des séquences de composants voire des plans de test entiers afin de les rendre réutilisables et d'éviter la duplication au sein d'un .jmx.

Pour cela, JMeter propose les 3 composants suivant : Test fragment20

Module Controller21

Include controller22

On pourrait regrouper les deux premiers sous le concept de modularisation et le dernier sous celui d'externalisation.

19 - http://jmeter.apache.org/usermanual/functions.html20 - http://jmeter.apache.org/usermanual/component_reference.html#Test_Fragment21 - http://jmeter.apache.org/usermanual/component_reference.html#Module_Controller22 - http://jmeter.apache.org/usermanual/component_reference.html#Include_Controller

49

http://jmeter.apache.org/usermanual/component_reference.html#Include_Controller

http://jmeter.apache.org/usermanual/component_reference.html#Module_Controller

http://jmeter.apache.org/usermanual/component_reference.html#Test_Fragment

http://jmeter.apache.org/usermanual/functions.html


ModularisationUn Test fragment peut contenir la séquence de composants à isoler et être référencé par un Module controller, qui exécutera ce fragment lorsqu'il sera appelé.

En général, le Test fragment se place sous le composant Test plan (racine), tandis que le Module controller se situe dans un Thread group pour pouvoir être exécuté.

ExternalisationL'Include controller permet de référencer un plan de test entier, contenu dans un autre .jmx. Placé dans un Thread group du plan de test "appelant", le plan de test "appelé" sera exécuté dans le contexte de l'"appelant".

IntérêtsUn fragment ou .jmx externe gagne à être variabilisé pour pouvoir être appelé avec différents paramètres. Pour cela, le Module/Include controller peut être placé dans un composant Parameterized controller23 (plugin palliant l'impossibilité d'indiquer directement des paramètres dans un Module/Include controller).

Dans le cas de la modularisation, l'avantage est de pouvoir organiser le plan de test en blocs (par exemple, une séquence de requêtes correspondant à l'action de s'identifier sur un site peut être regroupée sous un module de label "logging"), éventuellement paramétrables, et ainsi le rendre plus lisible.

Mais la force de ce mécanisme prend surtout son sens dans le cas de l'externalisation : des actions élémentaires peuvent être fragmentées en "briques" paramétrables et indépendantes ; par exemple dans le contexte de Scenari, un .jmx aurait uniquement pour rôle la création d'un atelier dérivé et serait appelé par plusieurs plans de test avec différents paramètres (le nom de dérivation et le code de l'atelier master typiquement).

Remarque sur l'externalisationCes "briques" externalisées n'ont pas vraiment d'enjeu à être exécutées individuellement ; il faut plutôt les voir comme un ensemble de routines mutualisées.

Ainsi, il convient mieux de les placer dans un Test fragment qui constituera à lui seul le .jmx.

Visibilité des variablesDans les deux cas précédant, les variables initialisées dans l'entité appelante sont partagées avec celles de l'entité appelée (fragment ou autre .jmx), et inversement. Il n'y a pas de "surcharge" des variables de l'appelant dans l'appelé : par exemple, si "var1" vaut 1 dans l'appelant, puis que l'appelé lui affecte la valeur 2, "var1" vaudra 2 par la suite dans l'appelant.

Malgré cette visibilité des variables, l'intérêt du Parametrized controller est toutefois de spécifier explicitement les valeurs des variables utilisées par un fragment.

23 - http://code.google.com/p/jmeter-plugins/wiki/ParameterizedController

50

http://code.google.com/p/jmeter-plugins/wiki/ParameterizedController


5. Serveur proxy HTTP

Cette fonctionnalité de JMeter est particulièrement intéressante pour construire des plans de test. Elle permet d'enregistrer de manière transparente les actions réalisées manuellement par l'utilisateur sur un logiciel, dès lors que ce dernier fonctionne sur un mécanisme d'envoi de requêtes HTTP (architecture client-serveur typiquement).

La documentation24 ainsi qu'un tutoriel25 donnent plus d'informations sur ce composant.

FonctionnementLe proxy doit spécifier un port sur lequel il va se mettre en écoute (champ à renseigner dans JMeter) ; le client dont il faut enregistrer les requêtes émises (un navigateur typiquement, ou Scenari dans notre cas) doit se connecter en localhost sur ce port.

Ainsi, dès lors que le proxy est lancé : chaque requête émise par l'utilisateur via l'interface du client est interceptée

par JMeter ; JMeter la renvoie lui-même au serveur de "destination" (un serveur web pour

une page HTML par exemple) ; le serveur de destination envoie sa réponse à JMeter ; JMeter retourne la réponse au client.

Entre deux, le proxy aura enregistré les requêtes (HTTP samplers) sous la forme d'un script .jmx qui pourra ainsi être exécuté par la suite.

Ajout de think-timesPour que le script enregistré soit fidèle au scénario réel de l'utilisateur, le proxy peut enregistrer les think-times (le temps mesuré entre deux actions) dans des composants Constant timer : pour cela, il faut simplement placer un Constant timer sous le composant du proxy, et spécifier la valeur du delay à "${T}".

24 - http://jmeter.apache.org/usermanual/component_reference.html#HTTP_Proxy_Server25 - http://jmeter.apache.org/usermanual/jmeter_proxy_step_by_step.pdf

51

Schéma de fonctionnement du serveur proxy JMeter avec un navigateur

http://jmeter.apache.org/usermanual/jmeter_proxy_step_by_step.pdf

http://jmeter.apache.org/usermanual/component_reference.html#HTTP_Proxy_Server


Ajout de variablesUn composant User defined variables situé sous le proxy permet de placer des variables dans le script ; une variable déclarée verra chaque occurrence de sa valeur "variabilisée" lors de l'enregistrement : par exemple, si la variable "${urlTest}" vaut "http://jmeter.apache.org/", toutes les requêtes vers cette URL seront enregistrées avec "${urlTest}". Ainsi, le script peut être rejoué avec d'autres données pour cette variable à condition que celle-ci soit initialisée dans le plan de test.

Intérêt dans le cadre de ScenariScenari fonctionnant sur une architecture client-serveur (y compris pour un SCENARIchain installé en local), le proxy JMeter peut parfaitement enregistrer les requêtes émises et constituer ainsi un scénario d'utilisation de Scenari, rejouable dans le cadre de tests.

NoteLe composant du serveur proxy ne peut être placé que dans le Workbench, et ne peut donc pas être sauvegardé.

Il faut faire attention à bien définir le composant où les requêtes sont enregistrées (idéalement dans un Thread group du plan de test) - par défaut elles sont placées dans le workbench ou dans le premier Recording controller trouvé.

6. Étendre JMeter

JMeter est un logiciel open source, ce qui permet de lui ajouter de nouvelles fonctionnalités.

Ce tutoriel26 explique entre autres comment : construire un projet Eclipse à partir des sources de JMeter - cf. partie "Building

JMeter" de ce tutoriel ; développer de nouveaux composants (plugins) selon deux méthodes (MVC

traditionnel et interface TestBean) - résumées rapidement dans cette fiche.

MVCLa première manière d'ajouter un plugin est de suivre le design pattern MVC : une classe est dédiée au modèle, et une autre à la vue (généralement, son nom est celui du modèle suffixé par "GUI") ; c'est dans cette dernière que le modèle est instancié.

Le modèle et la vue du plugin doivent surcharger des classes (abstraites ou non) dérivant respectivement de AbstractTestElement et AbstractJMeterGuiComponent ou d'une de leurs classes dérivées.

Pour plus d'informations, lire la sous-partie du tutoriel intitulée "Jmeter Gui – TestElement Contract".

26 - http://jmeter.apache.org/extending/jmeter_tutorial.pdf

52

http://jmeter.apache.org/extending/jmeter_tutorial.pdf


"Méthode TestBean"Les développeurs de JMeter ont mis en place l'interface TestBean (au sens d'une interface Java) afin de générer automatiquement une interface graphique pour le plugin à partir de son modèle.

A la manière d'un JavaBean, le modèle du plugin implémentant l'interface TestBean doit posséder des attributs privés ainsi que les getters et setters publics pour ces attributs. Ces attributs représentent ici les paramètres du composant, dont les valeurs seront spécifiés par l'utilisateur via l'interface.

Une autre classe est nécessaire pour que l'interface graphique soit générée correctement par rapport au modèle (elle doit surcharger la classe BeanInfoSupport) : elle spécifie notamment les informations sur les types de champ à associer aux attributs du modèle (texte, booléen, nombre entier, etc.).

Pour plus d'informations, lire la partie ''Making a TestBean Plugin For Jmeter" du tutoriel.

Comparaison des deux méthodesLa méthode TestBean semble bien adaptée pour des composants de test simples, où les paramètres sont clairement identifiés ; en effet, l'interface graphique standardisée est fidèle au modèle et suffit dans de nombreux cas.

Cependant, dès lors que la saisie de ces paramètres doit pouvoir être plus souple (par exemple si on veut avoir deux manières de spécifier un même paramètre avec deux champs, au choix), cette méthode connaît des limites ; dans ce cas, il vaut mieux passer par le MVC classique et créer sa propre interface graphique.

Autres extensions possiblesCette fiche aborde uniquement l'ajout de plugins car c'est ce qui est le plus courant ; mais d'autres classes des sources de JMeter peuvent bien entendu être surchargées pour des besoins spécifiques, telles que :

la classe AbstractFunction qui permet de créer ses propres fonctions accessibles sous la syntaxe "${...}" (cf. fiche "Variabilisation") ;

toute autre fonctionnalité (le serveur proxy HTTP par exemple).

Projet JMeter PluginsDu fait du caractère open source de JMerer, il existe plusieurs ensembles d'extensions disponibles sur le Web. Parmi eux, JMeter Plugins27 propose de nouvelles fonctionnalités intéressantes, notamment pour les montées en charge (Stepping thread group28) et la visualisation de résultats (Active threads over time29, Response times over time30 et Response times vs. threads31).

27 - http://code.google.com/p/jmeter-plugins/28 - http://code.google.com/p/jmeter-plugins/wiki/SteppingThreadGroup29 - http://code.google.com/p/jmeter-plugins/wiki/ActiveThreadsOverTime30 - http://code.google.com/p/jmeter-plugins/wiki/ResponseTimesVsThreads31 - http://code.google.com/p/jmeter-plugins/wiki/ResponseTimesVsThreads

53

http://code.google.com/p/jmeter-plugins/wiki/ResponseTimesVsThreads



http://code.google.com/p/jmeter-plugins/wiki/ActiveThreadsOverTime



http://code.google.com/p/jmeter-plugins/


Annexe 2 Requête GetSrc

Dans l'implémentation de Scenari, le cdaction GetSrc du service WspSrc permet d'obtenir des informations sur un item.

Il prend en paramètre l'URI de l'item, le code de son atelier ainsi que les champs d'information dont les valeurs doivent être précisées dans la réponse.

La requête de création d'un item ne renvoyant aucune information en réponse, GetSrc permet de connaître entre autres :

l'ID de l'item ; son statut (il vaut par exemple 1 si l'item existe et -1 si non) ; son état dans le cadre d'une dérivation (drvState) ; son état dans le cadre d'un brouillon (drfState).

Annexe 3 Ateliers dérivés et brouillon

Cette annexe présente succinctement ces deux fonctionnalités, qui font partie des fonctions de gestion de Scenari 4 DB32.

TerminologieOn appelle atelier master (respectivement de référence) l'atelier à partir duquel un atelier dérivé (respectivement brouillon) est créé.

Ateliers dérivésUn atelier dérivé fonctionne comme une surcharge :

les items du master peuvent être surchargés (état overriden) dans l'atelier dérivé (la modification est locale et n'affecte pas le master) ;

la surcharge peut être marquée "achevée" (done) dans la dérivation ; toute modification d'un item du master fait passer l'item dans l'état "à

contrôler" (dirty) dans la dérivation.Un atelier dérivé ne peut pas être lui-même dérivé, mais peut devenir une source de dérivation pour un autre atelier dérivé du même atelier master.

Ateliers brouillonUn atelier brouillon peut être créé à partir de n'importe quel atelier.

Les items de l'atelier de référence sont disponibles dans l'atelier brouillon après sa création.

Tout ajout de contenu dans l'atelier brouillon (nouvel item ou modification d'un item existant) doit faire l'objet d'un commit (validation) pour être "transmis" à l'atelier de référence ; néanmoins, ce dernier "garde la main" sur ses items en permettant d'abandonner (revert) les modifications validées dans son atelier brouillon.

32 - http://data.kelis.fr/docs/sc4/co/features-db.html

54

http://data.kelis.fr/docs/sc4/co/features-db.html

Documents

RAPPORT DE STAGE TN10 - UTCTests logiciels sur Scenari > Introduction Merci enfin à tous les employés de Kelis pour leur aide, en particulier à Thibaut, Antoine, Samuel, Julie et