Tests des logiciels

(Certification ISTQB)
Département Informatique

Taher LABIDI
Maître-assistant, Génie logiciel

© Taher LABIDI - taherlabidi@[Link]

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
Avant de commencer…
1. Mariner 1 - 1962 2. Ariane 5 - 1996
• Perte: La première sonde vers Perte: 37 sec après le décollage, la
fusée Ariane 501 (prototype de la
Venus qui s’est perdue dans l’espace version Ariane 5) fut détruite par une
• Cause: l'omission d'un trait d'union explosion
dans le code informatique Fortran Cause: un nombre à virgule flottante
originalement codé sur 64 bits a été
converti vers un entier signé à 16 bits

3
Avant de commencer…
3. Amazon AWS outage - 2017 4. 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 »

4
Objectif

Le cours vise à rendre l’étudiant capable de :

1. Acquérir le vocabulaire des normes et standards relatifs à

l'activité de Tests (ISO et IEEE)
2. Maîtriser l'ensemble des activités d'un processus de test
3. Connaître les différents niveaux et types de tests
4. Appréhender les techniques et méthodes de tests
5. Disposer d'une vue d'ensemble du métier de testeur

5
 Chapitre 1

Les fondamentaux du test

6
1. Définitions du test
❑ La plupart des gens ont eu une expérience avec un logiciel qui n'a pas
fonctionné comme prévu
❑ Un logiciel qui ne fonctionne pas correctement peut entraîner de nombreux
problèmes, y compris :
❑ La perte d'argent, de temps ou entacher la réputation de l'entreprise
❑ Des blessures qui peuvent être mortelles
❑ Les tests logiciels sont un moyen:
❑ d'évaluer la qualité du logiciel
❑ réduire le risque de défaillance de ce logiciel en cours de
fonctionnement
Test de logiciel ≠ Exécution du test
❑ Le processus de test comprend également des activités telles que la
planification des tests, l'analyse, la conception et la mise en œuvre des
tests, le suivi de la progression et des résultats des tests, ainsi que
l’évaluation de la qualité de l’objet de test
❑ L'exécution des tests n'est qu'une de ces activités
7
1. Définitions du test
• 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)
8
C’est quoi V&V?
• Vérification
Le développement est-il correct par rapport à la
spécification initiale ?
Est-ce que le logiciel fonctionne correctement?
• Validation
a-t-on décrit le « bon » système ?
est-ce que le logiciel fait ce que le client veut ?

9
Méthodes de V&V

• Test statique
examen ou analyse du texte
Revue de code, de spécifications, de documents de
design
• Test dynamique
Exécuter le code pour s’assurer d’un
fonctionnement correct
Exécution sur un sous-ensemble fini de données
possibles

10
Méthodes de V&V

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é

11
Méthodes de V&V

12
Importance du test
• Le test est une activité de V&V dominante et
cruciale dans le monde du logiciel:
Le poids de l’activité du test dans l’industrie du
logiciel aux USA s’élève à plusieurs dizaines de
milliards de dollars par an
En moyenne, le test représente 30% du coût de
développement d’un logiciel standard
Pour un logiciel critique (avionique, nucléaire,
médical, transport), cette part moyenne monte à 50
%

13
1.1. Les objectifs du test

14
1.1. Les objectifs du test
• 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 erreurs

• Le test n’a pas pour objectif de prouver la

correction d’un programme

• objectif irréaliste : 0 défaut

15
1.2. Test et débogage

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

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

16
1.2. Test et débogage

17
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

18
2.1. Contribution des tests au
succès
❑ La participation des testeurs à la revue des exigences ou au raffinement
des User Stories pourrait permettre de détecter des défauts dans ces
produits d’activités
❑ L'identification et l'élimination des défauts dans les exigences réduit le
risque de développement de fonctionnalités incorrectes ou non testables
❑ Le fait que les testeurs travaillent en étroite collaboration avec les
concepteurs du système pendant la conception du système peut aider
chaque partie à mieux comprendre la conception et la façon de la tester
❑ Cette meilleure compréhension peut réduire le risque de défauts de fond
dans la conception et permettre d'identifier les tests à un stade précoce

19
2.1. Contribution des tests au
succès
❑ Le fait que les testeurs travaillent en étroite collaboration avec les
développeurs pendant que le code est en cours de développement peut
augmenter la compréhension du code et de la façon de le tester par chaque
partie
❑ Cette meilleure compréhension peut réduire le risque de défauts dans le
code et les tests
❑ Le fait que les testeurs vérifient et valident le logiciel avant sa sortie
permet de détecter des défaillances qui auraient pu être manquées et aide
au processus d'élimination des défauts ayant causé les défaillances (c.-à-d.
le débogage)
❑ Cela augmente la probabilité que le logiciel répond aux besoins
des parties prenantes et satisfait les exigences

20
2.2. 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

21
2.3. 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
22
2.3. Erreurs, défauts et
défaillances

23
2.3. Erreurs, défauts et
défaillances

24
2.3. 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
25
2.4. 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

26
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
27
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)

28
3. Les 7 principes de Test
▪ Principe 2 : Les tests exhaustifs sont impossibles

29
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

30
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
31
3. Les 7 principes de Test
▪ Principe 5 : Usure des tests

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

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

32
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.
33
3. Les 7 principes de Test
▪ Principe 7 : L’illusion de l’absence de
défauts

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)

34
4. Activités et tâches de test et
Testware
L’activité 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
35
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

36
4. Activités et tâches de test et
Testware
❑ Pilotage et contrôle des tests

37
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

38
4. Activités et tâches de test et
Testware
❑ Analyse de test

39
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

40
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

41
4. Activités et tâches de test et
Testware

❑ Exécution des tests

42
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

43
4. Activités et tâches de test et
Testware

❑ Clôture des tests

44
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
45
4. Activités et tâches de test et
Testware
❑ Les produits d’activités du test

46
5. Rôles dans le test
Le test manager : le rôle de test manager axé sur les activités
de planification des tests, de pilotage et de contrôle des tests et
de clôture des tests (processus de test)
Le testeur: le rôle de testeur est axé sur les activités d'analyse
de test, de conception des tests, d'implémentation des tests et
d'exécution des tests (aspect technique)

47
6. Compétences essentielles et bonnes pratiques
en matière de test
• Compétences génériques requise pour le test: La curiosité,
esprit critique, souci du détail, esprit d'équipe, une bonne
communication, connaissances techniques, connaissance du
domaine.

• Approche équipe intégrée: Dans l'approche intégrée, tout

membre de l'équipe disposant des connaissances et des
compétences nécessaires peut effectuer n'importe quelle tâche,
et chacun est responsable de la qualité. Les membres de
l'équipe partagent le même espace de travail (physique ou
virtuel)

48
6. Compétences essentielles et bonnes pratiques
en matière de test
• Indépendance du test: Une indépendance est nécessaire pour
bien tester. Les produits d'activités peuvent être testés par :
- leur auteur (pas d'indépendance)
- les pairs de l'auteur appartenant à la même équipe (un peu
d'indépendance)
- des testeurs extérieurs à l'équipe de l'auteur mais au sein de
l'organisation (indépendance élevée)
- des personnes d'une organisation ou société différente
(indépendance très élevée)
49
7. 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.

50
7. 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

51
 7. 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]

52
 7. 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

53
 7. 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
54
 7. 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
55
 7. 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
56
Processus de test simplifié: Résumé

57
 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
58
 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

59