7.3 Repr´esentation alg´ebrique des processus de test . . . 125 7.4 Phase de g´en´eration de tests . . . 127 7.5 Phase d’instanciation des tests . . . 128 7.6 Phase de s´election et d’ex´ecution des tests . . . 130 7.7 Approche compositionnelle dirig´ee par la syntaxe . . . 131
7.7.1 Principe g´en´eral . . . 131
7.7.2 G´en´eration des tests. . . 132
Chapter abstract
This chapter presents an approach dedicated to property testing in which we do not use a complete behavioral specification of the implementation under test. From a Streett automaton recognizing a
r-property, we synthesize a set of communicating test processes. Those processes are purposed to evaluate
if a given relation holds between the sequences described by the r-property and the set of possible
execution sequences of the implementation. Also, we present an overview of a compositional version of
this approach which was previously proposed in [FFMR06,FFMR07a] (available in AppendixC).
R´esum´e du chapitre
Ce chapitre pr´esente une approche de test de propri´et´es o`u nous n’utilisons pas de sp´ecification
comportementale du syst`eme test´e. `A partir d’un automate de Streett reconnaissant uner-propri´et´e, nous
g´en´erons un ensemble de processus de test communicant. Ces processus ont pour but d’´evaluer si une certaine relation est v´erifi´ee entre l’ensemble des s´equences d´ecrites par lar-propri´et´e et l’ensemble des s´equences que peut produire l’implantation sous test. Nous pr´esentons ´egalement de mani`ere succinte une
version compositionnelle de cette approche de test qui avait ´et´e propos´ee pr´ec´edemment dans [FFMR06,
7.1 : Introduction
Scenario
Extraction and execution
Relation between Test Scenario Logic Plug-in Test Generation Test Instantiation Test Selection ImplementationI (using abstract propositions pi)
Verdict
ReqandI
Elementary test modules{tpi}
Formal requirement{Π}
Abstract tester{ATΠ}
Concrete tester{TΠ}
RequirementReq
Figure7.1 – Vue d’ensemble de l’approche de test
7.1 Introduction
Nous avons vu dans l’introduction que les m´ethodes de g´en´eration de tests de conformit´e boite noire reposaient souvent sur la disponibilit´e d’une sp´ecification compl`ete du syst`eme test´e. Dans le Chapitre2, nous avons identifi´e des situations o`u l’applicabilit´e de ces m´ethodes ´etait difficile du fait de l’absence de telles sp´ecifications. Nous proposons ici une approche alternative, pour produire une suite de tests, d´edi´ee `a la validation de propri´et´es fonctionnelles. Au lieu d’utiliser une sp´ecification comportementale compl`ete du syst`eme, nous utilisons une certaine forme de sp´ecification partielle. Cette sp´ecification partielle consiste en un ensemble d’exigences exprim´ees sur le comportement du syst`eme. L’exigence
est construite `a partir d’un ensemble de propositions abstraites d´ecrivant des op´erations (possiblement
non atomiques) r´ealisables sur le syst`eme sous test. Un exemple typique de telle exigence peut ˆetre une
politique de s´ecurit´e o`u les propositions abstraites pourraient d´enoter des op´erations de haut niveau
comme “l’utilisateur A est authentifi´e”, ou “le message M a ´et´e corrompu”.
L’approche que nous proposons repose sur les consid´erations suivantes : une bonne connaissance des d´etails d’implantation est requise pour produire des modules de test capables de d´ecider si de telles propositions sont satisfaites lors de l’ex´ecution du logiciel. Ainsi, ´ecrire les modules de test de ces propositions doit ˆetre laiss´e aux soins du programmeur (ou testeur) lorsqu’une sp´ecification d´etaill´ee du syst`eme n’est pas disponible. Cependant l’orchestration correcte de l’ex´ecution de ces “modules de test de base” et la combinaison de leur verdicts pour d´eduire une validit´e de la sp´ecification dans son ensemble
est plus facile `a automatiser car elle d´epend uniquement de la s´emantique des op´erateurs utilis´es dans
cette formule. Cette ´etape peut donc ˆetre r´ealis´ee par un g´en´erateur automatique de tests.
Cette g´en´eration peut mˆeme ˆetre faite, sous certaines conditions, de fa¸con compositionelle (sur la
syntaxe du formalisme utilis´e) (voir AnnexeC). Nous pensons que cette approche est assez g´en´erale pour
ˆetre instanci´ee pour plusieurs formalismes logiques utilis´es commun´ement pour exprimer des exigences sur les traces d’ex´ecution (e.g., les expressions r´eguli`eres ou la logique temporelle lin´eaire).
Il est important de noter ici la diff´erence avec les approches de v´erification et d’enforcement pr´e-c´edemment propos´ees. Les approches de v´erification et d’enforcement supposaient le programme sous jacent instrumentable. Ainsi, nous pouvions supposer que l’ensemble des ´ev´enements observables du
programme et le vocabulaire de la propri´et´e ´etaient identiques. Nous avons identifi´e des situations o`u
cette hypoth`eses ´etait difficilement r´ealisable en test. En cons´equence, le “vocabulaire” de la propri´et´e et l’ensemble des actions d’interaction avec l’implantation seront diff´erents. Chaque proposition apparaissant dans la propri´et´e test´ee s’´evaluera par des s´equences d’interactions exprim´ees dans un vocabulaire diff´erent.
Vue d’ensemble de l’approche. L’approche que nous proposons peut ˆetre r´esum´ee comme suit (cf. Fig.7.1) :
– une implantation logicielle sous testI (Implementation Under Test, IUT) ; – une exigence informelleRd´efinie `a partir de propositions abstraites pi;
– la relation qu’il souhaite tester entre les s´equences que l’implantation peut produire et les s´equences d’ex´ecution d´ecrites par l’exigence informelle ;
– et un ensemble de modules de test ´el´ementaires tpi associ´es `a chaque proposition pi d´edi´ee `a l’implantationI.
2. L’utilisateur doit ´egalement exprimer l’exigenceR par une expression formelle exprim´ee par une
r-propri´et´eΠ(choisissant un formalisme d’expression adapt´e).Πest construite `a partir des propositions
abstraites pi et un ensemble d’op´erateurs d´ependant du formalisme consid´er´e.
3. A partir de lar-propri´et´eΠ, une fonction de g´en´eration de test produit automatiquement un testeur
abstraitATΠ. Ce testeur consiste en un driver de test et un ensemble de processus de test construits
`
a partir des modules de test ´el´ementaires Tpi. Ainsi,ATΠd´epend uniquement de lar-propri´et´eΠ. 4. Un sc´enario de test est calcul´e `a partir de l’exigence formelleΠet la relation entreΠet les s´equence
d’ex´ecution de I qui doit ˆetre test´ee. Ce calcul du sc´enario se fait selon l’approche d´efinie dans le Chapitre 4, Section4.4.
5. Finalement, ATΠ est instanci´e en utilisant les modules de test ´el´ementairesTpi pour obtenir un
testeur concret TΠ pour la formuleΠ. Ce testeur concret est ensuite combin´e avec un sc´enario de
test (d´edi´e `a une relation entre les s´equence de l’implantation et la propri´et´e) pour ˆetre ex´ecut´e sur
l’implantation sous test I et produire un verdict final pour la relation test´ee.
Organisation du chapitre. La suite de ce chapitre est organis´ee comme suit. Le principe de l’approche
de test que nous proposons est pr´esent´e dans la Section 7.2. Dans la Section7.3, nous proposons une
alg`ebre de processus d´edi´ee `a l’expression des tests utilis´es dans ce chapitre. Nous pr´esentons la g´en´eration
de test dans le cadre desr-propri´et´es de la classificationSafety-Progress en Section7.4. Ces tests sont
destin´es `a ´evaluer uner-propri´et´e sur une implantation sous test. Dans la Section7.5, nous pr´esentons
l’instanciation d’un testeur abstrait en un testeur concret. Ensuite, dans la Section7.6, nous pr´esentons
l’ex´ecution de ces tests. `A partir des tests obtenus lors de la phase de g´en´eration, nous savons ´etablir
un verdict pour les relations d´ecrites au Chapitre4Section 4.4. Dans la Section 7.7, nous pr´esentons
une autre approche dirig´ee par la syntaxe pour la g´en´eration et l’ex´ecution de cas de test. Enfin, dans la Section7.8, nous concluons ce chapitre, et pr´esentons les perspectives soulev´ees par l’approche propos´ee.