S6
ENI-ABT BAMAKO 2026
Génie Logiciel
Test du logiciel
1
Sommaire
1. Définition du test
2. Processus du test
3. Types de tests
4. Comment tester ?
5. Vérification et Validation
6. Bibliographie
2
Test - objectif
1. Exécuter un programme pour trouver des erreurs
2. Un bon cas de test a une forte probabilité de
trouver des erreurs
3. Un test réussi révèle une nouvelle erreur
3
Test du Logiciel
• Il y a deux principales façons de Tester le Logiciel
• Boîte Noire
• Boîte Blanche
4
Boîte Noire
• Test Boîte Noire : vous n’avez aucune
connaissance de la façon dont le système va
satisfaire les besoins mais vous connaîssez la
fonctionnalité correspondante
• – Étant donné que vous savez ce qu’il est
supposé faire, vous concevez des tests qui lui
font faire ce que vous pensez qu’il doit faire
5
• – Vous testez la fonctionnalité par rapport aux
spécifications /exigences en observant son
comportement externe
– Qu’est-ce qui est entré dans le système?
– Qu’est-ce que vous pouvez faire de l’extérieur
pour changer le système ?
– Qu’est-ce qui est sorti du système ?
6
Boîte Blanche
• Test Boîte Blanche: vous connaîssez le code
– Compte tenu de la connaissance du
fonctionnement interne, vous testez en profondeur
ce qui se passe à l'intérieur
– Test au niveau de détail procédural (algorithmique)
– Les chemins logiques à travers le code sont testés
• Conditionnels
• Boucles
• Branchements conditionnels
7
– Le test se fait en fonction des valeurs
attendues
– Impossible de tester à fond tous les chemins
• Le test exhaustif peut s’étendre sans limite
– C’est pratique si un nombre limité de chemins
"importants" sont évalués
• – C’est pratique si on fait le test des structures
de données importantes
8
Quand & Quoi pour le Test?
9
Types de Test
• Test Unitaire
– Fait par les programmeurs
– Généralement tout se fait en Boîte Blanche
• Test d’Intégration
– Fait par les programmeurs quand ils intègrent leurs
codes
– Généralement Boîte Blanche, peut aussi être Boîte
Noire
10
• Test Fonctionnel/Système
– Il est recommandé qu’il soit fait par un groupe de test
extérieur
– Le plus souvent Boîte noire de telle sorte que le test ne
soit pas ‘corrompu’ par une trop grande connaissance
du système
• Test d’Acceptation
– Généralement fait pas le client ou son représentant
dans leur environnement à travers l’interface
– Entièrement Boîte Noire
11
Le Processus de Test
12
Planification des Cas Test
Boîte Noire
• Regarder les exigences/énoncé du problème.
• Autrement dit: les cas de test doivent être
reliés aux exigences.
• La “Grille de Cas de Test” Contient:
– Le Numéro du test
– La description des conditions d’entrée du test
– Les résultats attendus/prédits
– Les résultats réels
13
Grille de Cas de Test
• Pour vos rapports de test, veuillez utiliser le
format suivant:
14
Planification du Test
Boîte Blanche
• Les entrées doivent être très spécifiques
• Les résultats attendus doivent être très spécifiques
• Vous devez écrire le cas de test de telle sorte que
n’importe quel membre de l’équipe puisse exécuter le
test exact et avoir le résultat exact.
15
• Exemple: “Note de passage ?”
• Champ d’Entrée:
– Entrée correcte : Note = 18; Note = 5
– Entrée incorrecte : “une note de passage” ; “une
note de redoublement”
16
Exemple de Grille de Cas de Test
• Votre grille de cas de test (dernière section de
votre document d’analyse) doit identifier au
moins 15 cas de test.
• Exemple: “Note de passage?”
17
Exemple d’un Mauvais Cas de Test
• Qu’est-ce qu’une note de redoublement et
passage
• ?
• Problème: La valeur d’entrée est trop vague.
18
Echec des Cas de Test
• Qu’en est-il si le type d’entrée est mauvais (Vous
êtes en train d’attendre un entier, vous recevez un
réel. Vous êtes en train d’attendre un caractère,
vous avez un entier)?
• Qu’en est-il si le client prend un chemin non
logique (non défini) à travers votre fonctionnalité ?
19
• Qu’en est-il si les champs obligatoires ne sont pas
renseignés?
• Qu’en est-il si le programme est brutalement
interrompu ou les périphériques d’entrées/sorties
ne sont pas branchés?
20
Utilisation d’un diagramme d’activités
La cartographie des fonctionnalités
dans le diagramme rend le processus
de génération de cas de test
beaucoup plus facile.
21
Une entrée conduit à Une sortie
• Un bout de code avec les entrée a, b, et c. Il
produit les sorties x, y, et z.
22
Test Un-à-Un
• Chaque entrée a seulement un résultat valide
attendu.
• Pour vérifier une carte bancaire, le cas de test
suivant N’EST PAS correct.
23
Façon correcte
• Test pour la carte bancaire
– Entrée: Carte
– Résultat attendu : Accepte la carte et demande le
numéro de code
– Entrée : Carte invalide
– Résultat attendu : Exception “Aucune Carte” est
levée et la carte est retournée à l’utilisateur.
24
25
Un autre test
• Test pour “avoir le Code”
– Entrée : les 4 chiffres d’une carte volée
– Résultat attendu : l’Exception “Carte Volée” est levée
26
Qu’est-ce qui vient après ?
• Après que les tests soient effectués, les
résultats sont enregistrés.
27
Qu’est-ce qui vient après ?
• Après que les résultats aient été enregistrés, le
rapport de test est créé.
28
Vérification & Validation
• Le Test est effectué durant la phase d’implémentation du
système et les résultats sont délivrés dans le rapport final.
• Le Rapport de Test fournit la vérification & validation pour
le logiciel.
• Vérification: “Sommes-nous en train de bien construire le
• produit ?"
– Le logiciel doit être conforme à sa spécification
• Validation: “Sommes-nous en train de construire le bon
produit ?"
– Le logiciel doit faire ce dont l’utilisateur a réellement besoin
29
Projet
• Mini projet
Votre Document d’Analyse et de Conception
doit être complété!
30
Prochainement:
• Commencer à réfléchir aux différents cas de
test et à élaborer la grille des cas de test
• Commencer à vérifier la conformité des
fonctionnalités par rapport aux spécifications
du cahier des charges.
31
• Hecker B. (2014): « Software Engineering », cours
de l’Université des Technologies de l’Information
(IUT).
• Peters, James F. ; Pedrycz, Witold (2000) : «
Software Engineering – An Engineering Approach
»
32