Université de Carthage | Faculté des Sciences de Bizerte

Tests Logiciels
Tarek Ben Mena
Préparation à la Certification
International Software Testing Qualifications Board
Profitez de cette offre

2K21 TBM 2
Quel pirate atteindra la carte au trésor ?

2K21 TBM 3
Aidez ce programme à fonctionner

?!!? Aucun résultat

Il devrait afficher 3

2K21 TBM 4
1ER EXEMPLE

2K21 TBM 5
Test vs Débogage
§ L'exécution de tests peut mettre en évidence des défaillances causées par des
défauts dans le logiciel.

§ Le débogage est l'activité de développement qui trouve, analyse et corrige de

tels défauts.

§ Par la suite, le test de confirmation vérifie si les corrections apportées ont résolu
les défauts.

§ Dans certains cas, les testeurs sont responsables du test initial et du test de
confirmation final,

2K21 TBM 6
Test Initial - Ça ne marche pas

2K21 TBM 7
Débogage

2K21
Fixer des Breakpoint TBM Lancer le débogage 8
Débogage

2K21 TBM 9
Débogage

2K21 TBM 10
Test de confirmation - Ça marche

2K21 TBM 11
CONCEPTS FONDAMENTAUX

2K21 TBM 12
Le Bug le plus cher de l’histoire

Cause : Un simple dépassement d’entier !

Composant : Système d’auto pilotage :
Accéléromètres et de gyroscopes (mesure
de mouvements)
Sauf que une variable qui calcule
l’accélération horizontale est codée sur 8
bits (256 valeurs).
Sur Ariane 4, cette valeur avait pour
maximum 64 (64 < 256),
Mais sur Ariane 5, (plus puissante), cette
variable peut atteindre 300 !
Le problème, 300 > 256 la variable est
Date : 4 Juin 1996 passée à 256, puis non pas à 257, mais à 0,
Objet : Fusée Ariane 5 c’est ce que l’on appelle le passage aux
pôles. Le calcul se basait alors sur la
Durée vol : 36,7 secondes variable d’accélération horizontale = 0 pour
Coût : 475 M€ ce moment du vol.
2K21 TBM 13
Meme

Quand je prends pas au

2K21
sérieux le cours
TBM
« Test Logiciel » 14
Logiciel : Définitions
§ «est défini comme une création intellectuelle rassemblant des
programmes, des procédures, des règles et de la documentation utilisé
pour faire fonctionner un système informatique »
ISO (International Organization for Standardization).

§ «Ensemble des programmes, procédés et règles, et éventuellement de la

documentation, relatifs au fonctionnement d'un ensemble de traitement
de données.»
Journal Officiel du 17 janvier 1986.

19/2K20 TBM 15
 Un Bon Logiciel
Caractéristiques qualité
Interne et Externe

Functionnality Usability Reliability Efficiency Serviceability Portability

(Fonctionnalité) (Facilité à l’emploi) (Fiabilité & sûreté) (Performances) Maintenability (Evolutivité)

Adéquation des Capacité et facilité Maturité Temps de réponse Capacité et facilité Capacité et facilité
fonctions de : et comportement de : de :
Tolérance aux dynamique • Analyser des • Adaptation et
Précision et fidélité • Compréhension pannes défaillances évolution
des résultats Utilisation des
• Apprentissage Remise en état de ressources : • Modification • Installation des
Interopérabilité marche après • Mémoire modifications
• Exploitation échec • CPU • Tests
Sécurité • Débit en (automaticité, • Remplacement
• Ergonomie IHM transactionnel non régression)
Conformité aux du point de vue • Cohabitation
exigences métier
fonctionnelles

2K21 TBM 16
Test : Définitions
§ «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 »
IEEE (Standard Glossary of Software Engineering Terminology).

§ «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).

19/2K20 TBM 17
Qu’est-ce qu’un test et quel est son coût ?
§ Expérience d’exécution pour mettre en évidence un défaut / erreur
− diagnostic: quel est le problème, l’erreur
− localisation: où est la cause du problème?
− Vérifier que le résultat de l’expérience est conforme aux intentions
§ Les tests à faire et résultats dépendent des spécifications

2K21 TBM 18
Coût des Tests

2K21 TBM 19
MODÈLE DE CYCLES DE VIE LOGICIEL

2K21 TBM 20
Une vraie situation

ISET Charguia
Cycle de vie Logiciel - Définition
§ Comme pour tout produit manufacturé complexe :
− La production est décomposé en « Activités de développement » ou « Phases »
− L’ensemble d’Activités constitue un « cycle de vie »
− Les Activités font apparaître des tâches clés

§ Activités de développement (Phases)

− Analyse des besoins : Pourquoi le Logiciel?
− Spécification : Quoi faire ?
− Conception : Comment le faire ?
− Codage et Intégration
− Tests : Vérification et validation
• Vérification : Développeur
• Validation : Client
− Déploiement & Maintenance

2018/19 TBM 22
Cycle de vie
§ 2 Catégories:
• Modèles de développement séquentiel
• Modèles de développement itératif et incrémental
1. Modèle de développement séquentiel
− Décrit le processus comme un flux linéaire (Phases successives).
− Il est bénéfique d'avoir un retour rapide de la phase suivante.
− Fournit des logiciels qui nécessitent généralement des mois ou des années pour être
livrés aux parties prenantes et aux utilisateurs.
2. Modèle de développement itératif et incrémental
− Décrit le processus comme une série de cycle d’activités (Phases par morceaux)
− Fournit un incrément plus grand à chaque itération (Itération = succession de phase)
− Fournit des parties de logiciels en quelques semaines mais ne peuvent livrer
l'ensemble des exigences que sur une période de mois ou d’années.

2K21 TBM 23
Cycle de vie
§ Modèle de développement séquentiel

Analyse de Besoins Conception Codage Tests

Logiciel

2K21 TBM 24
 Cycle de vie
§ Modèle de développement itératif et incrémental

Conception
Conception Conception

Itéra,on Codage
Itération Itération Codage Analyse
Analyse Codage Analyse
#3
#1 #2

Tests
Tests Tests

2K21 TBM 25
Cycle de vie séquentiel – Modèle en Cascade

Analyse Besoins
& Faisabilité

Spécification &
Planification

Conception
Globale

Conception
Détaillée

Codage &
Tests Unitaires

Intégration &
Tests intégration

Déploiement &
Maintenance

2K21 TBM 26
Cycle de vie séquentiel – Modèle en V
Analyse Besoins Tests
& Faisabilité d’acceptation

Spécification & Installation &

Planification Tests Système

Conception Intégration &

Globale Tests intégration

Conception
Tests Unitaires
Détaillée

Codage

2K21 TBM 27
Cycle de vie Spiral : itératif et incrémental
Analyse Besoins
Conception
& Faisabilité

V5 V4 V3 V2 V1

Tests Codage

2K21 TBM 28
Cycle de vie itératif et incrémental
Expression des Besoins

Spécification Fonctionnelle

Conception du Système
§ Exemple
− Unified Process (2 à 4 mois) Conception Conception Conception
− Scrum (1 à 4 sem) Incrément #1 Incrément #2 Incrément #3
− Prototypage (Expérimentale)
Codage Codage Codage
Incrément #1 Incrément #2 Incrément #3

Tests Tests Tests

Incrément #1 Incrément #2 Incrément #3
2K21 TBM 29
PRINCIPES ET TERMINOLOGIE

2K21 TBM 30
7 Principes de Tests
1. Les tests montrent la présence de défauts, pas leur absence
− Si aucun défaut n’est découvert, ce n’est pas une preuve que tout est correct
2. Les tests exhaustifs sont impossibles
− Tester toutes les combinaisons d’entrées et de préconditions n’est pas faisable
3. Tester tôt économise du temps et de l’argent « shift left »
− les activités de tests statiques e dynamiques doivent être lancées ASAP dans le CVL
4. Regroupement des défauts
− Loi Pareto (dans les tests logiciels) : 80% des défauts proviennent des 20% des modules
5. Paradoxe du pesticide
− Pour détecter de nouveaux défauts, il peut être nécessaire de modifier les tests existants et
les données de test existantes
6. Les tests dépendent du contexte
− Par exemple, un logiciel de contrôle industriel, critique au niveau de la sureté, sera testé
différemment d’une application de commerce électronique sur téléphone mobile
7. L’absence d’erreurs est une illusion
− Corriger un grand nombre de défauts ne garanti pas la réussite d’un système (Ariane 5 !).

2K21 TBM 31
Anomalies Logicielles
§ Chaîne de causalité

Erreur Défaut Anomalie

Erreurs humaines :
Différence entre
• Spécification Présence ou absence
comportement attendu
• Conception d’éléments dans le
et comportement
• Développement logiciel
observé
• Etc.

2K21 TBM 32
Problématique
§ But : détecter les défauts le plus tôt possible dans le cycle
− Tester une nouvelle méthode dès qu’on l’écrit
− Répéter les tests à chaque modification du code

§ Mais prouver l’absence d’erreur = problème indécidable

− On ne peut pas tester tout le temps ni tous les cas possibles
− Il faut des heuristiques réalistes
− Critères pour choisir les cas intéressants = Cas de Test (CT)

§ Test Driven Development (TDD)

− Écrire les Cas de Test (CT) avant le programme
− Développer la partie du programme qui fait passer les CT

2K21 TBM 33
Test : une peu de Vocabulaire

Données de Test (DT) : jeux de données d’entrée d’un programme

Cas de Test (CT) : scenario à exécuter

Suite de Tests : ensemble de CTs

2K21 TBM 34
Test : Vocabulaire - exemple
§ Spécification
− Gérer une liste de noms de restaurants par ordre de proximité́

§ Cas de Test (CT) :

− CT1 : Cas limites et valeurs spéciales
• DT : ajout dans une liste vide
− CT2 : Test des cas normaux
• DT : ajout dans une liste à 1 élément
• DT : retrait dans une liste à 2 éléments
− CT3 : est des cas anormaux
• DT : entrée invalide (non respect des pré-conditions)
• DT : retrait dans une liste vide

2K21 TBM 35
EST VOUS UN BON TESTEUR ?

2K21 TBM 36
Jeu : est vous un bon testeur ? – 5 min
§ Exemple
− Un programme prend 3 entiers en entrée, qui sont interprétés comme représentant
les longueurs des côtés d’un triangle. Le programme doit retourner un résultat
précisant s’il s’agit d’un triangle scalène, isocèle ou équilatéral.

− Ecrivez l’ensemble des cas test pour ce programme ?

2K21 TBM 37
Calculer votre score
§ Est ce que vous avez le(s) cas test où vous vérifiez :
1. Cas scalène valide(1, 2, 3 et 2, 5, 10 ne sont pas valides par ex.)
2. Cas équilatéral valide
3. Cas isocèle valide (remarque le cas 2, 2 , 4 n’est pas valide traité après)
4. Cas isocèle valide avec les 3 permutations sur l’ordre des entrées (par ex. 3,3,4 – 3,4,3
– 4,3,3)
5. Cas avec un coté avec une valeur nulle
6. Cas avec une valeur négative
7. Cas où les 3 cotés sont > 0 et la somme de deux entrées est égale à la troisième entrée
8. 3 cas pour le test 7 avec les trois permutations
9. Cas où la somme de deux entrées est inférieure à la troisième
10. 3 cas pour le test 9 avec les 3 permutations
11. Cas avec les 3 entrées nulles
12. Cas avec une entrée non entière
13. Cas avec un nombre erroné d’entrée (2 ou 4)
14. Pour chaque cas test, avez-vous défini le résultat attendu?

2K21 TBM 38
Positionner vous

“ Highly qualified professional programmers

score, on the average, only 7.8 out of a
possible 14.
If you’ve done better, congratulations !”
The Art Of Software Testing,
3rd Ed G. J. Myers, T. Badgett, C. Sandler

2K21 TBM 39
 Etat d’esprit des testeurs et des développeurs
§ Identifier les défauts peut être
perçu comme une critique du
produit et de ses auteurs.
§ Les développeurs attendent de
leur code qu'il soit correct, ils ont
un biais de confirmation pour
accepter qu'il est incorrect.
§ On blâme toujours le porteur de la
mauvaise nouvelle
§ le test est perçu comme une
activité destructrice
2K21
§ Les testeurs doivent avoir de
bonnes compétences
interpersonnelles pour bien
communiquer sur les défauts
§ Mettre l'accent sur les bénéfices
du test.
§ Communiquer les résultats des
tests sans critiquer la personne
qui a créé l’item défectueux.
§ Rédiger des rapports objectifs et
factuels sur les défauts et les
constats des revues.
§ Essayer de comprendre ce que
ressent l'autre personne
TBM 40
PROCESSUS DE TEST

2K21 TBM 41
 Processus de Test
§ Pas de processus unique mais ensemble d’activités de test à faire pour atteindre
l’objectif.
§ Ce processus peut être influencé par des facteurs contextuels
CVL Risques du projets EXEMPLE Outsider
Modèle V
Domaine
Types de Tests d’activité Gestion
Processus Test e2e de Stock
Processus
Activité Test #1
Planifica8on Test

Activité Test #2
Analyse Test

Activité Test #3
Conception Test

Politiques & Pratiques Contraintes :

• Budgets Feedback Contraintes :
Organisationnelle
• Délai Comité de pilotage • 20M
Normes de qualité • Complexité • 3 mois
• Contrat ISO/IEC/IEEE 29119-2 • medium
2K21 TBM • 3 livrables
42
Processus de Test Simplifié
§ Exemple : Trier un ensemble de données en supprimant les doublons
− Interface : int[] montri(int[] tab)
§ Etape 1 : Définir un Cas test (CT) à exécuter, (un “scénario” à appliquer)
− tableau de N entiers non redondants
§ Etape 2 : Concrétiser le CT en lui fournissant des Données de Test (DT)
− DT : Le tableau [1,0,12,4,43,5,21]
§ Etape 3 : Indiquer le résultat attendu pour ce CT (prédiction de l’Oracle)
− DT : [1,0,12,4,43,5,21] Oracle : [0,1,4,5,12,21,43]
§ Etape 4 : Exécuter le script de test testant le CT sur les DT
− DT : [1,0,12,4,43,5,21] Résultat : [0,1,4,5,12,21,43]
− Oracle : [0,1,4,5,12,21,43]
§ Etape 5 : Compare le Résultat obtenu à la prédiction de l’Oracle (verdict)
− Oracle Résultat
§ Etape 6 : Rapporter le résultat : = succès | ≠ échec
2K21 TBM 43
Processus de test- Activités

Planification des Tests

Pilotage et contrôle des Tests

Analyse de Test

Conception des tests

Implémentation des Tests

Exécutions des Tests

Clôture des Tests

2K21 TBM 44
Processus de test- Activités
Planification des Tests
Pilotage et contrôle des Tests
Analyse de Test
Conception des tests
Implémentation des Tests
Exécutions des Tests
Clôture des Tests
2K21
Planification des Tests
• Définir les objectifs du test
• Retenir une approche pour atteindre les
objectifs (respect des contraintes)
• Spécifier les techniques et tâches de
test appropriées,
• Produire un calendrier de test pour
respecter une date limite).
• Revoir les plans de test en fonction des
retours sur les activités de pilotage et de
contrôle
TBM 45
Processus de test- Activités
Planification des Tests
Pilotage et contrôle des Tests
Analyse de Test
Conception des tests
Implémentation des Tests
Exécutions des Tests
Clôture des Tests
2K21
Pilotage et contrôle des Tests
• Comparer régulièrement l’avancement réel p/p
au plan (métriques)
• Prendre les mesures nécessaires pour
satisfaire les objectifs du plan de test
• Evaluer les critères de sortie (dod):
• Vérifier les résultats (R) et logs (L) des
tests (p/p critères de couverture)
• Évaluer niveau de qualité des composants
(selon L et R)
• Identifier et Ecrire d'autres tests (ex.
niveau de couverture des risques Produit
non atteint)
• Communiquer aux parties prenantes les écarts
par rapport au plan et les informations utiles à
toute décision d’arrêter les tests.
TBM 46
Processus de test- Activités
Planification des Tests
Pilotage et contrôle des Tests
Analyse de Test
Conception des tests
Implémentation des Tests
Exécutions des Tests
Clôture des Tests
2K21
Analyse de Test – « Quoi tester ?»
• Déterminer « Quoi tester" en termes de critères
de couverture mesurables.
• Analyser les bases de test :
• les exigences fonctionnelles (Use cases), la
conception (Diagrammes UML),
L’implémentation (code, requêtes BD) , Les
rapports de risques
• Evaluer les bases de test pour identifier des
défauts :
• Ambiguïtés, Omissions, Incohérences, Bruit
• Identifier les caractéristiques à tester
• Définir et prioriser les conditions de test pour
chaque caractéristique
• Capturer la traçabilité bidirectionnelle entre
chaque élément des bases de test et les
conditions de test associées
TBM 47
Processus de test- Activités
Planification des Tests
Pilotage et contrôle des Tests
Analyse de Test
Conception des tests
Implémentation des Tests
Exécutions des Tests
Clôture des Tests
2K21
Conception des Tests – « How test ? »
• Décliner les conditions de test en cas de test
de haut niveau.
• Concevoir et prioriser les cas de test et les
ensembles de cas de test (Suites)
• Identifier les données de test nécessaires pour
les conditions de test et les cas de test
• Identifier l'infrastructure et les outils
nécessaires
• Etablir la traçabilité bidirectionnelle entre les
bases de test, les conditions de test, les cas de
test et les procédures de test
TBM 48
Processus de test- Activités
Planification des Tests
Pilotage et contrôle des Tests
Analyse de Test
Conception des tests
Implémentation des Tests
Exécutions des Tests
Clôture des Tests
2K21
Implémentation des Tests
• Développer et prioriser les procédures de test
(PT) créer des scripts de test (ST) automatisés
• Créer des suites de tests à partir PT et ST
• Positionner les suites de tests dans un
calendrier d'exécution des tests
• Construire l'environnement de test (les harnais
de test, la virtualisation des services, les
simulateurs et d'autres éléments
d'infrastructure)
• Préparer les données de test et les chargées
dans l'environnement de test
• Vérifier et mettre à jour la traçabilité
bidirectionnelle entre les bases de test, les
conditions de test, les cas de test, les
procédures de test et les suites de tests
TBM 49
Processus de test- Activités
Planification des Tests
Pilotage et contrôle des Tests
Analyse de Test
Conception des tests
Implémentation des Tests
Exécutions des Tests
Clôture des Tests
2K21
Exécution des Tests
• Exécuter les suites de tests conformément au
calendrier d'exécution des tests.
• Enregistrer les versions des éléments de test,
des outils de test et des Testware
• Exécuter les tests manuellement / avec outils
• Comparer les résultats obtenus avec les
résultats attendus
• Analyser les anomalies identifier leurs causes
• Signaler les défauts sur la base des défaillances
• Enregistrer les résultats (ok, échec, blocage)
• Répéter certaines activités de test : exécution
d'un test corrigé, et/ou test de régression)
• Vérifier et mettre à jour la traçabilité
bidirectionnelle entre les bases de test, les
conditions de test, les cas de test, les
procédures de test et les résultats des tests
TBM 50
Processus de test- Activités
Planification des Tests
Pilotage et contrôle des Tests
Analyse de Test
Conception des tests
Implémentation des Tests
Exécutions des Tests
Clôture des Tests
2K21
Clôture des Tests
• Collecter les données des activités de test
terminées afin de consolider l'expérience,
• Vérifier si tous les rapports de défauts sont
clôturés,
• Saisir des demandes de modification pour tous
les défauts non résolus
• Créer un rapport de synthèse de test le
communiquer
• Finaliser et archiver l’environnement de test, les
données de test, et autres Testware pour une
réutilisation ultérieure
• Analyser le retour sur expérience afin de
déterminer les changements nécessaires pour
les itérations, versions et projets futurs
TBM 51
Produits d’Activité

Planification des Tests Objectifs du test Techniques Plans de test

Pilotage et contrôle des Tests

Analyse de Test Bases de test Caractéristiques Conditions de test

Conception des tests Cas de test Données de test + Outils

Procédures Scripts Suites Environnement

Implémentation des Tests de test + de test de Tests de test

Exécutions des Tests Résultats = Rapports + Log

Clôture des Tests Rapport de synthèse

2K21 TBM 52
Produits d’Activité
Bases de test Scénarios de Test
ST1: Vérifiez si l’admin peut
ajouter un nouveau
ST2: Validez si un pays existant
peut être supprimé par l'admin
ST3: Validez si un pays existant
peut être mis à jour
Cas de test Données de test
2K21 TBM
Conditions de test du Scénario ST1
TCd1.1: Entrez le nom du pays valide et vérifiez
l'ajout du pays
TCd1.2: Entrez un espace et vérifiez si le pays est
ajouté.
TCd1.x: Dans chaque cas, les données spécifiques
sont décrites et le but du test est plus précis.
Outils
53
Exemple d’un Template de Test Case
Project Name: <Name>
Test Case
Test Case ID: TC_Fun_10 Test Designed by: <Name>
Module Name: Manage Countries Test Designed date: <Date>
Requirements : REQ_Fun_10 Test Executed by: <Name>
Test Title: Verify add country with valid data Test Execution date: <Date>
Description: Test Admin add country Test Priority (Low/Medium/High): Med

Pre-conditions: Admin is logged

Dependencies:
Step Test Steps Test Data Expected Result Actual Result Status Notes
(Pass/Fail)
1 Navigate to Countries Page Manage User is navigated to
Url = https://site/country/add Pass
page Country loaded page with successful
2 Provide valid Country
Name = Tunisia
name
Provide valid country
3 Area = 163 610
area
4 Click on Add button

2K21
Post-conditions : a Country is added to the DB TBM 54
Autre Exemple d’une fiche de cas de test

19/2K20 TBM 55
Glossaire
Base de test : L'ensemble des connaissances utilisées comme base pour
l'analyse et la conception des tests.
Analyse

Condition de test : Un aspect des bases de test qui est pertinent pour
atteindre des objectifs de test spécifiques. (Situation de test)
Implémentation Conception

Cas de test : Un ensemble de conditions préalables, de données d'entrée,

d'actions (le cas échéant), de résultats attendus et de post-conditions,
élaboré sur la base des conditions de test. (Scénario)

Procédure de test : Une séquence de cas de test dans l'ordre d'exécution, et

toutes les actions associées qui peuvent être nécessaires pour mettre en
place les préconditions initiales et toutes les activités de bouclage après
l'exécution.
2K21 TBM 56