Test Logiciel

(Certification ISTQB)
Département Informatique
2023-2024

Mariem HAOUES
Maître-assistant, FSB

Université de Carthage

© Mariem HAOUES - [email protected]

 Avant de commencer…
 Les logiciels sont omniprésents
 Ils renferment des défauts qui demeurent parfois dissimulés
 Ces défauts peuvent entraîner des défaillances logicielles

 Un défauts dans un système peut causer :

 Une perte du temps
 Une perte d’argent
 Une mauvaise
réputation
 Des blessures et/ou
des morts

 Une étude menée en 2013 par l’université de Cambridge évaluait le

coût des bugs informatiques à 312 milliards de dollars par an

2
GLSI2 & SEIoT2
 Avant de commencer…
1. Amazon AWS outage - 2017 2. Fuite de données d'utilisateurs
de Facebook – 2018
Perte: Difficile à quantifier, mais
de nombreux sites web ont été Perte: La confiance des clients
touchés pendant des heures/jours Description: Les numéros de
Description: Les services téléphone et les données personnelles
Amazon étaient indisponibles de 533 millions d'utilisateurs de
pendant des heures, Certaines Facebook ont été divulgués en ligne
pertes de données permanentes Cause: Une vulnérabilité dans le
Cause: Le déclencheur de cet système qui permettait l'accès aux
événement était un « changement comptes des utilisateurs de Facebook
de configuration réseau »

3
GLSI2 & SEIoT2
 Chapitre 1

Les fondamentaux du test

4
GLSI2 & SEIoT2
 1. Que sont les tests ?
Définition de IEEE
« Le test est l’exécution ou l’évaluation d’un système ou d’un composant par des
moyens automatiques ou manuels, pour vérifier qu’il répond à ses spécifications ou
identifier les différences entre les résultats attendus et les résultats obtenus ».
(Standard Glossary of Software Engineering Terminology)

Le test est une méthode dynamique visant à trouver des bugs

«Tester, c’est exécuter le programme dans l’intention d’y trouver
des anomalies ou des défauts » G. Myers (The Art of Software testing)

Le test est une méthode de validation partielle des logiciels

« Tester permet seulement de révéler la présence d’erreurs mais
jamais leur absence. » E. W. Dijkstra (Notes on Structured
Programming, 1972)

5
GLSI2 & SEIoT2
 1. Que sont les tests ?

Test de
logiciel

Test Dynamique Test Statique

implique n'implique pas
l'exécution du l'exécution du
composant ou du composant ou du
système testé système testé

6
GLSI2 & SEIoT2
 1. Que sont les tests ?

Test Statique:
n'implique pas
l'exécution du
composant ou du
système testé

7
GLSI2 & SEIoT2
 1. Que sont les tests ?
Vérification
• Est-ce que le logiciel fonctionne
correctement ?
Construisons-nous le système
Test de correctement ? Est-il "correct" ?
logiciel Validation
• Le système répond-il aux exigences
du client ?
• La performance sera-t-elle
suffisante ?
• L'utilisabilité sera-t-elle suffisante ?
Construisons-nous le bon système ?

8
GLSI2 & SEIoT2
 1. Que sont les tests ?

9
GLSI2 & SEIoT2
 1.1. Les objectifs du test

10
GLSI2 & SEIoT2
 1.2. Test et débogage

Le test : consiste à
explorer le système afin
de détecter d'éventuelles
défaillances

Le débogage : est le
processus utilisé pour
identifier les causes des
bugs dans un code et les
corriger

11
GLSI2 & SEIoT2
 1.2. Test et débogage

 Dans le développement Agile et dans certains autres cycles de vie, les

testeurs peuvent être impliqués dans le débogage et les tests de composants

12
GLSI2 & SEIoT2
 2. Pourquoi les tests sont-ils
nécessaires ?
 Des tests rigoureux des composants et des systèmes, peuvent aider à
réduire le risque de défaillances pendant l'exploitation
 Lorsque des défauts sont détectés et corrigés par la suite, cela contribue à la
qualité des composants ou des systèmes
 Les tests logiciels peuvent également être nécessaires pour répondre à des
exigences contractuelles ou légales ou à des normes spécifiques de
l'industrie

13
GLSI2 & SEIoT2
 2.1. Assurance qualité et test

 L'assurance qualité et le test ne sont pas les mêmes

 La gestion de la qualité comprend toutes les activités qui dirigent et
contrôlent une organisation en matière de qualité
 L’assurance qualité est principalement axée sur le respect des processus
adéquats, afin de donner l'assurance que les niveaux de qualité
appropriés seront atteints
 Le contrôle de la qualité comprend diverses activités, y compris des
activités de test, qui contribuent à l'atteinte de niveaux de qualité
adéquats

14
GLSI2 & SEIoT2
 2.2. Erreurs, défauts et
défaillances
Une personne fait une
erreur

… qui crée une faute, un

défaut ou un bug dans le
logiciel…

… qui peut provoquer

une défaillance …

On estime qu’un développeur de bon niveau introduit en moyenne : 50

défauts par 1000 lignes de code
15
GLSI2 & SEIoT2
 2.2. Erreurs, défauts et
défaillances

16
GLSI2 & SEIoT2
 2.2. Erreurs, défauts et
défaillances
Des nouvelles
Une mauvaise technologies
Les contraintes de communication
temps

Pourquoi des
erreurs se Les malentendus
La faillibilité produisent-elles? sur les interfaces
humaine intra-système et
inter-système

L’inexpérience La complexité du Les conditions de

travail l’environnement
17
GLSI2 & SEIoT2
 2.2. Erreurs, défauts et
défaillances

Faux négatifs Faux positifs

Les faux négatifs sont des tests Les faux positifs sont signalés
qui n’ont pas détecté les défauts comme des défauts, mais ne sont
qu'ils devraient détecter pas réellement des défauts

18
GLSI2 & SEIoT2
 2.3. Défauts, causes racines et
effets
 Les causes racines des défauts sont les premières actions
ou conditions qui ont contribué à la création des défauts
 L'analyse des causes racines peut conduire à des améliorations
de processus qui préviennent l'introduction d'un nombre important de
défauts futurs

19
GLSI2 & SEIoT2
 3. Les 7 principes de Test
 Principe 1 : Les tests montrent la présence des défauts, pas leur
absence

Quelques soit l’importance du nombre de défauts qu’on a trouvé,

et le temps qu’on a passé dans les tests sans en trouver de
nouveaux, ce n’est pas une preuve d’absence de défauts

Cela ne prouve que le risque de défaillance a diminué, sans

jamais pour autant prétendre que le risque est nulle ou que le
logiciel contient 0% de défauts : Ce qui est impossible à affirmer
20
GLSI2 & SEIoT2
 3. Les 7 principes de Test
 Principe 2 : Les tests exhaustifs sont impossibles

Il est impossible de tout tester (à l'exception des cas triviaux)

Il faut sélectionner les tests les plus prioritaires et ceux qui ont un
impact sur la qualité de l’application (basé sur l’analyse des
risques)

21
GLSI2 & SEIoT2
 3. Les 7 principes de Test
 Principe 3 : Tester tôt économise du temps et de l’argent

Ce principe encourage à tester le plus tôt possible dans le cycle de

développement des logiciels

Plus tôt un défaut est détecté, plus tôt il sera corrigé et moins il
impactera les activités suivantes du projet

22
GLSI2 & SEIoT2
 3. Les 7 principes de Test
 Principe 4 : Regroupement des défauts

Il existe une loi universelle qu’on appelle la loi Pareto qui dit que
80% des problèmes sont issues de 20% des causes

Cette loi est aussi vrai dans les tests logiciels où 80% des défauts
de qualité proviennent des 20% des modules les plus complexes,
les plus instables ou les plus utilisés

Pour tester efficacement un logiciel il faut toujours commencer

par trouver les modules les plus critiques de ce logiciel
23
GLSI2 & SEIoT2
 3. Les 7 principes de Test
 Principe 5 : Le paradoxe du pesticide

Ce paradoxe nous explique que parfois utiliser un pesticide pour

éliminer un bug (insecte en anglais) peut avoir l’effet contraire et
faire proliférer ces bugs

La même chose risque de se produire dans les tests logiciels

quand on lance les même tests sur les mêmes modules en
utilisant les mêmes techniques, on trouvera de moins en moins
de défauts avec le temps
24
GLSI2 & SEIoT2
 3. Les 7 principes de Test
 Principe 5 : Le paradoxe du pesticide

Pour tester efficacement dans le temps, il faut varier les angles

d’attaque en mettant à jour les tests existants et en ajoutant des
tests nouveaux

Le paradoxe du pesticide
peut-il être utile?

25
GLSI2 & SEIoT2
 3. Les 7 principes de Test
 Principe 6 : Les tests dépendent du contexte

Tester un site de réservations de voyages est différent de la

démarche de test d’un équipement informatique pour les
hôpitaux : un défaut sur ce dernier peut impacter des vies d’êtres
humains contrairement au site de voyage

Les tests sur les systèmes les plus critiques doivent être les plus
rigoureux. Ainsi, des choix stratégiques doivent être faits :
niveaux de tests, tests manuels ou tests automatisés, types de
tests, techniques de test, niveau de traçabilité, etc.
26
GLSI2 & SEIoT2
 3. Les 7 principes de Test
 Principe 7 : L’absence d’erreurs est une illusion

Est-ce que la création d’un logiciel qui fonctionne bien dans le

sens ou tous les bugs trouvés ont été corrigés, va satisfaire les
clients ?
Ce n’est pas sûr. Un logiciel peut fonctionner correctement sans
incident mais sans satisfaire les attentes de l’utilisateur

Exemple: le logiciel fonctionne bien sur un navigateur X mais pas

bien sur un autre navigateur Y (plus préféré par les utilisateurs)
27
GLSI2 & SEIoT2
 4. Activités et tâches de test et
Testware
Un processus de test se compose des principaux groupes d'activités suivants :

 Plusieurs de ces groupes d'activités peuvent sembler logiquement

séquentiels, ils sont souvent mis en œuvre de façon itérative
 Par exemple, le développement Agile implique de petites itérations de
conception de logiciels, de construction et de test qui se produisent en
continu, soutenues par une planification régulière
 Même en mode séquentiel, la séquence logique par étapes des activités
induira le chevauchement
28
GLSI2 & SEIoT2
 4. Activités et tâches de test et
Testware
 Planification des tests
 Définir les objectifs du test et l'approche retenue pour atteindre les
objectifs
 Pilotage et contrôle des tests
 Le pilotage des tests implique la comparaison régulière de
l’avancement réel par rapport au plan de test à l'aide des métriques de
pilotage définies dans le plan de test
 Le contrôle des tests consiste à prendre les mesures nécessaires pour
satisfaire aux objectifs du plan de test
 Se basant sur l'évaluation des critères de sortie, que l’on appelle
« definition of done »
 L’avancement des tests par rapport au plan est communiqué aux
parties prenantes dans des rapports d'avancement des tests

29
GLSI2 & SEIoT2
 4. Activités et tâches de test et
Testware
 Pilotage et contrôle des tests

30
GLSI2 & SEIoT2
 4. Activités et tâches de test et
Testware
 Analyse de test
 La réponse de la question “qu'est-ce que tester”
 Analyser les bases de test
 Les spécifications des exigences
 Design
 Code
 Les rapports d'analyse des risques
 Définir et prioriser les conditions de test
 Capturer la traçabilité bidirectionnelle
 Identifier les caractéristiques et les ensembles de
caractéristiques à tester

31
GLSI2 & SEIoT2
 4. Activités et tâches de test et
Testware
 Analyse de test

32
GLSI2 & SEIoT2
 4. Activités et tâches de test et
Testware
 Conception des tests
 La réponse de la question “Comment tester”
 Concevoir et prioriser les cas de test et les ensembles de cas de
test
 Identifier les données
 Concevoir l'environnement de test

33
GLSI2 & SEIoT2
 4. Activités et tâches de test et
Testware
 Implémentation des tests
 La réponse de la question “Avons-nous maintenant tout en place
pour exécuter les tests”
 Développer et prioriser les procédures de test
 Créer des suites de tests à partir des procédures de test et les
positionner dans un calendrier d'exécution des tests
 Construire l'environnement de test
 Exécution des tests
 Exécuter les suites de tests
 Comparer les résultats obtenus avec les résultats attendus
 Rapport des défauts
 Test de confirmation, et/ou test de régression

34
GLSI2 & SEIoT2
 4. Activités et tâches de test et
Testware

 Exécution des tests

35
GLSI2 & SEIoT2
 4. Activités et tâches de test et
Testware
 Clôture des tests
 Analyser les leçons apprises des activités de test terminées afin
de déterminer les changements nécessaires pour les itérations,
versions et projets futurs
 Utiliser l'information recueillie pour améliorer la maturité du
processus de test
 Vérifier si tous les rapports de défauts sont clôturés
 Créer un rapport de synthèse de test
 Finaliser et archiver l’environnement de test, les données de test,
l'infrastructure de test et autres testware pour une réutilisation
ultérieure

36
GLSI2 & SEIoT2
 4. Activités et tâches de test et
Testware

 Clôture des tests

37
GLSI2 & SEIoT2
 4. Activités et tâches de test et
Testware
 Les produits d’activités du test
Activité Produit d’activité
Planification des tests Le plan de test
Pilotage et contrôle des tests Rapport d'avancement de test - Rapport de
synthèse de test
Analyse de test conditions de test - chartes de test
Conception des tests cas de test - données de test
Implémentation des tests Les procédures de test - Les suites de test -
Un calendrier d'exécution des tests
Exécution des tests statut de chaque cas de test - Les rapports
de défauts
Clôture des tests les rapports de synthèse de test - des
demandes de changement
38
GLSI2 & SEIoT2
 4. Activités et tâches de test et
Testware
 Les produits d’activités du test

39
GLSI2 & SEIoT2
 5. Processus de test simplifié
• Tester ?: réaliser une exécution d’un programme pour y
trouver des défauts
• Exemple: soit un programme pour trier un tableau
d’entiers en enlevant les redondances
Interface : int[] mon_tri(int[] vec)
• Exemples de cas de test
▫ Un tableau de N entiers non redondants
▫ Un tableau vide
▫ Un tableau de N entiers dont 1 est redondant
▫ Etc.

40
GLSI2 & SEIoT2
 5. Processus de test simplifié
• Tester ?: réaliser une exécution d’un programme pour y
trouver des défauts
• Exemple: soit un programme pour trier un tableau
d’entiers en enlevant les redondances
Interface : int[] mon_tri(int[] vec)
• Etape 1 : On définit un cas test (CT) à exécuter, i.e. un
“scénario” que l’on veut appliquer
▫ Un tableau de N entiers non redondants
Cas de test

41
GLSI2 & SEIoT2
 5. Processus de test simplifié
• Tester ?: réaliser une exécution d’un programme pour y
trouver des défauts
• Exemple: soit un programme pour trier un tableau
d’entiers en enlevant les redondances
Interface : int[] mon_tri(int[] vec)
• Etape 2 : On concrétise le cas de test en lui fournissant
les données de test (DT)
▫ Le tableau [1,0,12,4,41,5]
Cas de test
[1,0,12,4,41,5]

42
GLSI2 & SEIoT2
 5. Processus de test simplifié
• Tester ?: réaliser une exécution d’un programme pour y
trouver des défauts
• Exemple: soit un programme pour trier un tableau
d’entiers en enlevant les redondances
Interface : int[] mon_tri(int[] vec)
• Etape 3 : On indique le résultat que l’on attend pour ce
CT (prédiction de l’Oracle)
▫ [1,0,12,4,41,5] => [0,1,4,5,12,41]
Cas de test
[1,0,12,4,41,5] Données de test
+
[0,1,4,5,12,41] Prédiction de l’oracle

43
GLSI2 & SEIoT2
 5. Processus de test simplifié
• Tester ?: réaliser une exécution d’un programme pour y
trouver des défauts
• Exemple: soit un programme pour trier un tableau
d’entiers en enlevant les redondances
Interface : int[] mon_tri(int[] vec)
• Etape 4 : On exécute le script de test testant le CT sur
les DT

Cas de test
[1,0,12,4,41,5] Données de test Script de test Résultat [1,0,12,4,41,5]
+
[0,1,4,5,12,41] Prédiction de l’oracle
44
GLSI2 & SEIoT2
 5. Processus de test simplifié
• Tester ?: réaliser une exécution d’un programme pour y
trouver des défauts
• Exemple: soit un programme pour trier un tableau
d’entiers en enlevant les redondances
Interface : int[] mon_tri(int[] vec)
• Etape 5 : On compare le résultat obtenu avec le résultat
attendu (oracle)

Cas de test
[1,0,12,4,41,5] Données de test Script de test Résultat [1,0,12,4,41,5]
+
[0,1,4,5,12,41] Prédiction de l’oracle Comparaison
45
GLSI2 & SEIoT2
 5. Processus de test simplifié
• Tester ?: réaliser une exécution d’un programme pour y
trouver des défauts
• Exemple: soit un programme pour trier un tableau
d’entiers en enlevant les redondances
Interface : int[] mon_tri(int[] vec)
• Etape 6 : On rapporte le verdict final : Pass/Fail,
échec/succès

Cas de test
[1,0,12,4,41,5] Données de test Script de test Résultat [1,0,12,4,41,5]
+
[0,1,4,5,12,41] Prédiction de l’oracle Comparaison
46
GLSI2 & SEIoT2
 5. Processus de test simplifié :
Résumé

47
GLSI2 & SEIoT2
 Quiz 1/2
1. Lequel des éléments suivants n’est PAS considéré comme un objectif valide pour le test ?
a) Pour réduire le niveau de qualité logicielle inadéquate
b) Pour confirmer que le système fonctionne comme prévu
c) Pour trouver tous les défauts du système testé
d) Fournir suffisamment d'informations aux parties prenantes

2. Différenciez les termes de test suivants (1-4) en les associant aux bons exemples (A-D)
1. Erreur A. La banque est sanctionnée par le conseil de régulation bancaire
2. Défaut B. Le client se voit facturer plus d'intérêts sur ses comptes de prêt immobilier
3. Anomalie C. Le programme utilise le mauvais algorithme pour le calcul des intérêts du
prêt immobilier
4. Effet
D. L'analyste commercial a saisi la mauvaise formule pour le calcul du prêt
immobilier dans l'exigence
a) 1A, 2C, 3B, 4D
b) 1D, 2B, 3A, 4C
c) 1D, 2C, 3B, 4A
d) 1A, 2C, 3D, 4B
48
GLSI2 & SEIoT2
 Quiz 2/2
3. Lequel des éléments suivants est un exemple de défaillance du système de régulateur de
vitesse d'une voiture ?
a) Le développeur du système a oublié de renommer les variables après un copier-coller
b) Un code inutile qui déclenche une alarme lors de la marche arrière a été inclus dans
le système
c) Le système cesse de maintenir une vitesse définie lorsque le volume de la radio est
augmenté ou diminué
d) La spécification de conception du système indique à tort des vitesses en km/h

4. Laquelle des affirmations suivantes décrit correctement la différence entre le test et le

débogage ?
a) Le test identifie la source des défauts ; le débogage analyse les défauts et propose des
activités de prévention
b) Le test montre les défaillances causés par des défauts ; le débogage trouve, analyse et
supprime les causes des défaillances du logiciel
c) Le test supprime les défauts ; le débogage identifie les causes des défaillances
d) Le test prévient les causes des défaillances ; le débogage supprime les défaillances

49
GLSI2 & SEIoT2
 50
GLSI2 & SEIoT2