Chap 3: TECHNIQUES AVANCÉES DU TEST

LOGICIEL

Presented By:
Bah Moussa Demba
MQI Dept.
1
 Objectifs du cours d'aujourd'hui

 Comprendre ce qu’est la validation

 Identifier les principales difficultés du « test » de

programmes/de logiciels

 Connaître quelques techniques permettant de tester des

programmes
 La chaîne de l’erreur
 Erreur (Error): commise par un développeur
 Défaut ou Faute(Fault or Bug): état interne invalide d’un logiciel après l’activation
d’une erreur
 Défaillance ou Anomalie (Failure): manifestation externe d’une faute, le
comportement observé est différent du comportement attendu ou spécifié

Panne
+/- grave

3
 La chaîne de l’erreur

Erreur Défaut Défaillance

implique implique
(error) (fault) (faillure)

peut causer peut causer

Panne
+/- grave

4
5
6
 Processus logiciels

 Les processus logiciels définissent les activités liées à la

production de logiciels

 Tous les processus incluent les phases :

 de spécification du logiciel

 de conception du logiciel

 d'implantation du logiciel

 de vérification / validation
 Vérification et validation (1)
 Validation
 établissement par des preuves objectives que toutes les
exigences ont été correctement et complètement implémentée
(prises en compte)
 produit répond aux besoins

 Vérification
 confirmation que ce qui est produit pendant une étape de
développement correspond à toutes les exigences exprimées
au début de cette phase
 produit conforme à sa définition
 Vérification et validation (2)

 On peut se placer à différents niveaux

 Spécification
 correspond-elle aux exigences ?
 Conception
 correspond-elle à la spécification, aux exigences ?
 Implantation
 correspond-elle à la conception, à la spécification, aux
exigences ?
 Quelques techniques

 Analyse statique
 revue de code, relecture croisée
 Tests
 Preuve
 model-checking
 preuves déductives
Plan
 Rappel

 Principe du Test
 Définition

 Problématiques

 Techniques relatives au test

 Conclusion
Objectifs
 Le test vise à mettre en évidence les erreurs d’un logiciel

 Le test n’a pas pour objectif de diagnostiquer la cause des

erreurs

 Le test n’a pas pour objectif de corriger les fautes

 Le test n’a pas pour objectif de prouver la correction d’un

programme

12
 Définition du test
 Tester un logiciel, c'est :
 exécuter le logiciel
 en maîtrisant les données en entrée
 en s’assurant que le comportement est celui attendu

 Maîtrise des entrées

 sélectionner assez de données
 mais pas trop
 Vérification du comportement
 pouvoir observer le comportement
 adopter une vision critique

 Tester : rechercher des erreurs (Myers 79)

Exécution des tests

 « à la main »
 Programmes de test / batch
 Utilisation d’outils spécialisés
 J-unit
 Cpp-unit
 …
 Pourquoi tester ? (1)

 C’est la question clé

 Pourquoi est-ce que vous testez ?
 Est-ce que vous accepteriez de monter dans un avion qui
n’a jamais été testé en vol mais dont les fabricants vous
garantissent qu’ils ont «!prouvé!» que tout allait bien se
passer ?
 Pourquoi tester ? (2)

 On attend du logiciel certaines propriétés

 adéquation aux besoins
 absence d’erreur, robustesse,
 performances, ...
 Preuves formelles ou autres techniques
 Pas toujours possibles
 Pas toujours convaincantes
 Pourquoi tester ? (3)

 Soit une propriété attendue

 Exemple : absence d ’erreur
 Le test ne peux pas garantir que la propriété est vraie
 Si un contre-exemple est trouvé, on a la preuve que la
propriété est fausse
 Types de tests (1)
On caractérise l’activité de test en fonction
 de son objectif
 Test de conformité
 Test de performances, de non régression
 …
 du moment ou il est effectué dans le développement
 Test unitaire
 Test d’intégration
 Test système
 Test d’acceptation (ou de recette)
 Test de non-régression
 Types de test (2)
Analyse
des besoins Test d’acceptation

Spécification Tests système

Conception Tests
globale d’intégration

Conception Tests
détaillée unitaires

Codage
 Pourquoi le test est difficile (1)

 Difficultés théoriques
 On ne peut pas tout tester
Infinité de données et/ou pas le temps/argent
Dans d’autres domaines les ingénieurs arrivent à conclure, à partir
de qcq tests, que leur produit fonctionne dans tous les cas, pourquoi
ne pouvons-nous faire pareil ?
Ex. Un pont est testé pour vérifier sa capacité à supporter des camions, si le
test est concluant pour des camions de 1000 tonnes, il sera concluant pour
tout camion de poids inférieur a 1000 tonnes :
principe de continuité
 Quelles données choisir ? Il faut choisir des cas de test pertinents !
 Comment décider que le résultat est correct ?
 Quand peut-on / doit-on s’arrêter ? Même principe en génie logiciel ?
 Pourquoi le test est difficile (2)

 En génie logiciel, le principe de continuité ne s’applique pas la plupart du temps

car la nature du produit (le logiciel) ne s’y prête pas: il est difficile de généraliser
en utilisant le principe de continuité
– Ex. Si le programme fonctionne bien sur les entiers 1,2 et 3, on ne peut rien
conclure sur 4 sans vérifications
– Une ligne de code dans un programme peut tout changer !

Difficulté psychologique
 Programmation : activité constructive
 Test : activité « destructive »
 Il est difficile de détruire ce que l’on a construit
 Pourquoi le test est difficile (3)
Le choix de données
 Test exhaustif
 Exécuter le logiciel avec toutes les données d’entrée possibles dans
toutes les situations possibles
 Impossible
 Choisir des donnée pour découvrir des erreurs
 Quelles données pour trouver des erreurs ?
 Quelles données pour trouver toutes les erreurs ?
 Chaque programme est particulier = aucune technique générale
 Démarches classiques, basées sur l’expérience (ensemble de
« trucs »)
 Pourquoi le test est difficile (4)
Résultat correct ?

 Décider si le comportement du programme est correct

 Problème de l’oracle (verdict)
 Pouvoir observer :
 quelles sont les sorties du logiciels
 Savoir décider
 Comment décide-t-on que le comportement est OK ?
 Exple : Soit un programme de tri alphabétique
 Pourquoi le test est difficile (5)
Quand s’arrêter ?

 Le test n’a pas révélé d’anomalies

 Absence d’erreur ?
 Mauvais choix de données ?

 Le test a révélé des anomalies

 Existe-t-il d’autres erreurs ?
Plan
 Rappel

 Principe du Test

 Techniques relatives au test

 Arrêt du test

 Choix des données

 Correction du résultat (oracle)

 Conclusion
 Arrêt du test

 S’assurer que toutes les fonctionnalités ont été testées

 Base : cahier des charges; exigences et/ou spécification
 « Couverture fonctionnelle »
 S’assurer que tout le code a été exécuté
 Base : code
 « Couverture structurelle »
 Étudier l’évolution du nombre de fautes découvertes
 Analyse de fiabilité
 Arrêt du test

 S’assurer que toutes les fonctionnalités ont été testées

 Base : cahier des charges; exigences et/ou spécification
 « Couverture fonctionnelle »
 S’assurer que tout le code a été exécuté
 Base : code
 « Couverture structurelle »
 Étudier l’évolution du nombre de fautes découvertes
 Analyse de fiabilité
 Exemple
E
a
a b C1

si c1 alors b C2
si c2 alors d d e c
sinon e
sinon c

Graphe de contrôle
Types de couverture E
a
b C1

 Instructions C2
d e c
 Branches
 Conditions et conditions multiples
 …

S
Mesures de couverture, Attention!
 Mesure de couverture
 Soit un critère
 On s’arrête quand le critère est atteint
 L’industrie aime
 Manipulation de données quantitative
 Peut être outillé
 Attention : Un critère d’arrêt signifie
 Tant que le critère n’est pas couvert, on n’est sûr que l’on n’a pas fini de
testé
 Un critère d’arrêt NE signifie PAS
 Quand on a atteint le critère on a fini de tester
 Quand on a atteint le critère on a trouvé toutes les erreurs
Couverture des instructions
 Objectif :
 Exécuter au moins une fois toutes les instructions du
programme

 But :
 Détecter des instructions fautives

 Justification :
 Si on n’a pas testé toutes les instructions, on n’a pas testé
tout le programme
Couvertures des instructions: Limites

 On peut exécuter toutes les instructions sans

exécuter tous les cas
 Exemple :
s1;
Si C alors s2;
s3;
C = vrai satisfait le critère (s1, s2 et s3 exécutées).

C = faux potentiellement jamais testé, s2 ne sera pas

exécutée.
Couverture des branches
 Objectif :
 Exécuter au moins une fois chaque branche

 But :
 Mettre en évidence des défauts dans les instructions
conditionnelles ou itératives

 Justification
 Si toutes les conditions n’ont pas été exécutée au moins
une fois à vraie et à faux, certaines instructions ne seront
pas exécutées
Couverture des branches: Limites

 Limites
 Si C1 alors S1 sinon S2;
Si C2 alors S3 sinon S4;

 (C1, C2) = (F, F) et (V, V) satisfont le critère.

(F, V) et (V, F) jamais testés.
Couverture des conditions
 Objectif :
 Exécuter chaque condition avec la valeur
vrai puis faux
 But :
 Similaire couverture des branches
 Limites :
 si A et B alors ... si A alors si B alors ...
« A et B » est considéré comme une condition unique
 Couverture des conditions multiples
 Objectif :
 Exécution de toutes les combinaisons possibles entre
conditions élémentaires constituant une condition
composée

 Justification :
 Meilleure détection des défauts dans les conditions
 Thank You

Adapte’ du cours de

37