f. criteres d'arret des tests - Psylon

le
TEST
du
LOGICIEL
1.1 4/94 S O M M A I R E
I. INTRODUCTION 1 A. REFERENCES 1 II. TECHNIQUES DE BASE 2 A. DÉFINITIONS 2
B. PRINCIPES 3
C. CATÉGORIES DE TESTS 4
D. LE TEST BOITE NOIRE 6
1. Partitions en classes d'équivalence 6
2. Analyse aux bornes 6
3. Graphe causes/effets 7
4. la méthode intuitive 9
E. LE TEST BOITE BLANCHE 9
1. couverture des instructions 9
2. couverture des branches ou décisions 9
3. couverture des conditions 11
4. couverture des décisions/conditions 11
5. couverture des conditions multiples 11
6. couverture des chemins 12
F. CONCLUSION 12 III. LE TEST DU LOGICIEL 13 A. LE CYCLE DE VIE 13
1. Le test de la spécification 13
a) La revue de spécification du logiciel 14
b) Le maquettage 14
2. Le test de validation 14
3. Le test de la conception préliminaire 15
a) La revue de conception préliminaire 15
b) Le prototypage 15
4. Le test d'intégration 15
5. Le test de la conception détaillée 16
6. Le test du code 16
a) La revue de code 16
(1) L'inspection de code 16
(2) L'analyse de code 17
(3) L'analyse de la qualité 17
b) Le test unitaire 18
B. LE TEST UNITAIRE 18
C. LE TEST D'INTEGRATION 19
1. le test non incrémental 19
2. le test incrémental ascendant 21
3. le test incrémental descendant 23
D. LE TEST DE VALIDATION 24
E. PLANIFICATION DES TESTS 25
F. CRITERES D'ARRET DES TESTS 25
G. LA MISE AU POINT 26
H. LES OUTILS 28
1. XRAY 28
2. LOGISCOPE 29
3. TESTBED 30
4. PCA 30
5. LOGIMETRE 30
6. CANTATE ET ADATEST 30
a) ANALYSE DYNAMIQUE 31
b) ANALYSE STATIQUE 31
c) TAUX DE COUVERTURE 31
7. ATOLL 32 IV. CHECK-LIST D'INSPECTION DE CODE 35 A. ERREURS SUR LES RÉFÉRENCES DE DONNÉES 35
B. ERREURS SUR DÉCLARATION DE DONNÉE 35
C. ERREURS SUR LES CALCULS 35
D. ERREURS SUR LES COMPARAISONS 35
E. ERREURS SUR LE FLOT DE CONTRÔLE 36
F. ERREURS D'INTERFACE 36
G. ERREURS D'ENTRÉE-SORTIE 36
H. ERREURS DIVERSES 36
.Fin Table M.
INTRODUCTION ON ESTIME QUE LE TEST DEMANDE ENVIRON 50 % DE L'EFFORT DE DÉVELOPPEMENT.
POURTANT CETTE PHASE EST LA MOINS CODIFIÉE DU CYCLE DE VIE DU LOGICIEL.
1 REFERENCES 1. Glenford J Myers, the art of software testing. Wiley-interscience,
1979 Références extraites de [1]: 2. G.J.Myers, "A Controlled Experiment in Program Testing and Code
Walkthroughs/Inspections,' Commun. ACM,760-768(1978) 3. M.L. Shooman and M.I.Bolsky, "Types, Distribution, and Test and
Correction Times for Programming Errors," Proceedings of the 1975
Internationnal Conference on Reliqable Software.New York: IEEE,
1975,pp.347-357 4. M.E.Fagan, "Design and Code Inspections to Reduce Errors in Program
Development," IBM Systems J.,15(3),182-211(1976) 5. N.Anderson and B. Dhneiderman,"Use of Peer Ratings in Evaluating
Computer Program Quality,"IFSM-TR-20, Unversity of Maryland, 1977 6. G.J. Myers, Software Reliability : Principles and practices. Ney
York: Wiley Interscience,1976 autres référence 7. le test, Génie logiciel n°18 8. CEAT, Définitions par les services officiels de l'effort de test
unitaire des expressions conditionnelles multiples, 25/06/90 9. Testing in Software Development par OULD & UNWIN British conputer
Society
TECHNIQUES DE BASE
1 DÉFINITIONS On considère souvent le test comme un mal nécessaire destiné à livrer un
logiciel d'une qualité suffisante pour espérer réduire l'effort de
maintenance, réputé 70 % de l'effort global. Cependant le gain théorique est peu tangible surtout au niveau des études
où souvent seul l'effort de développement est quantifié. On définit souvent le test par :
le test doit démontrer l'absence d'erreur.
Le test doit démontrer que le logiciel réalise ce qu'il est
supposé réaliser.
Le test est réussi s'il s'exécute sans découverte d'erreur.
Problème apparemment technique qui peut à première vue se résoudre par un
test couvrant "tous les cas possibles". Malheureusement cette espérance est
souvent impossible ou économiquement irréaliste sauf pour les cas simples. De plus on demande au pauvre testeur une activité destructrice souvent
contre ses propres programmes, et en cas de problème il se sent suspecté de
mauvaise conception et de provoquer des glissements de délai. Car la planification souvent optimiste tient rarement compte de l'effort
nécessaire à la correction des erreurs trouvées. Aussi l'activité du test est-elle considérée comme peu gratifiante, au
mieux ennuyeuse, au pire stressante, et jamais exhaustive. Après cet amer constat, Myers [1], dans son livre "the art of software
testing" a cherché :
une approche psychologique favorisant l'efficacité et la
satisfaction du testeur,
une approche économique qui permet de situer son effort de test
dans les domaines les plus efficaces en fonction du coût prévu. Ce qui le conduit à la définition suivante du test : Le test du logiciel est l'activité destinée à trouver les erreurs du
logiciel. Un test est positif s'il permet de découvrir des erreurs. Un test
est efficace s'il a une forte probabilité de découverte d'erreurs.
2 Principes La réflexion menée lors de la définition précédente conduit Myers [1] aux
principes suivants : La définition des sorties ou résultats attendus est une activité préalable
indispensable aux tests. En effet, en l'absence de celle-ci, l'examen des résultats ne peut conduire
à un diagnostique fiable. Un programmeur ne devrait pas tester ses propres programmes. Pour deux raisons :
si le programmeur a commit une erreur d'interprétation des
spécifications, le test qu'il écrira ne peut le découvrir,
l'activité de test qui tend à chercher à démolir celle de
réalisation est psychologiquement difficile pour son auteur. Il ne faut pas confondre l'activité de test avec celle de la mise au point
qui elle est réalisée plus efficacement par l'auteur du programme. Il faut inspecter et analyser les résultats de chaque test. Le test devient une activité mécanique. Lorsque l'analyse du test est
humaine, l'attention finit par se relâcher, réduisant à zéro l'efficacité
du test. Les jeux de tests doivent être réalisés non seulement pour des données
valides et attendues, mais aussi pour des données non valides et
inattendue. Cette partie souvent négligée est la cause de nombreux problèmes ultérieurs
imprévisibles. Eviter les tests non reproductibles sauf si le programme testé est lui-même
fugitif. L'activité de test est un investissement coûteux qu'il faut rentabiliser. Sinon il faudra rééditer l'effort pour les versions ultérieures qui se
limiteront souvent à des tests sommaires ne portant que sur les
modifications. Ne planifiez pas les tests avec pour hypothèse l'absence d'erreur. Il faut prévoir une quantité statistique de travail nécessaire à la phase
corrective.
La probabilité d'existence d'erreur résiduelle dans une portion de code est
proportionnelle au nombre d'erreurs déjà découvertes. Ce principe ne s'applique que si l'effort de test est homogène. Le nombre d'erreur est bien sûr un critère de détection des modules
critiques traitant des problèmes les plus complexes. En cas de poursuite de
l'effort de test, il est donc plus rentable de se focaliser sur ceux-ci. L'activité de test est une tâche extrêmement créative et intellectuelle. Même dans le cas de programmes simples, nous avons vu que le test ne
pouvait être techniquement exhaustif. Il est donc fréquent de voir le test
mettre en oeuvre des techniques ou des environnements de simulation plus
complexes que l'application elle-même. Nous essaierons d'appliquer ces principes dans le reste du document.
3 Catégories de tests On associe généralement le test à des programmes contrôlant le logiciel à
tester. Se limiter à cette catégorie conduirait à des découvertes d'erreur
très tardives et à des retours en arrière coûteux. D'après la définition, toute activité destinée à trouver des erreurs est
une activité de test. Elle peut donc s'exercer dès la spécification et
mettre en oeuvre principalement deux techniques :
la revue, analyse purement humaine,
les programmes de tests. Ces derniers sont rangés dans deux sous-catégories :
[pic]
le test boite noire : le programme est regardé comme une boite noire
dont on ignore la structure interne. Le testeur ne considère que les
spécifications de sa boite, et doit déterminer si les sorties sont
correctes en fonction de toutes les combinaisons possibles d'entrées.
Le test boite blanche : la structure interne est connue. Les scénarios
de test en tiennent compte. Une première approximation consiste à
estimer que le test est exhaustif si toutes les combinaisons de chemins
de contrôle sont exécutées lors du test.
Dans les deux cas, un test exhaustif est souvent impossible, presque
toujours économiquement irréaliste. On utilise donc d'autres approximations
offrant la meilleure rentabilité : nombre d'erreurs trouvées
-------------------------
effort de test Suivant le critère de mesure choisi on désignera par taux de couverture de
test le rapport : nombre de cas testés
-----------------------
nombre de cas possibles 4 Le test b