Algorithme calculant le maximum de trois entiers donn ´es

r ´esultat : max //maximum de a, b, c

l0: max ← a si l1: b > max alors l₂: max ← b fin si si l3: c > max alors l₄: max ← c fin si l5: retourner max end.

Le tableau suivant pr ´esente les quatre chemins d’ex ´ecution et le pr ´edicat de chacun de ces chemins o `u a0, b0 et c0 sont des valeurs symboliques de a, b et c. Ces chemins sont

obtenus en construisant l’arbre pr ´esent ´e dans la Fig. 3.2 en faisant des branchements `a chaque point de choix, o `u li est le num ´ero de l’instruction de l’algorithme 3.1.1 et PC est

le pr ´edicat.

Chemins d’ex ´ecution Pr ´edicat de chemins cas de test

1 l0,l1,l3,l5 b06 a0 ∧ c06 a0 a0 = 2, b0= 0, c0= 0 2 l0,l1,l3,l4,l5 b06 a0 ∧ c0> a0 a0 = 1, b0= 0, c0= 2 3 l0,l1,l2,l3,l5 b0> a0∧ c06 b0 a0 = 1, b0= 2, c0= 1 4 l0,l1,l2,l3,l4,l5 b0> a0∧ c0> b0 a0 = 1, b0= 2, c0= 3 l0| PC= true | a = a0, b = b0, c = c0 l1 | PC = true | a0, b0, c0, max = a0 l3 | PC = b0 6 a0 | a0, b0, c0, max = a0 l5| PC= b06 a0∧ c06 a0| a0, b0, c0, max = a0 l4| PC= b06 a0∧ c0 > a0| a0, b0, c0, max = a0 l5| PC= b06 a0∧ c0> a0| a0, b0, c0, max = c0 max ← a b6 max c6 max c> max max ← c l2 | PC = b0 > a0 | a0, b0, c0, max = a0 l3 | PC = b0 > a0 | a0, b0, c0, max = b0 l5| PC= b0> a0∧ c06 b0| a0, b0, c0, max = b0 l4| PC= b0> a0∧ c0> b0| a0, b0, c0, max = b0 l5| PC= b0> a0∧ c0> b0| a0| a0, b0, c0, max = c0 b> max max ← b c6 max c> max max ← c

Il existe des m ´ethodes de test qui combinent ex ´ecution concr `ete et symbolique. Elles sont appel ´ees m ´ethodes concoliques. Elles ont permis le d ´eveloppement de plusieurs outils de g ´en ´eration de tests pour les programmes ´ecrits en langage C tels que DART [GKS05] PathCrawler [WMMR05], Cute [SMA05].

3.1.2.4/ G ´ENERATION ET´ EVALUATION PAR MUTATION´

Le test par mutation est une technique de test structurel propos ´e par Millo [DLS78a]. Elle consiste `a g ´en ´erer des versions erron ´ees du programme sous test appel ´e mutant qui est une copie exacte du programme sous test apr `es l’injection d’une erreur. Des op ´erateurs de mutation d ´ecrivent les fautes susceptibles d’ ˆetre pr ´esentes dans une trans- formation de mod `eles. Le testeur cr ´ee chaque mutant en appliquant ces op ´erateurs. Le test de mutation est une technique pour l’ ´evaluation et l’am ´elioration d’une suite de tests [Ham77][DLS78b]. La mutation peut ˆetre utilis ´ee dans les cas suivants :

• G ´en ´eration de tests par mutation : elle consiste `a g ´en ´erer des cas de tests permet- tent de d ´etecter des erreurs inject ´ees. Les cas de tests engendr ´es `a partir d’un mu- tant repr ´esentent des ex ´ecutions qui d ´etectent une erreur pour une impl ´ementation qui engendrerait cette ex ´ecution. Les auteurs de [AJT15] pr ´esentent un processus de g ´en ´eration de tests par mutation `a partir d’un mod `ele donn ´e. Il existe plusieurs m ´ethodes comme celle pr ´esent ´ee dans [ALN13] pour tester des automates tempo- ris ´es, [ABJK11][SHJ11] pour tester des mod `eles UML et [BHM+10][HRK11] dans le cadre de mod `eles Simulink. Une publication r ´ecente r ´edig ´ee par Jia and Har- man [JH11] montre l’int ´er ˆet pour les tests de mutation et souligne les probl `emes ouverts de g ´en ´erer des cas de test au moyen d’une analyse de mutation.

• ´Evaluation de tests par mutation : c’est une technique qui vise `a ´evaluer la qualit ´e d’une suite de tests par rapport aux fautes les plus probables qui ont ´et ´e en- visag ´ees. La qualit ´e d’une suite de tests est ´evalu ´ee quantitativement par la pro- portion de mutants qu’il est capable de d ´etecter.

3.1.3/ TEST FONCTIONNEL DE CONFORMITE ENGENDR´ E´ A PARTIR DE MOD` ELES`

Le test fonctionnel est bas ´e sur la relation entre la sp ´ecification et l’interface du pro- gramme. Il n’examine pas le programme, mais il examine son comportement observable. On pr ´esente dans cette partie le test fonctionnel, le processus de la g ´en ´eration de tests

`a partir de mod `eles et le test de conformit ´e.

3.1.3.1/ TEST FONCTIONNEL

Le test fonctionnel (appel ´e aussi test de boˆıte noire) [Bei95a] vise `a examiner le com- portement fonctionnel d’un logiciel et sa conformit ´e avec la sp ´ecification du logiciel. Il s’int ´eresse aux besoins fonctionnels du logiciel. Il comporte deux ´etapes importantes : l’identification des fonctions que le logiciel est suppos ´e offrir et la cr ´eation de donn ´ees de test qui vont servir `a v ´erifier si ces fonctions sont r ´ealis ´ees par le logiciel ou pas.

3.1.3.2/ G ´ENERATION DE TESTS´ A PARTIR DE MOD` ELES`

Le Model Based Testing (MBT ) [LY96][Bei95b][UL07] ou ”Test `a partir de mod `eles” est une approche de g ´en ´eration de tests fonctionnels `a partir de mod `eles qui est une descrip- tion du syst `eme appel ´ee sp ´ecification formelle. Elle utilise un solveur de contraintes pour g ´en ´erer des cas de test fonctionnels couvrant les comportements mod ´elis ´es du syst `eme sous test. Le processus de MBT est pr ´esent ´e dans la Fig. 3.3. Ses principales phases sont les suivantes :

1. d ´eveloppement pour produire une impl ´ementation appel ´ee syst `eme sous test SUT

(pour System Under Test) `a partir d’un cahier des charges ;

2. conception d’un mod `ele abstrait d ´edi ´e au test d’un syst `eme donn ´e : concevoir un

mod `ele `a partir duquel seront produits les cas de test `a ex ´ecuter sur le syst `eme sous test ;

3. g ´en ´eration de tests pilot ´ee par les mod `eles et une strat ´egie de test ;

4. concr ´etisation pour ´etablir un lien entre les ´el ´ements du mod `ele et les ´el ´ements

concrets du syst `eme. C’est une ´etape encore largement manuelle et qui n ´ecessite l’expertise de l’ing ´enieur pour passer d’une suite de tests abstraits en suite de tests ex ´ecutables ;

5. ex ´ecution des tests sur le syst `eme sous test et constitution de leur verdict en com-

parant les r ´esultats obtenus sur le SUT aux r ´esultats attendus par les tests. L’oracle est d ´efini par le mod `ele ;

Il existe des outils MBT comme CertifyIt1, Matelo2, etc.

3.1.3.3/ TEST DE CONFORMITE´

Sp ´ecification T g ´en ´eration de tests

crit `ere de couver- ture, param `etres

suite de tests

Impl ´ementation I concr ´etisation et

ex ´ecution des tests

pass/fail/inconc I est conforme `a T ?

FIGURE3.4 – Processus de test de conformit ´e

Le test de conformit ´e [Tre93][RAY87] est un test fonctionnel qui consiste `a v ´erifier qu’une impl ´ementation est conforme `a sa sp ´ecification. La sp ´ecification est une description formelle des comportements attendus du syst `eme. L’impl ´ementation `a tester n’est connue que par ce qui est observable `a partir de son interface et la conformit ´e est d ´efinie entre une sp ´ecification et ce qui est observable sur le syst `eme sous test. Le test de conformit ´e permet donc de d ´eterminer la conformit ´e d’un composant ou d’un syst `eme `a vis `a vis de ses exigences qui ont ´et ´e sp ´ecifi ´ees dans le mod `ele. Il vise `a v ´erifier que l’impl ´ementation remplit bien les fonctions attendues, et c’est pourquoi on le dit test fonctionnel. Dans cette section, nous pr ´esentons le processus de test de conformit ´e qui est pr ´esent ´e dans la Fig. 3.4. Les ´etapes sont les suivantes :

• G ´en ´eration de tests `a partir d’une sp ´ecification : c’est une activit ´e pilot ´ee par le tes- teur dont le but est de produire des cas de test `a partir de la sp ´ecification selon des crit `eres de couverture s ´electionn ´es. Ces cas de test observent une impl ´ementation relativement `a une relation de conformit ´e donn ´ee.

• Concr ´etisation puis ex ´ecution des tests : c’est un processus qui stimule l’impl ´ementation sous test par un cas de test. L’impl ´ementation r ´eagit `a ces stim- ulus et d ´elivre des r ´eponses qui vont ˆetre observ ´ees et utilis ´ees pour annoncer le verdict de test selon une relation de conformit ´e. Il existe trois types de verdict :

- pass si l’application des s ´equences de test permet d’observer sur

l’impl ´ementation des r ´eactions conformes `a celles de la sp ´ecification. Donc, il n’y a pas d’erreur d ´etect ´ee et l’on dit que le test a r ´eussi.

1. http://www.smartesting.com/fr/certifyit/

- inconc si l’application des s ´equences de test ne permet pas de conclure sur

la conformit ´e de l’impl ´ementation et qu’il n’y a pas d’erreur d ´etect ´ee, mais que l’objectif n’est plus atteignable.

- fail si l’ex ´ecution montre la pr ´esence d’erreurs dans l’impl ´ementation car on

observe une r ´eponse qui n’est pas la r ´eponse attendue. On dit qu’une erreur de non conformit ´e est d ´etect ´ee et l’impl ´ementation n’est pas conforme `a sa sp ´ecification.

Nous avons introduit dans ce chapitre des notions li ´ees au test d’une fac¸on g ´en ´erale. Et nous avons d ´etaill ´e les notions de test structurels et de test fonctionnels. Dans les sections suivantes, on pr ´esente des m ´ethodes de g ´en ´eration de tests existantes `a partir des mod `eles comme les IOLTS, les PA et les TAIO.

3.2/

G ´

´

`

’IOLTS

Dans cette partie, nous pr ´esentons une m ´ethode de g ´en ´eration de tests bas ´ee sur les syst `emes de transitions `a entr ´ees/sorties.

3.2.1/ RELATION DE CONFORMITE´ ioco

Dans cette partie, on d ´efinit la relation de conformit ´e ioco de Tretmans [Tre99] pour les automates non temporis ´es avec entr ´ees/sorties. Pour pr ´esenter la relation de conformit ´e ioco pour un IOLTS T = hS, s0, Σin ∪Σout ∪ {τ}, ∆i , on a besoin de d´efinir les notations

suivantes :

• safter ρ = {s0 | s →ρ}est l’ensemble d’ ´etats de T atteignable par la trace ρ.

• S T races(T )= {ρ ∈ (Σin∪Σout∪ {τ})∗| s0 →ρ}est l’ensemble de traces observables

pour T .

• out(s) = {a ∈ Σout | s →a} est l’ensemble des actions de sortie qui peuvent ˆetre

observ ´ees `a partir de l’ ´etat s. • out(S )= ∪

s∈Sout(s) est l’ensemble des actions de sortie qui peuvent ˆetre observ ´ees

`a partir d’un ensemble d’ ´etats S .

D ´efinition 13 : ioco [Tre99] - Relation de conformit ´e ioco

Soit T = hS, s₀, Σin∪Σout∪ {τ}, ∆i une sp´ecification et I = hSI, s₀I, ΣI_in∪ΣoutI ∪ {τI}, ∆Ii

une impl ´ementation de T . Formellement, I est conforme `a T , not ´e I ioco T , ssi ∀ρ.(ρ ∈ S T races(T ) =⇒ out(I after ρ) ⊆ out(T after ρ)).

Elle signifie que l’impl ´ementation I est conforme `a la sp ´ecification T si et seulement si apr `es toute trace de T , chaque action de sortie de I est sp ´ecifi ´ee par T .

Exemple 3.2.1. La Fig. 3.5.(a) pr ´esente un exemple d’une sp ´ecification T o `u Σin =

{a} et Σout = {b, c}. Les figures 3.5.(b), 3.5.(c) et 3.5.(d) pr´esentent des exem-

ples d’impl ´ementations appel ´ees I1, I2 et I3. L’impl ´ementation I1 est conforme `a T .

L’impl ´ementation I2 n’est pas conforme `a T car out(I2a f ter ) = {b} * out(T after ) = {}.

L’impl ´ementation I3 n’est pas conforme `a T car out(I3 a f ter ?a) = {d} * out(T a f ter

l0 l1 l2 l3 (a).T ?a !b !c l0 l1 l2 (b).I1 ?a !b l0 l1 (c).I2 !b l0 l1 l2 (d).I3 ?a !d

FIGURE3.5 – Exemple d’une sp ´ecification et de trois impl ´ementations

3.2.2/ G ´ENERATION DE TEST´ A PARTIR D` ’UNIOLTS

Algorithme 3.2.1 G ´en ´eration de cas de tests `a partir d’un IOLTS donn ´e [Tre99]