Automatisation du test tous-les-chemins en présence d'appels de fonctions

HAL Id: tel-00514053

https://tel.archives-ouvertes.fr/tel-00514053

Submitted on 1 Sep 2010

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of

sci-entific research documents, whether they are

pub-lished or not. The documents may come from

teaching and research institutions in France or

abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est

destinée au dépôt et à la diffusion de documents

scientifiques de niveau recherche, publiés ou non,

émanant des établissements d’enseignement et de

recherche français ou étrangers, des laboratoires

publics ou privés.

Automatisation du test tous-les-chemins en présence

d’appels de fonctions

Patricia Mouy

To cite this version:

Patricia Mouy. Automatisation du test tous-les-chemins en présence d’appels de fonctions. Génie

logiciel [cs.SE]. Université d’Evry-Val d’Essonne, 2007. Français. �tel-00514053�

présentée à l'INSTN(Institut National de S ien es etTe hniques Nu léaires)

pour obtenir legrade de

DOCTEUR DE L'UNIVERSITE D'EVRY VAL D'ESSONNE

par : Patri ia Mouy

Spé ialité : Informatique

Automatisation du test de tous-les- hemins

en présen e d'appels de fon tion

Soutenue le16mai2007

Composition du Jury :

 GillesBernot présidentdu jury

 Fabri eBouquet rapporteur

 Arnaud Gotlieb examinateur

 Pas ale Le Gall dire tri e de thèse

 Yves Le Traon rapporteur

 BrunoMarre examinateur

Définitions et on epts . . . 10 Notations . . . 12 1 Introdu tion 13 1.1 Contexte. . . 13 1.2 Sujet . . . 17 1.3 Plan . . . 19 I Contexte du mémoire 21 2 LangageC 23 2.1 Typesdebase . . . 23 2.2 Notiondevariables . . . 24 2.3 Stru turesdulangage . . . 24

2.3.1 Instru tionélémentaire:l'ae tation. . . 24

2.3.2 Évaluationd'uneexpressionetvéri ationd'une ondition . . . 25

2.3.3 Stru tures onditionnelles . . . 25

2.3.4 Stru turerépétitiveWhile . . . 26

2.4 Autresinstru tionsdemodi ationdeotde ontrle . . . 27

2.5 CatégoriesdevariablesC . . . 27

2.5.1 Variableslo ales . . . 28

2.5.2 Variablesglobales . . . 28

2.5.3 Pointeurs . . . 29

2.6 Fon tionset pro éduresenlangageC. . . 30

2.6.1 Pro édures . . . 30

2.6.2 Fon tions . . . 31

2.6.3 Paramètresee tifset paramètresformelsd'unefon tion . . . 31

2.6.4 Typesdepassaged'arguments . . . 35

2.6.5 Variablesd'entréeet variablesdesortied'unefon tionC. . . 37

2.7 Introdu tionànotremodélisation mathématiquedesfon tionsdulangageC. . . . 39

3 Spé i ation des fon tions à basede formulespre/post 41 3.1 Pré isionssurlavaleurindénie . . . 41

3.2 Sortes,opérateurset formulesdebases . . . 41

3.2.1 Domaineet odomained'unefon tion . . . 45

3.2.2 Domainededénition d'unefon tion. . . 45

3.3 Modèleasso ié . . . 46

3.4 Spé i ationdesfon tionsC . . . 47

3.5 Quelquespropriétésdesspé i ations . . . 51

4.1 Représentationdesstru turesdulangageC . . . 58

4.2 Constru tiond'unCFG . . . 60

4.3 Cheminsd'exé utionet prédi atsde hemin . . . 63

4.4 Modi ationdela onstru tionduCFGd'unefon tion ontenantdesinstru tions d'appel. . . 66

4.4.1 Cara térisationd'unefon tionimbriquéeenlangageC . . . 67

4.4.2 Isolationd'uneinstru tiond'appeldansunblo debase . . . 67

4.4.3 Illustration . . . 67

5 Introdu tion au testde logi iel 69 5.1 Dénitions . . . 69

5.1.1 Test delogi iel . . . 69

5.1.2 Autresdénitions né essaires . . . 70

5.2 Cy leenVetniveaux detest . . . 72

5.2.1 Cy leenV . . . 72

5.2.2 Validation etvéri ation. . . 72

5.2.3 Diérentsniveauxd'a tivitésdetest . . . 73

5.3 Diérenteste hniquesdetest. . . 73

5.3.1 Test statique . . . 74

5.3.2 Test dynamique. . . 74

5.3.3 Exé utionetévaluationsymbolique . . . 74

5.4 Te hniquesd'analyse . . . 75

5.4.1 Critèrefon tionnel . . . 76

5.4.2 Critèrestru turel . . . 76

5.5 Diérentesstratégiespourdéterminerlesdonnéesdetest . . . 78

5.5.1 Test exhaustif. . . 79

5.5.2 Stratégiealéatoire . . . 79

5.5.3 Stratégiestatistique . . . 79

5.5.4 Stratégie ombinatoire . . . 79

5.5.5 Analyse . . . 80

II Génération de as de test unitaires stru turels 81 6 ProblèmeATDG 83 6.1 Problèmedelagénérationautomatiquede asdeteststru turel . . . 83

6.1.1 Méthode lassique . . . 83

6.1.2 Lesprin ipaux problèmes . . . 84

6.2 Travauxdere her heantérieurs . . . 88

6.2.1 FormeSSA . . . 88

6.2.2 Méthodepoints-toanalysis . . . 90

6.2.3 Aspe tdynamique . . . 92

6.2.4 UtilisationdelaPLC . . . 93

6.2.5 Critèrestru turel des hemins. . . 94

6.2.6 Aspe tadaptatif . . . 95

6.2.7 CUTE: uneméthodepro he . . . 97

7 Laméthode PathCrawler 98 7.1 Idéedire tri e. . . 98

7.1.1 Cara téristiquesetprin ipedebase . . . 98

7.1.2 Domainessu essifsdes asdetest . . . 99

7.1.3 Explorationenprofondeur d'abordduCFG . . . 101

7.2.2 Dé ompositiondes onditionsmultiples . . . 103

7.2.3 Conitsdevariables . . . 106

7.2.4 Forme anonique desstru turesrépétitives . . . 108

7.2.5 Transformationdesstru tures onditionnellesSwit hetSwit hBreak . . . . 110

7.2.6 Isolementdesexpressionsàeetsdebord . . . 111

7.2.7 Instrumentation . . . 112

7.3 Notreappro he . . . 115

7.3.1 Cal ulduprédi atde hemin . . . 115

7.3.2 Propriétéset utilisationdesprédi atsde hemindansPathCrawler . . . 117

7.4 StratégiederésolutiondePathCrawler . . . 119

7.5 Appli ationàlafon tiongetmid . . . 120

7.5.1 Remarquespréalables . . . 120

7.5.2 Appli ation . . . 120

7.5.3 Analyse . . . 124

8 Illustrationdétaillée etanalyse 125 8.1 Appli ationdelaméthodePathCrawleràunefon tiondetrifusion . . . 125

8.1.1 Etudedelafon tionmerge . . . 125

8.1.2 Donnéesfourniesparl'utilisateur . . . 126

8.1.3 Casdetestsu essifs. . . 128

8.2 AnalysedelaméthodePathCrawler . . . 130

8.2.1 Pointsenétude . . . 130

8.2.2 Étapesnonautomatisées . . . 131

8.2.3 Intégrationd'aspe tsfon tionnelsàlaméthodePathCrawler . . . 132

8.2.4 Traitementdesappelsdefon tionsdanslafon tionsoustest . . . 132

III Génération de asde test stru turels et traitement des appels de fon tions 135 9 Notreappro he 137 9.1 Motivation . . . 137

9.1.1 Limitationsdutraitement"inlining"desfon tionsimbriquées . . . 137

9.1.2 Versunestratégiedetestmixte. . . 138

9.2 Contextesd'appeld'unefon tion . . . 140

9.2.1 Dénitiond'un ontexted'appel . . . 140

9.2.2 Contextesd'appeletstru ture répétitive. . . 142

9.3 Domained'appeld'unefon tionimbriquée . . . 143

9.4 Graphed'appel . . . 144

9.5 Prin ipedebase . . . 146

10 Étatde l'art etpositionnement 147 10.1 Généralités . . . 147

10.1.1 Test unitaire,testd'intégrationettestimbriqué . . . 147

10.1.2 Graphed'appel . . . 148

10.1.3 Diérentstypesdebou hons . . . 149

10.1.4 Lan eurs . . . 150

10.1.5 Graphed'a essibilité . . . 150

10.2 Test imbriquéouen ontexte . . . 152

10.2.1 Lamise enpla e dete hniques detestimbriqué. . . 152

10.2.2 Constru tiondesséquen esdetest . . . 153

10.2.3 Miseenparallèleave nosbesoins . . . 154

10.3.2 Méthodesdérivéesdesméthodesunitairesfon tionnelles . . . 154

10.3.3 Méthodesdérivéesdesméthodesunitairesstru turelles. . . 156

10.3.4 Méthodesdites" oupling-based" . . . 157

10.3.5 Intégrationparin rémentouparagrégats . . . 158

10.3.6 Méthodesd'intégrationas endanteset des endantes . . . 159

10.4 Uneméthodeoriginaledegestiondesappels. . . 160

10.5 Parallèleave leste hniquesexistantes pourlagestiondesappelsdefon tion . . . 160

10.5.1 Maintiendela ouverturedelafon tionsoustest. . . 160

10.5.2 Priseen ompte du omportementdesfon tionsimbriquées . . . 161

10.5.3 Positionnement . . . 162

11 Des riptionetmiseen ÷uvre 163 11.1 Prétraitementdesfon tionssoustestave appelsimbriqués . . . 163

11.2 Grapheabstrait . . . 164

11.2.1 Prin ipe . . . 165

11.2.2 Cara térisationdugrapheabstraitd'unefon tion. . . 165

11.2.3 DeuxIllustrations . . . 166

11.3 Inter onnexiondugraphede ontrlesoustest auxgraphesabstraitsimbriqués . . 168

11.3.1 Introdu tionsurunexemple . . . 168

11.3.2 Besoinde on rétisationdel'interfa e . . . 170

11.3.3 Diérentestypesdesvariables d'entréeet desortied'unefon tionC . . . . 175

11.3.4 Conséquen esurl'interfa e . . . 176

11.4 Constru tiondugraphemixted'unefon tionsoustest . . . 176

12 Soumissiondugraphemixted'unefon tionsoustestàlaméthodePathCrawler 179 12.1 Contexte. . . 179

12.2 En odagedugrapheabstraitdansPathCrawler . . . 181

12.2.1 Contraintesarithmétiques :en odagedansla ontinuitédePathCrawler . . 181

12.2.2 Autres ontraintes . . . 182

12.2.3 En odageduFIND. . . 182

12.3 Dénition d'un nouveau ritèrede test pour la ouverturedu graphemixte d'une fon tionsoustest . . . 182

12.3.1 CritèreTLCM . . . 183

12.3.2 Analyse . . . 184

12.4 Autre ritèrede ouverturedugraphemixted'unefon tionsoustest . . . 185

12.4.1 CritèreTLCS . . . 185

12.4.2 Couverturedugraphemixted'unefon tionsoustestpourle ritèreTLCS 186 12.5 Con lusion . . . 187

13 Validation 188 13.1 Analysed'unpremierexemple:appeldelafon tionma arthy. . . 188

13.1.1 Présentationdelafon tionimbriquéema arthy . . . 188

13.1.2 Traitement"inlining"delafon tionma arthy . . . 190

13.1.3 Utilisationdebou honsfon tionnels . . . 192

13.1.4 Appli ationdu ritèreTLCMaugraphemixtedelafon tionsoustest . . . 194

13.1.5 Appli ationdu ritèreTLCSaugraphemixtedelafon tionsoustest . . . 198

13.2 Se ondexemple:appeldelafon tiondelta_tab . . . 201

13.2.1 Présentationdelafon tionimbriquéedelta_tab . . . 201

13.2.2 Codesour eetspé i ation . . . 201

13.2.3 Traitement"inlining"delafon tiondelta_tab . . . 201

13.2.4 Utilisationdebou honsfon tionnels . . . 205

13.2.5 Graphemixtedelafon tionsoustestet ritèreTLCM. . . 208

14Con lusion 213

14.1 Rappelsdesobje tifs . . . 213

14.2 Bilan. . . 213

14.3 Perspe tives . . . 215

14.3.1 Problèmedes heminsmanquants . . . 215

14.3.2 Miseenpla ed'unora leautomatiquedelafon tionsoustest . . . 216

14.3.3 Test imbriquédesfon tionsimbriquées. . . 216

A Autres notionsutilesdu langage C 217 A.1 Stru tures onditionnelles Swit hetSwit hBreak . . . 217

A.2 Stru turesrépétitivesForDo etDoWhile . . . 218

B Rappelssur lathéoriedes graphes 220 B.1 Classedegraphes onsidéréedelathéoriedesgraphes . . . 220

B.2 Lesnotionsde heminspour

G =< N, E, e, s, δ >

B.3 Connexitéetsous-graphe . . . 223

C Notions de la programmationlogique ave ontraintes 225 C.1 Motivationsdelaprogrammationlogiqueave ontraintes . . . 225

C.2 Quelquesdénitionspréliminaires . . . 225

C.3 RésolutiondesCSP . . . 227

C.3.1 Simpli ationduproblème . . . 227

C.3.2 Re her hedesolutions . . . 228

2.1 SyntaxeCdelastru tureIfThenElse. . . 26

2.2 SyntaxeCdelastru tureIfThen . . . 26

2.3 SyntaxeCdelastru tureWhile . . . 27

2.4 Fon tionCave onitdevariables. . . 29

2.5 Codesour edelafon tionf . . . 33

2.6 Codesour edelafon tiongappeléedanslafon tionf . . . 33

2.7 IllustrationdesdiérentstypesdevariableC . . . 38

3.1 Codesour edelafon tionpg d. . . 53

3.2 Codesour edelafon tiontritype. . . 54

3.3 Exemplesimpled'appeldefon tion. . . 56

3.4 Implantationré ursivedelafon tionn_somme . . . 57

4.1 Représentationd'unblo debase . . . 59

4.2 Représentationdesstru turesIfThenet IfThenElse . . . 60

4.3 Représentationdesstru turesSwit hetSwit hBreak . . . 60

4.4 Représentationdesstru turesrépétitivesdulangageC . . . 61

4.5 Constru tiondegraphede ontrledelafon tionfon tion_bidon . . . 62

4.6 Algorithme lassiquede al ul deprédi atde hemin . . . 65

4.7 Codesour edelafon tionf . . . 68

4.8 Graphede ontrledelafon tionf. . . 68

5.1 Cy ledevied'unlogi ielou y leenV . . . 72

6.1 Déroulementdelaméthodestru turelle lassique . . . 84

6.2 Fon tiongetmid . . . 85

6.3 Graphe(getmid) . . . 85

6.4 Fon tionavantmisesousformeSSA . . . 89

6.5 Fon tionaprès misesousformeSSA . . . 89

6.6 Autrefon tionavantmise sousformeSSA . . . 90

6.7 Se ondefon tionaprèsmisesousformeSSA. . . 90

6.8 Fon tionexemplepourlaméthodepoints-to. . . 91

7.1 Prin ipedebase denotreappro he . . . 99

7.2 Domainesdesvaleursd'entréedes asdetest . . . 100

7.3 Illustrationdenotrestratégie . . . 102

7.4 PrétraitementdulangageC . . . 103

7.5 Fon tionCave onditionsmultiples . . . 103

7.6 Dé ompositiondes onditionsmultiples . . . 104

7.7 CFGavantetaprèsprétraitement . . . 105

7.8 Éliminationdes onitsdevariables . . . 107

7.9 Fon tionCave stru turesrépétitives . . . 108

7.12 Transformationd'unestru ture onditionnelleSwit hBreak . . . 111

7.13 Fon tionave expressionsàeetsdebords. . . 112

7.14 Isolementdesexpressionsàeetsdebord . . . 112

7.15 Fon tiongetmidaprès prétraitementdontinstrumentation . . . 121

7.16 Termesgénérésàl'instrumentationdelafon tiongetmid . . . 122

7.17 Illustrationdenotrestratégiesurlafon tiongetmid . . . 123

8.1 Fon tionmerge . . . 126

8.2 Fon tionmergeprétraitéeetinstrumentée . . . 127

8.3 ClausesProloggénéréespourlafon tionmerge . . . 128

8.4 Illustrationdenotrestratégiesurlafon tionmerge. . . 129

9.1 Graphede ontrledefs hématisé. . . 138

9.2 Graphede ontrledefave dépliagedeg . . . 139

9.3 Fon tionsoustestave plusieursinstru tionsd'appel . . . 141

9.4 CFGdelafon tionfdelagure9.3 . . . 141

9.5 Codesour edelafon tionsoustestff. . . 142

9.6 Graphede ontrledelafon tionff . . . 143

9.7 Graphed'appeldelafon tionf . . . 145

9.8 Graphed'appeldelafon tionff . . . 145

10.1 Graphed'appelsimpledelafon tionfA . . . 149

10.2 Graphed'a essibilitésimpliépourunsystèmemodélisantunema hineà afé . . 151

10.3 Exempledegraphede ontrleave dépliage delafon tionimbriquée. . . 157

11.1 Fon tionCave instru tionsd'appel . . . 163

11.2 Résultatduprétraitementsurle hierdelagure11.1 . . . 164

11.3 Représentationdugrapheabstraitdelafon tiongàpartirde

Spec(g, W, Z)

11.4 Grapheabstraitdelafon tionvalAbs . . . 167

11.5 Grapheabstraitdelafon tiongetmid . . . 168

11.6 Fon tionfsoustestappelantlafon tionvalAbs . . . 168

11.7 Graphede ontrledefetgrapheabstraitdevalAbs . . . 169

11.8 Graphemixtedelafon tionsoustest . . . 170

11.9 Fon tionfsoustestappelantlafon tiondiv . . . 171

11.10Graphede ontrledefetgrapheabstraitdediv . . . 172

11.11Graphemixtedelafon tionfappelantlafon tiondiv . . . 175

12.1 Illustrationdudépliagedelafon tiongappeléedanslafon tionf . . . 180

12.2 Dugraphede ontrleaugraphemixtedelafon tionsoustest . . . 180

12.3 Graphemixtedelafon tionf. . . 183

12.4 Chemins ouvertslorsdel'appli ationdu ritèreTLCM . . . 184

12.5 Chemins ouvertslorsdel'appli ationdu ritèreTLCS . . . 186

13.1 Implantationsdesfon tionsfetma arthy . . . 189

13.2 Spé i ationdelafon tionma arthy . . . 189

13.3 Graphede ontrledelafon tionappelantlafon tionma arthy. . . 190

13.4 CheminsduCFGdelafon tionsoustest ouvertslorsdel'utilisationd'unbou hon fon tionnel . . . 194

13.5 Graphemixtedelafon tionappelantlafon tionma arthy. . . 195

13.6 Constru tiondel'arbredes heminsfaisablesdugraphe mixtede lafon tionsous testpourle ritèreTLCM . . . 196

13.7 Chemins ouvertsdanslegraphemixtepourle ritèreTLCM . . . 197

13.8 Constru tiondel'arbredes heminsfaisablesdugraphe mixtede lafon tionsous testpourle ritèreTLCS . . . 198

13.10Codesour edelafon tionsoustestetdelafon tionimbriquéedelta_tab . . . . 202

13.11Spé i ationdelafon tiondelta_tab . . . 202

13.12Graphedeotde ontrledelaguredelta_tab. . . 203

13.13Graphede ontrledelafon tionappelantlafon tiondelta_tab. . . 203

13.14Graphede ontrledelafon tionfave dépliagedugraphedelafon tionimbriquée delta_tab. . . 205

13.15CheminsduCFGdelafon tionsoustest ouvertslorsdel'utilisationd'unbou hon fon tionnel . . . 207

13.16Graphemixtedelafon tionappelantlafon tiondelta_tab. . . 208

13.17Constru tiondel'arbredes heminsfaisablesdugraphe mixtede lafon tionsous testselonle ritèreTLCM. . . 209

13.18Chemins ouvertslorsdelasoumissiondugraphemixtedelafon tionsoustestau ritèreTLCM . . . 211

A.1 SyntaxeCdelastru tureSwit h . . . 217

A.2 SyntaxeCdelastru tureSwit h ave l'utilisationdel'instru tionbreak. . . 218

A.3 SyntaxeCdelastru tureDoWhile . . . 218

A.4 SyntaxeCdelastru tureForDo . . . 218

B.1 Illustrationd'ungraphe orienté

G =< N, E >

B.2

G =< N, E, e, s >

G

′

_{=< N}

′

_{, E}

′

_{, e}

′

_{, s}

′

_{, δ}

′

_>

G =< N, E, e, s, δ >

2.1 Intervalles destypesdebaseet tailleasso iéeeno tets. . . 24

7.1 FormatagedesvariablesdanslestermesProlog . . . 113

7.2 Équivalen edelasyntaxeCetdelasyntaxeProlog . . . 114

7.3 Exemplesderèglesdesimpli ation destermes Prolog . . . 114

13.1 Diérents résultats obtenus pour le test de la fon tion appelant la fon tion ma arthy . . . 201

13.2 Diérents résultats obtenus pour le test de la fon tion appelant la fon tion delta_tab . . . 210

alavolée,84 ae tation onsistante,189 ae tationin onsistante,189 ae tationpartielle (CSP),189 ae tationtotale (CSP),189 alias,29 ba ktra k,191 blo debase,51,58 bogue,60 bou honfon tionnel,125 bou honstru turel,125

al uld'un hemin,57

asdetest,61

atégoriedefon tion,130

CFG,53

hemin,185

hemind'exé utionpartiel,55

hemind'exé utiontotal,54

heminfaisable,56 hemininfaisable,56 heminmanquant,62 hemins-long

n

odomained'unefon tion,41

omposantdelogi iel,63 onitdevariable,27 onnexité,186 onsistan ed'ar ,189 onsistan edebornes,189 ontexted'appel,117

ouplespre/post ontradi toires,46

ouverturedetest,61

ritèredetest, 61

ritèreMC/DC,89

ritèrestru tureldesk- hemins,75

ritèreTLCM,153 ritèreTLCS,155 CSP,189 CSPéquivalents,190 défaut,60 dénitiondevariable, 25

domained'appeld'unefon tion,120

domained'un hemin,57

domained'unefon tion,41

domainededénition,42

domainefon tionnel,45

ensembledes ontextesd'appel,117

évaluationsymbolique,64

otde ontrle,24

fon tion,30

fon tion ommeopération,37

fon tionimbriquée,57

formulelogique, 41

formulelogiqueatomique, 40

grapheétiqueté,184

grapheabstrait,140

graphed'a essibilité,126

graphed'appel,124

graphed'appelpartiel,121

graphedeotde ontrle,53

grapheorienté,184

graphe unique entrée, unique sortie orienté,

185 hypothèsed'uniformité,62 instrumentation,62 intégrationas endante,133 intégrationdes endante,134 intégrationensandwi h,134 intégrationmassive,133

intégrationparagrégats,133

intégrationparin rément,133

interprétationd'unefon tion,43

jeu detest,61

labelling,190

lan eur,125

obje tifdetest, 61

o urren ed'unevariable, 41

o urren elibre,41 opérateurdebase,40 ora ledetest, 61 orientéebut, 62 orientée hemin,62 paramètresee tifs,32 paramètresformels,32

passaged'argumentparadresse,34

passaged'argumentparvaleur,33

pointeur,28

post ondition,44

pré ondition,44

prédé esseur,185

pro édure,29 qualitédetest, 61 rédu tiond'unCSP, 190 séquen edetest,127 solutiond'unCSP, 189 sortesprimitives,39 sous- hemin,186 sous-graphe,186 spé i ation,38 spé i ation omplète,46 spé i ationdéterministe,46 spé i ationin ohérente,46 SSA,76 stru ture onditionnelleC,25 stru turerépétitiveC,26

stru turerépétitivexe,75

stru turerépétitivevariable,75

su esseur,185

têted'unblo debase,58

têtedeblo ,53 terme,40 testd'intégration,63 testdevalidation,63 testen ontexte,123 testexhaustif,61 testfon tionnel,65 testimbriqué, 123 testmixte,116 teststru turel,66 testunitaire,63

tra esymboliqued'exé ution,54

utilisationdevariable,25

véri ation,62

validation,62

variabled'un hemin,55

variabledesortie,35

variableglobale,28

variablelibre,41

variablesd'entréed'unefon tion,35

variablessynonymes,29

Ch

Ch(X, Y, f )

Ch

∗

Ch

p

CoDom(Ch)

CoDom(f )

CtxA(f → g)

DF

i

Def (f )

Def (f )

|user

Dom(Ch)

Dom(f )

Dom(f )

|user

DomA(f, elem(CtxA(f → g), i))

DomA

i

(g, f → g)

G =< N, E >

G =< N, E, δ >

G =< N, E, e, s, δ, X, X

L

>

G =< N, E, e, s, δ >

G =< N, E, e, s >

GAppelP :< f, F, A, δ >

L

N

, L

E

M axC

i

(X)

P C(Ch, f, X)

P P

i

(f, X, Y )

P ost(f, X, Y ) : Q(f, X, Y )

P ost(f, X, Y ) : (D(f, X) ∧ Q(f, X, Y ))

P re(f, X)

SD

i

SSD

i

Spec(f, X, Y )

V ar(Ch, G)

V arF ree()

X

X

L

X

i

Y

δ, δ

N

, δ

E

7→

L = (S, V, F, P)

L

0

= (S

0

, V

0

, F

0

, P

0

)

M

M |=

M

0

P

ef f

P

f orm

R(f )

ν

ν()

D

1

_(D2)

D

→

τ (Ch(e, s), δ)

|L|

c

j

_i

elem(L, i)

f (x

1

× . . . × x

n

) → y

1

× . . . × y

m

f : s

1

× . . . × s

n

→ s

′

1

× . . . × s

′

m

f

M

f

|X

f

return

p

i

()

p

n

i

()

pc

i

pred

succ

x

in

Introdu tion

1.1 Contexte

Le logi iel fait aujourd'hui partie intégrante de notre quotidien que sesoit sur nos lieux de

travail (ordinateurs, logi iels,...), à domi ile (téléphone portable,...), dans nos dépla ements

(voiture, train,...), et . Cette présen e des logi iels dans notre quotidien a ompagnée de

dysfon tionnements ne nous surprend plus. Nous avons tous souert au moins une fois d'un

"plantage" intempestif denotre ordinateur outéléphone portablepour les as lesplus ourants.

Ces bogues sontdevenus presquehabituelsmais sonten généralsans grandeimportan e et sans

onséquen e. En revan he, si nous prenons omme exemple un défaut dans un régulateur de

vitesseautomobile ( asavéréil yaen orepeude temps),d'unlogi ielavioniqueou en ored'un

logi ieldepilotagedetrains,nousnousplaçonsdans unelogiquetotalementdiérente.La lasse

delogi iels on ernéeest touteautre. Elleregroupeleslogi ielsqualiésde ritiques:engénéral,

ils interviennent dans des domaines sensibles omme eux des transports, de la produ tion

d'énergie, delasanté et delanan e.La ara térisation ommuned'un logi iel ritiqueest tout

logi iel dontune anomalie dans son fon tionnement peutavoirdes onséquen es beau oup plus

importantesquelebéné epro uréparleservi equ'ilassureenabsen e d'anomalies[LAB

+

95℄.

Pour e typedelogi iels,ilest primordialdepouvoirs'assurerdeleursbonsfon tionnements.

Legénielogi ielpermetd'a quérirla onan edésiréedansleslogi iels ritiquesoudumoins,

des'enappro her.Selonl'arrêtédu30dé embre1983,"legénielogi ielestl'ensembledesa tivités

de on eptionetdemiseen÷uvredesproduitsetdespro édurestendantàrationaliserlaprodu tion

dulogi iel etson suivi".Myers[Mye79℄dénit legénielogi iel ommel'ensembledespro édures,

méthodes, langages, ateliers, imposés ou pré onisés par les normes adaptées à l'environnement

d'utilisationan defavoriserlaprodu tion etlamaintenan ede omposantslogi ielsdequalité.

Legénielogi ielestbasésurdesméthodologiesetdesoutilsquipermettentdeformaliseretmême

d'automatiserpartiellementlaprodu tiondelogi iels,maisilestégalementbasésurdes on epts

plusinformelsetdemandedes apa itésde ommuni ation,d'interprétationetd'anti ipation.Le

génielogi iels'intéresseàlamanièredontle odesour ed'unlogi ielestspé iépuisproduit.Les

diérentesthématiquesabordéesengénielogi ielsont,defaçonnonexhaustive,laspé i ationde

fon tionnalitésd'un logi iel,la on eptiondelogi iel,lagénération automatiquede oded'après

unespé i ationformelle,....

Commelegénielogi ielestl'artdeproduiredeslogi ielsdequalité,ilfautpré iser equenous

entendonsparun"logi ieldequalité".Lesqualitésd'unlogi iel on ernentàlafoissonutilisation

(abilité, adéquation aux besoins, e a ité,...) et sa maintenan e (exibilité, portabilité,...).

Ces diérentes qualités ne sontpas toujours ompatibles ni même réalisableset il est né essaire

de trouver des ompromis. Dans tous les as, les obje tifs de qualité doivent être dénis pour

rementleproblèmedelavéri ationdesmodèlesformelsparrapportàl'expressioninformelledes

besoins.Ladi ulté résidedansladiéren edelangagesentrele lient( eluiqui ommandeun

logi ielselondesbesoinsplusoumoinspré is)etles on epteursdulogi iels( euxqui onçoivent

lelogi ieldemandé).Lepremiers'exprimedanslelangagedudomainedel'appli ationdulogi iel

ave pour support le langagenaturel. De fait, lesdésirs du lient sont généralement ambigus et

in omplets. Les on epteurs du logi iels utilisent, quant à eux, des méthodes de modélisation

omme lamodélisation UML [RJB04℄ ou des méthodes formelles ommela méthode B [Abr96℄

quisontgénéralementmalounon omprisesparle lient.

Les a tivitésde véri ation et de validation [WF89℄ ont pour but d'augmenter la sûreté de

logi iels.Selonlesdénitions ommunémentadmises,lavéri ationpermetd'établirla

orrespon-dan eentreunproduitlogi ieletsaspé i ation.Lavalidationpermetthéoriquementdes'assurer

quelelogi iela omplitbien lafon tionpourlaquelleil aété onçu.Dit plussimplement,la

va-lidationapourobje tif "lebon" logi ielalors quelavéri ation apour obje tif lelogi iel "bien

fait".Enréalité, parvéri ationetvalidation,ondésigneunensembledete hniquesportantsur

toutle y lededéveloppementdulogi ieletsurtoussesproduitsintermédiaires.Ainsi,lesrevues

etlesinspe tionsdedo umentslogi iels

1

ainsiqueletestfontpartiede este hniques.

Lesa tivitésdevalidationetdevéri ationsedéroulentbiensouvent onjointement.Deuxdes

prin ipaleste hniquesdevéri ationet validationsontlapreuveetletestdelogi iel.

Lapreuve onsisteàdémontrermathématiquementet formellementla orrespondan eexa te

entre un modèle de l'implantation d'une fon tion et sa spé i ation. Il s'agit d'une te hnique

permettantd'avoirunniveaude onan eélevédanslelogi ielmaisils'agitaussid'unete hnique

oûteuseetin omplètepourleslogi iels omplexes.

Notonsquenousnenousintéresseronspasàlapreuvedans emanus rit.Nousnous

onsa re-ronsuniquementautestdelogi iel.

Letest onsistequantàluiàmontrerla onformitéd'uneimplantationàlaspé i ationdela

fon tion surun nombreni d'exé utions (oude simulation d'exé utions)de la fon tionan d'y

trouverunmaximumdedéfauts.Myers[Mye79℄dénitundéfautdelogi ieldelafaçonsuivante:

"Asoftwareerrorispresent whentheprogramdoesnotdo whatitsenduserreasonability expe ts

todo.". Ilest importantdepré iser quemêmesi une méthodedetest nedéte te pasde défauts

dans un logi iel, elui- i ne peut pas être jugé omme 100% able. La itation de Edsger W.

Dijkstra,extraitde"NotesOnStru turedProgramming"en1970,illustrebien epoint:"Program

testing anbe usedtoshow the presen eof bugs, butnever to show theirabsen e!.".Idéalement,

la te hnique de test exhaustif permet de s'assurer de la orre tion totale d'un programme et

permet également de faire la preuvede orre tion d'un programme. Cette te hnique onsiste à

exé uterun logi iel sur toutes les ombinaisonsdes valeursen entrée possibles. Parexemple, le

test exhaustif d'unesimple fon tionpossédantune unique valeurentière enentrée odée sur 32

bits impose

2

32

as de test su essifs. On s'aperçoit que ette te hnique est malheureusement

inappli ableenréalitéà ausedunombredetestsqu'ellerequiert.

Le test de logi iel peut être distingué en trois niveaux de test selon le type de omposant

logi ieltesté.Lepremierniveaudetestlogi iel,letestunitaire,apourobje tifdevérierquedes

modules individuels omposantunlogi ielfon tionnent orre tement.Lebutdutestunitaireest

d'isoler haquemodule individuel (fon tion,méthode, lasse, ...) d'un logi iel pour montrer sa

orre tion.Cetteétapepermet defa iliter lese ond niveaude testàsavoirletest d'intégration.

Ce se ondniveau detest onsiste,quantàlui,àtester l'agen ementdesdiérentsmodules d'un

systèmeainsiquelafaçondontils ommuniquententreeux [Bei90℄pourévaluerla orre tionde

l'ensemble.

Nouspré isonsquenotretravail on erneleslangagesdeprogrammationimpératifs(en

parti- ulierlelangageC),nousne traitonsdon pasladimensionobjet.Ainsi,dans emanus rit,par

1

Lesdo umentslogi ielssonttouslesdo uments on ernantunlogi ieldonnéàsavoirl'expressiondesbesoins

Laméthodologieusuellepré onisedetesterindividuellement haquefon tiond'unlogi ielavant

de lesregrouperpour letest d'intégrationan de pouvoirvérierleurinter-fon tionnement. En

pratique, ela n'est pas aussi simple. Le fait que ertaines fon tions d'un logi iel interagissent

et/ouutilisentd'autresfon tionsd'unmêmelogi iel omplexieletestunitaire.Eneet,il n'est

pasaiséd'isolerletest unitaired'unefon tionenprésen ed'appelsdefon tions.Onest souvent

amenéà testerd'autres fon tionsdu faitqu'il existe peude fon tions réellementindépendantes

ouen oreàrempla erlesfon tionsappeléespardesmodulessimulantleursexé utions.Ainsi,la

frontièreentreletest unitaireet letestd'intégrationest trèsne etmême si,théoriquement,les

deux méthodes sont lairement dénies omme diérentes, en pratique les deux méthodes sont

étroitementliées.Ilexiste,enpratique,un ompromisentreletestunitaireetletestd'intégration.

Ils'agitdansunpremiertempsdedénirunehiérar hisationd'appelsdulogi ielsousformed'un

graphe d'appel àpartir de l'étude dulangage de programmation utilisé oude lades ription de

la spé i ation du logi iel. Deux méthodes de test d'intégration se distinguent parti ulièrement

selonl'ordred'intégrationutiliséepourregrouperlesdiérentesfon tionsdulogi ielsoustest.La

méthode"bottom-up"reposesuruneagrégationenprioritédesfon tionsdeplusbasniveaudans

lahiérar hied'appels(lesfon tionsappelées)représentéesparlesfeuillesdansungraphed'appel.

Lesfon tionsfonttoutes,aupréalable,l'objetdetestsunitaires.Ensuite,lesdiérentesfon tions

sont intégrées par étapes intermédiaires via une exploration as endante du graphe d'appel. La

méthode"top-down"débute,quantàelle,enintégrantd'abordlesfon tionsdehautniveau(les

fon tionsappelantes).Lara ine dugraphed'appelreprésente lafon tiondeplushautniveau.Il

s'agitd'uneintégrationdesfon tionsdulogi iel orrespondantàune explorationdes endantedu

graphed'appel.

Pour les systèmes reposant sur de multiples intera tions et ommuni ations entre modules

( omme lesproto olesde ommuni ation,lessystèmesde ontrlesavioniques,...)deste hniques

ditesdetestimbriquésontappliquées.Elles onsistentàtesterunitairementun omposantdonné

dansunenvironnementpré is 'est-à-direauseindugroupement omposédesautres omposants

du système. Ces te hniques se justient par la omplexité du système sous test ne permettant

pasdetesterunitairementet indépendammentles omposantsdusystème entotalité.Lebut du

testimbriquéestdevérierqu'un omposantpossèdeun omportementàl'exé ution onformeà

eluidesaspé i ationlorsqu'ilinteragitave lesautres omposants.

En quelques mots, le test d'intégration orrespondà une te hnique de test unitaire étendue

sur les agrégations su essives des fon tions d'un logi iel sous test. Les fon tions non en ore

intégrées sontsimulées et rempla éespar des bou hons pour lesfon tions de bas niveauet par

deslan eurs pourdes fon tionsdehaut niveau[Mye79℄simulant le omportement desfon tions

rempla ées. Parallèlement, letest unitaire d'unefon tion utilise également es mêmes bou hons

pour rempla er les appels de fon tions ontenus dans la fon tion testée individuellement. Du

fait de ette ambiguïté entre le test unitaire et le test d'intégration, la littérature sur le test

d'intégrationresteen oreassezfaibleaujourd'hui.Cependant,ilexistedeste hniques propresau

testd'intégrationorientéesversl'évaluationdes onnexionsentrelesfon tionsd'unlogi iel omme

[OHK93℄. Lorsdutest imbriqué,lelienentrele omposantsoustestetlesautres omposantsdu

système est évident dufait que le test imbriqué est destiné aux systèmes omposés de modules

fortementdépendantslesunsdes autres.Nousverronsunpanoramaplusdétaillédeste hniques

detestd'intégrationetdeste hniquesdetestimbriquédansle hapitre10.

Revenonsmaintenantsurlaproblématiquedutest unitaire.Trois lassesdeméthodesdetest

sedistinguentparles ritèresdeséle tiondes asdetestutilisés.Commençonsparleste hniques

de testaléatoire onsistantàinje ter au hasarddiérentesvaleursaux variablesd'entrée de

la fon tionsous test. Le omposant est exé uté ave des données hoisiesaléatoirement dans le

domainede dénition de lafon tion. En pratique,plusle nombrede asde test est grand,plus

le pour entage d'objets testésest élevé[GDGM01℄. La di ulté de es te hniques vient du fait

qu'ellesnegarantissentpasd'atteindre tousles omportementsdelafon tionetenparti ulierles

D'autre part, les te hniques de test fon tionnel (ou méthodes boîte noire) déterminent les

diérentes données de test en s'appuyant sur les do uments de spé i ation de la fon tion. Le

plussouvent, este hniquesreposentsurunpartitionnementdudomained'entrée orrespondant

auxdiérentesfon tionnalités delafon tionexpriméesdanslaspé i ation.Ellespermettentde

hoisirleniveaudedétailsdestestsparle hoixduniveaud'abstra tiondelaspé i ationutilisée.

Enn, lesméthodesdeteststru turel(ouméthodesboîte blan he)sontlesméthodeslesplus

ommunémentadmises. Elles onsistent àdéterminerles diérentes donnéesde testpar analyse

du odesour eselonuneétudeotdedonnées

2

ouselonuneétudeotde ontrle

3

delafon tion

sous test. Les ritères de ot de données sont basés sur la ouverture des hemins reliants les

dénitions 4

d'unevariable àleur utilisation

5

[RW85℄. Le but est de s'assurer quela totalité des

diérentesexé utionspossibles(ouunnombremaximal)dulogi ielabienétéexplorée.

Alande haque asdetest, ilfaut pouvoirémettreunverdi t detest 'est-à-diredénirsi

lessortiesobtenuesàl'exé utionsont onformesà ellesattenduestellesqu'ellessontdéniesdans

laspé i ation.Ils'agit duproblèmede l'ora le.Pourune méthodestru turelle, s'appuyant sur

le odesour edelafon tion,laspé i ationdelafon tionest né essairepourprévoirlesvaleurs

ensortieattendues.Laspé i ationdelafon tionestutiliséepour omparerlesvaleursensortie

obtenueslorsdes asdetestave ellesattenduesouen orepourvérierquelesvaleursensortie

obtenues àl'exé ution respe tentbien les propriétésspé iées. Pour une méthode fon tionnelle,

lamise en pla ed'un verdi t detest est fa ilitée dufait queles diérentes donnéesde testsont

déterminéesparl'étudedelaspé i ationdelafon tionsoustest.L'utilisationd'assertionsdansle

odesour edelafon tionsoustestenprogrammationdéfensiveoudansl'interfa esousformede

ontrats[Mey92℄introduitparlelangageEiel

6

deMeyer[Mey88℄,jouelerled'ora leembarqué.

Meyerest le premieràavoirutilisé lesspé i ationsexpriméessousforme de ouplespre/post

7

d'une fon tion sous test omme ora le embarqué exprimé par des assertions dans le ode. Les

assertions ontiennent des propriétés de la fon tion à vérier àun instant pré isde l'exé ution

[TBJ06℄,[CL01℄.Uneautreappro hedemiseenpla ed'ora le onsisteà al ulerlessorties

atten-duesde lafon tion ensebasantsurlaspé i ationet de omparerlerésultat auxsortiesréelles

obtenueslorsdes test[PP94℄, [GA95℄, [RAO92℄. Notonsque leproblèmede l'ora leresteen ore

troppeuabordé danslalittératureàl'ex eptiondesappro hesformelles.

L'automatisation des as de test permet de gagner en temps et par onséquent en oût de

la phasede test d'une fon tion. Dans la pratiqueindustrielle, l'automatisation dutest est trop

souventlimitéeàl'exé utiondestests.C'estl'utilisateurquidénitles asàtesteretlesdonnées

detest(entréesetsortiesattendues),éventuellementàl'aided'outilsdepréparationde"s riptsde

test".Lagénérationautomatiquedesdonnéesdetestetd'unora lepermetuneséle tiondes asde

testbaséesurdes ritèresjustiéspardeshypothèsesexpli ites.L'automatisation omplèted'une

méthode detest permet larédu tiondes oûts et desdélaisde véri ation desproduits logi iels

tout en améliorant la qualité du logi iel. Les te hniques fon tionnelles sont privilégiées pour la

générationautomatiquede asde test ommepourlesoutilsBZ-TT[ABC

+

02℄,GATEL[MA00℄,

Casting[ABM97℄,LUTESS[BORZ99℄,AUTOFOCUS[PO01℄,....Ladi ultéprin ipalede

l'au-tomatisationdutestdelogi iel on erneenparti ulierl'automatisationdel'ora le.A tuellement,

l'utilisationdespé i ationsformellesrestelemoyenre onnu ommeleplusadapté pour

l'auto-matisationd'ora lesables[GA95℄.L'utilisationdesméthodesformellesest re ommandéepourle

développementdelogi iels ritiques.Leursémantiquebiendéniepermetunespé i ationpré ise

duservi eàdélivrer.Elles sontfondéessurdesbases mathématiquespermettantéventuellement

d'ee tuerdespreuvespourdémontrer ertainespropriétésdelaspé i ationoupourvérierde

2

Uneétudeotdedonnéesebasesurlesdonnéesmanipuléesouutilesetsurleursdénitionsetleursutilisations.

3

Uneétudeot de ontrle sebasesurlesen haînementspossiblesdesdiérentes instru tionsdu omposant

soustest.

4

Ladénitiond'unevariable orrespondàunemodi ationdelavaleurdela asemémoireasso iée

5

L'utilisationd'unevariable orrespondàl'a èsenle turedela asemémoireasso iée.

6

LelangageEielestunlangagedeprogrammationpar ontratorientéobjetimplantéparBertrandMeyer.

7

Les ouplespre/postsontdespropriétéssurlesvariablesdelafon tionsoustestàvérierendiérentsinstants

del'exé ution(avantl'exé ution pourles pre onditions,aprèspourlespost onditions, à haqueinstantpourles

L'arrêtdutestsurvientquandle ritèred'arrêt(plusoumoinsformel)estsatisfait.Pourletest

unitaire,l'arrêtdutestestdire tementdéterminéparles ritèresdetestséle tionnés.Idéalement,

letests'arrêtequand:

 touslesobjets iblesdugraphede ontrleou

 touslesobjetsdugraphe deotdedonnéesdelafon tionou

 touslesdomainesd'entréedelafon tionasso iésàunefon tionnalité spé iée

ontété ouverts.Enpratique,pourdes ritèresdetestexigeants ommeles ritèresstru turels(en

parti ulierle ritèretous-les- hemins),letestpeutêtrearrêtélorsqu'unpour entagexé(tauxde

ouverture)desobjetsdugraphe de ontrleoudu graphedeotde donnéesaété ouvert. Les

méthodesorientéesotdedonnées omme[KL85℄sontre onnues ommee a esdansdiérentes

études empiriques [Won93℄, [HFGO94℄. L'automatisation de es méthodes est omplexiée par

l'étude pré ise desdénitions et utilisationsde haque variablede lafon tion soustest. Le plus

rigoureux ritèrestru turelorientéotdedonnées 'est-à-direle ritère"all-du-path"

8

estre onnu

ommemoinsrigoureuxquele ritèreorientéotde ontrletous-les- hemins.Nousavons hoisi

d'adopter e ritèred'unepartpoursarigueurmaisaussidufaitquenotrestratégiedeséle tion

des asdetestpermetdelimiterlesdi ultéspropresà e ritèreàsavoirladéte tiondes hemins

infaisables etl'explosion ombinatoiredunombredes heminstout en limitantle oût du al ul

deladéterminationdesdonnéesdetest.

Latroisièmete hniquedeteststru turelestletestmutationnel.Ils'agitdegénérerdesmutants

du odesour ede lafon tionsoustest enmodiantune seuledesesinstru tions.Le but est de

générerunesuitededonnéesdetestpermettantdetuer esmutantsouunnombremaximal

( 'est-à-dirededéte terlesanomaliesinje téesàlafon tion).Letestmutationnelresteplusuneappro he

pourévaluerlaqualitéd'unesuitededonnéesdetest.L'étudeempirique[ABL05℄montrel'e a ité

dedéte tiondesfautesdesjeuxdetestdénislorsdete hniquesdetestmutationnel parrapport

àdessuitesdetestgénéréespard'autresappro hessouventplus oûteuses.Lesméthodesdetest

mutationnel [NFTJ06℄, [BDL06℄,[OAL06℄seheurtent ependantàladi ulté demiseen÷uvre

de etteappro heenparti ulierenprésen ede mutantséquivalents(lesfautesgénéréespeuvent

nepasavoird'inuen esurl'exé utiondelafon tion).Celaimposeuneinspe tionsupplémentaire

empê hantl'automatisationde es méthodes.

Nousnousintéresseronsdon uniquementauxte hniquesdeteststru turel baséessur l'étude

du otde ontrle des fon tions soustest et en parti ulier sur l'appli ationdu ritère

tous-les- hemins.

Noussommesfor ésde onstater que,malgré larigueurdes te hniquesstru turelles, elles- i

restentpeuappliquéesenpratiqueà ausedela omplexitédupassageàl'é helleàdesfon tions

réalistes omplexes (présen e de bou les, appel àd'autres fon tions, ...) et à ause de la

di- ultéde mise en ÷uvredesjeux de test satisfaisantles ritères onsidérés(présen e de hemins

inexé utables,di ultédelamiseenpla ed'unora le,...).

Nousproposonsi i unenouvelleappro hepourletestunitairestru turel visantd'unepartà

fa iliterladéterminationetlagénérationdes asdetestetd'autrepartàautomatiseraumaximum

lagénérationdestests.

1.2 Sujet

Lesméthodesdeteststru turelsontlargementre onnuespourleurrigueur.Leteststru turel

est tout parti ulièrementrequispourleslogi iels ritiques qui doiventsatisfaire ertains ritères

imposés par les organismes normatifs (ISO, AFNOR, ...). Elles représentent un oût non

né-gligeabledans le développement des logi iels lorsque lesexigen es de sé urité sontimportantes.

Ainsi, pour le test de logi iels ritiques, il est régulièrement imposé d'atteindre une ouverture

omplètede ertainsobjetsdugraphedeotde ontrle(CFG) ommelesn÷uds,lesar set les

heminsreprésentantrespe tivementlesinstru tions,lesbran hementsoules heminsd'exé ution

8

Ce ritère orrespondà ouvrirpour haquedénitiond'unevariabletousles hemins ontenantuneutilisation

desdiérentsobjetsissusduCFG hoisis omme iblesdu ritèredetestabienétéexploréeave

lesexé utionsséle tionnées lorsdesdiérents as detest ee tués.

Dans la lasse des ritères dénis àpartir duCFG, le ritèretous-les- hemins est le ritère

le plus omplet, exigeantet demandant le plus grand nombre de as de tests. Pour les projets

logi iels industriels on ernant des logi iels de faible ou moyenne omplexité, l'appli ation du

ritère tous-les- hemins peut être imposée. Cependant, le plus souvent, la totalité des hemins

exé utablesn'est pas ouverte et on se ontente d'atteindre untauxde ouverture le plusélevé

possible.Ainsi,pourdeslogi ielsplus omplexes 'est-à-direréalistes,l'appli ationdu ritère

tous-les-bran hements( ouverturedetouteslesbran hesdugraphede ontrledelafon tionsoustest)

estsouventrequise.Unautre ritèrestru turelorientéotde ontrlesouventimposéestle ritère

MC/DC orrespondantàunevarianteplusrigoureusedu ritèretous-les-bran hements( ouverture

individuelle de tous les sous- onditions omposant une instru tion onditionnelle). Pour haque

fon tionpossédant

n

2

n

hemins diérents

d'exé utions. Par onséquent, la présen e de stru tures répétitives (ou bou les) peut résulter à

une innitéde heminsdiérents.Ilestalorsparfois né essairedelimiter lenombredepassages

dans esstru turesrépétitives:le ritèredetesttous-les- heminsestrestreintalorsau ritèredes

k

k

parstru turerépétitive.

Notons que plusieurs hemins peuvent,de plus, êtreinfaisables 'est-à-direqu'au une entrée

delafon tionn'entraînel'exé utionde es hemins.Cettedi ultéestnonnégligeable: 'estun

problèmeindé idabledans le asgénéralet NP- ompletpourdesvariablesprenantleursvaleurs

dansdesdomainesnis.

Touteslesdi ultés asso iéesauteststru turel omplexientouempê hentl'automatisation

deste hniquesdetestasso iées.

Letest stru turelpeutsedé omposerendeuxétapes:

 l'identi ationde hemin(s)dontl'exé utionestné essairepoursatisfaireun ritèredetest,

 la génération d'un as de test (i.e. ladétermination d'un ensemble devaleurspour les

va-riablesd'entrée)garantissantquele hemin(ouundes hemins) séle tionné(s) sera

ee ti-vementexé uté.

Lesdi ultés liées àl'analyse du ode sour e sont nombreuses. D'une part, les langages de

programmationne possèdent pasen général deforme anonique, il s'agit leplus souvent

d'uni-formiserl'implantationd'unefon tionparunprétraitementdu odevisantàatteindreuneforme

anonique fa ilitant l'analyse. D'autre part, pour haque hemin d'exé ution suivi, il s'agit de

onstruire le prédi at de hemin asso ié orrespondant à la onjon tion des ontraintes sur les

valeursinitialesenentréeentraînantl'exé utionde e hemin.Le al ulde e prédi atde hemin

demande un eortnon négligeablelors del'analyse du odesour e des fon tions(expressions à

eetsdebord,instru tionsdemodi ationdeotde ontrle,présen ed'alias,gestiondestypes

ottantsentreautres).Leste hniquesdeteststru turelpossèdentde efait ertainesrestri tions

quantàl'ensembledulangagedeprogrammationtraité.

Uneautre desdi ultés majeuresliéesauxméthodesstru turelles on ernel'explosion

om-binatoiredunombrede heminsenprésen edestru turesrépétitives ommenousl'avonspré isé

pré édemmentmaisaussienprésen ed'appelsdefon tions.Quandle ritèrestru turel hoisiest

tous-les- hemins,l'explosion ombinatoire on erne,parvoiede onséquen e,lenombrede asde

testàee tuer.Pourlagestiondesappelsdefon tions,deuxméthodessont ourammentutilisées.

Laméthode"inlining" onsisteàdéplierle odesour edesfon tionsappeléesdansle odesour e

delafon tionappelante pouryétendrele ritèredetest.Cetteméthodeamplie leproblèmede

l'explosion ombinatoiredunombredes heminsenajoutantla ombinatoiredunombredes

he-minsdesfon tionsappeléesàla ombinatoiredunombredes heminsdelafon tionsoustest.Une

autreméthode onsisteàsubstituerlesappelsdefon tionspardesmodulessimulantle

omporte-mentdelafon tionappeléeparl'étudedesesspé i ations(bou honsfon tionnels)ouretournant

desvaleursdonnéesenvuedela ouverturedelafon tionsoustest(bou honsstru turels)[Mye79℄

relationentrées/sortiesestainsivériéepar onstru tion.Pourun ontexted'appeletundomaine

fon tionneldonnéd'unefon tionappelée,diérents heminsensortiepeuventêtreexé utésdans

lafon tionsoustest.Ilfautalorspouvoirorienterl'exé utiondesbou honsfon tionnelspour

pou-voirgarantirlemaintiende la ouverture delafon tionsous test.Or,les bou hons fon tionnels

sontassimilablesàdes omposantsboîtesnoires.Lesbou honsstru turels, quantàeux,peuvent

amenerà ouvrirdes heminsinfaisablesenréalitédufaitquele omportementréeldesfon tions

appeléesest ignoré.

Cemanqued'outillagequantàlagestiondesappelsdefon tionempê helepassageàl'é helle

dutestunitairedefon tionsréalistes.

Nousadressons ettedi ultédemiseenpla ed'uneméthodeautomatiquedeteststru turel.

Noustraitonsenparti ulierdupassageàl'é helledeste hniquesstru turellesdetestpourletest

defon tionsdontle odefaitappelàd'autresfon tionset del'automatisationde este hniques.

Nous proposons i i une nouvelle méthode de génération automatique de as de test stru turels

[WMM04b℄ainsiqu'unenouvellegestiondesappelsdefon tionand'assurerla ouverture

stru -turelle d'une fon tion sous test [Mou07℄ . La méthode automatique de test stru turel proposée

répond au ritèrestru turel tous-les- hemins ou savariante,le ritèredes

k

mé-thode permet d'atteindre une ouverture totale des

k

en fa ilitant le problème de la déte tion des hemins infaisables pour un oût limité lors de la

déterminationdesdonnéesdetestsu essives.

En equi on ernelagestiondesappelsdefon tion,nousavons hoiside ombinerlesaspe ts

fon tionnelsetstru turelsdetestpourproterdel'ensembledeleursavantages.

Noussommespartisdel'idéed'exploiterlesspé i ationsdesfon tionspourletestd'une

fon -tiondont le ode faitappelà d'autresfon tions.Nous proposonsune nouvellemodélisation des

fon tionssoustestave instru tionsd'appelreposantàlafoissurlesinformationsstru turellesde

lafon tionsoustest et surlesinformations fon tionnellesissues delaspé i ationdesfon tions

appelées.Nousproposonségalementdeuxnouveaux ritèresdeteststru turelspermettantde

ga-rantirlemaintiendela ouverturedelafon tionsoustesttoutenlimitantl'explosion ombinatoire

dunombrede heminsprovoquéeparlesappelsdefon tions.Notreobje tifestdepouvoir

main-tenirla ouverturestru turelledelafon tionsoustesttoutenlimitantl'explorationdesfon tions

appeléesan delimiter leproblèmedel'explosion ombinatoiredunombredes hemins.

1.3 Plan

Lapremièrepartiede emanus ritprésentele ontextegénéraldelathèse.

Le hapitre2 dé rit et justie le sous-ensemble du langage C onsidérépar notre appro he.

La quasi-totalité du langage C ANSI est traitée.Les odes sour es des fon tionssont soumis à

unprétraitementde façonà e que les odes prétraitésappartiennentàunsous-ensemblepré is

dulangageCANSI.Nousdé rivonsdon esous-ensembledulangageCqui orrespondau

sous-ensembleréellementmanipulélorsdelaséle tionetdelagénérationdesdiérents asdetest.

Le hapitre3 ara tériselelangagedespé i ationutilisépourmodéliserlesfon tionsappelées.

Ce langage de spé i ation orrespond àun langage dupremier ordre sur domaines nis. Nous

présentonségalementleformat hoisi pour exprimerlesspé i ationsdesfon tionsàsavoirune

axiomatisationsousforme de ouplespre/post.

Le hapitre 4 présente la représentation ourante du ode sour e des fon tions sous test à

savoirle graphede ontrled'unefon tion (CFG).Ce hapitreintroduit égalementla notionde

hemind'unCFGetlanotionasso iéedeprédi atde hemin.NousinsistonssurlanotiondeCFG

dansla mesureoùnous proposonsune nouvellemodélisation desfon tionssoustest ave appels

s'apparentantàlareprésentation lassiqued'un odesour esousformedeCFG.

Le dernier hapitre de ette partie, le hapitre 5, est onsa ré à la présentation du test

de logi iel et des te hniques les plus ouramment utilisées. Les le teurs familiers au test

Lase ondepartiede edo umentest onsa réeauproblèmedelagénérationautomatiquede

asdeteststru turel.

Le hapitre 6 dénit la génération automatique de as de test stru turel, sa problématique

ainsiquesesprin ipalesdi ultés.Un rapidepanoramadete hniques onsa réesàlagénération

automatiquede asdeteststru turelyestégalementdressé.

Le hapitre 7 présente en détails notre méthode automatique de génération de as de test

stru turelnomméePathCrawler.Cetteméthoderespe tele ritèredeteststru turelleplus

rigou-reux:le ritèretous-les- heminsousavariante,le ritèredes

k

répétitivesànombreélevéd'itérations.Cetteméthode adaptativeréutiliseleprédi atde hemin

du as de test ourant pour déterminer les données du pro hain as de test. Les informations

extraitesduprédi at de heminpré édentpermet defa iliterladéte tiondes heminsinfaisables

toutenlimitantle oûtdeladéterminationdupro hain asdetest.

La hapitre 8illustre plus en détails notre méthode de génération de as de test stru turels

parsonappli ationsurunexemple.Nousdis utonségalementdesdi ultésdepassageàl'é helle

de etteméthodeenprésen ed'instru tionsd'appel.

Enn,la troisième partie est,quantàelle, onsa réeau traitementparti ulier des appels de

fon tions.

Dans le hapitre 9, nous faisons tout d'abord une rapide présentation de notre gestion des

appelsdefon tionsetnousdénissonslaproblématiqueasso iée.

Le hapitre10présentediérentes te hniquesdetest hargéesd'évaluerunensemblede

om-posantsentreeuxouun omposantdans unenvironnementdonné(respe tivementletest

d'inté-grationetletestimbriqué).Nousprésentonségalementplusendétailsleste hniquesd'"inlining"

etd'utilisationdebou hons,te hniquesleplussouventutiliséespourlagestiondesappelsde

fon -tion.Nouspouvonsainsinoussituerdefaçonpluspré iseparrapportauxappro hesexistantes.

Le hapitre11dé ritendétailslamiseen÷uvredenotreappro hedegestiondesappels.Nous

avons hoisid'abstrairelesfon tionsappeléesparl'étudedeleursspé i ations.Nous onstruisons

ainsiunereprésentationfon tionnelledesfon tionsappeléesdésignée ommegrapheabstrait.Cette

représentation fon tionnelledes fon tionsappelées sesubstitue aux instru tionsd'appel dans le

ode sour e de la fon tion sous test lors de la onstru tion de son graphe de ontrle. Nous

obtenons une nouvellemodélisation des fon tionssous test ave instru tions d'appelsous forme

d'un graphemixte omportantàlafois desinformations stru turellesdelafon tionsoustest et

fon tionnelles des fon tions appelées. Nous dénissons deux nouveaux ritères de test dédiés à

ettereprésentationgarantissantlemaintiendela ouverturestru turelledelafon tionsoustest

etlalimitationdel'explorationdesfon tionsappelées.

Le hapitre 12 dé rit l'appli ation de notre modélisation des fon tions sous test sous forme

de graphe mixte dans le adre de la méthode de génération de as de test PathCrawler. Nous

dénissonsensuitelesdeuxnouveaux ritèresdetestdédiésà ette représentationsousforme de

graphemixte.

Dansle hapitre13, nous validonsnotre appro he parson appli ation àdeux exemples.Ces

exemples de fon tionssous test ave instru tionsd'appels sont soumis, dans unpremier temps,

aux deux traitements lassiques d'"inlining"et d'utilisation de bou hons. Ensuite, es exemples

sont soumisàl'appli ationde nosdeux ritèresde testappliqués augraphe mixte desfon tions

soustest.Lesrésultatsobtenuspermettentd'illustrerlesgainsetavantagesdenotreappro hepar

rapportauxte hniquesplus lassiquespeuadaptées.

Enn,ledernier hapitre,la on lusion,permettradedresserunbilanpré isdenotretravail.

Nous dis utons durespe t desobje tifs initiaux et des améliorationsenvisagées de laméthode.

Nousexpliquonségalementnotre ontributionen donnantquelques-unesdesorientations

e do ument. Nousavonsen eetbesoind'établir lairement ertainesnotionspour

aborderlesdeuxthèmesprin ipauxde emanus ritàsavoirletestunitaireetletest

d'intégration.

Dans unpremier hapitre,nous donneronsles prérequis né essaires pourla le ture

de e manus rit et nous nous attarderons sur ertains points du langage étudié à

savoirlelangageC.

Ensuite, nous onsa reronsun hapitreàlaspé i ation desfon tionsCàl'aidede

formulesdetypespre/post.

Dans le hapitresuivant, nous présenteronsla notion de graphe de otde ontrle

omme la représentation interne d'une fon tion C utilisée ommunément par les

méthodesdetest stru turel.

Enn,undernier hapitredresseraunpanoramadesprin ipaleste hniquesdetestde

Langage C

La méthode présentée dans e do ument s'adresseaux langages impératifs séquentiels et en

parti ulieraulangageC,langagepourlequelnousavonsimplantéunprototypedenotrestratégie.

Nous supposons lele teur familier ave lelangage C. Cependant en asde besoin,lele teur

pourraseréférerauxmultiplesouvragesdédiésà elangage omme[Ame86℄.

Ce quinous intéressedans e do umentpar rapport aulangage Cest d'une partla

ara té-risation dela notionde otde ontrled'un programme ainsique l'expli itation desnotions de

variablesd'entréeetdesortied'unefon tionC.

Nous nous limitons dans e hapitre à un sous-ensemble du langage C orrespondant au

sous-ensemble résultant du prétraitement des fon tions ( f. se tion 7.2) sous test opéré en

amont de la génération des as de test dans notre méthode de test stru turel PathCrawler.Ce

prétraitementestbasé surl'utilisationdel'analyseursyntaxique CIL[Lan06℄.Nousinsistons sur

lefaitquenoustraitonslaquasitotalité dulangageCANSIàquelquesrestri tionsprèsdonnées

danslase tion7.2.1etsurlefaitqueleprétraitementee tué enamontdelagénérationdes as

de testparlaméthode PathCrawlersimplieet transforme ertainesstru turesdulangage sous

formes anoniques. Nousverrons également plustard quele prétraitementmodie également le

otde ontrledelafon tion.

L'annexeAprésented'autresnotionsdulangageCn'appartenantpasausous-ensemble

résul-tantduprétraitementmaisquiserontutilespourlasuite.

2.1 Types de base

En equi on erneletypagedesvariables,ilexistedeuxfamillesprin ipales.D'unepart,nous

avonsles types simples appelés types de bases et d'autre part, nous avons les types omplexes

outypesstru turésrésultantd'une onstru tiondetypesdontlabasereposesurunouplusieurs

typesdebases( ommeparexempleunevariabledetypetableau ontenant

n

debase). Nousverronsdans lase tionsuivante quelestypesdebases sontsusantspournotre

méthode de génération de as de test dans la mesure où les types stru tures sont totalement

dé omposés.

Chaque type de base est asso ié à un intervalle de valeurs muni d'un ordre total dont la

taille est dire tement dépendante de la taille en o tets asso iée. Le tableau 2.1 nous donne es

intervalles devaleurspour haquetypeCdebase selonlatailleeno tetsasso iée.

Nousréutiliserons esmêmes intervalles parla suite ommelesdomaines asso iés auxsortes

int 4

[−2

31

_{; 2}

31

_{− 1]}

[−2

15

_{; 2}

15

_{− 1]}

[−2

31

_{; 2}

31

_{− 1]}

unsignedshort int 2

[0; 2

16

_{− 1]}

unsignedlongint 4

[0; 2

32

_{− 1]}

[−2

7

_{; 2}

7

_{− 1]}

[0; 2

8

_{− 1]}

[−3.4

38

_{; 3.4}

38

_]

double(longoat) 8

[−1.7

308

_{; 1.7}

308

_]

(15 hiressigni atifs)

longdouble(nonstandard) 10

−3.4

4932

_1.1

4932

(quadruplepré ision)

Tab.2.1Intervallesdestypesdebaseettaille asso iéeeno tets

2.2 Notion de variables

Nous onsidérons omme des variables toute variable C dé larée de type de base ainsi que

haque élément de type de base des variables stru turées. Si un élément de variable de type

stru turé est également detype stru turé, nousdé omposons et élémentjusqu'àen déterminer

lesélémentsdetypedebase asso iés.

Illustration 1

Ladé larationdelavariableCsuivante:"int tab[2℄;" orrespondantàuntableauà2éléments

detypeentier induitselonnotredénitiondeuxvariables t[0℄ett[1℄detypeint.

Lesvariablesdanslesensoùnousl'entendonssontdon toutesd'untypedebase.

Introduisons dèsàprésentun on eptprimordialpourlasuite:lanotiondeotde ontrle.

Leotde ontrleréfèreàl'ordredanslequellesinstru tionsindividuellesd'unprogramme

impératifsontexé utées.Leotde ontrleestinuen éparlesdiérentesstru turesnotamment

onditionnellesourépétitivesdulangageren ontréeslelongd'uneexé utiondonnéeetdépenddon

delasatisfa tiondes onditionsasso iéesauxstru turesdulangageet ainsidesvaleursenentrée

inje tées au programme (nous reviendrons sur e point dans la se tion 2.6.5). L'évaluation des

stru turesren ontréesenfon tiondesvaleursenentréed'unefon tionmodiedon lesséquen es

d'instru tions exé utées. C'est ettevariabilité des séquen es d'instru tions qui reètela notion

deotde ontrle.

2.3 Stru tures du langage

Le langageCadmetdes expressions onstruitesàpartirdesdiérentsopérateursdulangage.

Cesexpressionsserontnotéesdefaçongénériqueexp.

Ilexistedesinstru tionsélémentaires( al uls surdesvariables)et desinstru tions

ondition-nellesourépétitives.Nousnenousattarderonspasi isurlasémantiquedesdiérentesopérations

élémentaires du langage C ( omme la division,l'addition et .). En revan he, nous allonsparler

de l'utilisation de stru tures onditionnelles et répétitives utilisées dans le langage après avoir

présenté l'instru tionélémentairedulangageàsavoirl'ae tation.

2.3.1 Instru tion élémentaire : l'ae tation

En langage C, l'opérateur = est un opérateur que l'on peut interpréter omme l'a tion de

"id = exp;"

ave id l'identiant d'une variable non onstante dé laré ave un ertain type et exp une

expression du même type alors l'évaluation de ette ae tation, for ée par ";", a pour eet

d'évaluerl'expression expet de rempla er dansla mémoire le ontenu de la asedont l'adresse

orrespond àl'identiantid parla valeurde exp.On dit alors ommunément quelavaleur des

variablesdeexpsontutiliséespourdénirlavaleurdeid.

Lanotiondedénition d'une variabledésigneune modi ationde lavaleurde elle- iet

lanotiond'utilisationd'une variable orrespond àsonévaluation 'est-à-direàlale ture desa

valeur.

Illustration 2

L'exé ution del'ae tation"tab[i+2℄=3*x;"signiequelavaleur orrespondanteàlavariable

tab[i+2℄prendlavaleurdel'expression3*x.

L'ae tationest uneinstru tionquimodie l'étatdelamémoireduprogramme.

Lesautresstru turesdulangageCsurlesquellesnousallonsnousattarderreposentsur

l'éva-luationetlavéri ationd'uneexpressionCappelée ondition.Cepointnousamènedon àpré iser

toutd'abordlanotiondevéri ationd'une onditionenlangageC.

2.3.2 Évaluation d'une expression et véri ation d'une ondition

Iln'existe pas dans le langage C de type de base omposé de 2 onstantes bien identiées.

Néanmoins, il est possible de distinguer les expressions en les évaluant an de les lasser

respe tivementendesexpressions onsidérées ommevraiesetfausses.

Nousavons,d'unepart,letestdevaliditéd'uneexpressionoud'unedonnéeC:uneexpression

estnonvalidesisavaleurvautzéroet validedansle as ontraire.

D'autre part, lorsque le résultat d'une expression logique i.e. une expression ontenant des

opérateurslogiquesestunevaleurdiérentedezéro, eladénoteenlangageClavaleurvraiealors

quelorsquelavaleurrésultante vautzéro,ils'agitd'uneexpression onsidérée ommefausse.

Illustration 3

Lerésultatdel'expression:

 !expr1est vériéesiexpr1estévaluéeà0(!estl'opérateurCdelanégationlogique);

 expr1&&expr2estvériéesietseulementsilesdeuxexpressionsexpr1etexpr2sontvériées

i.e.nesontpasévaluéesà0(&&est le"et-logique"dulangageC);

 expr1||expr2est vériée siet seulement sil'une aumoins des expressionsexpr1, expr2

n'estpasévaluée à0(||estle"ou-logique"dulangageC).

2.3.3 Stru tures onditionnelles

Une stru ture onditionnelle permet à un programme de dé ider ou non d'exé uter une

séquen e d'instru tions en se basant sur la valeur d'une expression appelée ommunément la

onditiondelastru ture onditionnelle.

Dufaitquelavaleurd'uneexpressionpeutvarier d'uneexé utionàuneautre, elapermet à

otde ontrled'unefon tionselonqu'une onditionsoit vériéeounon.

Lesdeuxstru tures onditionnelles onservéesaprèsprétraitementdu odesour edesfon tions

soustestsontlesstru tures onditionnelles IfThenElseetIfThen.

Stru ture IfThenElse

La syntaxe de la première forme d'instru tion onditionnelle, la stru ture onditionnelle

IfThenElse, est présentée dans la gure 2.1 dans laquelle exp, bthen, belse, b représentent

respe tivementuneexpressiondulangageCettroisblo sd'instru tions

1 . 1 if (exp) 2 bthen; 3 else 4 belse; 5 b;

Fig.2.1SyntaxeCdelastru tureIfThenElse

La sémantique de la stru ture IfThenElse onsiste à exé uter le blo d'instru tions bthen

si l'expression exp est vériée et d'exé uter le blo d'instru tions belse dans le as ontraire.

L'expressionexpreprésente i isoit unevariabledetypeentiersoit uneexpressionbooléenne sur

des variables. exp est évaluée selon la notion de validité expliquée dans la se tion 2.3.2. Deux

otsde ontrlediérentssont réésselonquel'évaluationdel'expressionexpestvériéeounon.

Notonsqueleblo d'instru tionsbest quantàluitoujoursexé utéaprès la onditionnelle.

Stru ture IfThen

Lasyntaxedeladeuxièmeformedestru ture onditionnelleIfThenestprésentéedanslagure

2.2.

1 if (exp)

2 bthen;

3 b;

Fig.2.2SyntaxeCdelastru tureIfThen

La sémantique de la stru ture IfThen est similaire à elle de la stru ture onditionnelle

pré édente IfThenElse à la diéren e près que si l'expression exp n'est pas vériée au une

instru tion spé ique est exé utée. Sinon, de façon similaire à la stru ture IfThenElse, le blo

d'instru tions b est toujours exé uté après la stru ture onditionnelle. Nous avons toujours la

réationdedeuxotsde ontrlediérents.

2.3.4 Stru ture répétitive While

Unestru ture répétitiveestunestru ture quipermet derépéterun ertainnombredefois

unblo d'instru tionset e, jusqu'àlavéri ationd'uneexpression delastru tureentraînantla

sortiedelastru ture, expression ommunémentappelée onditiondesortiedebou le.

1

Unblo d'instru tionsenlangage Cdésignesoituneinstru tionseulesoitungroupementd'instru tions

répétitivesquisontexpliquéesdansl'annexeA.2.

Lors du prétraitement des fon tions sous test ( f. se tion 7.2), les diérentes stru tures

ré-pétitivesdu langage Csonttoutes transformées sousune forme anonique orrespondantàune

stru turerépétitiveWhile.

Lastru ture répétitive While dulangage C onsiste à exé uter plusieursfois su essives un

mêmeblo d'instru tions.Lagure2.3présentesasyntaxe.

1 while (exp)

2 b1;

3 b;

Fig.2.3SyntaxeCdelastru tureWhile

En e qui on erne son fon tionnement, le blo d'instru tions b1 est exé uté tant que

l'expressionexpest vériée. En parti ulier,si l'expressionexpest toujoursvériée,l'instru tion

Whileneterminejamais,onparlealorsdebou lage à l'inni.

Leblo d'instru tionsbseraexé utéensortiedelastru tureWhilesi elle- itermine.

2.4 Autres instru tions de modi ation de ot de ontrle

L'instru tion break est utilisée dans les stru tures répétitives et onditionnelles. Dans une

stru ture répétitive, ette instru tion provoque la sortie immédiate de la stru ture sans tenir

omptedes onditionsdesortiedelastru ture.

Dansunestru turerépétitive,l'instru tion ontinueproduitl'abandondel'itération ourante

et,sile onditiondesortiel'autorise,ledémarragedel'itérationsuivante.

L'instru tiongototransfèredire tementle ontrleduprogrammeàuneinstru tionétiquetée.

Cetteinstru tionpermetde ontinuerl'exé utionduprogrammeàunautreendroit,danslamême

fon tion. On l'utilise de la manière suivante : "goto label;" où label est un identi ateur

quel onque.Cetidenti ateurdevraêtredéniquelquepartdanslamêmefon tion,ave lasyntaxe

suivante:"label :/*instru tions*/".Celabelpeutêtremisàn'importequelendroitdansla

fon tion,y omprisdansunautreblo quelàoùsontutiliséeslaoulesinstru tionsgotopointant

vers elabel.Leslabelsdoiventêtreuniquesauseind'unemêmefon tion,maisonpeutlesréutiliser

dansuneautrefon tion.Notonsque,a tuellement,l'outild'analysestatiqueCIL[Lan06℄nepermet

pasdeprendreen omptelesgotos

2

arrières(dontlelabelpré èdel'instru tiongotoasso iéedans

le ode).

2.5 Catégories de variables C

En langage C, on distingue diérentes atégories de variables selon leur portée

'est-à-dire selon leur durée de vie dans l'implantation asso iée. Nous avons les variables dites

globales qui ont une portée qui s'étend à tout le programme dans lequel elles sont dé larées

etlesvariablesditeslo alesquiontuneportéequiselimiteaublo danslequelellessontdé larées.

Nousallonsexpli iter espointsplusendétail.

2