9.4.1 Vue d’ensemble. . . 167
9.4.2 Principe de fonctionnement. . . 169
9.4.3 Concr´etisation des interactions avec l’IUT . . . 170
9.4.4 Exemple . . . 173
Chapter abstract
j-POSTis an integrated tool chain for property-oriented software testing. This tool chain includes a
test designer, a test generator, and a test execution engine. The test generation is based on an original
approach which consists in deriving a set ofcommunicating test processesobtained both from a requirement
formula (expressed in a trace-based logic) and a behavioral specification of some specific parts of the implementation under test. The test execution engine is then able to coordinate the execution of these test processes against a distributed Java program. A typical application of j-POST is to check the correct deployment of security policies.
R´esum´e du chapitre
j-POSTest une chaˆıne d’outils int´egr´es d´edi´ee au test de logiciels orient´e par des propri´et´es. Cette chaˆıne d’outils comprend un concepteur de test, un g´en´erateur de test, et un moteur d’ex´ecution des
tests. La g´en´eration de test est bas´ee sur une approche originale qui consiste `a d´eriver un ensemble de
processus de test communicants obtenus `a partir d’une exigence formelle exprim´ee dans un formalisme
bas´e sur les traces et d’une sp´ecification comportementale de certaines parties de l’implantation sous test. Le moteur d’ex´ecution des tests est ensuite capable de coordonner l’ex´ecution de ces processus de test
avec un programme Java distribu´e. Une application typique de j-POSTest de v´erifier le d´eploiement
9.1 : Introduction
9.1 Introduction
Dans le Chapitre7(et dans [FFMR06,FFMR07a]), nous avons pr´esent´e une technique boˆıte noire de
g´en´eration de tests capable de construire des cas de test abstraits depuis une exigence (une propri´et´e que le syst`eme est suppos´e satisfaire). Cette m´ethode, dont l’implantation est pr´esent´ee dans ce chapitre, est bas´ee sur un calcul de test permettant de d´efinir la m´ethode formellement et de fa¸con compositionnelle.
Dans ce cadre, une exigence est exprim´ee par une formule logique construite `a partir d’un ensemble de
pr´edicats abstraits. Chaque pr´edicat correspond `a une op´eration possiblement non atomique `a r´ealiser sur
l’implantation sous test. Cette op´eration est founie par l’utilisateur comme unmodule de testindiquant
comment r´ealiser cette op´eration sur l’implantation r´eelle, et comment d´ecider si cette ex´ecution a r´eussi ou
non. L’´etape de g´en´eration de test consiste `a construire, parcompositionde modules de test, un ensemble
deprocessus de test communicants, depuis la propri´et´e. Dans ce chapitre nous proposons l’implantation de
cette technique de test. D’abord, nous pr´esentons formellement comment les tests pr´ec´edemment g´en´er´es peuvent ˆetre ex´ecut´es. De plus, nous pr´esentons j-POST, une chaˆıne d’outils int´egr´es d´edi´ee au test orient´e par les propri´et´es.
Une vue d’ensemble du principe de fonctionnement de j-POSTest d´epeinte sur la Fig.9.1. L’utilisateur
de j-POST veut tester une implantation pour laquelle une interface est disponible (test boite noire).
Premi`erement, en les fournissant au concepteur de test (´etape 1), l’utilisateur ´elabore une biblioth`eque de modules de test abstraits par combinaison des actions offertes par l’interface de l’IUT. Deuxi`emement, l’utilisateur d´efinit une (ou plusieurs) exigence(s). Pour cela, il utilise les pr´edicats ´el´ementaires `a disposition dans la biblioth`eque. Ces deux donn´ees sont utilis´ees par le g´en´erateur de tests (´etape 2). Ce qui produit un ensemble de composants de test communicants, qui forme un cas de test pour la propri´et´e. La trois`eme ´etape est l’ex´ecution. L’utilisateur peut fournir un objectif de test. Le moteur d’ex´ecution des tests utilise ce dernier pour guider l’ex´ecution du test et s´electionner les ex´ecutions d´esir´ees parmis celles contenues dans le cas de test.
Formal Requirement ATM Library
Test Designer 1 Test Generator 2
Abstract test suite
RMI
IUT
Engine
3 communication
(pass,fail,inc) Log informations
Test Execution
Test Objective Mapping abstract/concrete
actions
Informal Requirement Specified abstract actions
F(pi)∈ERE,LT L pi ↔mi
m1k · · · kmn communicating
Verdict forF
Graph representation Specified Abstract Actions
Informal Requirement Requirement Editor Test Designer Test Modules Visualizer Test Module Test Module Editor
Formal Requirement ATM Library
(png, jpeg, . . . )
F(pi)∈ERE,LT L pi ↔mi
Figure9.2 – Architecture du Test Designer de j-POST
Exemple. Pour illustrer l’utilisation de j-POST, nous utiliserons l’un des exemples qui nous a servi
pour l’exp´erimentation de j-POST: l’applicationTravel et sa politique de s´ecurit´e.
L’exemple de l’application Travel vient du projet fran¸cais RNRT Politess1. Les ´etudes dans ce projet
ont men´e `a une sp´ecification de cette application. L’applicationTravel permet la gestion de requˆetes de
missions concurrentes de ses utilisateurs. Dans le but d’enregistrer des requˆetes de mission, un utilisateur doit d´etenir un compte sur l’application. Chaque utilisateur poss`ede son propre valideur (´egalement un utilisateur de Travel) qui est l’unique personne pouvant v´erifier l’´etat de la mission et faire la validation finale. Dans le cas d’une absence prolong´ee, un utilisateur deTravel peut d´el´eguer ses droits d’acc`es `a un autre utilisateur. La personne d´el´egu´ee peut alors agir au nom de l’utilisateur original.
En ´etudiant la sp´ecification et le descriptif initial de cette application, nous avons d´evelopp´e une
implantation prototype d´edi´ee `a l’exp´erimentation de j-POST. Nous renvoyons `a [Fal07] pour une
description compl`ete de l’application. L’architecture de l’application est assez simple, elle suit un sch´ema de type client-serveur. Nous avons impl´ement´e l’application en Java, et utilis´e le m´ecanisme de RMI pour la communication depuis un client vers le serveur applicatif.
Dans ce chapitre, nous illustrerons la conception, la g´en´eration, et l’ex´ecution des tests avec j-POST
pour tester des propri´et´es surTravel. L’exigence que nous choisissons pour cette illustration peut ˆetre
informellement exprim´ee comme : “il est impossible de valider une mission qui n’a pas ´et´e d’abord cr´ee”.
Organisation du chapitre. La suite de ce chapitre est organis´ee comme suit. Dans la Section 9.2, nous pr´esentons la conception de tests avec j-POST. Dans la Section9.3, nous nous int´eressons `a la phase de g´en´eration de tests. Puis, en Section9.4, l’ex´ecution des test est pr´esent´ee. Enfin, la Section9.5 est consacr´ee `a la conclusion et aux perspectives.
9.2 Conception des tests
Cette section d´ecrit comment il est possible de concevoir les entit´es de test (une biblioth`eque de tests
abstraits et une exigence) avec le Test Designer de j-POST. Son architecture est sch´ematis´ee sur la
Fig.9.2 et une capture d’´ecran est propos´ee sur la Fig.9.3.
L’interface de l’implantation sous test contient un ensemble de variables et m´ethodes publiques. En les utilisant comme entr´ees, l’utilisateur ´ecrit une biblioth`eque de modules de test, correspondant `a des op´erations de haut niveau qui peuvent ˆetre r´ealis´ees sur l’implantation (e.g., “cr´eer une mission” ou la “connexion d’un utilisateur”). Ces composants peuvent ˆetre vus comme des termes de l’alg`ebre de
processus d´ecrite dans le Chapitre7Section7.3. Les actions ´el´ementaires peuvent ˆetre soit des actions
9.2 : Conception des tests
Figure9.3 – ´Edition d’un module de test avec le Test Designer
internes des composants de test (comme des assignations de variables) ou des appels externes `a l’interface de l’IUT. Notons que l’ex´ecution d’une action externe est consid´er´ee comme atomique.
Le Test Designer de j-POSTfournit une interface (Fig.9.3) `a l’utilisateur pour concevoir les modules
de test et les visualiser de mani`ere intelligible. Le format XML a ´et´e choisi pour l’encodage interne des
modules de test. Nous utilisons l’Eclipse Modeling Framework2 pour g´en´erer l’´editeur de modules de
test (Test Module Editor) : l’utilisateur du Test Designer de j-POST peut produire les modules de
test en composant les actions param´etr´ees de l’interface sans manipuler directement le format XML. Un composant du Test Designer permet la visualisation des modules de test comme des syst`emes de
transitions ´etiquet´es. Cette derni`ere partie du Test Designer (Test Module Visualizer) utilise GraphViz3
pour g´en´erer les images des modules de test.
9.2.1 Exemple
Nous illustrons la construction de modules de test avec le Test Designer.
Exemple 39 (Modules de test) Les deux exemples de modules de test donn´es ci-dessous ´evaluent des pr´edicats sur l’application Travel :
– Le module de test missionCreation (voir Fig. 9.4) r´ealise essentiellement un appel `a la m´ethode
abstraite missionRequest2(id, New York,01/12/2008,20/12/2008), o`u id est un param`etre
indiquant l’identit´e de l’utilisateur. Cette valeur est interne `a l’applicationTravel, et est g´en´er´ee
lorsque l’utilisateur ouvre une connexion vers Travel. Notons que l’op´eration missionRequest2
retourne un missionNumber dont la valeur peut ˆetre soit un entier positif, auquel cas le verdict
retourn´e estpass, ou−1, auquel cas le verdict retourn´e estfail. Les variablesidetmissionNumber
sont d´eclar´ees commepartag´ees, ce qui signifie qu’elle peuvent ˆetre lues et assign´ees par plusieurs
modules de tests. Notons que les transitions ´etiquet´ees avecc_start2,c_loop2,c_ver2etc_stop2
sont automatiquement ajout´ees par le g´en´erateur de test pour g´erer l’ex´ecution du test (voir Section 7.4. Ce n’est pas `a l’utilisateur d’´ecrire ces transitions.
2. http://www.eclipse.org/modeling/emf
Figure 9.4 – Module de test pour le pr´edicatmissionCreation
– Le module de testmissionValidation(Fig.9.5) r´ealise un appel `a la m´ethode abstraitevalidMission(id, missionNumber). Cet appel retourne soit une valeur correcteokauquel cas le verdict r´esultant est
pass, soit une valeur incorrecte, auquel cas le verdict estfail. Ici ´egalement, les transitions
´etique-t´ees par c_start3,c_loop3,c_ver3etc_stop3sont automatiquement ajout´ees par le g´en´erateur
de test.
9.3 G´en´eration des tests
Cette section d´ecrit le fonctionnement du g´en´erateur de test (Test Generator) et le processus de g´en´eration de test. L’architecture du Test Generator est repr´esent´ee sur la Fig.9.6et une capture d’´ecran est propos´ee sur la Fig.9.7.
9.3.1 Vue d’ensemble de la g´en´eration de test
Le g´en´erateur de tests de j-POSTconsiste principalement en l’implantation de la fonction de g´en´eration
de test d´ecrite dans le Chapitre7Section7.7. Cette fonction prend pour entr´ee une exigence formelle,
exprim´ee dans un formalisme logique bas´e sur les traces. La fonction produit un cas de test complet suivant une approche dirig´ee par la syntaxe du formalisme.
Des contrˆoleurs de test et des algorithmes de g´en´eration de test ont ´et´e d´efinis pour diff´erents
formalismes de sp´ecification. Le format interne pour l’encodage des contrˆoleurs est le XML. Par exemple,
sur la Fig.9.8et le Listing 9.1sont donn´es respectivement une repr´esentation graphique et l’encodage
XML associ´e pour un contrˆoleur r´ealisant la conjonction logique. Pour l’instant j-POSTprend en charge
les deux formalismes g´en´eraux pour lesquels nous avons d´efinis l’approche : une variante de la logique temporelle et les expressions r´eguli`eres ´etendues. Toutefois, il est ais´e de prendre en charge de nouveaux formalisme. Il suffit pour cela de fournir un plugin logique d´edi´e au formalisme souhait´e. Ce plugin consiste `
a fournir les contrˆoleurs pour l’ensemble des op´erateurs du formalisme.
9.3.2 Analyse syntaxique de l’exigence
La premi`ere ´etape est la construction d’un “arbre de communication” obtenu grˆace `a l’arbre syntaxique de la formule. Cet arbre repr´esente l’architecture de communication entre les processus de test qui sera produit par le g´en´erateur de test. Les feuilles de cet arbre sont les modules de test correspondant aux pr´edicats atomiques de la formule fournis par l’utilisateur. Les nœuds internes sont des copies de
9.3 : G´en´eration des tests
Figure9.5 – Module de test pour le pr´edicatmissionValidation
Test Instanciation Test Tree Builder Requirement Parser Generator Test
Requirement ATC Library
Instanciated tests
F(pi)∈ERE,LT L pi ↔ ti
t1k · · · ktn communicating
✞
< t e s t C o n t r o l l e r id = " a n d C o n t r o l l e r " > < param id = " cs " type = " c h a n n e l S e t " >
< c h a n n e l L i s t startC = " c _ st ar t " stopC = " c_stop " verC = " c_v er " loopC = " c_loop " / > </ param >
< param id = " cs1 " type = " c h a n n e l S e t " >
< c h a n n e l L i s t startC = " c _ s t a r t R " stopC = " c _s t op R " verC = " c _verR " loopC = " c_ l oo pR " / > </ param >
< param id = " cs2 " type = " c h a n n e l S e t " >
< c h a n n e l L i s t startC = " c _ s t a r t L " stopC = " c _s t op L " verC = " c _verL " loopC = " c_ l oo p L " / > </ param >
< d ec l ar e id = " xv " type = " ve rd i ct " value = " fail " / > < d ec l ar e id = " xvL " type = " v e rd i ct " value = " fail " / > < d ec l ar e id = " xvR " type = " v e rd i ct " value = " fail " / > < state id = " s1 " i n it ia l = " true " >
< t r a n s i t i o n n e x t S t a t e = " s2 " >
< i n t e r a c t i o n guard = " true " type = " r e c e p t i o n " scope = " c o m m u n i c a t i o n " > < c ha n ne l > c _ st ar t </ c h an n el >
</ i n t e r a c t i o n > </ t r a n s i t i o n >
< t r a n s i t i o n n e x t S t a t e = " stop " >
< i n t e r a c t i o n guard = " true " type = " r e c e p t i o n " scope = " c o m m u n i c a t i o n " > < c ha n ne l > c_stop </ ch an n el > </ i n t e r a c t i o n > </ t r a n s i t i o n > </ state > ... < state id = " s13 " > < t r a n s i t i o n n e x t S t a t e = " s8 " >
< i n t e r a c t i o n guard = " true " type = " e m i s s i o n " scope = " c o m m u n i c a t i o n " > < c ha n ne l > c _ st op R </ c h an n el >
</ i n t e r a c t i o n > </ t r a n s i t i o n >
< t r a n s i t i o n n e x t S t a t e = " stop " >
< i n t e r a c t i o n guard = " true " type = " r e c e p t i o n " scope = " c o m m u n i c a t i o n " > < c ha n ne l > c_stop </ ch an n el > </ i n t e r a c t i o n > </ t r a n s i t i o n > </ state > ... </ t e s t C o n t r o l l e r > ✡✝ ✆
9.3 : G´en´eration des tests
Figure 9.7 – Capture d’´ecran du Test Generator de j-POST
sont obtenus `a partir d’un ensemble fini de contrˆoleurs de test g´en´eriques fournis par le plugin logique.
Finalement la racine de cet arbre est un processus de test sp´ecial, appel´etestCaseLauncher, dont le but
est d’initialiser l’ex´ecution du test et de d´elivrer le verdict final (voir Fig.9.9).
L’analyse de la formule (exprimant l’exigence) est r´ealis´ee grˆace `a un analyseur syntaxique. Pour
r´ealiser l’analyse grammaticale, nous avons choisi Java-CC4. Cette biblioth`eque g´en`ere un ensemble de
classes Java par analyse d’un ensemble de r`egles de grammaire d´ecrivant le langage (voir [FMFR08a]
pour plus de d´etails).
9.3.3 Implantation de la fonction de g´en´eration de test
Pour mettre en œuvre le principe de la g´en´eration de test (Chapitre7 Section7.7), nous construisons
un arbre de test syntaxique. Par exemple, si nous consid´erons la formule LTL :(p1()∨p2())U p3(a,b,c),
l’arbre abstrait est repr´esent´e sur la Fig.9.10. Dans la suite, nous illustrons seulement l’implantation
pour la version LTL deGenTest, le principe est identique pour les expression r´eguli`eres. Pour repr´esenter l’arbre en m´emoire, nous avons d´efini un ensemble de classes Java repr´esentant de mani`ere g´en´erique la
syntaxe d’une exigence (voir [FMFR08a] pour plus de d´etails).
Comme vu pr´ec´edemment, les processus de test (pr´edicats et contrˆoleurs) sont repr´esent´es en XML.
Chacun de ces processus est instanci´e par la fonctionGenTest, qui modifie leur structure et param`etres.
Deux procesus de test instanci´es sont repr´esent´es sur les Fig.9.4et 9.5. Nous avons utilis´e JDOM5, un outil permettant la manipulation et la modification de fichiers XML de donn´ees.
Pour chaque formalisme d’expression d’exigences, le principe est le suivant :
– GenTest : Cr´ee un contrˆoleur maˆıtre g´erant les processus de test au plus haut niveau de l’arbre.
Dans un second temps, elle appelle une m´ethode de g´en´eration associ´ee `a ce processus (avec un
nom de canal de communication frais pour pouvoir l’instancier).
– GT(Fn(φ1,· · ·, φn),cs): Prend en param`etre un canal de communicationcs et g´en`ere un nouveau
canal de communication pour chaque op´erande de Fn. Le contrˆoleur de test g´en´erique associ´e `a
l’op´erateur Fn est ensuite instanci´e avec ces noms de canaux, et la m´ethode de g´en´eration est
r´ecursivement appel´ee sur chaque op´erande deFn avec le nom de canal correspondant en param`etre.
4. http://javacc.dev.java.net
9.4 : Ex´ecution des tests rootTestCase Controller until Controller not connection missionCreation c start1,c stop1, c loop1,c ver1 c start0,c stop, c loop0,c ver c start2,c stop2, c loop2,c ver2, c start3,c stop3, c loop3,c ver3
Figure9.9 – Structure du cas de test produit pour¬(missionCreation)Uconnection
p3(a,b,c)
p1() p2
U
∨
Figure9.10 – Arbre syntaxique abstrait correspondant `a(p1()∨p2())Up3(a,b,c)
– La fonctionTest(tp,{c start,c stop,c loop,c ver})prend un num´ero de canal et g´en`ere les ´etats de contrˆole et les transitions pour ce pr´edicat. La structure du module de test est ainsi modifi´ee suivant le principe d´ecrit dans le Chapitre7Section 7.7et sch´ematis´e sur la Fig.7.11, p.129.
Une fois cette ´etape termin´ee, nous obtenons une liste de fichiers XML repr´esentant les processus de test instanci´es. Ceux-ci peuvent ˆetre utilis´es comme entr´ee pour le moteur d’ex´ecution de test.
9.3.4 Exemple
Pour l’exigence de l’Exemple 39 formalis´ee par la formule logique ¬(missionCreation)Uconnection,
et dont les deux modules de test ont ´et´e con¸cus, nous pouvons proc´eder `a la g´en´eration du cas de
test. Une repr´esentation de “l’arbre de communication” du cas de test obtenu est repr´esent´ee sur la
Fig.9.9. La structure de ce cas de test suit la syntaxe de la formule. Il contient un contrˆoleur de test
pour chaque op´erateur apparaissant dans la formule (UntiletNot), et un module de test pour chaque
pr´edicat (missionCreation()etConnection()). Le processustestCaseLauncherprend en charge la gestion
de l’ex´ecution du cas de test et l’´emission du verdict final. Le canalc start (resp.c stop,c loop, c ver) est utilis´e par le processus pour r´ealiser les op´erations de d´emarrage (resp. d’arrˆet, de red´emarrage, et de transmission du verdict).
9.4 Ex´ecution des tests
Cette section d´ecrit comment les test sont ex´ecut´es avec le moteur d’ex´ecution de test de j-POST
(Test Execution Engine). Son architecture est repr´esent´ee sur la Fig.9.11.
9.4.1 Vue d’ensemble
Le but du moteur d’ex´ecution des test est de produire un verdict pour l’exigence test´ee. Pour cela, le moteur utilise le cas de test produit par le g´en´erateur et unobjectif de test.
S´election des test en utilisant des objectifs de test comportementaux. Le cas de test produit
par le g´en´erateur peut d´ecrire plusieurs ex´ecutions. Ceci provient du non-d´eterminisme possible `a la
fois dans les modules de test et introduit par la composition parall`ele des modules de test. De plus, la fonction de g´en´eration de test assure simplement que le verdict produit par l’ex´ecution du test est correcte
ATC Engine Concretisation Wrapper Scheduler Logger Objective Engine Test case Loader Engine communicationRMI informationexecution Execution traces Execution graphs (pass,fail,inc) abstract external actions
Instanciated tests Test Objective
Test Execution
IUT
Verdict forF
t1k · · · ktn communicating
Figure9.11 – Architecture du Test Execution Engine de j-POST
9.4 : Ex´ecution des tests
vis-`a-vis de la formule initiale : elle n’aide pas `a s´electionner les s´equences d’ex´ecution int´eressantes qui