Ce document traite de l'ingénierie du test logiciel, expliquant l'importance du test dans le développement de logiciels et les différentes techniques de test à adopter. Il présente des exercices pratiques relatifs aux tests de programmes, ainsi que des conseils sur les processus de développement et de validation. Enfin, il aborde les types, niveaux et démarches des tests, soulignant la complexité et la nécessité d'une approche structurée pour garantir la qualité des produits logiciels.

1. Ingénierie du test logiciel
I
Version 0.9 juillet 2013
Stéphane Salmons
g 6 )  N O Y4
1
Cours de génie logiciel
n°3

2. Avertissements/Contact
Violation de copyright / copyright infringement
‣ Si l’utilisation d’une ressource de cette présentation va a l’encontre de sa licence
d’utilisation, cela n’est pas intentionnel. Veuillez contacter l’auteur et la ressource
sera immédiatement retirée.
‣ If the use of a resource of this slideshow conflicts with its licence, this not intentional.
Please contact the author to have the resource immediately removed
Contact
‣ stephane.salmons@gmail.com
2

3. Sommaire
Introduction : pourquoi tester ? et comment ?
Qu’est ce qu’un test ?
Test et processus de développement
Processus de test
Zoologie des techniques de conception de test
Conclusion
3

4. Introduction
Pourquoi tester ?
Et comment ?
4

5. Exercice
Soit le programme suivant :
‣ (E1) Lecture de trois entiers entrés par l’utilisateur sur la console
‣ (E2) Les trois entiers représentent la longueur des cotés d’un triangle
‣ (E3) Le programme affiche si le triangle est :
(E3.1) scalène (cotés différents)
(E3.2) isocèle
ou (E3.3) équilatéral
5
Combien faut-il de tests pour tester correctement ce programme ?

6. Réponse
Id Description du test Entrées Résultat attendu Exigences testées
1 Triangle scalène valide (5,4,3) Scalène E1, E2, E3.1
2 Triangle isocèle valide (5,5,8) Isocèle E1, E2, E3.2
3 Triangle équilatéral valide (2,2,2) Equilatéral E1, E2, E3.3
4 Triangle isocèle : permutations des cotés égaux
(permutations du cas n°2)
(5,8,5)
(8,5,5)
Isocèle
Isocèle
E1, E2, E3.2
5 Triplet d’entiers contenant un zéro (1,2,0) Erreur: non triangle E1, E2
6 Triplet contenant un entier négatif (-1,2,2) Erreur: non triangle E1, E2
7 Triplet d’entiers positifs différents dont la somme
de deux des nombres est égale au troisième
(1,2,3) Erreur: non triangle E1, E2
8 Permutations du cas n°7 (1,3,2)
(3,2,1)
Erreur: non triangle
Erreur: non triangle
E1, E2
9 Triplet d’entiers positifs différents dont la somme
de deux des nombres est inférieure au troisième
(1,2,5) Erreur: non triangle E1, E2
10 Permutations du cas n°9 (1,5,2)
(5,1,2)
Erreur: non triangle
Erreur: non triangle
E1, E2
11 Triplet (0,0,0) (0,0,0) Erreur: non triangle E1, E2
12 Triplet contenant des valeurs non entières (1.2,1.8,3.2) Erreur: entrée illégale E1
13 Entrée de plus de trois valeurs (5,8,8,8) Erreur: entrée illégale E1
14 Entrée de moins de trois valeurs (5,8) Erreur: entrée illégale E1

7. Contexte
Ces tests correspondent à des bogues réellement constatés
sur un programme réel (The Art of Software Testing, 2nd Ed G. J. Meyers – Wiley)
‣ En moyenne, des programmeurs très expérimentés identifient 7.8 tests sur les 14
présentés
‣ On pourrait imaginer d’autres tests !
7

8. Quelques enseignements
Tester est une activité COMPLEXE
‣ Tester un programme même trivial n’est pas une tâche simple
Tester est une activité CRITIQUE
‣ Impossible de caractériser entièrement le comportement d’un logiciel
‣ Seul le test permet d’obtenir un certain niveau de confiance (hors preuve
formelle de programme)
‣ Arbitrage entre le coût de test et le niveau de confiance voulu
8
C’est le domaine de l’ingénierie des tests
Basili and Boehm, Software Defect Reduction Top 10 List,
IEEE - Computer Society, vol. 34, (1), Jan. 2001, pp. 135–137.

9. Quelques enseignements
Test et référence
‣ Un test est défini par rapport à une référence attendus avec lequel on
compare le résultat obtenu
Exemples de références : spécifications, exigences, des retours d’expériences, bonnes pratiques, ...
‣ Que doit faire le programme de l’exercice ...
dans le cas d’entrées illégales (violant l’exigence E1) ?
dans le cas de valeurs ne représentant pas un triangle (violant l’exigence E2) ?
Exemple de raffinement des exigences :
(E1.1) Lecture de 3 entiers entrés par l’utilisateur sur la console
(E1.2) Si plus ou moins de trois entrés, indiquer une entrée illégale et redemander
(E1.3) Si valeur une valeur ou plus est non entière, indiquer une entrée illégale et redemander
(E2.1) Les 3 entiers représentent la longueur des côtés d’un triangle
(E2.2) Si les 3 entiers ne représentent pas un triangle, indiquer que ce n’est pas un triangle et arrêter le programme
9
C’est le domaine de l’ingénierie des exigences

10. Erreur, défaut et défaillance
10
Erreur Défaut Défaillance
‣ Action humaine provoquant
l’introduction d’un défaut
dans le logiciel
Mauvaise compréhension du
besoin, déviation intentionnelle
des spécifications
Choix de structures de données
ou d’algorithme inadaptées
Non respect des standards de
codage
‣ Prévention
Formations, communication,
processus plus matures,
meilleures conditions de travail
‣ Imperfection présente dans le
logiciel (incluant sa doc)
Fonctionnalités oubliées (présentes
dans les spécifications)
Défauts de programmation (New
sans Delete)
Défauts de portabilité
‣ Détection
Directe par les tests en boite
blanche
Indirecte, par les défaillances
‣ Déviation observée du
comportement d’un système
par rapport à un
comportement requis
Résultat de l’exécution d’un
programme contenant un défaut
‣ Détection
Test en boite noire

11. Génèse du test logiciel
1945 à 15h45 : premier bogue
‣ Grace M. Hopper sur le calculateur Mark 1 à Harvard
Années 60 à 70 : “il faut montrer que ça marche
(test positif)”
‣ Vérification du “bon fonctionnement”
‣ Tests aux limites
‣ Recette informelle
Années 80 : “il faut trouver les défauts cachés
(test négatif)”
‣ Recherche des défauts
‣ Notions de couverture des tests
‣ Mesure de performance
‣ Recette moins informelle
‣ Vision du tests comme une activité à part entière du processus de
développement
Années 90 : “il faut manager la qualité”
‣ Détection des défauts au plus tôt
‣ Importance de la clarté des exigences
‣ Apparition de processus de tests donnant la
prépondérance aux tests
‣ Le test donne une image de la qualité du logiciel,
permettant des prises de décisions
‣ Recette formelle, par rapport à des exigences
11
Années 2000 “le test est un métier”
‣ Définition de normes/référentiels
‣ Certifications des métiers du tests

12. Qu’est-ce qu’un test ?
12

13. Qu’est-ce qu’un test ? (1)
‣ « Le test est l’exécution ou l’évaluation d’un système ou d’un
composant du système, par des moyens automatiques ou manuels
1. pour vérifier qu’il répond à ses spécifications, ou
2. pour identifier les différences entre les résultats attendus et les résultats
obtenus »
13
IEEE STD 729 - Standard glossary of software engineering
L’art et la manière de trouver
les bogues

14. Qu’est-ce qu’un test ? (2)
14
Condition de test
‣ Un raisonnement général :
Que cherche-t-on à évaluer ? (raison, objectif du test)
Que faut-il examiner pour cela ? (quel est l’objet sous test ?)
Par rapport à quoi ? (quelle est la référence ?)
Pourquoi

15. Qu’est-ce qu’un test ? (2)
15
Cas de test
‣ Une instance détaillée de la condition de test qui définit :
Les données d’entrées
Les préconditions (conditions préalables nécessaires au démarrage
du test)
Les postconditions (conditions assurées après l’exécution du test)
L’oracle, un processus fournissant les références et permettant de
prononcer le verdict du test
Le résultat attendu
‣ L’oracle est constitué
d’un Prédicteur qui fournit le résultat attendu
d’un Comparateur qui le compare avec le résultat obtenu
d’un Évaluateur qui délivre le verdict en déterminant si le résultat
de la comparaison est acceptable (OK) ou non (KO) (exemple :
notion de tolérance numérique)
Quoi

16. Qu’est-ce qu’un test ? (3)
16
Procédure de test
‣ Une réalisation pratique du cas de test
Automatique (scripts) ou manuelle (actions humaines)
‣ Séquence d’actions pour l’exécution du test
Récupération des données d’entrée
Constructions des préfabriqués (“fixtures”)
Exécution des opérations
Exécution de l’oracle
Récupération des verdicts
Nettoyage
Comment

17. Qu’est-ce qu’un test ? (4)
17
Verdict
‣ Réponse à une requête d’exécution d’un test
OK : réussite
KO : échec
NI : non implémenté
NE : non exécuté
Rapport d’exécution
‣ Journal des activités réalisées
‣ Preuves des résultats et des verdicts
Réponse
Preuve
Une série de tests exécutés selon la même démarche est une campagne
de test

18. Qu’est-ce qu’un test ? (5)
18
Outils et environnements de test
‣ Exécution
Machines dédiées au test, machines virtuelles
Outillage des objets sous test : émulateur
Framework de tests : CPPUNIT, GOOGLE TEST
Lanceur automatique : JENKINS, OLYMPE, ...
Outils d’analyse statique : CPPDEPEND, UNDERSTAND, CAST
Outils d’analyse dynamique : VALGRIND, GPROF, ELECTRIC FENCE, SQUISH COCO
‣ Conception
Gestionnaires de tests (conditions, cas, procédure) et d’exigences : CALIBER, ...
Gestionnaire de revues
Outils de modélisation
‣ Implémentation
Créateur automatique de test
Oracles, comparateurs
Avec quoi

19. Qu’est-ce qu’un test ? (6)
19
Harnais de test : ensemble de l’outillage autour de l’objet sous tests
Objet sous test
Récupérateur/
générateur de
données
Oracle
Préfabriqués
Bouchons
Générateur de rapport
Instrumentation

20. Autres aspects du test
Psychologiques
‣ Le but principal du test est de trouver des défauts et pas seulement de montrer
que “ça marche”
Exception : les tests d’acceptation
‣ Les développeurs ne sont pas les meilleurs testeurs !
Exception : les tests unitaires
‣ Les défauts sont générés par le processus de développement dans son ensemble
et non pas par tel ou tel individu
Contractuels
‣ Le test est utilisé pour accepter ou refuser des livrables
Réglementaires
‣ Le test est utilisé pour certifier des systèmes logiciels
20

21. Principes de base du test
21
w
$

Indépendance
testeurs / développeurs
Résultats prouvés et
reproductibles
Effort conforme aux risques
acceptés sur le projet
Harmonie avec le
développement
Tester au plus tôt et au plus
près des causes d’erreur
[
Y Automatisation

22. Test et processus de
développement
Démarches de test
Niveaux de test
22

23. Test et développement (1)
Le test est une activité structurée
‣ Comme un sous-projet du projet développement
‣ Comme un projet distinct du projet développement (mais synchronisé
avec lui)
‣ Ou de façon quasi-indissociable du développement
C’est une activité complexe qui s’articule autour de
plusieurs questions
‣ Pourquoi tester ?
‣ Tester quoi ? par rapport à quoi ?
‣ Tester à quel moment ?
‣ Qui teste ?
‣ De quoi a-t-on besoin pour tester ?
‣ Quel est le rapport coût / bénéfice de l’activité de test ?
23

24. Test et développement (2)
Le test est intimement lié au processus de
développement et à la qualité du logiciel
‣ Modèles séquentiels
Cascade : le test est une phase spécifique
Cycle en V : chaque phase de réalisation est associée à un niveau
de test
‣ Modèles itératifs
Chaque itération contient une activité de test
‣ Modèles incrémentaux :
Tous les incréments successifs sont testés
‣ Modèles agiles :
Le test continue est un moyen nécessaire pour atteindre l’agilité
Certaines méthodes font du test le moteur du développement
(TDD)
24
«Testing
must be an unavoidable
aspect of development, and the
marriage of development and testing
is where quality is achieved»
How google tests softwares

25. Démarche de vérification
Objectif
‣ A-t-on fait ce que l’on voulait faire ? Le logiciel est-il “bien fait” ?
‣ Les références sont les documents de conceptions, d’implémentation
‣ Concerne une version donnée
Niveaux de test
‣ Unitaire
‣ Intégration
Types de test
‣ Fonctionnels, extra-fonctionnels,
‣ Structurels statiques et dynamiques,
‣ Revues
‣ Preuves formelles

26. Démarche de validation
Objectifs
‣ “A-t-on fait le logiciel qu’attendent les clients / les utilisateurs ?”
‣ Les références sont les exigences fonctionnelles et les spécifications
‣ Concerne une version donnée
Niveaux de test
‣ En général, tests système
Types de test
‣ En général, tests fonctionnels
‣ Parfois structurels, rarement structurels

27. Démarche de non-régression
Objectif
‣ Évaluer la différence entre une version et une autre
‣ S’assurer qu’un aspect du logiciel (comportement, structure, architecture) n’a
pas changer
‣ Exemple : après la correction d’un bogue, s’assurer de l’absence d’impact sur le
reste du logiciel
Type de test
‣ Tous

28. Démarche de confirmation (“retest”)
Objectif
‣ S’assurer qu’une correction de bogue a bien l’effet recherché
‣ Exemple : la correction d’un bogue corrige-t-elle le bogue ?
Type de test
‣ Tous ceux qui ont mis le bogue en évidence

29. Démarche de test de maintenance
Objectif
‣ S’assurer qu’une opération de maintenance a bien l’effet recherché
‣ Exemples d’opération de maintenance
Evolution fonctionnelle
Corrections de défaillance («hot fix»)
Portage
Retrait du service (archivage ou migration de données)
‣ Combiner démarches de non-régression et de confirmation sur le système en
opération
Type de test
‣ Boite noire

30. Tests unitaires (1)
30
Objectifs
‣ Détecter les défaillances d’un composant individuel de manière isolée des autres
Objets sous test
‣ Selon la granularité du test :
fonction/méthode, classe, bibliothèque/module/package, programmes
mais pas le système entier
‣ Doit être testable (isolable)
Tests
‣ Tous types
Références
‣ Spécifications et document de conception détaillées du composant

31. Tests unitaires (2)
31
Pré-conditions
‣ Composant disponible, compilé, exécutable dans l’environnement de test
‣ Références disponibles et suffisamment stable
Post-conditions
‣ Défauts identifiés, tracés et priorisés
‣ Corrections vérifiées
‣ Impacts des défauts non corrigés évalués
‣ Couverture recherchée atteinte
‣ Traçabilité des résultats avec le référentiel assurée

32. Tests unitaires (3)
32
Conception et implémentation
‣ Isolation du composant : bouchons, préfabriqués (fixture), pilotes, simulateurs,
…
‣ Instrumentation du code du composant
‣ Préparation des données
‣ Assertions sur les résultats
‣ De nombreux frameworks facilitent la tâche (xunit, Boost, Google test, …)
Testeurs
‣ En général, les développeurs assure la conception, l’implémentation et
l’exécution sur une plateforme de développement
‣ S’appuient sur une infrastructure de tests automatiques

33. Tests d’intégration (1)
33
Objectifs
‣ Détecter les défaillances dans les échanges entre composants (test des interfaces)
Objets sous test
‣ Selon la granularité du test :
plusieurs composants : fonctions/méthodes/classes/modules/bibliothèque/packages/
programmes
un composant et son environnement : système de fichiers, autres systèmes, matériel, ...
mais pas le système entier
Tests
‣ Tous types
Référence
‣ Spécifications et document de conception générale ou d’architecture du système

34. Tests d’intégration (2)
34
Pré-conditions
‣ Composants disponibles, compilés et exécutables dans l’environnement de test
‣ Ils ont passé avec succès les tests unitaires
‣ Références sont disponibles et suffisamment stables
Posts-conditions
‣ Composants intégrés les un aux autres
‣ Défauts dans les interfaces et/ou les échanges identifiés, tracés et priorisés
‣ Corrections vérifiées
‣ Impacts des défauts non corrigés évalués
‣ Couverture recherchée atteinte
‣ Traçabilité des résultats avec le référentiel assurée

35. Tests d’intégration (3)
35
Conception et implémentation
‣ Intégration des composants dépendante de l’architecture du système
‣ Différentes méthodes d’intégration : bottom-up, top-down, tous les composants
simultanément
‣ Isolation parfois nécessaire (selon méthode d’intégration et granularité du composant)
‣ Préparation des données
‣ Assertions sur les résultats
Testeurs
‣ En général, les développeurs fournissent les composants aux testeurs qui
réalisent l’intégration
‣ Conçoivent, implémentent et exécutent les tests sur une plateforme d’intégration
‣ S’appuient sur une infrastructure d’intégration

36. Tests système (1)
36
Objectifs
‣ Détecter les défaillances dans le logiciel dans son ensemble
‣ S’assurer qu’il correspond aux exigences
Objets sous test
‣ Le logiciel entièrement intégré, installé et configuré
‣ Éventuellement ses échanges avec d’autres systèmes (test d’intégration système)
Tests
‣ En boite noire : fonctionnels, extra-fonctionnels, ...
Référentiel
‣ Spécifications et exigences du logiciel, Use Cases, normes

37. Tests système (2)
37
Pré-conditions
‣ Tous les composants sont intégrés
‣ Ils sont passé avec succès les tests d’intégration
Posts-conditions
‣ Défauts dans le système identifiés, tracés et priorisés
‣ Corrections vérifiées
‣ Impacts des défauts non corrigés évalués
‣ Couverture recherchée atteinte
‣ Traçabilité des résultats avec le référentiel assurée

38. Tests système (3)
38
Conception et implémentation
‣ Préparation des données
‣ Assertions sur les résultats
Testeurs
‣ En général, une équipe de testeurs assurent la conception, l’implémentation et
l’exécution sur une plateforme de production, ainsi que le reporting
‣ L’équipe de test système est parfois très indépendante de l’équipe de
développement
‣ S'appuient sur une infrastructure de production

39. Tests d’acceptation (1)
39
Objectifs
‣ Acceptation du logiciel par les clients/utilisateurs avant sa mise en production
‣ Acquérir la confiance dans la capacité opérationnelle du logiciel à répondre aux
besoins (la recherche des défaillances n’est pas l’objectif)
Objets sous test
‣ Le logiciel dans son ensemble, installé et configuré en situation «client»
‣ Éventuellement ses échanges avec d’autres systèmes (test d’intégration système)
Tests
‣ En boite noire : fonctionnels, extra-fonctionnels
Référentiel, selon le type d’acceptation
‣ Contractuelle : cahier des charges
‣ Opérationnelle : plan d’opération
‣ Réglementaire : normes, certification, ...

40. Tests d’acceptation (2)
40
Pré-conditions
‣ Le logiciel a passé avec succès les tests système
Posts-conditions
‣ Couverture recherchée atteinte
‣ Traçabilité des résultats avec le référentiel assurée
‣ Logiciel conforme au référentiel d’acceptation ou défauts dans le système
identifiés et tracés
Déroulement
‣ Conçus et implémentés par le client, ou par le fournisseur, ou encore une tierce-
partie (Tierce Recette Applicative) pour le compte du client
‣ Exécutés par le client, éventuellement aidés par des testeurs indépendants

41. Processus de test
Activités fondamentales
Gestion des tests
41

42. Métier du test
42
‣ Éditeurs de logiciel
Équipes dédiées : vérification,
validation, recette usine
Embarqué au sein d’équipes de
spécifications, de développement, de
conception
‣ Leurs clients
Équipe de recette
Utilisateurs bêta-testeur
‣ Prestataires de service de test
Tierce Recette Applicative (TRA)
Consulting en ingénierie des tests
‣ Organismes de certification
Équipe d’audit de certification
Manager
d’équipe
de test
Concepteur
de test
Testeur Automaticien
de test

43. Processus de test
Planification
Tester quoi et pourquoi
Analyse et conception
Comment tester ?
Implémentation
Comment tester ?
Exécution
Quelles sont les anomalies ?
Évaluation, reporting
et clôture Qu’en déduit-on ?
Exigences
Spécifications Stratégie
de test
Plan
de test
Cas de
test
Procédures
de test
Résultats
Enseigne-
ments
Suivi

44. Planification
Entrées
‣ Stratégie de test du projet, de l’organisation
‣ Exigences du logiciel
Activités
‣ Définir l’objectif général de la campagne de test en relation avec le niveau de
risque accepté et les moyens dédiés au test
‣ Définir le(s) critère(s) d’arrêt de la campagne
‣ Définir les objets sous tests
‣ Définir les tâches, les priorités, les ressources
‣ Estimer la charge et le délai de la campagne
Fournitures
‣ Plan de test
44
Manager
d’équipe
de test

45. Exemple : plan de test (1)
Stratégie
‣ Introduction
‣ Stratégie générale et risques
Définir la stratégie générale en relation avec les risques
Périmètre
‣ Objets sous test
Identifier tous les objets sous tests et leurs références documentaires
‣ Caractéristiques sous tests
Identifier les caractéristiques sous tests et spécifier les tests associés
‣ Caractéristiques non testées
Identifier les caractéristiques qui ne seront pas testées et préciser pourquoi
‣ Critères
Pour tous les objets sous tests définir les critères OK/KO
45

46. Exemple : plan de test (2)
Moyens
‣ Ressources
Lister les ressources matérielles et logicielles nécessaires à la campagne de test
‣ Équipe
Lister les rôles et responsabilités affectés à chaque tâches
Identifier les compétences particulières nécessaires, les besoins de formations éventuels
46

47. Exemple : plan de test (3)
Réalisation
‣ Processus de test
Définir le processus de test et les démarches utilisées
‣ Planning
Construire le planning de toutes les tâches de test : spécification, conception, exécution, ...
Indiquer les jalons et dates de livraison des livrables de test
Identifier les compétences particulières nécessaires et les besoins de formations
‣ Suspension
Critère pour la suspension et le redémarrage de la campagne de test
‣ Livrables
Définir les livrables du processus de test. Exemple : plan de test, spécifications de test, rapports
d’exécution
47

48. Suivi
Entrées
‣ Plan de test
‣ Retours du déroulement des autres activités
Activités
‣ Analyser les déviations / plan, ré-évaluer la stratégie de test
‣ Informer les parties prenantes
‣ Mettre en place les actions correctives
Fournitures
‣ Révisions du plan de test
‣ Plan(s) d’actions correctives
48
Manager
d’équipe
de test

49. Analyse et conception
Entrées
‣ Plan de test
‣ Spécifications
Activités
‣ Analyser les spécifications, en déduire et hiérarchiser les conditions
de tests : objectifs détaillées, objets sous tests, références
‣ Concevoir le cas de test : spécifier les préconditions, données de
tests, opérations à réaliser, oracle, résultat attendus, postconditions,
environnement de test, outillage
‣ Tracer le cas de test
Fourniture
‣ Cas de test
49
Concepteur
de test

50. Implémentation
Entrées
‣ Cas de test
‣ Spécifications de l’objet sous test, ou une maquette ou l’objet
lui-même
Activités
‣ Développer ou définir les procédures de test (automatiques ou
manuelles) : opérations et oracle
‣ Générer les données d’entrée ou implémenter leur récupération
‣ Implémenter ou installer l’environnement de test
‣ Vérifier le test (un test, ça se teste !)
Fourniture
‣ Procédures, données et environnement de test, opérationnels
50
Testeur
Automaticien
de test

51. Exécution
Entrées
‣ Procédures de test
‣ Objets sous test sous sa forme exécutable
Activités
‣ Exécuter les tests, récupérer les verdicts et résultats (preuves)
‣ Identifier les défauts/défaillances
‣ Enregistrer les défauts/défaillances (base d’anomalies), les résultats et tout
événement notable
Fourniture
‣ Fiches d’anomalie
‣ Rapport de tests
51
Testeur

52. Évaluation et reporting
Entrées
‣ Plan de test
‣ Fiches d’anomalie
‣ Rapports de résultats
‣ Cas et procédures de test
Activités
‣ Analyser les résultats
‣ Évaluer le(s) critère(s) d’arrêt : taux de couverture, délais, coût, nombre de
défauts, métriques, ...
‣ Rapporter aux parties prenantes
Fournitures
‣ Fournitures : dashboard de la campagne de test
52
Manager
d’équipe
de test

53. Activités de clôture
Entrées
‣ Tous les documents des phases précédentes
Activités
‣ Tirer les leçons et capitaliser les enseignements de la campagne
‣ Archiver tous ce qui a été produit (gestion de conf.)
Fournitures
‣ Le cas échéant, note sur les enseignements de la campagne
53
Manager
d’équipe
de test

54. Risques de l’activité de test (1)
Liés au projet
‣ Problèmes d’organisation
Ressources inadaptées aux besoins
Incapacité du projet à apprécier la valeur de l’activité de test («trouver des
défauts») et à tirer les bénéfices de ses résultats
‣ Problèmes techniques
Incapacité à définir des exigences compatibles avec les contraintes du projet
Environnement de test incomplet ou non opérationnel
Faible qualité de la documentation
‣ Défaillance fournisseur
54

55. Risques de l’activité de test (2)
Liés au produit
‣ Faible qualité des caractéristiques extra-fonctionnelles du logiciel
‣ Caractéristiques fonctionnelles du logiciel en désaccord avec ses exigences
fonctionnelles
‣ Faible qualité des données (accessibilité, intégrité, pb de standard, ...)
‣ Impact des défauts (de «négligeable» à «potentiellement mortel»)
55

56. Zoologie des techniques
de conception de test
56

57. Zoologie des techniques de test
57
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonctionnel
Boite blanche
Boite noire
Revue
Analyse statique

58. Tests dynamiques
58
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonctionnel
Boite blanche
Boite noire
Revue
Analyse statique
‣ Examine l’objet sous test lors de son exécution
‣ Précondition : disposer de l’objet sous test, fabriqué et
exécutable

59. Tests statiques
59
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonctionnel
Boite blanche
Boite noire
Revue
Analyse statique
‣ Examine l’objet sous test en tant que code source (ou
modèles, voire documentation) sans fabrication ni
exécution
‣ Précondition : disposer des sources, modèles ou docs

60. Tests en boite noire
60
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonctionnel
Boite blanche
Boite noire
Revue
Analyse statique
‣ Le test est réalisé par rapport à des spécifications
‣ Pas de «présupposés» structurel
‣ Techniques :
Partitions équivalentes
Valeurs limites
Transition d’état
Cas d’usage

61. Tests fonctionnels
61
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonctionnel
Boite blanche
Boite noire
Revue
Analyse statique
‣ Examine les services rendus (capacités fonctionnelles) :
aptitude
exactitude
interopérabilité
sécurité
conformité réglementaire
usage
‣ Met en évidence les défaillances
‣ Permet de mesure la couverture fonctionnelle (matrice
«exigences / verdicts»)
‣ Tests bien compris par les clients/utilisateurs

62. Partitions équivalentes
Grouper les données d’entrées
‣ En classes disjointes devant fournir un comportement identique (valide ou invalide)
selon les spécifications
‣ Décomposer en sous classes (arbre) et créer un cas de test pour chaque classe finale
Id Description du test Entrées Résultat attendu Exigences testées
1 Triangle scalène valide (5,4,3) Scalène E1, E2, E3.1
2 Triangle isocèle valide (5,5,8) Isocèle E1, E2, E3.2
3 Triangle équilatéral valide (2,2,2) Equilatéral E1, E2, E3.3
4 Triangle isocèle : permutations des cotés égaux
(permutations du cas n°2)
(5,8,5)
(8,5,5)
Isocèle
Isocèle E1, E2, E3.2
5 Triplet d’entiers contenant un zéro (1,2,0) Erreur: non triangle E1, E2
6 Triplet contenant un entier négatif (-1,2,2) Erreur: non triangle E1, E2
7 Triplet d’entiers positifs différents dont la somme
de deux des nombres est égale au troisième (1,2,3) Erreur: non triangle E1, E2
8 Permutations du cas n°7
(1,3,2)
(3,2,1)
Erreur: non triangle
Erreur: non triangle E1, E2
9 Triplet d’entiers positifs différents dont la somme
de deux des nombres est inférieure au troisième
(1,2,5) Erreur: non triangle E1, E2
10 Permutations du cas n°9 (1,5,2)
(5,1,2)
Erreur: non triangle
Erreur: non triangle E1, E2
11 Triplet (0,0,0) (0,0,0) Erreur: non triangle E1, E2
12 Triplet contenant des valeurs non entières (1.2,1.8,3.2) Erreur: entrée illégale E1
13 Entrée de plus de trois valeurs (5,8,8,8) Erreur: entrée illégale E1
14 Entrée de moins de trois valeurs (5,8) Erreur: entrée illégale E1
TriangleNontriangleIllégal
Classes d’équivalence

63. Id Description du test Entrées Résultat attendu Exigences testées
1 Triangle scalène valide (5,4,3) Scalène E1, E2, E3.1
2 Triangle isocèle valide (5,5,8) Isocèle E1, E2, E3.2
3 Triangle équilatéral valide (2,2,2) Equilatéral E1, E2, E3.3
4 Triangle isocèle : permutations des cotés égaux
(permutations du cas n°2)
(5,8,5)
(8,5,5)
Isocèle
Isocèle E1, E2, E3.2
5 Triplet d’entiers contenant un zéro (1,2,0) Erreur: non triangle E1, E2
6 Triplet contenant un entier négatif (-1,2,2) Erreur: non triangle E1, E2
7 Triplet d’entiers positifs différents dont la somme
de deux des nombres est égale au troisième (1,2,3) Erreur: non triangle E1, E2
8 Permutations du cas n°7
(1,3,2)
(3,2,1)
Erreur: non triangle
Erreur: non triangle E1, E2
9 Triplet d’entiers positifs différents dont la somme
de deux des nombres est inférieure au troisième
(1,2,5) Erreur: non triangle E1, E2
10 Permutations du cas n°9 (1,5,2)
(5,1,2)
Erreur: non triangle
Erreur: non triangle E1, E2
11 Triplet (0,0,0) (0,0,0) Erreur: non triangle E1, E2
12 Triplet contenant des valeurs non entières (1.2,1.8,3.2) Erreur: entrée illégale E1
13 Entrée de plus de trois valeurs (5,8,8,8) Erreur: entrée illégale E1
14 Entrée de moins de trois valeurs (5,8) Erreur: entrée illégale E1
Valeurs limites (1)
Choix de cas test aux valeurs limites des données pour
représenter les classe d’équivalence
Autres cas :
+ grand entier possible (OS
dépendant)

64. Valeurs limites (2)
Valeurs limites
‣ Issues des spécifications et de la connaissance de l’environnement : OS, FS, ...
Cas des flottants
‣ Zéro ? Précision (epsilon) de la limite ? Arrondis ?
‣ Peuvent être définis par l’application (finance, simulation) ou laissé à la définition
de l’OS

65. Tests extra-fonctionnels
65
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonctionnel
Boite blanche
Boite noire
Revue
Analyse statique
‣ Examine la façon dont les services sont rendus
(caractéristiques extra-fonctionnelles) :
fiabilité, robustesse (test de charge)
efficacité, performance, rendement
utilisabilité
maintenabilité
portabilité, installabilité
‣ Met en évidence les défaillances
‣ Permet de mesure la couverture extra-fonctionnelle
(matrice «exigences / verdicts»)
‣ Techniques : nombreuse selon la caractéristique testée
‣ Tests parfois «oubliés» car non associés aux fonctionnalités

66. Tests basés sur l’expérience
66
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonctionnel
Boite blanche
Boite noire
Revue
Analyse statique
‣ Examine la faç
‣ Techniques :
rob

67. Tests en boite blanche (1)
67
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonctionnel
Boite blanche
Boite noire
Revue
Analyse statique
‣ Examine le comportement de l’objet sous test en relation
avec sa structure
‣ Préconditions :
disposer des sources et des outils d’analyse
instrumentation, fabrication et exécution de l’objet sous
test dans l’environnement d’analyse
‣ Mets en évidences les défauts
‣ Techniques :
flot de contrôle (couverture structurelle = % du code
exercé par les tests)
flot de données

68. Couverture du flot de contrôle (1)
68
Couverture en instructions
‣ Toutes les instructions exécutées au moins une
fois = 100% de couverture
‣ Problèmes :
Toutes les branches ne sont pas testées (conditions)
Que faire avec les boucles ?
‣ Les instructions sont insuffisantes, il faut
considérer aussi les décisions
Test 1
100% des instructions sont couvertes

69. Couverture du flot de contrôle (2)
Couverture en instructions/décisions
(ou « branches »)
‣ Toutes les instructions sont exécutées au moins
une fois ET toutes les instructions conditionnelles
évaluées à vrai et à faux (généralisé pour les cases/
switch/elseif …) = 100% de couverture
Test 1
100% des branches (ou presque)
Test 2
vrai faux

70. Couverture du flot de contrôle (3)
A et
(B ou F(C))
Couverture en instructions/décisions
(ou « branches »)
‣ Problèmes :
Évaluation paresseuses : la façon dont la décision
est prise n’est pas examinée
Des conditions peuvent exister sans qu’il n’y ait de
branche
vrai faux
Test 1
A vrai
B vrai
Test 2
A faux
B faux
Toute les branches semblent couvertes, mais ce
n’est pas le cas : F(C) n’est jamais appeléebool a=(i>0)&&(j>0);
(i>0), (j>0) et (i>0)&&(j<0) sont
des conditions sans décision, donc sans
branche associée

71. Couverture du flot de contrôle (4)
A et
(B ou F(C))
Couverture en conditions (ou prédicats)
‣ Toutes les sous-expressions participant à l’élaboration d’une décision sont
évaluées à vrai et à faux = 100% de couverture
vrai faux
Test 1
A vrai
B vrai
F(C) vrai
Test 2
A faux
B faux
F(C) faux
Test 1 Test 2
A VRAI FAUX
B VRAI FAUX
F(C) VRAI FAUX
B ou F(C) VRAI FAUX
A et (B ou F(C)) VRAI FAUX
Toutes les conditions
sont exercées
Toutes les
décisions sont
exercées

72. Couverture du flot de contrôle (5)
Couverture en conditions (ou prédicats)
‣ Problèmes :
N’examine pas toutes les décisions
A et B
vrai faux
Test 1
A vrai
B faux
Test 2
A faux
B vrai
Test 1 Test 2
A VRAI FAUX
B FAUX VRAI
A et B FAUX FAUX
Toutes les conditions
sont exercées
Toutes les décisions
ne sont pas
exercées

73. Couverture du flot de contrôle (6)
73
D’autres critères existent
‣ Couverture MD/DC
Instructions/décisions/conditions + contrainte que chaque prédicat influence la décision
Utilisée (ainsi que ses variantes) pour la certification des systèmes avioniques
‣ Couverture en chemins
Chemin = ensemble de branches allant du début à la fin du programme
Les boucles sont considérées comme deux branches : zéro répétition, une répétition ou plus
Nombre de chemins ∼ exp(Nbranches), la couverture à 100% est très difficiles à atteindre
Voire impossible, car elle dépend des données
Outils de couverture du flot de contrôle
‣ SquishCoco (TestCocoon), Coverage
La couverture « ultime » de tous les chemins et valeurs de variables est inaccessible

74. Couverture du flot de données (1)
74
Circulation des données dans un programme
Action Signification Notation
Définition d’une donnée
Réservation de la mémoire et attribution d’une valeur.
Ex : int a = 10 ;
d
Utilisation dans un calcul
Présence à droite de l’opérateur d’affection.
Ex : b = 2 * a ;
cu
Utilisation dans un prédicat
Présence dans une instruction conditionnelle.
Ex : if ( a > 10 ) {…}
pu
Suppression de la donnée Libération de la mémoire. k
Première rencontre d’une donnée (dans un bloc de granularité spécifiée)Première rencontre d’une donnée (dans un bloc de granularité spécifiée) ~[…]
Dernière rencontre d’une donnée (dans un bloc de granularité spécifiée)Dernière rencontre d’une donnée (dans un bloc de granularité spécifiée) […]~

75. Couverture du flot de données (2)
75
Circulation des données dans un programme
Branche ~d ~u ~k dd du dk ud uu uk kd ku kk d~ u~ k~
Valide
Suspect
Invalide
X X X X X X X
X X X X X
X X X

76. Analyse dynamique (1)
76
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonctionnel
Boite blanche
Boite noire
Revue
Analyse statique
‣ Mesure/surveillance de l’objet sous test pendant son
exécution
‣ Réalisée avec des outils :
type compilateur (code instrumenté à la compilation)
type machine virtuelle (code instrumenté à l’exécution)
‣ Préconditions :
disposer des sources et des outils d’analyse
instrumentation, fabrication et exécution de l’objet sous
test dans l’environnement d’analyse
‣ Mets en évidences les défauts
‣ Techniques : surveillance des
fuites mémoires
pointeurs «pendants»
débordement de buffer, de tableau, etc.

77. Analyse dynamique (2)
77
Recherche des problèmes de programmation
‣ Variables non initialisées
‣ Incohérences appels/définitions
‣ Problèmes de logiques : boucle infinie, branche de condition morte, …
Analyse mémoire
‣ Fuites mémoire
‣ Violation de la mémoire (SEGFAULT)
‣ Audit de l’utilisation mémoire

78. Analyse dynamique (3)
78
Mesures de performances (profilage)
‣ Nombre d’appels
‣ Temps passé dans chaque fonction, dans les appels systèmes, dans les
bibliothèques externes
‣ Graphe d’appels
Exemples d’outils d’analyse dynamique
‣ Couverture : Squish Coco, Cobertura,
‣ Mémoire : Electric Fence, Valgrind
‣ Performance : gprof

79. Revues
79
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonctionnel
Boite blanche
Boite noire
Revue
Analyse statique
‣ Examen réalisée directement par des humains
‣ Objets sous revue: code source, modèles ou documents
(tout ce qui est écrit)

80. Revues
80
Objectifs
‣ Trouver des défauts
‣ Acquérir/améliorer la compréhension du code
‣ Favoriser la collaboration
‣ Prendre des décisions techniques consensuelles
Processus
‣ Différent niveau de formalisme :
Informel, discussions entre développeurs
Programmation en binôme, «Over the shoulder review»
Revue formelle (rôles spécifiques, planning, ...)
Inspection (revue formelle réalisée par une équipe externe)
‣ Importance du soutien du management au processus de revue
‣ Règles d’accès aux données, de communication des résultats

81. Revues de code
81
Méthodes
‣ Formelles : méthode Fagan (IBM , 1976), méthode Gilb-Graham, ...
‣ Utilisation de check-lists basées sur des règles de codage ou de conception et les
conventions de nommage
Efficacité
‣ Les revues de codes (particulièrement les inspections de code) sont les moyens
les plus efficaces de trouver les défauts
Chez IBM : 1h d’inspection de code équivaut à 20h de test pour trouver les défaut et 82h de
travail correctif une fois les défaillances apparues
(http://www.processimpact.com/articles/seven_truths.html)
Outils
‣ AGILE REVIEW, CODE STRIKER, RIETVELD, ...

82. Analyse statique (1)
82
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonctionnel
Boite blanche
Boite noire
Revue
Analyse statique
‣ Examen réalisée par un outil automatique
‣ Objet sous test : code source, modèles voire documents
‣ Met en évidence les défauts
‣ Fournit des indications pour évaluer le risque de défaut
(domaine de R&D)
‣ Techniques :
métriques de volumétrie
métriques de complexité, de cohésion
métriques orientées objet
graphe d’appel, métriques de couplage
vérification des règles de codage

83. Analyse statique (2)
83
Vérification de règles
‣ Règles de codage
‣ Convention de nommage
‣ Règles d’architecture
Recherche des problèmes de programmation
‣ Variables non initialisées
‣ Incohérences appels/définitions
‣ Problèmes de logiques : boucle infinie, branche de condition morte, …
‣ Fuites mémoires (par recherche des appariements : New/Delete, Malloc/Free,
Allocate/Deallocate)
‣ Capacité du code à tourner en multi-thread
‣ Code mort

84. Analyse statique (3)
84
Métriques sur les sources
‣ Volumétrie
lignes de code
taux de commentaire
‣ Couplage
couplage afférent, couplage
efférent,
indice de cohésion des méthodes
‣ Complexité
complexité cyclomatique de
McCabe
métrique d’Halstead
‣ Orientées objet
taux d’abstraction
taux d’héritage
Exemples d’outil d’analyse statique
‣ CppDepend, Understand, CAST, Sonar, Logiscope, LINT, …

85. Tests «structurels»
85
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonctionnel
Boite blanche
Boite noire
Revue
Analyse statique
‣ Techniques basées sur la structure
‣ Certains défauts sont détectables seulement par ces
techniques
‣ Le ratio «défauts détectés / coûts» est bien meilleur
qu’avec les tests en boîte noire

86. Conclusion
86

87. Quelques mythes du test
87
‣ « En testant, on élimine tous les défauts »
‣ « Je suis un bon programmeur, tester mon code c’est du temps perdu »
‣ « Plus on corrige de défauts, plus le logiciel est fiable »
‣ « Un testeur, c’est un programmeur raté »

88. Quelques référentiels
88

89. Références
89