Les Tests du Logiciel

Ahmed ZELLOU
ahmed.zellou@um6p.ma

UM6P, Novembre 2024.

 Plan
n Aperçu Historique
n Les tests de logiciels
n Définitions et objectifs des tests
n Types de tests
n Caractéristiques facilitant les tests
n Critères de terminaison des tests
n Atelier Pratique

2
A.ZELLOU
 Les tests de logiciels
n Élément critique de l’assurance qualité logiciel
n Représente l’ultime revue de la spécification, conception et
génération de code

3
A.ZELLOU
 Célèbres défaillances de l'histoire
n Certaines ont coûté des vies humaines,
d'autres ont gaspillé des milliards de
budget
n La sonde Mariner 1, lancée le 22
juillet 1962 par la NASA pour une
mission de survol de Vénus,
s’explose 294,5 secondes après son
décollage.
n Raison : Une défaillance des
commandes de guidage ;

4
A.ZELLOU
 Célèbres défaillances de l'histoire
n Le satellite Mars Climate Orbiter
a raté sa mise en orbite autour de la
planète Mars pour s'écraser sur la
planète rouge.
n Certains paramètres avaient été
calculés en unités de mesure
anglo-saxonnes et transmises à
l'équipe de navigation en unités du
système métrique.
n Coût total du projet : 327,6
millions de $ ;
5
A.ZELLOU
 Célèbres défaillances de l'histoire
n Appolo 8 : 5.8 millions de pièces
n Si chaque pièce fonctionne à 99.9% d'efficience

n Il y'aura 5800 erreurs ou pannes.

6
A.ZELLOU
 Célèbres défaillances de l'histoire
n Certaines ont coûté des vies humaines,
d'autres ont gaspillé des milliards de budget
n Therac-25, est une machine de
radiothérapie qui coûta la vie à plusieurs
patients ;
n Des patients reçevait des doses massives
de radiation et qui décédèrent des suites
de l'irradiation.
n Le projet Virtual Case File est un fiasco :

n Le développement, commandé par le FBI, fut

entièrement abandonné au bout de 5 ans (entre 2000 et
2005) et fait couté au gouvernement fédéral 170
7 millions de $ ; A.ZELLOU
 Célèbres défaillances de l'histoire
n Certaines ont coûté des vies humaines, d'autres ont gaspillé
des milliards de budget
n Le vol 501 de la fusée Ariane 5 : elle explosa lors de
son premier vol le 4 juin 1996, 40 secondes après son
décollage.
n Elle emporte avec elle les 370 millions $ investis dans
le projet et les satellites qu'elle devait transporter.

n Les bogues et les erreurs logiciels coûtent chaque année

59 billions $ à l'économie américaine soit 0,6 % du PIB.

8
A.ZELLOU
 Attention
n Souvent, le risque causé par une panne est limité.
n Toutefois, de nombreux projets nécessitent un haut niveau
de sureté de fonctionnement :
n Contrôle de centrale nucléaire,

n Émetteur de télécommunication/télévision/radio
(niveau d'émission des ondes),
n Tout logiciel qui contrôle un équipement utilisant une
puissance électrique potentiellement dangereuse,
n Tout logiciel contrôlant des équipements impliquant des
êtres vivants (médical, transport, ...).

9
A.ZELLOU
 Les tests de logiciels
n Quoi ?
n Une fois le code source généré, le logiciel doit être testé
pour découvrir et corriger les erreurs possibles avant la
livraison au client
n C’est une procédure de vérification partielle du logiciel.

n Le but est de concevoir une série de jeu de tests qui a

plus de chance de trouver des erreurs.
n L’objectif est de trouver un nombre maximum de
comportements problématiques.

10
A.ZELLOU
 Les tests de logiciels
n Qui ?
n Durant les premières étapes de test, un ingénieur
programmeur se charge de tous les tests
n Une fois le processus de test progresse, des spécialistes
de tests doivent être invoqués
n Il vaut mieux que ce ne soit pas les mêmes personnes qui
analysent, conçoivent, codent et qui testent le soft.

11
A.ZELLOU
 Les tests de logiciels
n Attention ?
n Les tests se distinguent :

n Des inspections ou revues de code, où il n’y a pas

exécution du programme, et des « walkthroughs » où
l’exécution est faite à la main
n Du débogage, dont l’objectif est de localiser et de
corriger les erreurs
n Les tests et le débogage sont souvent réalisés par des
équipes différentes

12
A.ZELLOU
 Les Tests du Logiciel
Définitions et objectifs des tests

13
A.ZELLOU
 Définitions et objectifs des tests
n Tester un logiciel consiste à l’exécuter en ayant la totale
maîtrise des données qui lui sont fournies en entrée (jeux
de test) pour vérifier que son comportement est celui
attendu.
n Un défaut est une imperfection dans un composant ou un
système qui peut en perturber le fonctionnement.
n Une défaillance peut être due à un défaut ou erreur
présente dans le logiciel ou au matériel.
n Le défaut est révélé par une défaillance (failure) s'il est
exécuté, c'est-à-dire une déviation par rapport au
comportement ou résultat attendu.
14
A.ZELLOU
 Définitions et objectifs des tests
n Un test est l’exécution d’un programme pour une donnée
particulière, pour vérifier si le résultat obtenu est correct
n Un jeu de tests est un ensemble fini de données tel que pour
chacune d’entre elles un test sera conduit
n Le testage (ou tests) désigne l’activité de conception des
jeux de tests, de conduite des tests, et d’évaluation des
résultats des tests, à différentes étapes du cycle de vie du
logiciel
n Un objet ne peut être testé que si on peut déterminer
précisément le comportement attendu en fonction des
conditions auxquelles il est soumis.
15
A.ZELLOU
 Définitions et objectifs des tests
n Un test examine une hypothèse exprimée en fonction de
trois éléments :
n les données en entrée,

n l'objet à tester,

n les observations attendues.

n Un test vise à mettre en évidence des défauts de l'objet

testé. Cependant il n'a pas pour objectif :
n de diagnostiquer la cause des erreurs,

n de les corriger,

n de prouver la correction de l'objet testé.

16
A.ZELLOU
 Définitions et objectifs des tests
n Le testeur est l’informaticien (ou équipe) qui réalise le
testage
n L’activité du testeur comprend
n La conception des jeux de tests

n La réalisation des tests

n Le rapporting sur les résultats des tests

n L’ archivage des rapports

17
A.ZELLOU
 Objectifs des tests
n Prouver que le programme est
correct
n Dijkstra : les tests permettent de
prouver qu’un programme est
incorrect, mais jamais de prouver
qu’il est correct
n Il est difficile de prouver qu'un
logiciel fonctionne bien dans tous
les cas.

18
A.ZELLOU
 Objectifs des tests
n Trouver des erreurs
n Myers: le testage consiste à exécuter
un programme dans le but de trouver
des erreurs. « The Art of Software
Testing ».

n Dans la suite, on appellera de tels tests « tests destructifs »,

leur objectif étant de détruire le travail des développeurs en
mettant en évidence les erreurs qu’ils ont commises
n Donner une évaluation statistique de la qualité du programme
(tests statistiques)

19
A.ZELLOU
 Objectifs des tests
n Selon Myers :
n Tester est le processus d’exécuter un programme avec
l’intention de trouver des erreurs
n Un bon jeu de test est celui qui a une probabilité élevée
pour trouver des erreurs non encore trouvées
n Un test réussi est celui qui découvre une erreur non encore
trouvée

20
A.ZELLOU
 Principes des tests
n Tous les Tests doivent être retrouvés à partir des besoins du
client
n Les Tests doivent être planifiés longuement avant de pouvoir
les démarrer
n Appliquer le principe de Pareto aux tests
n Les tests doivent démarrés “in the small” et progresser vers
les tests “in the large” ou inversement
n Les tests exhaustifs ne sont pas possibles
n Pour être plus efficace, les tests doivent être conduits par
une tierce partie indépendante

21
A.ZELLOU
 Critères d’un bon test
n Un bon test :
n a une probabilité élevée pour trouver des erreurs

n ne doit pas être redondant

n doit être le meilleur de sa catégorie

n doit être ni trop simple ni trop compliqué

22
A.ZELLOU
 Les Tests du Logiciel
Caractéristiques facilitant les tests

23
A.ZELLOU
 Testabilité
n Testable easily, hardly conceivable
n Désigne la facilité avec laquelle un programme peut être
testé
n Un ensemble de caractéristiques sont présentées pour
mener vers un logiciel testable

24
A.ZELLOU
 Opérabilité
n Test the empirical, does not test the fundamental
n Le mieux il fonctionne, le plus il peut être testé
efficacement
n Le système a peu de bugs

n Aucun bug ne va bloquer l’exécution des tests

n Le produit évolue aux niveaux fonctionnels

25
A.ZELLOU
 Observabilité
n What you see is what you test
n Sortie différente pour chaque entrée

n Les variables et états du système sont visibles et

interrogeables durant l’exécution
n Tous les facteurs affectant la sortie sont visibles

n Une sortie incorrecte est facilement identifiable

n Les erreurs internes sont automatiquement détectées

durant les mécanismes de tests
n Les erreurs internes sont automatiquement reportées

n Le code source est accessible

26
A.ZELLOU
 Contrôlabilité
n The better we can control the software, the more the
testing can be automated and optimized
n Toutes les sorties possibles sont générées via une
combinaison d’entrées
n Tout le code est exécutable via une combinaison
d’entrées
n Les variables et états du logiciel et matériel peuevent
être contrôlés directement par l’ingénierie du test
n Les tests peuvent être convenablement spécifiés,
automatisés et reproduits

27
A.ZELLOU
 Simplicité
n The less there is to test, the more quickly we can test it
n Simplicité fonctionnelle

n Simplicité structurelle

n Simplicité du code

28
A.ZELLOU
 Stabilité
n The fewer the change, the fewer the disruptions to testing
n Les changements au logiciel ne sont pas fréquents

n Les changements au logiciel sont contrôlés

n Les changements au logiciel n’invalident pas les tests

existants
n Le logiciel se remet bien après les défauts

29
A.ZELLOU
 Compréhensibilité
n The more information we have, the smarter we will test
n La conception est bien comprise

n Les dépendances entre les composantes internes,

externes et partagées sont bien comprises
n La documentation technique est accessible
instantanément
n La documentation technique est bien organisée

n La documentation technique est spécifique, détaillé et

précise

30
A.ZELLOU
 Les Tests du Logiciel
Les types de tests

31
A.ZELLOU
 Différents types de tests
n Les tests unitaires (tests de modules)
n Les tests d’intégration
n Les tests du système
n Les tests d’acceptation
n Les tests de régression
n Les tests d’IHM

32
A.ZELLOU
 Différents types de tests
n On distingue deux principales méthodes :
n Méthodes fondées sur les programmes

n Méthodes fondées sur les spécifications

33
A.ZELLOU
 Les tests unitaires
n Le « test unitaire » est le plus couramment utilisé et le plus
important.
n L'objectif est de s'assurer qu'une unité de code ne comporte
pas d'erreur.
n La vérification est faite en exécutant une unité de code.
n En programmation orientée objet, l'unité est la classe.
n Un test est un programme qui exécute le code d'une classe
pour s'assurer qu’elle est correcte.
n À chaque classe d'une application, on associe une autre
classe qui la teste.

34
A.ZELLOU
 Les tests unitaires
n Pour tester un module M :
n Un problème est posé par les modules appelés par M, et
dont on ne dispose pas pour exécuter le test.
n Ceux-ci doivent être remplacés par des modules de
même en-tête, qui réalisent de façon simplifiée la
fonction assurée par le module appelé.
n Ces modules sont appelés stubs.

35
A.ZELLOU
 Exemple de stubs
n Si le module testé appelle une procédure de tri d’en-tête:
procédure tri(tableau T; entier n)
n On pourra utiliser le stub :
n Procedure tri (tableau T; entier n)

Ecrire ("la séquence à trier est:");

Pour i:=1 jusqu'à n faire lire(T[i]);
Opération de Trie
Pour i:=1 jusqu'à n faire écrire(T[i]);

n Le testeur réalise le tri à la main

36
A.ZELLOU
 Tests unitaires (suite)
n Pour tester un module M :
n Un problème analogue est posé par l'absence des
modules appelant le module testé M
n Ces Modules doivent être remplacés par un module
appelant M pour les valeurs d'entrée du jeu de tests
n Ils récupérant les résultats calculés par M, pour les
imprimer ou les comparer avec les résultats corrects
attendus

n Un tel module est appelé driver

37
A.ZELLOU
 Tests unitaires

38
A.ZELLOU
 Les frameworks de type xUnit
n En Java : JUnit est le framework le plus utilisé pour Java.
Intégré dans la plupart des IDE.
n En C++ : Cutter
n En Python : unittest, PyUni.
n En PHP : PHPUnit, SimpleTest.
n En Ruby : Test::Unit.
n En JavaScript et jQuery : qunit, Jarvis, jfUnit, google-js-test
n Etc.

39
A.ZELLOU
 Exemple : JUnit
n Créer une nouvelle classe pour chaque classe testée.
n Créer au moins un test par méthode de la classe testée.
n Pour désigner une méthode comme un test, rajoutez
l'annotation @Test.
import static org.junit.Assert.*;
import org.junit.Test;
public class StringTest {
@Test
public void testConcatenation() {
String ch1 = “zellou";
String ch2 = “ ahmed";
assertEquals(“zellou ahmed", foo + bar);
}
@Test
public void testStartsWith() {
String ch1 = “zellou";
40 assertTrue(ch1.startsWith("ah"));
}} A.ZELLOU
 Lancer les tests
n Pour lancer les tests, plusieurs possibilités selon les
préférences :
n Lancer les tests depuis l’IDE (La plus courante)

n Utiliser l'outil graphique

n Lancer les tests en ligne de commande

n Utiliser un système de construction logiciel (Ant,

Maven, etc.)

41
A.ZELLOU
 Limites du test unitaire
n Le test fait appel à :
n un composant difficile ou coûteux à mettre
en place.
n une classe dans une situation exceptionnelle.

n un composant non disponible de façon stable.

n un code non-déterministe.

n un code lent.

42
A.ZELLOU
 Tests d'intégration
n Dédiés aux tests de l'interfaçage des modules, et aux tests
de composants de plus en plus gros, jusqu'aux tests du
système complet.
n Il y a plusieurs méthodes pour conduire les tests
d'intégration
n La méthode du "Big Bang"

n La méthode descendante

n La méthode ascendante

n La méthode Sandwich

43
A.ZELLOU
 La méthode du Big Bang
n Une fois que tous les modules ont passé les tests unitaires,
une édition de liens est réalisée pour constituer une version
du système complet, et on teste cette version.
n On aura besoin de :
n autant de drivers qu'il y a de modules, et

n un stub pour tout module appelé, sauf le module

principal
n La méthode Big Bang est dangereuse:
n toutes les erreurs se produisent en même temps, et leur
localisation est difficile

44
A.ZELLOU
 La méthode du Big Bang

Sens du test
1 Test du Software

Unité A Unité B Unité C Unité D Unité E Unité F Unité G Unité H Unité I

2

45
A.ZELLOU
 La méthode Descendante
n On commence par tester le module principal, puis on teste
le programme obtenu par édition de liens du module
principal et des modules appelés directement par le module
principal, etc.
n Cette méthode demande
n un seul driver (pour le module principal), et

n un stub pour chaque autre module.

46
A.ZELLOU
 La méthode Descendante

1 Test du Software
Sens du test

2 Unités A, B, C, D et E Unités F, G, H et I

3 Unités A, B et C Unités D et E Unités F et G Unités H et I

Unité A Unité B Unité C Unité D Unité E Unité F Unité G Unité H Unité I

447
A.ZELLOU
 La méthode Ascendante
n On commence par tester les modules n'appelant pas
d'autres modules, puis les programmes obtenus par édition
de liens d'un module n'appelant que des modules déjà testés
avec ces modules, etc
n Cette méthode demande
n un driver par module, et

n pas de stub

48
A.ZELLOU
 La méthode Ascendante

4 Test du Software
Sens du test

3 Unités A, B, C, D et E Unités F, G, H et I

2 Unités A, B et C Unités D et E Unités F et G Unités H et I

Unité A Unité B Unité C Unité D Unité E Unité F Unité G Unité H Unité I

149
A.ZELLOU
 La méthode Sandwich
n Combine les approches descendantes et ascendantes
n Distingue trois couches :
n Au-dessus : testée selon la méthode ascendante

n Intermédiaire

n Au-dessous : testée par la méthode descendante

50
A.ZELLOU
 La méthode Sandwich

1 Test du Software
Sens du test

3 Unités A, B, C, D et E Unités F, G, H et I

4 Unités A, B et C Unités D et E Unités F et G Unités H et I

Unité A Unité B Unité C Unité D Unité E Unité F Unité G Unité H Unité I

251
A.ZELLOU
 Panorama des erreurs
n IEEE définit un défaut comme une anomalie du produit
n Un défaut est le résultat de la présence d’une faute (erreur)
n Une erreur provoque un défaut à l’exécution

n Une erreur est une caractéristique statique du logiciel

n Dans le contexte du logiciel, le défaut est synonyme

d’erreur (bug)

52
A.ZELLOU
 Panorama des erreurs
Classe Classe de Description
panne
Apparition Transitoire Ne se produit qu’avec certaines
données
Permanente Se produit avec toutes les entrées

Correction Réparable Ne nécessite pas d’intervention

humaine
Irréparable Nécessite une intervention de
l’opérateur

Altération Non corruptrice Ne détruit et ne corrompt les

données
Corruptrice Détruit ou corrompt les données
53
A.ZELLOU
 Panorama des erreurs
n Spécification incomplète ou erronée (SIE)
n Mauvaise interprétation de la communication avec les
clients (MICC)

n Déviations intentionnelles des spécifications (DIS)

n Erreurs dans la logique de conception (ELC)
n Erreurs dans la translation de la conception à un langage de
programmation (ETLP)
n Violation des standards de programmation (VSP)
n Erreurs dans les données de représentation (EDR)
54
A.ZELLOU
 Panorama des erreurs
n IHM ambiguë ou inconsistante (IHM)

n Composant d’interface inconsistant (CII)

n Documentation incomplète ou inadéquate (DII)
n Tests erronés ou incomplets (TEI)
n Divers (DIV)

55
A.ZELLOU
 Panorama des erreurs
n Les erreurs sont réparties en trois catégories :
n Sérieuses

n Modérées

n Mineures

n Des études ont montré que 53% des erreurs sont induites
par les SIE, MICC et EDR
n Au niveau des erreurs sérieuses, les SIE, EDR, E TLP et
ELC représentent le "vital few causes"

56
A.ZELLOU
 Les simulacres (mock objects)
n Les doublures sont des classes :
n similaire à la classe originale et peut donc la remplacer.

n écrites par le développeur

n générés par un outil à partir de la classe originale.

n La plus courante : *
n Java : Mockito, Mockachino,ou JMockit ;

n C++ : Google C++ Mocking Framework ;

n Ruby : mocha

57 n JavaScript : SinonJS
A.ZELLOU
 Les espions (ou « spy »)
n Un espion est une doublure qui enregistre les traitements
qui lui sont fait.
n Les tests se déroulent alors ainsi :
n On introduit une doublure dans la classe testée

n On lance le traitement testé

n Une fois finie, on inspecte la doublure pour savoir ce

qu'il s'est passé.
n On peut vérifier qu'une méthode a bien été appelée, avec
quels paramètres et combien de fois etc.

58
A.ZELLOU
 Le doctest
n doctest est un outil livré avec Python

n doctest interprète les lignes préfixées par >>> et vérifie

que ce qui est retourné par l'évaluation de l'expression
correspond à ce qui est écrit (ici, doctest va vérifier que
l'évaluation de a + b renvoie bien 3)
59
A.ZELLOU
 Tests par classes d'équivalence
n Principe
n Partitionner le domaine des données en un nombre fini
de classes, et choisir un élément (ou échantillon
d'éléments) dans chaque classe.
n On mettra dans une même classe les données que l'on
estime devoir se comporter de la même façon vis-à-vis
du programme.
n Exemple : tester la solution d’une inéquation du
deuxième degré.

60
A.ZELLOU
 Tests par classes d'équivalence
n Pour tester une condition "A ou B », on teste
n A vrai, … ?

n Pour une condition "A et B", on teste

n A vrai, … ?

n Pour une condition "A et B ou C et D", on teste :

n A, B vrai; C, D vrai; A faux, C faux; A faux, D faux; B
faux, C faux; B faux, D faux

61
A.ZELLOU
 Tests dirigés par la syntaxe
n Principe
n Quand les données sont des ensembles de chaînes de
caractères, elles sont souvent spécifiées par des
formalismes comme les automates finis, ou les
grammaires hors-contexte
n On peut définir un jeu de tests couvrant les états d'un
automate fini, couvrant les chemins de longueur borné
d'un automate fini
n On peut définir un jeu de tests couvrant les règles d'une
grammaire hors-contexte
n Exemple: tester une adresse mail

62
A.ZELLOU
 Tests dirigés par les mutants
n Principe
n On modifie le programme en introduisant des erreurs.

n Les programmes ainsi modifiés sont appelés "mutants".

n Un jeu de test est bon s'il tue 100% (95%, etc.) des
mutants

63
A.ZELLOU
 Les tests exhaustifs
n On teste le programme pour toutes les données possibles.
n Ceci n'est théoriquement possible que si l'ensemble des
données est fini
n Le temps d'exécution des tests exhaustifs est prohibitif dans
la plupart des cas

64
A.ZELLOU
 Les tests exhaustifs
n Exemple 1
n Un calcul de Öx, avec x entier entre 0 et 2 .
31

n Durée d'un test: 1s. En un an, il y a 365´24´3600=

31536000 secondes.
n Le temps d'un test exhaustif est à peu près …

n Exemple 2
n Test d'un additionneur, avec opérandes entiers entre 0 et
231.
n Durée d'un test: 1µs. nombre de données:
231´231=262=9,22´1018.
n Le temps des tests exhaustifs est supérieur à …
65
A.ZELLOU
 Tests aléatoires
n Principe
n Le jeu de tests est tiré au hasard dans le domaine des
données.
n C'est une méthode facile pour produire des jeux de tests,
mais qui est souvent considérée comme la moins efficace
pour trouver les erreurs

66
A.ZELLOU
 Les tests du Système
n Permet de s’assurer que l’application est conforme aux
spécifications via une simulation d’utilisation réelle
n Aussi appelés tests d’infrastructure, ils permettent
d’évaluer les performances du système
n Il s'agit des tests du logiciel complet et du matériel pour les
performances, la sécurité, la conformité aux spécifications,
etc.
n Débutent lorsque le système dans son ensemble est prêt, ou
lorsque des sous-ensembles importants de fonctionnalités
sont prêts
n Test long à réaliser
67
A.ZELLOU
 Tests de charge et de performance
n Test de charge
n Consiste à simuler un nombre d'utilisateurs virtuels
prédéfinis, afin de valider l'application pour une charge
attendue d'utilisateurs.
n Permet de mesurer le dimensionnement des serveurs, de
la bande passante nécessaire sur le réseau, etc.
n Test de performance
n Consiste à mesurer les performances de l'application
soumise à une charge d'utilisateurs.
n Permet de mesurer les temps de réponse utilisateurs, les
temps de réponse réseau et les temps de traitement
68
d’une requête sur le(s) serveur(s).
A.ZELLOU
 Tests de dégradation et de stress
n Test de dégradations
n Il s'agit de déterminer quelle charge le système est
capable de supporter pour chaque scénario fonctionnel
et d'isoler par la suite les transactions qui dégradent le plus
l'ensemble du système.
n Ce test peut tenir compte la représentativité
d'utilisateurs simultanés vs. sessions simultanées
n Test de stress
n Il s'agit d'un test au cours duquel on va simuler l'activité
maximale attendue tous scénarios fonctionnels confondus en
heure de pointe de l'application, pour voir comment le
système réagit au maximum de l'activité attendue des
69
utilisateurs. A.ZELLOU
 Tests de robustesse et de capacité
n Test de robustesse, d'endurance, de fiabilité
n Il s'agit de tests au cours desquels on va simuler une
charge importante d'utilisateurs sur une durée relativement
longue
n Test de capacité
n Il s'agit d'un test au cours duquel on va simuler un
nombre d'utilisateurs sans cesse croissant de manière à
déterminer quelle charge limite le système est capable
de supporter.

70
A.ZELLOU
 Les tests de montée en charge
n Test aux limites
n Il s'agit d'un test au cours duquel on va simuler en
général une activité bien supérieure à l'activité normale
n Permet de voir comment le système réagit aux limites
du modèle d'usage de l'application.

71
A.ZELLOU
 Les tests d'acceptation
n Appelés aussi tests de validation
n sont parfois conduits par le client

n tests du produit final contre le contrat passé avec le

client
n sont effectués lorsque le système est prêt à être déployé,
juste avant qu'il soit livré et officiellement installé

72
A.ZELLOU
 Les tests de régression
n Sont des tests
n exécutés après correction d'erreurs

n permettent de vérifier si d'autres erreurs n'ont pas été

introduites au cours de la correction.
n Ce type de tests est en particulier conduit pendant la
maintenance

73
A.ZELLOU
 Conclusion d’Approche
n Une méthode efficace pour trouver les erreurs consiste à
combiner les tests fonctionnels et les tests structuraux.
n On commence par définir un jeu de tests
fonctionnels, dès que la spécification est connue
n On complète par les tests structuraux quand on
dispose du programme
n Les jeux de test doivent être écrits pour des entrées aussi
bien invalides et inattendues, que valides et attendues.
n Inspectez en profondeur les résultats de chaque test.
n Se fonder sur l'expérience de projets similaires

74
A.ZELLOU
 Conclusion : Meilleurs critères
n Tester tant que le nombre d'erreurs trouvées ne décroît pas
de façon significative

n Testez tant que 70 erreurs (par exemple) n'ont pas été détectées
ou qu'un délai de 3 mois ne s'est pas écoulé
n La probabilité d'existences de plus d'erreurs dans une section d'un
programme est proportionnelle au nombre d'erreurs déjà
75 trouvées dans cette section. A.ZELLOU
 Conclusion
n Ne pas planifier de tests sous l'hypothèse qu'aucune erreur
ne sera trouvée.
n Un programmeur doit éviter d'essayer de tester son propre
programme.
n Une structure de programmation ne doit pas tester ses
propres programmes.
n Tester est une tâche créative et intellectuelle.

76
A.ZELLOU
 Fin

77
A.ZELLOU