APPEL
“a1 !b1.g2” est un appel qui signifie que dans l’instance a1 de la classe A, on fait appel `a une m´ethode du groupe g2 de l’instance b1 de la classe B. Un appel doit respecter deux conditions : qu’il existe une relation entre les classes correspondant aux 2 instances mises en jeu (ici une relation entre A et B), et que le groupe consid´er´e contienne une m´ethode d´efinie dans la classe de la deuxi`eme instance (ici g2 contient les m´ethodes m3 et m4, toutes deux d´efinies dans la classe B). Dans un sch´ema de test, une instance peut ˆetre clairement identifi´ee par son nom ou remplac´ee par “*” qui d´esigne toutes les instances v´erifiant les deux conditions ci-dessus.
BOUCLE FINIE
Les sch´emas de test permettent de d´ecrire une r´ep´etition d’une mˆeme partie d’un sch´ema de test. Si nous avons par exemple : (ST)∧ 2..4, cela signifie que nous avons deux `a quatre appels successifs `a ST. Il faut donc produire des objectifs de test avec 2, 3 et 4 fois la s´equence repr´esent´ee parST. entier repr´esente les bornes inf´erieure et sup´erieure de la r´ep´etition d’un appel. La borne inf´erieure ne peut pas prendre une valeur plus petite que 1 et doit ˆetre inf´erieure `a la borne sup´erieure.
BOUCLE INFINIE
L’ing´enieur de test a la possibilit´e d’exprimer le fait qu’on fasse un nombre d’it´eration non d´efini sur une s´equence d’appel. On d´efinit une boucle infinie non born´e avec la notation ∧ * .
“a1 !b1.g2∧ *” signifie que l’appel `a une m´ethode du groupe g2 par l’instance
4.1. LES SCH ´EMAS DE TEST 47 SEQUENCEMENT´
Le s´equencement est repr´esent´e par le symbole ; . C’est l’op´eration de base des sch´emas de test. Cette op´eration permet d’ordonner les appels dans un sch´ema de test.
“a1 !b1.g2 ; b1 !a1.g1” signifie que la s´equence est form´ee d’un appel `a une m´ethode du groupe g2 suivi d’un appel `a une m´ethode du groupe g1.
ALTERNATIVE
Les sch´emas de test peuvent contenir du non d´eterminisme, de la mˆeme fac¸on que les objectifs de test g´er´es par TGV. Pour exprimer ce choix nous utilisons le symbole 8 .
a1 !b1.m3()8a1 !b1.m4() correspond au fait que pour ce sch´ema de test,
l’ins-tance a1 peut aussi bien proc´eder `a un appel `a la m´ethode m3 qu’`a un appel `a la m´ethode m4(). Le sch´ema de test “a1 !b1.m4()8a1 !b1.m3()” a le mˆeme
compor-tement. CO-REGION´
Le m´ecanisme de co-r´egion permet de repr´esenter le caract`ere parall`ele ou non ordonn´e d’une ex´ecution. Si nous avons par exemple <app1><app2><app3>, cela signifie que nous n’imposons pas d’ordre entre les occurrences des appels de m´ethode app1, app2 et app3. Les s´equences suivantes sont donc possibles :
– app1 ; app2 ; app3 – app1 ; app3 ; app2 – app2 ; app1 ; app3 – app2 ; app3 ; app1 – app3 ; app1 ; app2 – app3 ; app2 ; app1 NEGATION´
Dans un sch´ema de test on peut exprimer le fait qu’on ne veuille pas voir ap-paraˆıtre un appel. Le symbole − est plac´e juste `a gauche de l’appel non d´esir´e. “a1 !b1.g2 ;−a1 !b1.g2 ; b1 !a1.g1” signifie qu’apr`es un premier appel `a une
m´ethode du groupe g2 il ne peut pas y avoir un autre appel `a une m´ethode de ce mˆeme groupe tant qu’un appel `a une m´ethode du groupe g1 n’a pas eu lieu. SEQUENCE STRICTE´
s´equence qui reste ins´ecable dans les tests abstraits.
“[a1 !b1.g2 ; a1 !b1.g2 ; b1 !a1.g1]” caract´erise les objectifs de test qui com-portent une suite d’appel stricte `a des m´ethodes des groupes g2, g2, g1 et qui ne peut pas ˆetre interrompue par un autre appel de m´ethode.
4.2 La g´en´eration des objectifs de test
TObiAs permet de g´en´erer des objectifs de test correspondant `a un sch´ema de test. Le format adopt´e pour les objectifs de test est un format propri´etaire dans lequel les boucles finies sont d´epli´ees et les groupes d´ecompos´es en m´ethodes instanci´ees. La fonction de traduction T d´ecrite dans le tableau 4.2 permet de calculer, pour chaque forme de sch´ema de test, l’ensemble des objectifs de test qui lui sont associ´es.
Seul les APPELS et les BOUCLES FINIES sont interpr´et´es `a ce niveau. Les autres constructions sont interpr´et´es dans un deuxi`eme temps lors de la traduction vers un langage cible donn´e.
La fonction T n´ecessite un contexte qui d´ecrit l’environnement de campagne de test et le diagramme de classes de la sp´ecification.
– Comme d´ecrit dans la d´efinition 4, un environnement de campagne est constitu´e de l’ensemble “I” des instances sous test et des groupes. La fonc-tionGprend en entr´ee un nom de groupe et renvoie l’ensemble des appels de m´ethodes de ce groupe.
– Le diagramme de classes permet de connaˆıtre les associations entre classes et la visibilit´e des m´ethodes (savoir si elles sont publiques ou priv´ees). L’ensemble des associations entre classes, nomm´e “R”, permet de savoir s’il existe une relation entre deux instances de classe et de d´eterminer pour chaque m´ethode la liste des instances qui peuvent les appeler1.
La fonction Classe prend comme param`etre un nom d’instance et renvoie le nom de la classe associ´ee. Dans notre exemple,Classe(a1) = A. La fonction M Classerenvoie, quant `a elle, l’ensemble des m´ethodes de la classe associ´ee `a l’instance pass´ee en param`etre.
1Dans le cas de la deuxi`eme r`egle, l’existence d’une relation entre les classes des instances i1 et i2 est v´erifi´ee `a l’´ecriture du sch´ema. Il n’est pas utile d’effectuer `a nouveau cette v´erification.
4.3. MISE EN ŒUVRE DE TOBIAS 49
T(E∧int1..int2) ={e1;.. ;en| ∀i∈1..n,ei ∈T(E)
∧int1≤n≤int2}
T(i1 !i2.groupe) ={i1 !i2.m|m∈G(groupe)∧m ∈M Classe(i2)}
T(* !i2.groupe) ={i1 !i2.m|m∈G(groupe)∧i1∈I
∧(Classe(i1), Classe(i2))∈R∧m∈M Classe(i2)}
T(i1 !*.groupe) ={i1 !i2.m|m∈G(groupe)∧i2∈I
∧(Classe(i1), Classe(i2))∈R∧m∈M Classe(i2)}
T(* !*.groupe) ={i1 !i2.m|m∈G(groupe)∧i1∈I∧i2∈I
∧(Classe(i1), Classe(i2))∈R∧m∈M Classe(i2)}
T(E18E2) ={e18e2|e1∈T(E1)∧e2∈T(E2)}
T(E1 ; E2) ={e1;e2|e1∈T(E1)∧e2∈T(E2)}
T(E∧*) ={e∧*|e∈T(E)}
T(<E1>E2) ={<e1>e2|e1∈T(E1)∧e2∈T(E2)}
T(<E1><E2>) ={<e1><e2>|e1∈T(E1)∧e2∈T(E2)}
T([E]) ={[e]|e∈T(E)}
T(−E) ={−e|e∈T(E)}
T((E)) ={(e)|e∈T(E)}
TAB. 4.2 – Traduction des sch´emas de test
4.3 Mise en œuvre de TObiAs
Nous venons de pr´esenter les sch´emas de test et les r`egles de traduction uti-lis´ees pour g´en´erer des objectifs de test `a partir de ces sch´emas de test. Un sch´ema de test ne se compose pas d’une seule expression, il est soumis au contexte d’un diagramme de classes ainsi que d’un ensemble d’instances et d’un ensemble de groupes qui forment l’environnement de campagne de test.
Pr´esentation
TObiAs se d´ecompose en deux parties. La premi`ere est l’interface utilisateur qui permet au testeur de d´efinir des environnements de campagne de test pour lesquels il d´efinit des sch´emas de test. La seconde partie de TObiAs consiste en l’implantation d’un algorithme de g´en´eration d’objectifs de test, correspondant `a la fonction de traduction T vue pr´ec´edemment et leur traduction enIOLTS.
Interface utilisateur de TObiAs
1. Importation d’un diagramme de classes
TObiAs prend en entr´ee un diagramme de classes relatif au syst`eme `a tes-ter. Actuellement ce diagramme est sous la forme d’un fichier XMI g´en´er´e par l’outil Objecteering. A partir du diagramme de classes, TObiAs affiche les diff´erentes classes du syst`eme, avec leurs m´ethodes et les types de param`etres de ces m´ethodes. Ce diagramme permet ´egalement de construire les relations entre classes (la relation R de la section pr´ec´edente) et les liens entre m´ethodes et classes (la fonctionM Classe).
2. D´efinition de l’ensemble des instances
Chaque environnement de campagne de test s’appuie sur un ensemble d’instances. L’utilisateur peut d´efinir autant d’instances diff´erentes qu’il le souhaite par classe du diagramme de classe. Cette d´efinition produit l’ensemble I et la fonction Classe de la section pr´ec´edente.
3. D´efinition des groupes
Les groupes se d´efinissent en s´electionnant des m´ethodes et en d´efinissant pour chaque param`etre de ces m´ethodes un ensemble de valeurs. Les groupes peuvent ˆetre d´efinis d’une fac¸on globale au niveau du diagramme de classe. Dans ce cas ils sont utilisables dans tous les environnements de campagne de test. Ils peuvent aussi ˆetre rattach´es `a un environnement de campagne de test sp´ecifique, dans ce cas les groupes ne peuvent ˆetre consitu´es que de m´ethodes appartenant `a des classes repr´esent´ees par des instances, et les groupes ne sont utilisables que dans cet environnement.
4. D´efinition des sch´emas de test
TObiAs poss`ede une interface de d´efinition des sch´emas de test (figure 4.2) qui permet toutes les constructions d´efinies pour les sch´emas de test. Chaque sch´ema de test est d´efini dans le cadre d’un environnement de campagne de test, pour des ensembles d’instances et de groupes donn´es.
G´en´eration des objectifs de test
5. D´epliage et synth`ese d’objectifs de test
La fonction T est implant´ee dans TObiAs et assure la g´en´eration automatique de l’ensemble des objectifs de test associ´es `a un sch´ema de test.
4.3. MISE EN ŒUVRE DE TOBIAS 51