Exemple 2.6.1. La Fig. 2.16.(b) pr ´esente le RA du PA T = hL, l0, ∅, Γ, ∆, Fi qui est
pr ´esent ´e dans la Fig. 2.16.(a) o `uΓ = {a, b}. Le table 2.2 pr´esente toutes les transitions du RA o `u la premi `ere colonne pr ´esente la transition et la deuxi `eme colonne indique la r `egle appliqu ´ee pour obtenir cette transition.
(a) (b) l0 l1 l2 l3 l4 b+ a+ a+ a− b+ b− b− a− l0 l1 l2 l3 l4 b a, a b
Algorithme 2.6.1 Calcul du RA [FWW97] d’un PA donn ´e ENTREE´ : Un PA hL, l0, ∅, Γ, ∆, Fi
SORTIE: un RA hL, l0, {} ∪ Γ, ∆R, Fi
VARIABLES: stack ∈ pile de L × L ; C Direct ∈ L × L pile de L × L ; C T rans ∈ L × L
pile de L × L × L × L ; l, l0, l1, l2, l3, l4∈ L;
DEBUT´
1: stack ← ∅,∆R ← ∅
2: pour chaque localit ´e l ∈ L faire 3: empiler (l, l) dans stack //R1 4: fin pour
5: pour chaque couple (l, l0) ∈ (L × L) faire
6: C Direct(l, l0) ← ∅, C T rans(l, l0) ← ∅
7: fin pour
8: pour chaque couple (l1 a+ −−→ l2,l3 a− −−→ l4) ∈ (∆ × ∆) o`u a ∈ Γ faire 9: C Direct(l2, l3) ← C Direct(l2, l3) ∪ {(l1, l4)} //R3 10: fin pour
11: pour chaque triplet (l, l0, l00) ∈ (L × L × L) faire
12: si l , l0alors
13: C T rans(l, l0) ← C T rans(l, l0) ∪ {(l0, l00, l, l00))} ∪ {(l00, l, l00, l0))} //R4 14: fin si
15: fin pour
16: tant que stack , ∅ faire 17: (l, l0) ← d ´epiler(stack)
18: si (l, , l0) < ∆Ralors
19: ∆R←∆R∪ {(l, , l0)}
20: pour (l1, l2) in C Direct((l, l0)) faire
21: empiler (l1, l2) dans stack
22: fin pour
23: pour (l1, l2, l3, l4) in C T rans((l, l0)) faire
24: si (l1, , l2) ∈∆Ralors
25: empiler (l3, l4) dans stack
26: sinon
27: empiler (l3, l4) dans C Direct((l1, l2))
28: fin si 29: fin pour 30: fin si 31: fin tant que
32: pour chaque transition l1 a
+ −−→ l2o `u a ∈Γ faire 33: ∆R←∆R∪ {(l 1, a, l2)} //R2 34: fin pour FIN.
Finkel et al. proposent le th ´eor `eme 2.6.1 qui montre le lien d’atteignabilit ´e des ´etats entre un PA et son RA. Ils proposent aussi le th ´eor `eme 2.6.2 `a propos de la complexit ´e de calcul du RA d’un PA donn ´e.
Th ´eor `eme 2.6.1. Un ´etat (l, p) est atteignable dans un PA si et seulement si la localit ´e l
Th ´eor `eme 2.6.2. Le RA d’un PA donn ´e est calcul ´e avec une complexit ´e O(n3) o `u n est le
nombre de localit ´es du PA [FWW97].
Transition de∆R R `egle (l0, , l0) R1car l0∈ L (l1, , l1) R1car l1∈ L (l0, , l2) R3car (l0, a+, l1) ∈∆, (l1, , l1) ∈∆R et (l1, a−, l2) ∈∆ (l2, , l2) R1car l2∈ L (l3, , l3) R1car l3∈ L (l2, , l4) R3car (l2, b+, l3) ∈∆, (l3, , l3) ∈∆R et (l3, b−, l4) ∈∆ (l0, , l4) R4car (l0, , l2) ∈∆R et (l2, , l4) ∈∆R (l4, , l4) R1car l4∈ L (l0, a, l0) R2car (l0, a+, l0) ∈∆ (l0, b, l0) R2car (l0, b+, l0) ∈∆ (l0, a, l1) R2car (l0, a+, l1) ∈∆ (l2, b, l3) R2car (l2, b+, l3) ∈∆
TABLE2.2 – Transitions du RA present ´e dans la Fig. 2.16.(b)
2.7/
C
ONCLUSIONNous avons pr ´esent ´e dans ce chapitre quelques notions et d ´efinitions des mod `eles qui sont largement utilis ´ees pour sp ´ecifier des syst `emes comportementaux et des syst `emes temps-r ´eel dans le but de les tester et de les v ´erifier. Dans le chapitre suivant, nous pr ´esentons des m ´ethodes existantes de g ´en ´eration de tests `a partir de ces mod `eles.
´
ETAT DE L’ART
Sommaire
3.1 Test structurel et fonctionnel . . . . 37
3.2 G ´en ´eration de tests `a partir d’IOLTS . . . . 45
3.3 G ´en ´eration de tests `a partir de PA . . . . 47
3.4 G ´en ´eration de tests `a partir de TAIO . . . . 50
3.5 Conclusion . . . . 54
Tester est l’une des principales m ´ethodes qui peuvent ˆetre utilis ´ees pour s’assurer de la correction d’un logiciel. De ce fait, il y a donc une activit ´e de recherche tr `es importante pour automatiser la g ´en ´eration et l’ex ´ecution des tests. L’approche de g ´en ´eration de tests `a partir de mod `eles a pour objectif de v ´erifier si une impl ´ementation est conforme `a une sp ´ecification. Dans ce chapitre, nous allons nous int ´eresser aux m ´ethodes de tests `a partir d’IOLTS, de TAIO et de PA. Les IOLTS et les TAIO sont des syst `emes qui interagissent avec leur environnement par des op ´erateurs d’entr ´ee et sortie, ce qui est souvent le cas par exemple pour des applications critiques. Notons que les automates `a pile peuvent ˆetre utilis ´es pour mod ´eliser des programmes r ´ecursifs.
Dans la Sec. 3.1, nous pr ´esentons quelques notions habituelles dans le domaine du test, test structurel et test fonctionnel, g ´en ´eration de tests `a partir de mod `eles et test de conformit ´e. Nous pr ´esentons dans la Sec. 3.2 des m ´ethodes de g ´en ´eration de tests `a partir d’un IOLTS. Nous montrons quelques m ´ethodes de g ´en ´eration de tests `a partir d’un PA dans la Sec. 3.3. Enfin, nous pr ´esentons dans la Sec. 3.4 des m ´ethodes de g ´en ´eration de tests `a partir d’un TAIO.
3.1/
T
EST STRUCTUREL ET FONCTIONNELLes tests peuvent aussi ˆetre cat ´egoris ´es en fonction des diff ´erents aspects du syst `eme qu’ils visent `a exercer. Il existe dans la litt ´erature plusieurs m ´ethodes de test. Parmi celles- ci, on peut distinguer deux grandes familles de test de programme : les m ´ethodes de test structurel qui sont bas ´ees sur l’analyse du code source et les m ´ethodes de test fonction- nel qui s’appuient sur la sp ´ecification des programmes. Le test de conformit ´e appartient `a la famille du test fonctionnel dont l’objectif est de r ´epondre `a la question suivante : ”Est ce que l’impl ´ementation sous test est conforme `a sa sp ´ecification ?”. Notons qu’une sp ´ecification d’un syst `eme transformationnel peut- ˆetre de type pre-post. Par contre la
sp ´ecification d’un syst `eme r ´eactif est de type comportemental sous forme d’un syst `eme d’actions ou d’un syst `eme ´etat-transition.
3.1.1/ NOTION DE TEST
Dans la litt ´erature, on trouve de nombreuses d ´efinitions de la notion de test, plus ou moins diff ´erentes. Ci-dessous, nous en pr ´esentons quelques unes qui sont prises de la th `ese [SK06].
- ”Le test est l’ex ´ecution ou l’ ´evaluation d’un syst `eme ou d’un composant par des moyens automatiques ou manuels, pour v ´erifier qu’il r ´epond `a ses sp ´ecifications ou identifier les diff ´erences entre les r ´esultats obtenus” - IEEE (Standard Glossary of software Engineering Terminology) [IEE90].
- ”Tester, c’est ex ´ecuter le programme dans l’intention d’y trouver des anomalies ou des d ´efauts” [Mye79].
- ”Le processus de test consiste en une collection d’activit ´es qui visent `a d ´emontrer la conformit ´e d’un programme par rapport `a sa sp ´ecification. Ces activit ´es se basent sur une s ´election syst ´ematique des cas de test et l’ex ´ecution des segments et des chemins du programme” [Was77].
- ”L’objectif du processus de test est limit ´e `a la d ´etection d’ ´eventuelles erreurs d’un programme. Tous les efforts de localisation et de correction d’erreurs sont class ´es comme des t ˆaches de d ´ebogage. Ces t ˆaches d ´epassent l’objectif des tests. Le pro- cessus de test est donc une activit ´e de d ´etection d’erreurs, tandis que le d ´ebogage est une activit ´e plus difficile consistant en la localisation et la correction des erreurs d ´etect ´ees [IW78].
Pr ´esentons maintenant les deux grandes classes de test [Bei90][Bei95a] : le test struc- turel et le test fonctionnel.
3.1.2/ TEST STRUCTUREL PAR EXECUTION SYMBOLIQUE ET´ MUTATION
Le test structurel, ou test boite blanche [Bei90], est bas ´e sur une analyse du pro- gramme. Il n ´ecessite le code source du programme (ou d’un mod `ele). Les tests struc- turels s’int ´eressent principalement aux structures de contr ˆole et aux d ´etails proc ´eduraux. Ils s’int ´eressent ´egalement aux d ´ependances de donn ´ees repr ´esent ´ees par un graphe de flot de donn ´ees. Ils permettent de v ´erifier si les aspects int ´erieurs de l’implantation ne contiennent pas d’erreurs de logique. Ils s’appuient sur l’analyse du code source de l’application pour ´etablir les tests en fonction de crit `eres de couverture du graphe de flot de contr ˆole (instructions, point de contr ˆole, chemins) ou du graphe de flot de donn ´ees ou d’un mod `ele de fautes.
3.1.2.1/ G ´ENERATION DE TESTS COUVRANT LE GRAPHE DE FLOT DE CONTR´ OLEˆ
Elle se base sur une repr ´esentation du programme par un graphe de flot de contr ˆole. Les nœuds du graphe repr ´esentent des blocs d’instructions, les arcs sont orient ´es et repr ´esentent la possibilit ´e de transfert de l’ex ´ecution d’un nœud `a un autre. La g ´en ´eration de tests se base sur des crit `eres de couverture du graphe. Il existe plusieurs crit `eres de
couverture [ZHM97] comme la couverture de tous-les-nœuds (bloc d’instructions), la cou- verture de tous-les-arcs, la couverture de tous-les-chemins-ind ´ependants, la couverture de toutes-les-PLCS (Portions Lin ´eaires de Code suivies d’un Saut), la couverture des chemins limites et int ´erieurs, la couverture de tous-les-k-chemins et la couverture de tous-les-chemins quand c’est possible. Le crit `ere ”tous les nœuds” consiste `a g ´en ´erer des cas de test qui passent au moins par chaque nœud (bloc d”instructions). Le crit `ere ”tous les arcs” vise `a s ´electionner les cas de test qui couvrent tous les arcs d’enchaine- ment de blocs d’instructions. Le crit `ere ”tous les chemins” consiste `a g ´en ´erer les cas de test qui couvrent tous les chemins du graphe du flot de contr ˆole.
3.1.2.2/ G ´ENERATION DE TESTS COUVRANT LE FLOT DE DONN´ EES´
La couverture de flot de donn ´ees [FW88][Her76] se base sur une repr ´esentation du pro- gramme par un graphe de d ´ependances de donn ´ees. Le flot de donn ´ees est repr ´esent ´e en annotant le graphe de contr ˆole par des informations sur les utilisations de variables par le programme :
• Def(x) : instruction pour d ´efinir x comme par exemple : affectation de x, instruction de lecture de x, etc.
• use(x) : instruction d’utilisation de x comme par exemple : x dans le membre droit d’une affectation, utilisation de x dans une condition, etc.
• paire Def-Use pour x : il existe au moins une trace d’ex ´ecution passant par Def puis par Use, tel que x n’est pas red ´efini entre Def et Use.
• chemin Def-Use pour x : un chemin passant par une paire Def-Use de x.