Ingénierie du test 0.9

Ingénierie du test logiciel

I

Version 0.9 juillet 2013

Stéphane Salmons

g 6 ) N O Y41

Cours de génie logiciel n°3

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‣ [email protected]

2

Sommaire

Introduction : pourquoi tester ? et comment ?Qu’est ce qu’un test ?Test et processus de développementProcessus de testZoologie des techniques de conception de testConclusion

3

IntroductionPourquoi tester ?

Et comment ?

4

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 ?

RéponseId 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èleIsocè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 triangleErreur: 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)


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

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

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 testsBasili and Boehm, Software Defect Reduction Top 10 List, IEEE - Computer Society, vol. 34, (1), Jan. 2001, pp. 135–137.

Quelques enseignementsTest et référence ‣ Un test est défini par rapport à une référence attendus avec lequel on

compare le résultat obtenuExemples 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

9C’est le domaine de l’ingénierie des exigences

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écificationsChoix de structures de données ou d’algorithme inadaptéesNon respect des standards de codage

‣ PréventionFormations, 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 blancheIndirecte, 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étectionTest en boite noire

Génèse du test logiciel1945 à 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

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 moyens automatiques ou manuels1. 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

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

Cas de test‣ Une instance détaillée de la condition de test qui définit :

Les données d’entréesLes 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 testLe résultat attendu

‣ L’oracle est constituéd’un Prédicteur qui fournit le résultat attendud’un Comparateur qui le compare avec le résultat obtenud’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

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éeConstructions des préfabriqués (“fixtures”)Exécution des opérationsExécution de l’oracleRécupération des verdictsNettoyage

Comment


17

Verdict‣ Réponse à une requête d’exécution d’un test

OK : réussiteKO : échecNI : 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

Outils et environnements de test‣ Exécution

Machines dédiées au test, machines virtuellesOutillage des objets sous test : émulateurFramework de tests : CPPUNIT, GOOGLE TESTLanceur automatique : JENKINS, OLYMPE, ...Outils d’analyse statique : CPPDEPEND, UNDERSTAND, CASTOutils d’analyse dynamique : VALGRIND, GPROF, ELECTRIC FENCE, SQUISH COCO

‣ ConceptionGestionnaires de tests (conditions, cas, procédure) et d’exigences : CALIBER, ...Gestionnaire de revuesOutils de modélisation

‣ ImplémentationCréateur automatique de testOracles, comparateurs

Avec quoi


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ésBouchons

Générateur de rapport

Instrumentation

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

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

Test et processus de développement

Démarches de testNiveaux 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 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

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ératifsChaque 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

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

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

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

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

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 fonctionnelleCorrections de défaillance («hot fix»)PortageRetrait 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

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, programmesmais 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

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

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

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/programmesun 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

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

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

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

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

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

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

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ésDé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

Processus de testActivités fondamentales

Gestion des tests

41

Métier du test

42

‣ Éditeurs de logiciel Équipes dédiées : vérification, validation, recette usineEmbarqué au sein d’équipes de spécifications, de développement, de conception

‣ Leurs clients Équipe de recetteUtilisateurs bêta-testeur

‣ Prestataires de service de testTierce 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

Processus de testPlanification

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 ?

ExigencesSpécifications Stratégie

de test

Plan de test

Cas de test

Procédures de test

Résultats

Enseigne-ments

Suivi

PlanificationEntré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


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éesIdentifier les caractéristiques qui ne seront pas testées et préciser pourquoi

‣ CritèresPour tous les objets sous tests définir les critères OK/KO

45

Exemple : plan de test (2)Moyens‣ Ressources

Lister les ressources matérielles et logicielles nécessaires à la campagne de test

‣ ÉquipeLister les rôles et responsabilités affectés à chaque tâchesIdentifier les compétences particulières nécessaires, les besoins de formations éventuels

46

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 testIdentifier les compétences particulières nécessaires et les besoins de formations

‣ SuspensionCritè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

SuiviEntré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


Analyse et conceptionEntré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

ImplémentationEntré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

ExécutionEntré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

Évaluation et reportingEntré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


Activités de clôtureEntré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


Risques de l’activité de test (1)Liés au projet‣ Problèmes d’organisation

Ressources inadaptées aux besoinsIncapacité 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 techniquesIncapacité à définir des exigences compatibles avec les contraintes du projetEnvironnement de test incomplet ou non opérationnelFaible qualité de la documentation

‣ Défaillance fournisseur

54

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

Zoologie des techniques de conception de test

56

Zoologie des techniques de test

57

Test Analyse dynamique

Basé sur l’expérience

Extra-fonctionnelDynamique

Statique

Fonctionnel

Boite blanche

Boite noire

Revue

Analyse statique

Tests dynamiques

58




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

Tests statiques

59




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

Tests en boite noire

60




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 équivalentesValeurs limitesTransition d’étatCas d’usage

Tests fonctionnels

61




Statique

Fonctionnel

Boite blanche

Boite noire

Revue

Analyse statique

‣ Examine les services rendus (capacités fonctionnelles) :aptitudeexactitudeinteropérabilitésécuritéconformité réglementaireusage

‣ Met en évidence les défaillances‣ Permet de mesure la couverture fonctionnelle (matrice

«exigences / verdicts»)‣ Tests bien compris par les clients/utilisateurs

Partitions équivalentesGrouper 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ées1 Triangle scalène valide (5,4,3) Scalène E1, E2, E3.12 Triangle isocèle valide (5,5,8) Isocèle E1, E2, E3.23 Triangle équilatéral valide (2,2,2) Equilatéral E1, E2, E3.3


(5,8,5)(8,5,5)


5 Triplet d’entiers contenant un zéro (1,2,0) Erreur: non triangle E1, E26 Triplet contenant un entier négatif (-1,2,2) Erreur: non triangle E1, E2







11 Triplet (0,0,0) (0,0,0) Erreur: non triangle E1, E212 Triplet contenant des valeurs non entières (1.2,1.8,3.2) Erreur: entrée illégale E113 Entrée de plus de trois valeurs (5,8,8,8) Erreur: entrée illégale E1


Trian

gleNo

n tria

ngle

Illéga

l

Classes d’équivalence

Id Description du test Entrées Résultat attendu Exigences testées1 Triangle scalène valide (5,4,3) Scalène E1, E2, E3.12 Triangle isocèle valide (5,5,8) Isocèle E1, E2, E3.23 Triangle équilatéral valide (2,2,2) Equilatéral E1, E2, E3.3


(5,8,5)(8,5,5)


5 Triplet d’entiers contenant un zéro (1,2,0) Erreur: non triangle E1, E26 Triplet contenant un entier négatif (-1,2,2) Erreur: non triangle E1, E2







11 Triplet (0,0,0) (0,0,0) Erreur: non triangle E1, E212 Triplet contenant des valeurs non entières (1.2,1.8,3.2) Erreur: entrée illégale E113 Entrée de plus de trois valeurs (5,8,8,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)

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

Tests extra-fonctionnels

65




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, rendementutilisabilité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

Tests basés sur l’expérience

66




Statique

Fonctionnel

Boite blanche

Boite noire

Revue

Analyse statique

‣ Examine la faç‣ Techniques :

rob

Tests en boite blanche (1)

67




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’analyseinstrumentation, 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

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

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


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éeDes conditions peuvent exister sans qu’il n’y ait de branche

vrai faux

Test 1A vraiB vrai

Test 2A fauxB 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


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 1A vraiB vraiF(C) vrai

Test 2A fauxB fauxF(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

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 1A vraiB faux

Test 2A fauxB 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

D’autres critères existent‣ Couverture MD/DC

Instructions/décisions/conditions + contrainte que chaque prédicat influence la décisionUtilisée (ainsi que ses variantes) pour la certification des systèmes avioniques

‣ Couverture en cheminsChemin = ensemble de branches allant du début à la fin du programmeLes boucles sont considérées comme deux branches : zéro répétition, une répétition ou plusNombre de chemins ～ exp(Nbranches), la couverture à 100% est très difficiles à atteindre

Voire impossible, car elle dépend des donnéesOutils de couverture du flot de contrôle‣ SquishCoco (TestCocoon), Coverage

La couverture « ultime » de tous les chemins et valeurs de variables est inaccessible

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) […]~

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

Analyse dynamique (1)

76




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’analyseinstrumentation, 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émoirespointeurs «pendants»débordement de buffer, de tableau, etc.


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

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

Revues

79




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)

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éveloppeursProgrammation 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

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 nommageEfficacité‣ Les revues de codes (particulièrement les inspections de code) sont les moyens

les plus efficaces de trouver les défautsChez 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, ...

Analyse statique (1)

82




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étriemétriques de complexité, de cohésionmétriques orientées objetgraphe d’appel, métriques de couplagevérification des règles de codage


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

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 McCabemétrique d’Halstead

‣ Orientées objet taux d’abstractiontaux d’héritage

Exemples d’outil d’analyse statique‣ CppDepend, Understand, CAST, Sonar, Logiscope, LINT, …

Tests «structurels»

85




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

Conclusion

86

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é »

Quelques référentiels

88

Références

89

Technology

Ingénierie du test 0.9