1 les tests des logiciels introduction. 2 importance •les « bogues » : des conséquences parfois...
TRANSCRIPT
1
Les tests des logiciels
Introduction
2
Importance
• Les « bogues » : des conséquences parfois mortelles, parfois gênantes et très coûteuses
• 50 à 60 % du coût total du projet d’un logiciel (hors maintenance)
• De nouvelles méthodes, de nouveaux outils, un nouveau métier …
3
Définitions
• L’assurance qualité :– ensemble des dispositions qui vont être prises tout au
long des différentes phases de fabrication d’un logiciel pour accroître les chances d’obtenir en final un logiciel qui corresponde aux objectifs d’utilité désirés et fixés.
• Les activités de tests sont un sous-ensemble des activités de l’assurance qualité.
• Les activités de tests appartiennent au processus de développement.
4
Définitions
• Erreur – est commise par une ressource participant à la
création du logiciel.
• Défaut (faute) – est en quelque sorte le résultat d’une erreur.
• Anomalie (défaillance).– est un comportement observé différent du
comportement attendu (ou spécifié).
Une erreur génère un défaut qui génère une anomalie
5
Une typologie de défauts (1)
• Calcul : mauvais calcul• Logique : mauvaise expression d’un prédicat• Entrée / sortie : mauvaise communication avec
l’extérieur– mauvaise description, une mauvaise conversion ou un
formatage adéquat
• Traitement de données– Mauvais(e) accès (manipulation) aux (de) données.
• Exemple : mauvaise utilisation de pointeur, variable non définie, débordement d’indice, etc.
6
Une typologie de défauts (2)
• Interface– Mauvaise communication entre les constituants
internes du logiciel.• Exemple : appel de la procédure P1 au lieu de P2.
• Définition des données• Exemple : la donnée est définie comme un entier au
lieu d’un réel ; en simple précision au lieu d’être en double, etc.
7
Définition de l’activité de tests (1)
• Le test est l’exécution ou l’évaluation d’un système ou d’un composant, par des moyens automatiques ou manuels, pour vérifier qu’il répond à ses spécifications ou identifier les différences entre les résultats attendus et les résultats obtenus. (IEEE)
8
Définition de l’activité de tests (2)
• Tester, c’est exécuter le programme dans l’intention de trouver des erreurs (G.J. Myers).
• Le test est une technique de contrôle consistant à s’assurer, au moyen de son exécution, que le comportement d’un programme est conforme à des données préétablies. (AFCIQ)
9
Objets & Critères de classification
• Les objets nécessaires aux tests sont :– les spécifications de programme,– le code source du programme,– le code binaire du programme,
• Critères : d’utilisation de ces objets.
• Donc 7 classes de techniques possibles
10
Typologie des techniques de tests
Légende : la case colorée et coché indique que la classe demande l’existence de l’objet correspondant
Classes Spécifications Code source code binaire1 X Certains tests aléatoires
2 XAnalyse statique du flot de données, revue de code, calcul de complexité
3 X X Analyse dynamique du flot de données
4 XAnalyse de cohérence de spécifications formelles
5 X XTests aux limites, graphes causes-effets, algorithmique qualitative, analyse partitionnelle
6 X X exécution symbolique, preuve formelle
7 X X Xméthodes de couverture, tests mutationnels
Objets nécessairesExemples de techniques
11
Présentation des 7 classes (1)
• Classe 1 : sont groupées dans cette classe toutes les techniques de tests « aveugles » (tests faits par l’utilisateur ou un certain ensemble de tests aléatoires).
• Classe 2 : le code source est examiné pour identifier des erreurs indépendantes de l’application.– Techniques d’analyse statique du flot de
données, les revues de codes, les analyseurs de complexité, etc.
12
Présentation des 7 classes (2)
• Classe 3 : formée par l’analyse dynamique du flot des données.
• Classe 4 : sont comprises dans cette classe toutes les techniques d’analyse de spécifications (cohérence, etc.).
• Classe 5 : tests aux limites, graphes cause-effet, la plupart des tests aléatoires, tests basés sur la syntaxe, etc.
13
Présentation des 7 classes (3)
• Classe 6 : techniques– d’exécution symbolique de programme et– de preuve d’exactitude d’algorithme.
• Classe 7 : sont regroupées ici la plupart des techniques structurelles.– Techniques de couverture des instructions, des arcs du
graphe de contrôle, PLCS, etc.– Techniques de tests mutationnels.– Méthodes de couverture basées sur les flots de données.
14
Fonctionnel / structurel & Boîte « noire » / « blanche »
• Les techniques qui n’ont pas besoin du code source sont appelées techniques fonctionnelles (ou boîte noire), cas des classes 1, 4 et 5.
• Les classes 2, 3, 6 et 7 s’appellent techniques de tests boîte « blanche » ou structurelles basées sur le code source.
15
Statique / dynamique
• Les techniques qui exécutent le code binaire en examinant le comportement réel du programme s’appellent « dynamiques ».Cas des classes 1, 3, 5 et 7.
• Les autres techniques, qui examinent la forme (le code source), sont appelées statiques. Cas des classes 2, 4 et 6.
16
Tests fonctionnels et structurels
• Les techniques fonctionnelles testent ce qui devrait être fait– détection des erreurs omises– détection d’erreurs, localisation à effectuer
• Les techniques structurelles testent ce qui est fait– détection des erreurs commises.– localisation aisée
17
Rapport de détection & couverture
• Le rapport de détection D est égal
nombre de défauts trouvés / nombre total de défauts– Note le nombre total de défauts est le nombre
de défauts détectés à la fin de la phase de tests. C’est une approche empirique.
• La couverture de tests est égale au nombre de cas spécifiés / nombre de cas testés.
18
Les tests fonctionnels• Approche par les données
– Techniques fonctionnelles classiques– Analyse partitionnelle– Tests aux limites
• Approche par le comportement– Passe par une modélisation du logiciel avec des graphes
orientés ou des arbres.– Technique cause – effets,– Tests syntaxiques avec des grammaires ou automates
d’états finis,– Tests aléatoires ou statistiques.
19
Technique fonctionnelle classique
• C’est la technique la plus employée et de très loin.
• Elle consiste à tester– chacune des fonctions du logiciel– avec des jeux d’essais établis– vis-à-vis d’un cahier des charges ou des
spécifications.
20
Technique d’analyse partitionnelle
• Voisine de la technique fonctionnelle classique
• Elle s’intéresse au domaine des variations de données en entrée pour partitionner ce domaine en classes d’équivalence
21
Technique de tests aux limites
• Voisine de la technique fonctionnelle classique
• Basée sur le principe que « les erreurs se cachent dans les coins »
• Elle fait ressortir les aspects liés aux domaines de variation des données et identifie leurs intervalles de variations pour en déduire des jeux d’essais.
22
Technique cause effets
• Elle met en avant le comportement du logiciel
• Elle consiste à lier les effets c.-à-d. les sorties aux causes qui sont à l’origine c.-à-d. les entrées par un graphe.
23
Les techniques syntaxiques
• Elle met en avant le comportement du logiciel
• Elle consiste à modéliser le logiciel par une grammaire ou un automate d’états finis.
24
Technique de tests aléatoires ou statistiques
• Elle met en avant le comportement du logiciel.
• Elle consiste à générer des données aléatoires pour solliciter le logiciel.
• Sa version manuelle est le « monkey tests »: tests réalisés par un béotien
25
Techniques structurelles
• Statiques – Revue de code– Mesure des caractéristiques du code– Analyse du flot de données
• Dynamiques– L’objectif est la couverture de la structure du
code
26
Revue de code
• Elle consiste à :– la relecture par une équipe– du code– pour vérifier le respect de règles de
programmation et des bonnes pratiques.
• Elle dépend de la sagacité et de l’attention du lecteur
27
Mesure des caractéristiques du code
• Elle consiste à mesurer des caractéristiques du code telles que :– Le nombre de lignes par module,– Le taux de commentaires,– Le nombre de données en entrée et en sortie …
• Et de les comparer à des seuils afin de décider suivant une stratégie de tests établie en amont.
• La plus connue est la mesure de complexité de Mc Call ou celle de Halstead par exemple.
28
Analyse du flot de données
• Elle consiste à analyser le flot de données ou le flot de contrôles
• pour vérifier typiquement– l’absence de variables déclarées mais jamais
utilisées,– l’absence de variables écrites à 2 reprises sans
être relue entre ces 2 opérations.
29
Les types de tests au cours d’un projet
• On distingue principalement – pendant le projet
• les tests unitaires,
• les tests d’intégration,
• les tests de validation;
– en maintenance corrective ou évolutive• les tests de non régression.
30
Les principaux cycles de vie d’un logiciel
• Les cycles les plus connus sont :– le cycle de vie en cascade,– le cycle de vie en V,– le cycle de vie Merise,– le cycle de vie en spirale.
31
Les tests unitaires (1)
• Ils concernent – les modules élémentaires en conception classique,
– les machines abstraites en conception par abstraction,
– les objets terminaux en orienté objet.
• Ces entités élémentaires ont leurs entrées, leurs sorties, leurs propres données, une fonction clairement identifiée ainsi qu’une interface au moins.
32
Les tests unitaires (2)
• Il est souhaitable de réaliser ces tests sur machine cible mais en réalité ils s’exécutent sur une machine de développement.
• Ces tests sont d’abord conçus dans un dossier de tests unitaires,
• puis exécutés ce qui donne lieu à un compte rendu et des fiche d’anomalies ou de non conformités.
• Toutes les techniques de tests sont applicables.
33
Les tests d’intégration (1)
• Ils testent – les interfaces entre les entités élémentaires,– leur comportement dans l’environnement,– leurs interactions avec le matériel,
• D’où la nécessité de les réaliser sur machine cible même s’ils débutent sur machine de développement.
34
Les tests d’intégration (2)
• Ils sont réalisés vis-à-vis de la conception générale ou préliminaire.
• Toutes les techniques de tests sont applicables :– pour les logiciels standards, seules les
techniques fonctionnelles sont réalisées, en général,
– pour les logiciel critiques, les techniques structurelles sont appliquées.
35
Outils d’intégration
• Les bouchons– qui simulent des composants non encore
intégrés.
• Les lanceurs – qui sollicitent les entrées des composants non
encore intégrés.
• Ces programmes, bouchons et lanceurs, sont testés.
36
Organisation de l’intégration
• Il est délicat d’établir l’ordre des tests.
• Cet ordre dépend de – l’architecture,– la disponibilité des composants,– de l’environnement à mettre en place
(matériels, logiciels, bouchons, lanceur, …)
• Et influe sur le planning de développement
37
Stratégies d’intégration
• Premier choix– intégration en une seule fois,– intégration par incréments c.-à-d. composant par
composant,– intégration par agrégats c.-à-d. groupes de composants
par groupes de composants.
• Deuxième choix– Démarche ascendante : commencer par les composants
de plus bas niveau,– Démarche descendante : commencer par les composants
de plus haut niveau.
38
Intégration en une seule fois
• Avantages– pas de développement de bouchons et lanceurs,– pas de contraintes sur le développement;
• Inconvénients – risque de grandes difficultés de localisation des
erreurs– et de maîtrise du logiciel.
39
Intégration par incréments
• Avantages– localisation aisée des erreurs;
• Inconvénients – grand nombre de bouchons à développer,– de nombreuses étapes.
40
Intégration par agrégats
• Avantages– peu d’outillage (bouchons, …) et de jeux
d’essais– bien adaptée à une livraison par lot;
• Inconvénients – localisation des erreurs pas très aisée mais
quand même circonscrite
41
Intégration ascendante / descendante
ascendante descendante
bouchonspeu debouchons àréaliser
de nombreuxbouchons àréaliser
architecturedétection tardive desdéfauts
détection précoce desdéfaurs
42
Tests de validation (1)
• Vérification– on vérifie que l’on a bien fait le logiciel.
• Validation – on valide que l’on a fait le bon logiciel.
• En validation, on adopte le point de vue de l’utilisateur et donc
• on réalise des tests fonctionnels, boîte noire.
43
Tests de validation (2)
• Ils s’exécutent – vis-à-vis des spécifications ou de l’étude
préalable– sur des machines cibles d’exploitation– dans un environnement réel ou une simulation
de cet environnement.
44
Tests de non régression (1)
• Aujourd’hui, 54% des erreurs sont détectées par le client,
• d’où des maintenances correctives et évolutives.
• Le but est de maîtriser et tester l’introduction de nouvelles erreurs lors de maintenances.
45
Tests de non régression (2)
• Sur les logiciels standards– S’interroger de manière informelle sur l’impact
de la modification sur les autres composants et sur les variables manipulées.
• Sur les logiciels critiques– Recours à des outils d’analyse de flots,– Examination de graphe d’appel logiciel,– Technique d’injection de défaut.
46
Tests de non régression (3)
• Les modifications réalisées suivent le cycle normal de tests :– réaliser une campagne de tests unitaires sur les
composants modifiés,– adapter et rejouer les tests d’intégration qui font
appel aux composants modifiés,– adapter et rejouer les tests de validation qui font
appel aux fonctions modifiées,– mettre à jour les spécifications.
47
Conclusion
• Beaucoup de travail en perspective,
• des techniques qui évoluent,
• des outils nouveaux.
Merci !
48
Bibliographie
• Le test des logiciels par Spyros Xanthakis, Pascal Régnier, Constantin Karapoulios. Edition Hermes Sciences.
• M.-C. Gaudel, B. Marre, F. Schlienger et G. Bernot. Précis de génie logiciel. Collection Enseignement de l'Informatique. Masson, 1996. 142 pages. Préface de Michel Lemoine.
• La qualité des logiciels par Jean-Pierre Martin. Afnor