La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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.

Présentations similaires


Présentation au sujet: "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."— Transcription de la présentation:

1 1 Les tests des logiciels Introduction

2 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 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 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 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 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 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 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 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 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

11 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 39 Intégration par incréments •Avantages –localisation aisée des erreurs; •Inconvénients –grand nombre de bouchons à développer, –de nombreuses étapes.

40 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 41 Intégration ascendante / descendante

42 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 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 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 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 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 47 Conclusion •Beaucoup de travail en perspective, •des techniques qui évoluent, •des outils nouveaux. Merci !

48 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, pages. Préface de Michel Lemoine. •La qualité des logiciels par Jean-Pierre Martin. Afnor


Télécharger ppt "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."

Présentations similaires


Annonces Google