4.3 G´en´eration de tests concrets
4.3.2 G´en´eration de tests Java
"Cas de test 1i", init, new("p2"), rdy("p2"), swap(), rdy("p1"),
...
"Cas de test 1k", init, rdy("p1"), new("p1"), rdy("p1"), rdy("p3"), rdy("p1"),
...
Les chaˆınes de caract`eres entre guillemets ("), comme "Cas de test 1", ne sont pas
interpr´et´ees par l’atelier, sauf lorsqu’il s’agit du param`etre d’une op´eration.
Les appels d’op´erations sont ex´ecut´es les uns `a la suite des autres. Il s’av`ere que le fichier
d’entr´ee est limit´e en taille et ne peut exc´eder un certain nombre d’appels. L’´elaboration
d’un pilote de test nous a permis de passer outre cette limitation (cf Chapitre 7).
4.3.2 G´en´eration de tests Java
Les tests que nous g´en´erons pour Java sont ex´ecut´es `a l’aide du framework de test JUnit.
Avant l’ex´ecution de chaque cas de test, JUnit ex´ecute une m´ethode permettant d’initialiser
le syst`eme, c’est-`a-dire de cr´eer les instances qui vont ˆetre utilis´ees pour le test.
L’utili-sateur doit donc d´efinir de quelle mani`ere les instances vont ˆetre cr´e´ees. Rappelons qu’il a
pr´ealablement d´efini le type de ces objets (p1 :PID,p2 :PIDetc.) dans la partie d´eploiement
de l’application. Par exemple, pour l’exemple du gestionnaire de processus, l’utilisateur peut
d´efinir les instanciations suivantes :
p1 = new PID("p1");
p2 = new PID("p2");
p3 = new PID("p3");
Sch1 = new Scheduler();
La classe de test peut maintenant ˆetre g´en´er´ee. En premier lieu, nous d´eclarons sous la
forme d’attributs de la classe, les diff´erentes variables d´efinies dans le d´eploiement :
public class TestS1 extends TestCase {
PID p1;
PID p2;
PID p3;
Scheduler Sch1;
Nous g´en´erons ensuite la m´ethode setUp qui est appel´ee avant chaque cas de test et qui
permet d’initialiser l’´etat pour chaque test :
protected void setUp(){
p1 = new PID("p1");
p2 = new PID("p2");
p3 = new PID("p3");
Sch1 = new Scheduler();
}
Pour finir, chaque cas de test est stock´e dans une m´ethode qui lui est propre :
...
public void testSequence 11(){
try{
Sch1.new(p1);
Sch1.new(p1);
Sch1.rdy(p1);
Sch1.rdy(p1);
} catch( JMLEntryPreconditionError e$) {
...
} catch( JMLAssertionError e$){
...
}
...
L’outil JUnit identifie les cas de tests en r´ecup´erant les m´ethodes de la classe de test qui
commencent partest. Puis, il les ex´ecute les uns `a la suite des autres en faisant en s´equence
un appel `a la m´ethode setUp(), un appel `a la m´ethode contenant le cas de test et un appel
`a la m´ethode tearDown() qui permet de mettre le syst`eme dans un ´etat stable apr`es le cas
de test. Cette derni`ere m´ethode est, elle aussi, d´efinie par l’utilisateur. ´Etant donn´e que nous
r´einitialisons l’application avant chaque test, nous n’avons pas eu `a utiliser cette m´ethode.
4.4 Synth`ese
Nous proposons ici une technique permettant de structurer les tests et d’amplifier la
cr´eativit´e de l’ing´enieur de test. La d´efinition de campagnes de tests permettant de mettre
en œuvre diff´erentes instanciations de l’application ainsi que la d´efinition de groupes de
m´ethodes permettent `a l’utilisateur de structurer ses tests. Les sch´emas de tests permettent
`a l’utilisateur de d´efinir simplement et rapidement de nombreux tests. La structuration des
donn´ees de tests lui permet d’adapter rapidement les tests `a ses besoins : si une valeur ne
convient pas, il lui suffit de la changer au niveau du groupe concern´e et de reg´en´erer les
tests. La g´en´eration combinatoire va amplifier sa cr´eativit´e en produisant des tests auxquels
il n’aurait pas pens´e. Nous offrons ici une chaˆıne compl`ete de production de tests
permet-tant `a l’utilisateur de produire des tests ex´ecutables. Aujourd’hui nous n’avons cibl´e que les
langages VDM et Java mais nous pouvons facilement imaginer traduire les tests abstraits
dans d’autres langages comme le C ou le C++.
Cependant, de par la nature mˆeme du fonctionnement de cette technique, nous tombons
sur le probl`eme de l’explosion combinatoire du nombre de tests. Si cet ´el´ement n’est pas
cor-rectement maˆıtris´e, l’utilisateur risque de g´en´erer un trop grand nombre de tests les rendant
inexploitables (temps d’ex´ecution et d’analyse trop long).
Afin d’´eviter ce probl`eme, il faut, pour chaque sch´ema de tests, r´eussir `a trouver le bon
compromis entre le nombre de valeurs de param`etres, la longueur des s´equences que l’on
souhaite g´en´erer, le nombre de m´ethodes par groupe et le nombre d’it´erations de chaque
appel de groupe. Il n’y a malheureusement pas de recettes miracles, c’est `a l’utilisateur de
faire les bons choix de test. Nous montrons comment il est possible d’utiliser cette approche
de mani`ere intelligente chapitre 5. De plus, nous proposons , chapitres 6 et 7, des techniques
permettant `a l’utilisateur de mieux contrˆoler le nombre de tests g´en´er´es et d’optimiser le
temps d’ex´ecution des tests en fonction de l’ex´ecution d’autres tests.
Chapitre 5
´
Etude de cas industrielle en Java
Ce chapitre traite une ´etude de cas effectu´ee lors de la collaboration entre la soci´et´e
Gem-plus et le laboratoire LSR au cours du projet COTE. Depuis Gem-plusieurs ann´ees d´ej`a, la soci´et´e
Gemplus s’est int´eress´ee au d´eveloppement d’applications pour carte `a puce (smartcard) `a
l’aide de m´ethodes formelles et notamment `a l’aide de la m´ethode B [Abr96]. Gemplus s’est
´egalement int´eress´e au langage JML afin de valider des applications embarqu´ees sur carte `a
puce `a l’aide de techniques de preuve implant´ees dans l’outil Jack [BRL03].
La preuve permet de garantir la correction d’une application par rapport `a sa sp´ecification
formelle. Toutefois, le caract`ere ind´ecidable des logiques utilis´ees empˆeche le solveur de
r´esoudre automatiquement toutes les obligations de preuve. De plus, l’activit´e de preuve
ne permet de garantir que la conformit´e de l’application vis-`a-vis de sa sp´ecification
for-melle, or, le cahier des charges informel est rarement enti`erement d´ecrit par la sp´ecification
formelle. Dans un tel contexte, d’autres activit´es de validation, comme le test, doivent ˆetre
utilis´ees.
Ce chapitre pr´esente les r´esultats de notre activit´e de test, effectu´ee `a l’aide des outils
d´evelopp´es au sein de notre laboratoire, dont l’outil Tobias pr´esent´e dans cette th`ese.
Ce chapitre se d´ecoupe en quatre parties. En premier lieu, nous pr´esentons le contexte de
l’´etude ainsi que l’application test´ee. Puis, nous pr´esentons notre d´emarche exp´erimentale.
Nous d´efinissons ensuite les diff´erentes campagnes de tests qui ont ´et´e cr´ees. Pour finir, nous
pr´esentons les r´esultats obtenus.
5.1 Contexte et application
Dans le document
Outils pour la synthèse de tests et la maîtrise de l'explosion combinatoire.
(Page 76-80)