Dunod Toute reproduction non autorise est un dlit.

Table des matires

Avant-propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

XI

Chapitre 1 Quelques ides essentielles sur les tests . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1

Chane de lerreur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2

Rle des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3

Les sept principes gnraux des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.1

Principe 1 Les tests montrent la prsence de dfauts . . . . . . . . . . . . . . . . . . . . . .

1.3.2

Principe 2 Les tests exhaustifs sont impossibles . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.3

Principe 3 Tester tt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.4

Principe 4 Regroupement des dfauts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.5

Principe 5 Le paradoxe du pesticide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.6

Principe 6 Les tests dpendent du contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.7

Principe 7 Lillusion de labsence de dfaut . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Processus et psychologie lis aux tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapitre 2 Tester chaque niveau du cycle de vie . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.1

Les diffrents modles de dveloppement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.2

Prparer les tests lors des phases de conception du cycle en V . . . . . . . . . . . . . .

15

1.4

2.2.1

Prparer les tests lors des phases dexpression et danalyse du besoin . . . . . . . . . .

15

2.2.2

Prparer les tests lors de lcriture des spcifications fonctionnelles . . . . . . . . . . . .

16

2.2.3

Prparer les tests lors de la conception globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

Pratique des tests logiciels

VI

2.2.4
2.3

Prparer les tests lors de la conception dtaille . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

Les tests et les modles itratifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

2.3.1

Le dveloppement itratif UP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

2.3.2

Le dveloppement itratif XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

Les diffrents niveaux de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

2.4

2.4.1

Le test de composants ou tests unitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

2.4.2

Le test dintgration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

2.4.3

Les tests systme et les tests de validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

2.4.4

Les tests dacceptation, tests alpha et tests bta . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

Les diffrents types de tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

2.5

2.5.1

Tests fonctionnels versus tests non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

2.5.2

Tests lis au changement et tests de non-rgression . . . . . . . . . . . . . . . . . . . . . . . . .

38

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

Chapitre 3 Tester efficacement : les diffrentes stratgies . . . . . . . . . . . . . . . . . . . . .

41

3.1

42

2.6

Aperu des stratgies de tests dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.1

Techniques alatoires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

3.1.2

Techniques Bote noire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

3.1.3

Techniques Bote blanche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

Aperu des stratgies de tests statiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

3.2

3.2.1

Lanalyse statique de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

3.2.2

Lutilisation de mtriques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

Revue de code, revue technique, inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

3.3

3.3.1

Revue de type buddy check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

3.3.2

Revue de type walkthrough . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

3.3.3

Revue de type inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

Le processus dinspection en six tapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

3.4

3.4.1

Plan type du rapport dinspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

3.4.2

Choisir un type de revue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

3.4.3

Processus de revue : conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

Tests dynamiques versus tests statiques : synthse . . . . . . . . . . . . . . . . . . . . . . . . . .

57

3.5

3.5.1

Choisir une technique de tests dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

3.5.2

Choisir une technique de tests statiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

Table des matires

3.6

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

Chapitre 4 Concevoir efficacement des jeux de tests grce aux spcifications . . .

59

4.1

60

Rduire le combinatoire avec les techniques All Singles et All Pairs . . . . . . . .

4.1.1

Principes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

4.1.2

Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

4.1.3

Commentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

Tester grce aux classes dquivalence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

4.2

4.2.1

Principes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

4.2.2

Utilisation des classes dquivalence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

4.2.3

Construction des classes dquivalence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67

4.2.4

Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

4.2.5

Commentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

Tester aux limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

4.3

4.3.1

Principes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

4.3.2

Prise en compte de contraintes liant les paramtres. . . . . . . . . . . . . . . . . . . . . . . . .

73

4.3.3

Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75

4.3.4

Commentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

Tester grce une table de dcision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

4.4

Dunod Toute reproduction non autorise est un dlit.

VII

4.4.1

Principes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

4.4.2

Format dune table de dcision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

4.4.3

Construction et simplification dune table de dcision . . . . . . . . . . . . . . . . . . . . . .

78

4.4.4

Illustration : le problme des triangles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

4.4.5

Illustration : le problme du calcul du lendemain . . . . . . . . . . . . . . . . . . . . . . . . . .

81

4.4.6

Commentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

Utiliser un diagramme tats transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

85

4.5

4.5.1

Principes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

85

4.5.2

Format gnral dun diagramme tats transitions . . . . . . . . . . . . . . . . . . . . . . . . . .

86

4.5.3

Construction dun diagramme tats transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . .

87

4.5.4

Construction des squences de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

88

4.5.5

Commentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

88

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

89

4.6

Pratique des tests logiciels

VIII

Chapitre 5 Utiliser les dtails dimplmentation dans les tests . . . . . . . . . . . . . . . . .

91

5.1

92

Dfinir des objectifs de couvertures par rapport au flot de contrle . . . . . . . . . .

5.1.1

Principes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

92

5.1.2

Construire et utiliser un graphe de contrle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

92

5.1.3

Critre de couverture toutes les instructions . . . . . . . . . . . . . . . . . . . . . . . . . . .

93

5.1.4

Critre de couverture tous les chemins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

95

5.1.5

Critre de couverture toutes les branches ou toutes les dcisions . . . . . . . . . .

96

5.1.6

Critre de couverture toutes les conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . .

97

5.1.7

Critre de couverture toutes les conditions dcisions . . . . . . . . . . . . . . . . . .

97

5.1.8

Critre de couverture toutes les conditions multiples . . . . . . . . . . . . . . . . . . . .

98

5.1.9

Critre de couverture toutes les conditions dcisions modifies (MC/DC)

98

5.1.10 Critre de couverture tous les i-chemins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

101

5.1.11 Autres critres de couverture bass sur le flot de contrle . . . . . . . . . . . . . . . . . . .

102

5.2

Dfinir des objectifs de couvertures par rapport au flot de donnes . . . . . . . . . .

103

5.2.1

Principes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

103

5.2.2

Construire et utiliser un graphe de flots de donnes . . . . . . . . . . . . . . . . . . . . . . . .

104

5.2.3

Squences caractristiques et utilisation statique de ltiquetage des nuds . . . . .

105

5.2.4

Critres de couverture associs aux flots de donnes. . . . . . . . . . . . . . . . . . . . . . . .

108

5.3

Trouver les jeux de valeurs satisfaisant un critre de couverture . . . . . . . . . . . . .

112

5.4

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

113

Chapitre 6 Processus et tests dintgration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

115

6.1

Lintgration dans le cycle de vie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

115

6.2

Intgration dans une architecture client/serveur . . . . . . . . . . . . . . . . . . . . . . . . . . .

119

6.3

Notion dintgrat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

125

6.4

Difficults et risques de lintgration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

128

6.4.1

Intgration verticale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

129

6.4.2

Intgration continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

133

6.5

Mcanique du processus dintgration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

137

6.6

Dynamique du processus dintgration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

139

6.6.1

Rappel sur la mcanique du procd de construction . . . . . . . . . . . . . . . . . . . . . . .

141

6.6.2

La machine intgrer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

145

6.6.3

Retour sur lintgration continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

148

 Dunod Toute reproduction non autorise est un dlit.

Table des matires

IX

6.6.4

Intgration et gestion de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

151

6.6.5

Intgration dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

152

6.7

Stratgie dintgration pour la validation, la vrification et lintgration . . . . .

155

6.8

Rsum des rgles de la dynamique du processus dintgration . . . . . . . . . . . . . .

162

6.8.1

Rgle N 1 Vitesse dcriture des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

162

6.8.2

Rgle N 2 Nombre de tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

162

6.8.3

Rgle N 3 Effort de vrification des rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . .

163

6.8.4

Rgle N 4 Effort pour la gestion des configurations . . . . . . . . . . . . . . . . . . . . . .

163

6.8.5

Rgle N 5 Effort de non-rgression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

163

6.8.6

Rgle N 6 Automatisation des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

164

6.8.7

Rgle N 7 Simplification et rduction de la complexit du processus

dintgration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

165

Chapitre 7 Grer les tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

167

7.1

168

Organisation des tests et rpartition des rles . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.1.1

Choix des types de tests effectuer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

168

7.1.2

Les diffrents acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

171

7.2

Planifier les tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

172

7.3

Dfinir et valuer les critres de sorties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

174

7.4

Estimer leffort de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

175

7.5

Grer les tests en configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

178

7.6

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

179

Chapitre 8 Outils pour les tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

181

8.1

Typologie attendue des outils de tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

181

8.2

Les grandes familles doutils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

183

8.2.1

Outils pour les tests statiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

183

8.2.2

Outils daide lexcution des tests dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . . .

185

8.2.3

Outils dappui la gestion des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

191

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

193

Chapitre 9 tude de cas : validation des systmes C4ISTAR . . . . . . . . . . . . . . . . . .

195

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

205

8.3

Pratique des tests logiciels

Exemple de QCM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

211

Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

219

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

221

Avant-propos

Dunod Toute reproduction non autorise est un dlit.

Les logiciels informatiques, indispensables au fonctionnement des entreprises et des

infrastructures technologiques, ont galement pris une place essentielle dans notre vie
quotidienne : ils amliorent la qualit des images de nos appareils photos, grent nos
annuaires tlphoniques mais participent aussi la scurit de nos trajets automobiles.
Si le dysfonctionnement dun appareil photo peut tre dsagrable, larrt de lABS ou
du contrle dynamique de trajectoire peut avoir des consquences dramatiques1 . La
socit dite numrique est en fait une socit o la matire premire est le logiciel,
une socit o les programmeurs se comptent en millions et les lignes de code quils
crivent en milliards. Cest une production de masse ! Le monde du dveloppement
de logiciels est donc confront de nouveaux dfis o linnovation ne peut se faire
au dtriment de la qualit. On attend, bien entendu, des logiciels quils ralisent ce
pourquoi ils ont t conus mais galement quils ne fassent pas ce pourquoi ils nont
pas t conus. Crs par lhomme, les logiciels sont soumis aux alas de lactivit
humaine et de ce fait contiennent des erreurs quil faut sefforcer de dtecter afin de
les corriger avant la mise en service.
Ceci ne peut se faire sans tester rgulirement le logiciel et/ou les parties qui le
composent. Rgulirement car il ne suffit pas de tester uniquement le produit final.
En effet, une erreur dcouverte en bout de chane peut entraner la refonte totale et
le re-dveloppement de tout ou de presque tout. Il faut donc tester en amont lors des
phases dassemblages des composants du logiciel (il sagit des tests dits dintgration),
mais galement lors du dveloppement des composants (il sagit des tests dits unitaires)
car assembler des composants truffs derreurs ne peut que compliquer le diagnostic et
rduire nant le rendement de leffort des tests suivants.
Les tests doivent donc rechercher des erreurs : des erreurs dites fonctionnelles, le
logiciel ne fait pas ce quil devrait faire ; mais aussi des erreurs non fonctionnelles :
le logiciel fait ce quil faut mais pas dans des temps acceptables ou en devant tre
relanc frquemment ou ne supportant pas la monte en puissance. Le nombre de

1. On pourra galement penser aux normes soucis humains crs par le dysfonctionnement du
logiciel de gestion de paie de larme Louvois mis en place en 2011.

Pratique des tests logiciels

XII

cas dutilisation possibles dun logiciel tant en gnral trs grand, il est tout la
fois illusoire de penser mener cette recherche derreur de manire empirique, mais
galement de vouloir prtendre lexhaustivit ; la bonne approche sera de nature
statistique, avec des stratgies bases sur les contextes demploi. Il faudra savoir
construire efficacement les cas de tests pertinents, cest--dire ceux permettant de
mettre en vidence rapidement les erreurs. Il faudra galement savoir dterminer
quel moment on peut arrter les tests sans crainte de ne pas avoir assez test afin de
garantir la qualit de service conforme au contrat de service. Ces jeux de tests peuvent
tre construits laide des textes sources du logiciel et/ou des dtails de son assemblage
ou, uniquement laide de ses spcifications. On parlera, selon les cas, de tests Botes
blanches ou Botes noires.
On le voit, tester un logiciel est un challenge aussi excitant que de le programmer,
et, qui tout comme la programmation, ne peut se faire sans une bonne assise technique ;
tester cest mener une exprimentation scientifique et il faut pour cela enthousiasme
mais aussi rigueur et mthode. Les mthodes les plus rcentes comme les mthodes
dites agiles ou leXtreme Programming insistent juste titre sur limportance des
tests et sur le dveloppement guid par les tests, i.e. le Test Driven Development .

qui sadresse ce livre ?

Ce livre a un triple objectif. Tout dabord il vise donner aux tudiants des universits
et des grandes coles dingnieurs, cest--dire aux futurs concepteurs, dveloppeurs,
intgrateurs de logiciels ou aux futurs chefs de projets, les bases indispensables pour
concevoir et mener bien les tests tout au long du cycle de vie du logiciel et du
systme. Deuximement, ce livre vise donner aux quipes de testeurs une rfrence
en termes de vocabulaire, de mthodes et de techniques permettant un dialogue plus
efficace entre les donneurs dordre, les matrises duvre et les matrises douvrage.
Enfin, conforme au Syllabus niveau fondation de lISTQB, cet ouvrage prpare au
passage de la certification ISTQB du mtier de testeur.
Cette seconde dition reprend ces objectifs tout en proposant un nouveau chapitre
sur les outils de tests et un nouveau chapitre sur les enjeux des tests dintgration. Enfin,
un QCM permet au lecteur dvaluer son niveau face une possible certification.

Supplments en ligne
Retrouvez sur www.dunod.com/contenus-complementaires/9782100706082 les supplments en ligne qui compltent cet ouvrage. Il sagit dexercices corrigs, du corrig
comment du QCM, de complments sur les tests unitaires avec JUnit, des informations de mise niveau, des applications avances, des logiciels recommands, des
supports didactiques...

1
Quelques ides essentielles
sur les tests

Dunod Toute reproduction non autorise est un dlit.

Le samedi 21 juillet 1962, la premire sonde spatiale interplantaire du programme

Mariner de la NASA, Mariner I, est lance depuis Cap Canaveral pour une mission
danalyse de Vnus. Quatre minutes aprs son lancement, le lanceur dvie de sa
trajectoire et doit tre dtruit.
Un article du New York Times dat du 27 juillet 1962 relate cet pisode malheureux de la conqute de lespace et donne une premire explication de cet chec : The
hyphen, a spokesman for the laboratory explained, was a symbol that should have been fed
into a computer, along with a mass of other coded mathematical instructions. The first phase
of the rockets flight was controlled by radio signals based on this computers calculations.
The rocket started out perfectly on course, it was stated. But the inadvertent omission of the
hyphen from the computers instructions caused the computer to transmit incorrect signals to
the spacecraft...
Lexplication donne lpoque de cet chec et maintenue jusqu rcemment est
quune instruction du programme de guidage (crit en Fortran) contenait une virgule
la place dun point. Linstruction DO 10 I = 1.100 aurait d tre DO 10 I
= 1,100 . Dans le premier cas, il sagit dune dclaration de variable de nom DO
10 I de type rel auquel on donne la valeur 1,1 alors que dans le second cas il sagit
dune boucle qui rpte de 100 fois la suite dinstructions qui suit la ligne ; la diffrence
de comportement rsultant de linterprtation de ces deux instructions est radicale !
En fait, la cause du problme la plus probable est plus subtile car elle proviendrait
non dune erreur de codage mais dune erreur dinterprtation des spcifications : la
__
transcription manuelle du symbole surlign ( a ) sur une variable, crit rapidement
dans la marge des spcifications, correspondant au lissage de la variable en question,
fut pris pour une apostrophe, (a), notant la drive de la variable. Il sagirait donc
dune apostrophe au lieu dune barre et non dune virgule au lieu dun point.

Chapitre 1. Quelques ides essentielles sur les tests

Figure 1.1 Les sondes Mariner (image NASA)

http://upload.wikimedia.org/wikipedia/commons/7/7f/Mariner_1_to_10.jpg

Cette confusion conduisit un code non conforme aux spcifications initiales

ce qui sest traduit par une diffrence de comportement importante entre la version
code et la version souhaite. Ainsi, lors des tentatives de stabilisation du lanceur, le
systme de contrle lui envoya des ordres incohrents causant sa perte.
Quelle que ce soit la version de ce terrible chec parmi ces deux hypothses, il
est la consquence dune erreur de ralisation dun logiciel informatique : une erreur
dinterprtation des spcifications ou une erreur de codage.
De nombreux autres et malheureux exemples sont l pour nous rappeler limportance du logiciel dans le monde actuel ; nous ne citons que les plus (tristement)
clbres :
Convocation lcole de personnes ges de 106 ans. Cause : codage de lge

sur deux caractres.

Navire de guerre anglais coul par un Exocet franais, au cours de la guerre
des Malouines, le vaisseau anglais nayant pas activ ses dfenses. Plusieurs
centaines de morts. Cause : les missiles de type Exocet ntaient pas rpertoris
comme des missiles ennemis.
Passage de la ligne : au passage de lquateur un F16 se retrouve sur le dos.
Cause : changement de signe de la latitude mal pris en compte.
Station MIR : deux jours sans courant (14 au 16 novembre 1999). Cause : arrt
dun ordinateur qui contrlait lorientation des panneaux solaires.

1.1 Chane de lerreur

Hpital : Dcs dun malade. Cause : erreur logicielle dans un programme de

contrle dappareil de radiothrapie.

Missile : en URSS, fuse pointant Hambourg au lieu du Ple Nord. Cause :

erreur de signe entranant une erreur de 180 du systme de navigation.

Inondation de la valle du Colorado en 1983. Cause : mauvaise modlisation
du temps douverture du barrage.
Perte de la sonde Mars Climate Orbiter (anciennement Mars Surveyor Orbiter)
le 23 septembre 1999 aprs 9 mois de voyage. Cause : confusion entre pieds et
mtres.
Et bien dautres dont tout chacun peut tre tmoin dans sa vie professionnelle
ou familiale.
Dans tous ces cas, une erreur de ralisation ou de conception dun logiciel conduit
un systme automatique faire autre chose que ce pourquoi il est fait. Diffrents
termes sont employs pour relater ces problmes et il nous faut prciser ici ce que lon
entend par erreur, dfaut, dfaillance ou panne.

Dunod Toute reproduction non autorise est un dlit.

1.1 CHANE DE LERREUR

Comme toute activit humaine, la conception et le dveloppement de logiciel sont
sujets des imperfections qui sont sans consquences dans certains cas et dans dautres
conduisent des comportements non prvus et sont la cause de dysfonctionnement
plus ou moins graves. En tout tat de cause, lorsque les tests sont correctement
raliss et utiliss, ils permettent de dcouvrir des erreurs. Si lon veut tre prcis, les
tests mettent en avant des dfaillances du logiciel, cest--dire des fonctionnements
anormaux aux vues de ses spcifications. Une dfaillance provient dun dfaut de
ralisation ou de conception du logiciel, qui suite une excution du code impliqu
engendre un comportement fautif. Il faut noter que tout dfaut ne conduit pas
systmatiquement une dfaillance et que, au contraire, il est frquent quun logiciel
se comporte correctement alors quil contient un grand nombre de dfauts mais
qui ne sont jamais exercs en fonctionnement ; cette constatation implique donc
dadopter une stratgie de grande prudence lorsque lon rutilise une partie dun
logiciel fonctionnant parfaitement.
Ces dfauts prsents dans les logiciels proviennent derreurs humaines qui sont
le fait de mprises sur la comprhension ou linterprtation des spcifications ou
encore derreurs de ralisation lors du codage ou galement doublis lors des phases de
conception.
Une suite de dfaillances peut entraner une panne du logiciel ou du systme,
mais il ne faut pas confondre une dfaillance et une panne. Une dfaillance se
caractrise par des rsultats inattendus (calculs errons, fentre mal place, message
non affich, etc.) ou un service non rendu (donnes non stockes dans une base,
fentre non ouverte, etc.) ; cependant le logiciel peut continuer bon gr mal gr son
fonctionnement normal. Une panne a un caractre plus franc et se rvlera par un

Chapitre 1. Quelques ides essentielles sur les tests

arrt total ou partiel du logiciel qui conduit un fonctionnement en mode (trs)

dgrad. La seule manire de sortir de ce mode est de redmarrer le logiciel ou le
systme avec toutes les consquences que cela peut avoir.

Figure 1.2 La chane de lerreur

Afin de mesurer (a posteriori) le fonctionnement sans dfaillance ou panne dun

logiciel et limpact de ces dfaillances ou panne sur la disponibilit du logiciel deux
indicateurs sont utiliss :
Le MTBF (Mean Time Between Failure) qui dfinit le temps moyen de bon

fonctionnement entre deux dfaillances ou pannes, temps de rparation compris.

Ce nombre doit tre le plus grand possible.
Le MTTR (Mean Time To Repair) qui dfinit le temps moyen de remise en route
aprs une panne.
Il faut noter que seul un modle prcis, et donc difficile produire, permet dessayer
de calculer a priori ces indicateurs. Le plus souvent ils sont estims laide danciens
logiciels ou des logiciels concurrents, ce qui donne une ide de ce qui est possible, et
ils sont affins en fonction des exigences mtiers, ce qui donne un objectif de ce quil
faudrait atteindre.

1.2 RLE DES TESTS

Le rle des tests est multiple. En effet, aujourdhui de trs nombreuses activits ne
peuvent tre ralises sans laide de logiciels et ceci dans des domaines trs varis :
gestion de la paye, gestion de la carrire des personnels, suivi des clients, contrle des
centrales nuclaires, aide au pilotage des avions civils et militaires, amlioration du
fonctionnement des appareils mnagers, services offerts sur les mobiles ou les tablettes,
etc. Il y a plus dinformatique dans la Volvo S80 que dans le chasseur F15 dclarait en
janvier 2000 Denis Griot, responsable de llectronique automobile chez Motorola.

1.2 Rle des tests

Or, on ne sait pas, par construction, fabriquer des logiciels sans dfaut : lhomme
commet des erreurs et aucun programme ne peut gnrer de faon sre un autre
programme ou vrifier quun programme fait exactement ce pour quoi il est fait.
En effet, les limites thoriques montrent quil est impossible dans le cas gnral,
de construire un algorithme permettant de dire si deux programmes ralisent les
mmes fonctions (il sagit dun problme insoluble). La base de ce rsultat provient de
limpossibilit fabriquer un programme qui statue, sans se tromper, sur la terminaison
dun programme quelconque. Si tel tait le cas, et si lon notait Stop ce programme
et Stop(P), le rsultat de lanalyse de la terminaison dun programme P par Stop,
on pourrait construire un programme B contenant linstruction si Stop(B) alors
rentrer dans une boucle sans fin, sinon arrter . Ce programme B mettrait en dfaut
systmatiquement ce programme oracle Stop.
Devant ce constat dimpossibilit, diffrentes approches sont possibles :
1. se limiter construire des programmes trs simples que lon sait analyser de
faon certaine mais qui ne pourront rsoudre que des problmes limits ;

Dunod Toute reproduction non autorise est un dlit.

2. construire des programmes complexes dont on ne pourra prdire de faon

exacte le comportement mais qui permettront dans la plupart des cas de
rsoudre des problmes ambitieux.
Comme les besoins en termes de logiciels voluent plus vite que les possibilits
thoriques de construction sre, lapproche 2 est celle qui est choisie dans la majorit
des cas. Il faut donc accepter que le logiciel produit contienne des dfauts ; lenjeu
est alors dliminer les dfauts qui conduisent des dfaillances avant que le logiciel
entre en service. Si ncessaire, il faudra galement sassurer que le logiciel satisfait un
certain nombre de normes lgales ou contractuelles, ncessaires par exemple pour une
certification du logiciel. Enfin, une fois le logiciel dploy, il faudra, lors des phases de
maintenance, vrifier que les volutions ou amliorations nont pas entam les parties
non modifies du logiciel et, dans le cas de maintenances correctives, que la nouvelle
version corrige bien les dfauts de lancienne. Toutes ces tapes sont ralises laide
de diffrents types de tests : tests unitaires ou tests dintgration lors des phases de
dveloppement, tests systme et tests de validation lors des phases de dploiement,
tests dacceptation et tests de recette lors des phases dacceptation ou de certification,
et enfin tests de correction et de non-rgression lors des phases de maintenance.
On le voit, les objectifs des tests peuvent tre multiples ; cependant, en aucun cas,
et mme si cela est choquant, il faut tre conscient que leur but nest pas dliminer
tous les dfauts. Lobjet principal est danalyser le comportement dun logiciel dans un
environnement donn : ainsi, il ne sert a priori rien de tester le bon fonctionnement
de la gestion du systme de freinage dune automobile pour une vitesse de 1 000 km/h.
Par ailleurs, les tests vont permettre de dcouvrir un certain nombre derreurs, mais
il est faux de penser que lamlioration de la fiabilit est proportionnelle au nombre
de dfauts dtects puis corrigs. En effet, un logiciel mal conu, en particulier du
point de vue de son architecture, va faire apparatre un grand nombre de dfauts. La
correction de ces dfauts pourra avoir pour consquence, non de rduire leur nombre,
mais au contraire den crer de nouveaux. Si le ratio entre le nombre de dfauts crs
et le nombre de dfauts corrigs est suprieur 1, les tests ne cesseront de dcouvrir des

Chapitre 1. Quelques ides essentielles sur les tests

dfauts sans pour autant quil y ait convergence vers un logiciel fiable. De mme, tester
beaucoup en quantit et en temps nest pas ncessairement un gage de qualit. Exercer
sans cesse le mme code avec des jeux de valeurs similaires ne donne aucune garantie
quant la capacit dcouvrir des dfauts de comportement. Tester est une activit
complexe qui demande exprience et mthode et nous allons essayer maintenant de
cerner les quelques principes qui doivent guider toute activit de test.

1.3 LES SEPT PRINCIPES GNRAUX DES TESTS

Quelques grands principes nous permettront de mieux cerner et de dfinir intuitivement ce que sont et ce que ne sont pas les tests.

1.3.1 Principe 1 Les tests montrent la prsence de dfauts

Il est important de se convaincre que les tests ne peuvent pas prouver labsence
derreur de conception ou de ralisation. Leurs objets au contraire sont de mettre en
vidence la prsence de dfaut ; aussi, lorsquune srie de tests, conus et appliqus
avec mthode, ne trouve aucun dfaut, il est important de se poser la question de la
pertinence des jeux de tests avant de conclure une absence de dfauts. En tout tat
de cause, si aucun dfaut nest dcouvert, ce nest pas une preuve quil nen reste pas.

1.3.2 Principe 2 Les tests exhaustifs sont impossibles

Sauf pour des cas triviaux, la combinatoire dun programme est impossible explorer
de faon exhaustive. En effet, du fait des diffrentes valeurs possibles des paramtres des
mthodes ou sous-programmes et de la combinatoire engendre par lalgorithmique,
la plupart des programmes peuvent atteindre rapidement un nombre dtats diffrents
suprieurs au nombre estim datomes dans lunivers (de lordre de 1080 ). Pour mieux
nous rendre compte de la complexit intrinsque dun programme informatique,
considrons une fonction daddition de deux nombres entiers ; on ne peut plus simple.
Si les entiers sont des valeurs codes sur 32 bits, chaque paramtre peut prendre 232
valeurs distinctes (un peu plus de 4 milliards). Le nombre de cas diffrents dexcution
de cet additionneur est donc gal 264 , ce qui correspond plus de 4 milliards de
milliards. Si lon veut tester tous les cas, il faudrait, raison de 1 milliard doprations
de test par seconde, prs de 127 annes de travail !
2 32

+
2 32

Figure 1.3 Tester tous les cas (264 )

= 127 annes
raison de 1 milliard doprations par seconde