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
Avertissements/Contact
Violation de copyright / copyright infringement
‣ Si l’utilisation d’une ressource de cette présent...
Sommaire
Introduction : pourquoi tester ? et comment ?
Qu’est ce qu’un test ?
Test et processus de développement
Processus...
Introduction
Pourquoi tester ?
Et comment ?
4
Exercice
Soit le programme suivant :
‣ (E1) Lecture de trois entiers entrés par l’utilisateur sur la console
‣ (E2) Les tr...
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...
Contexte
Ces tests correspondent à des bogues réellement constatés
sur un programme réel (The Art of Software Testing, 2nd...
Quelques enseignements
Tester est une activité COMPLEXE
‣ Tester un programme même trivial n’est pas une tâche simple
Test...
Quelques enseignements
Test et référence
‣ Un test est défini par rapport à une référence attendus avec lequel on
compare l...
Erreur, défaut et défaillance
10
Erreur Défaut Défaillance
‣ Action humaine provoquant
l’introduction d’un défaut
dans le ...
Génèse du test logiciel
1945 à 15h45 : premier bogue
‣ Grace M. Hopper sur le calculateur Mark 1 à Harvard
Années 60 à 70 ...
Qu’est-ce qu’un test ?
12
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 ...
Qu’est-ce qu’un test ? (2)
14
Condition de test
‣ Un raisonnement général :
Que cherche-t-on à évaluer ? (raison, objectif...
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...
Qu’est-ce qu’un test ? (3)
16
Procédure de test
‣ Une réalisation pratique du cas de test
Automatique (scripts) ou manuell...
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...
Qu’est-ce qu’un test ? (5)
18
Outils et environnements de test
‣ Exécution
Machines dédiées au test, machines virtuelles
O...
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...
Autres aspects du test
Psychologiques
‣ Le but principal du test est de trouver des défauts et pas seulement de montrer
qu...
Principes de base du test
21
w
$

Indépendance
testeurs / développeurs
Résultats prouvés et
reproductibles
Effort confo...
Test et processus de
développement
Démarches de test
Niveaux de test
22
Test et développement (1)
Le test est une activité structurée
‣ Comme un sous-projet du projet développement
‣ Comme un pr...
Test et développement (2)
Le test est intimement lié au processus de
développement et à la qualité du logiciel
‣ Modèles s...
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érenc...
Démarche de validation
Objectifs
‣ “A-t-on fait le logiciel qu’attendent les clients / les utilisateurs ?”
‣ Les référence...
Démarche de non-régression
Objectif
‣ Évaluer la différence entre une version et une autre
‣ S’assurer qu’un aspect du log...
Démarche de confirmation (“retest”)
Objectif
‣ S’assurer qu’une correction de bogue a bien l’effet recherché
‣ Exemple : la...
Démarche de test de maintenance
Objectif
‣ S’assurer qu’une opération de maintenance a bien l’effet recherché
‣ Exemples d...
Tests unitaires (1)
30
Objectifs
‣ Détecter les défaillances d’un composant individuel de manière isolée des autres
Objets...
Tests unitaires (2)
31
Pré-conditions
‣ Composant disponible, compilé, exécutable dans l’environnement de test
‣ Référence...
Tests unitaires (3)
32
Conception et implémentation
‣ Isolation du composant : bouchons, préfabriqués (fixture), pilotes, s...
Tests d’intégration (1)
33
Objectifs
‣ Détecter les défaillances dans les échanges entre composants (test des interfaces)
...
Tests d’intégration (2)
34
Pré-conditions
‣ Composants disponibles, compilés et exécutables dans l’environnement de test
‣...
Tests d’intégration (3)
35
Conception et implémentation
‣ Intégration des composants dépendante de l’architecture du systè...
Tests système (1)
36
Objectifs
‣ Détecter les défaillances dans le logiciel dans son ensemble
‣ S’assurer qu’il correspond...
Tests système (2)
37
Pré-conditions
‣ Tous les composants sont intégrés
‣ Ils sont passé avec succès les tests d’intégrati...
Tests système (3)
38
Conception et implémentation
‣ Préparation des données
‣ Assertions sur les résultats
Testeurs
‣ En g...
Tests d’acceptation (1)
39
Objectifs
‣ Acceptation du logiciel par les clients/utilisateurs avant sa mise en production
‣ ...
Tests d’acceptation (2)
40
Pré-conditions
‣ Le logiciel a passé avec succès les tests système
Posts-conditions
‣ Couvertur...
Processus de test
Activités fondamentales
Gestion des tests
41
Métier du test
42
‣ Éditeurs de logiciel
Équipes dédiées : vérification,
validation, recette usine
Embarqué au sein d’équip...
Processus de test
Planification
Tester quoi et pourquoi
Analyse et conception
Comment tester ?
Implémentation
Comment teste...
Planification
Entrées
‣ Stratégie de test du projet, de l’organisation
‣ Exigences du logiciel
Activités
‣ Définir l’objecti...
Exemple : plan de test (1)
Stratégie
‣ Introduction
‣ Stratégie générale et risques
Définir la stratégie générale en relati...
Exemple : plan de test (2)
Moyens
‣ Ressources
Lister les ressources matérielles et logicielles nécessaires à la campagne ...
Exemple : plan de test (3)
Réalisation
‣ Processus de test
Définir le processus de test et les démarches utilisées
‣ Planni...
Suivi
Entrées
‣ Plan de test
‣ Retours du déroulement des autres activités
Activités
‣ Analyser les déviations / plan, ré-...
Analyse et conception
Entrées
‣ Plan de test
‣ Spécifications
Activités
‣ Analyser les spécifications, en déduire et hiérarc...
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
‣...
Exécution
Entrées
‣ Procédures de test
‣ Objets sous test sous sa forme exécutable
Activités
‣ Exécuter les tests, récupér...
Évaluation et reporting
Entrées
‣ Plan de test
‣ Fiches d’anomalie
‣ Rapports de résultats
‣ Cas et procédures de test
Act...
Activités de clôture
Entrées
‣ Tous les documents des phases précédentes
Activités
‣ Tirer les leçons et capitaliser les e...
Risques de l’activité de test (1)
Liés au projet
‣ Problèmes d’organisation
Ressources inadaptées aux besoins
Incapacité d...
Risques de l’activité de test (2)
Liés au produit
‣ Faible qualité des caractéristiques extra-fonctionnelles du logiciel
‣...
Zoologie des techniques
de conception de test
56
Zoologie des techniques de test
57
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonct...
Tests dynamiques
58
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonctionnel
Boite bl...
Tests statiques
59
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonctionnel
Boite bla...
Tests en boite noire
60
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonctionnel
Boit...
Tests fonctionnels
61
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonctionnel
Boite ...
Partitions équivalentes
Grouper les données d’entrées
‣ En classes disjointes devant fournir un comportement identique (va...
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...
Valeurs limites (2)
Valeurs limites
‣ Issues des spécifications et de la connaissance de l’environnement : OS, FS, ...
Cas ...
Tests extra-fonctionnels
65
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonctionnel
...
Tests basés sur l’expérience
66
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonction...
Tests en boite blanche (1)
67
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonctionne...
Couverture du flot de contrôle (1)
68
Couverture en instructions
‣ Toutes les instructions exécutées au moins une
fois = 10...
Couverture du flot de contrôle (2)
Couverture en instructions/décisions
(ou « branches »)
‣ Toutes les instructions sont ex...
Couverture du flot de contrôle (3)
A et
(B ou F(C))
Couverture en instructions/décisions
(ou « branches »)
‣ Problèmes :
Év...
Couverture du flot de contrôle (4)
A et
(B ou F(C))
Couverture en conditions (ou prédicats)
‣ Toutes les sous-expressions p...
Couverture du flot de contrôle (5)
Couverture en conditions (ou prédicats)
‣ Problèmes :
N’examine pas toutes les décisions...
Couverture du flot de contrôle (6)
73
D’autres critères existent
‣ Couverture MD/DC
Instructions/décisions/conditions + con...
Couverture du flot de données (1)
74
Circulation des données dans un programme
Action Signification Notation
Définition d’une...
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 ...
Analyse dynamique (1)
76
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonctionnel
Boi...
Analyse dynamique (2)
77
Recherche des problèmes de programmation
‣ Variables non initialisées
‣ Incohérences appels/défini...
Analyse dynamique (3)
78
Mesures de performances (profilage)
‣ Nombre d’appels
‣ Temps passé dans chaque fonction, dans les...
Revues
79
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonctionnel
Boite blanche
Boit...
Revues
80
Objectifs
‣ Trouver des défauts
‣ Acquérir/améliorer la compréhension du code
‣ Favoriser la collaboration
‣ Pre...
Revues de code
81
Méthodes
‣ Formelles : méthode Fagan (IBM , 1976), méthode Gilb-Graham, ...
‣ Utilisation de check-lists...
Analyse statique (1)
82
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonctionnel
Boit...
Analyse statique (2)
83
Vérification de règles
‣ Règles de codage
‣ Convention de nommage
‣ Règles d’architecture
Recherche...
Analyse statique (3)
84
Métriques sur les sources
‣ Volumétrie
lignes de code
taux de commentaire
‣ Couplage
couplage affé...
Tests «structurels»
85
Test Analyse
dynamique
Basé sur
l’expérience
Extra-fonctionnel
Dynamique
Statique
Fonctionnel
Boite...
Conclusion
86
Quelques mythes du test
87
‣ « En testant, on élimine tous les défauts »
‣ « Je suis un bon programmeur, tester mon code c...
Quelques référentiels
88
Références
89
Prochain SlideShare
Chargement dans…5
×

Ingénierie du test 0.9

4 311 vues

Publié le

Cours de génie logiciel n°3

Publié dans : Technologie
0 commentaire
12 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
4 311
Sur SlideShare
0
Issues des intégrations
0
Intégrations
14
Actions
Partages
0
Téléchargements
36
Commentaires
0
J’aime
12
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Ingénierie du test 0.9

  1. 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. 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. 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. 4. Introduction Pourquoi tester ? Et comment ? 4
  5. 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. 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. 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. 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. 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. 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. 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. 12. Qu’est-ce qu’un test ? 12
  13. 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. 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. 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. 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. 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. 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. 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. 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. 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. 22. Test et processus de développement Démarches de test Niveaux de test 22
  23. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 41. Processus de test Activités fondamentales Gestion des tests 41
  42. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 56. Zoologie des techniques de conception de test 56
  57. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 86. Conclusion 86
  87. 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. 88. Quelques référentiels 88
  89. 89. Références 89

×