Les pilotes de test
Les pilotes de test, tel que Cactus6 pour le test d’EJB, servent `a ex´ecuter une suite de tests concrets sur l’impl´ementation consid´er´ee et `a ´evaluer si les tests se d´eroulent sans erreur. Dans le cas o`u une erreur survient, le pilote de test permet d’identifier la source de l’erreur.
Les compilateurs
Ces composants int´egr´es `a Objecteering permettent de traduire un test abstrait sous la forme d’un test ex´ecutable pour une cible donn´ee. Ces compilateurs ont ´et´e d´efinis pour les langages Java et Corba, entre autres.
3.3. L’ARCHITECTURE DU PROJET COTE 37
TGV
TGV effectue la g´en´eration de tests abstraits `a partir d’objectifs de test et d’une sp´ecification. Les objectifs de test sont fournis soit de mani`ere manuelle soit via une interface d’Objecteering. TGV est pr´esent´e plus en d´etail dans le chapitre 2.
UMLAUT
L’outil UMLAUT d´evelopp´e par l’IRISA permet de simuler une sp´ecification UML [JHGP99] en calculant le graphe d’accessibilit´e de la sp´ecification. La sp´ecification doit contenir un diagramme d’´etats-transitions ´etendu par du code Eiffel permettant l’animation de la sp´ecification. Dans le cadre du projet COTE, UMLAUT construit le produit de l’ensemble des diagrammes d’´etats-transitions pour calculer la sp´ecification comportementale du syst`eme [Gue01].
UMLAUT est coupl´e `a TGV pour animer la sp´ecification comportementale et fournir `a TGV les transitions possibles. Ce travail conjoint permet `a TGV de travailler sur la sp´ecification comportementale `a la vol´ee.
TObiAs
L’outil TObiAs (Test OBjective desIgn ASsitant) permet de d´efinir des sch´emas de test et de construire des objectifs de test associ´es `a ces sch´emas. TObiAs interagit aussi avec l’outil Casting pour obtenir des jeux de valeurs pour les param`etres. TObiAs sera pr´esent´e de mani`ere plus compl`ete dans le chapitre 4.
Casting
L’outil Casting est en marge de la chaˆıne principale d’outils d´efinie dans le projet. DansCOTEcet outil intervient de deux fac¸ons :
– en l’associant `a TObiAs pour qu’il lui fournisse des valeurs de tests ou va-lide des s´equences de test ;
– en synth´etisant des tests abstraits `a partir de la sp´ecification UML [AJ03], et en offrant une mesure de couverture de la sp´ecification en terme de cou-verture des branches du diagramme d’´etats-transitions.
R´esum´e
Le projet COTE avait comme objectif de mettre en place un environne-ment de test UML permettant d’automatiser, au moins partielleenvironne-ment, la phase d’´elaboration des tests dans le cadre de sp´ecifications comportementales ex-prim´ees en UML. Le projet COTE permet de r´eduire le temps de conception des tests en proposant diff´erents niveaux de description de ceux-ci (tests abstraits, ob-jectifs de test et sch´emas de test) et en permettant de passer d’un niveau `a un autre automatiquement.
L’outil TObiAs permet de synth´etiser des objectifs de test `a partir des sch´emas de test tandis que les outils UMLAUT/TGV permettent d’obtenir des tests abstraits associ´es `a ces objectifs de test. Les compilateurs int´egr´es `a Objecteering et les pilotes de test sp´ecifiques assurent la traduction des tests abstraits vers les langages cibles et leur ex´ecution.
Un autre objectif de l’environnement COTE ´etait de g´erer la phase de d´ecision d’arrˆet des tests afin de couvrir tout le processus de test. Seul l’outil Casting int`egre une notion de couverture de la sp´ecification par une suite de tests. Mais cette sp´ecificit´e n’est pas int´egr´ee dans le processus principal de l’environnement COTE. La troisi`eme partie de cette th`ese pr´esentera la notion de couverture de la sp´ecification que nous avons mise en place au niveau des sch´emas de test.
Dans la partie suivante nous pr´esentons plus en d´etail la notion de sch´ema de test ainsi que l’outil TObiAs. Nous d´ecrivons des ´etudes de cas ayant permis d’´evaluer l’apport de l’approche propos´ee.
Deuxi`eme partie
Les sch´emas de test et leur outillage
Introduction aux sch´emas de test et
`a TObiAs
Le projet COTE pr´esent´e dans la partie pr´ec´edente avait pour but de construire un environnement UML pour le test de conformit´e, notamment dans le cadre du test de composants. Cet environnement a la particularit´e de permettre la mod´elisation des tests `a diff´erents niveaux d’abstraction, ainsi que l’automatisa-tion de la cr´eal’automatisa-tion de tests ex´ecutables.
Nous avons effectu´e deux tˆaches principales, fortement li´ees, sur le projet COTE. La premi`ere a consist´e `a ´elaborer un nouveau niveau d’abstraction pour d´efinir des tests, ce sont les sch´emas de test. La deuxi`eme tˆache consistait `a outiller les sch´emas de test, afin de faciliter l’´ecriture de sch´emas de test et de g´en´erer automatiquement des tests `a des niveaux d’abstraction moindre. Cet outil est l’outil TObiAs.
Dans la section 3.2 nous avons pr´esent´e les diff´erents niveaux d’abstraction du projet, dont le niveau des objectifs de test. Ce niveau permet au testeur de d´ecrire un test partiellement, l’outil TGV ´etant alors en charge de compl´eter ces objec-tifs de test pour obtenir des tests abstraits. L’inconv´enient de TGV est qu’il ne produit qu’un test abstrait `a partir d’un objectif de test `a chaque ex´ecution. Deux ex´ecutions successives de TGV avec ce mˆeme objectif de test peuvent permettre de produire deux tests diff´erents. De plus, il est souvent n´ecessaire que l’ing´enieur de test d´ecrive un objectif de test tr`es d´etaill´e afin de guider l’outil vers le cas de test souhait´e [Mar01]. Sachant qu’une campagne de test industrielle peut com-prendre plusieurs milliers de tests, l’ing´enieur de test peut ˆetre amen´e `a ´ecrire autant d’objectifs de test.
Il a ´et´e constat´e exp´erimentalement que les objectifs de test pouvaient pr´esenter de nombreuses similarit´es [Mar01, dBMJ01]. C’est pourquoi nous avons propos´e de d´efinir la notion de sch´ema de test, qui permet de factoriser
certains ´el´ements des objectifs de test. Un sch´ema de test peut alors ˆetre d´epli´e en plusieurs objectifs de tests, qui auraient sinon dˆu ˆetre ´ecrits `a la main (pour une partie). Ainsi, l’id´ee principale des sch´emas de test est d’exprimer les similarit´es entre les objectifs de tests via des expressions de plus haut niveau d’abstraction.
Cette deuxi`eme partie de la th`ese pr´esente les sch´emas de test et les concepts qui leurs sont associ´es, ainsi que l’outil TObiAs. Le chapitre 4 sera consacr´e `a la pr´esentation de la syntaxe et de la s´emantique des sch´emas de test puis `a leur mise en œuvre dans TObiAs. Le chapitre 5 pr´esentera les diff´erentes orientations prises avec les sch´emas de test et TObiAs pour les exploiter dans d’autres cadres que celui de la g´en´eration d’objectifs de test. Enfin le chapitre 6 illustrera l’utilisa-tion des sch´emas de test et de TObiAs sur deux ´etudes de cas. La premi`ere ´etude pr´esentera une utilisation conjointe de TOBiAs et TGV sur un syst`eme d’ascen-seur. La seconde ´etude, men´ee d’une part par le laboratoire de recherche de Gem-plus et d’autre part par notre laboratoire, portera sur l’utilisation de TObiAs sur un syst`eme bancaire.
Chapitre 4
Sch´emas de test et TObiAs
Ce chapitre est compos´e de trois parties. La premi`ere partie pr´esente les abs-tractions qu’apportent les sch´emas de test par rapport aux objectifs de test ainsi que la syntaxe des sch´emas de test. La deuxi`eme partie d´ecrit la s´emantique as-soci´ee aux sch´emas de test, en d´epliant les sch´emas de test en des objectifs de test. La troisi`eme partie est consacr´ee `a l’outil TObiAs qui permet la cr´eation des sch´emas de test et leur d´epliage en objectifs de test.
4.1 Les sch´emas de test
Nous avons vu pr´ec´edemment que [Mar01] et [dBMJ01] mettaient en ´evidence la n´ecessit´e de g´en´erer de multiples objectifs de test semblables pour mener `a bien une campagne de test. Comme nous avons pu le voir dans le chapitre 2, les objectifs de test mettent en jeu des instances ainsi que des appels de m´ethodes. Factoriser ces objectifs de test permet d’´ecrire une seule expression pour exprimer plusieurs objectifs de test. Cette expression se nomme sch´ema de test. Nous avons d´ecid´e d’effectuer cette factorisation par rapport aux m´ethodes, aux valeurs des param`etres, aux instances sur lesquelles s’appliquent les m´ethodes ainsi qu’au nombre de r´ep´etitions d’appels de m´ethodes. Un sch´ema de test se d´efinit de la mani`ere suivante :
D´efinition 2 (Sch´ema de test) chemin partiel dans la sp´ecification
comportementale qui fait abstraction des instances et factorise les r´ep´etitions d’appels de m´ethodes, les m´ethodes ainsi que les valeurs de leurs param`etres.
4.1.1 L’environnement des sch´emas de test
Les sch´emas de test servent `a exploiter les similarit´es entre plusieurs objectifs de test, tel que le fait que l’on puisse ˆetre amen´e `a ex´ecuter le mˆeme test sur des
instances diff´erentes.
De mˆeme, certains objectifs de test ont un mˆeme pr´eambule suivi, soit d’un appel `a une mˆeme m´ethode mais avec des valeurs de param`etres diff´erentes, soit d’appels `a des m´ethodes diff´erentes. Les sch´emas de test comportent la notion de groupe qui permet d’exprimer de telles abstractions sur les m´ethodes et sur les param`etres.
D´efinition 3 (Groupe) repr´esentation abstraite d’un ensemble de
m´ethodes avec pour chaque param`etre de chaque m´ethode un jeu de valeurs possibles.
A partir de ces informations sur les groupes et sur les instances mis en jeu, le testeur peut ´ecrire des sch´emas de test suivant la grammaire d´efinie dans le tableau 4.1.
Les trois notions de sch´ema de test, groupe et ensemble d’instances forment ce que nous appelons un environnement de campagne de test. Cet environnement constitue le cadre dans lequel est ´elabor´ee une campagne de test pour produire des suites de test.
D´efinition 4 (Environnement de campagne de test) correspond `a un
ensemble de param`etres constitutifs d’une campagne de test, `a savoir les instances sous test et les groupes.
4.1.2 La grammaire des sch´emas de test
Les sch´emas de test ayant pour but de d´ecrire de fac¸on abstraite des objectifs de test exploitables par TGV, nous avons choisi des constructions similaires `a celles d´efinies pour les langages O-TeLa et TeLa [PJH+01] du projet COTE. Le tableau 4.1 d´ecrit la grammaire des sch´emas de test. Les constructions offertes par la grammaire sont illustr´ees ci-dessous, en prenant l’exemple du diagramme de classes de la figure 4.1 page 46. Dans cet exemple l’environnement de campagne
4.1. LES SCH ´EMAS DE TEST 45
ST : := SEQ8ST
| SEQ
SEQ : := STRUCT ; SEQ
| STRUCT STRUCT : := BOUCLE | COREG | STRICT | −APPEL | APPEL | ST
APPEL : := INST !INST.GROUPE INST : := identifiant | * GROUPE : := identifiant BOUCLE : := APPEL∧NB | (ST)∧NB NB : := entier..entier | *
COREG : := <APPEL>COREG
| <APPEL><APPEL>
STRICT : := [ST]
constitu´e des m´ethodes m3 et m4 et les instances a1 de la classe A et b1 de la classe B.
A B
m1()
m2() m3()m4()