Transcription

1 Génie logiciel Test logiciel A.U. 2013/2014 (Support de cours) R. MAHMOUDI 1

2 Plan du chapitre - Définition du test logiciel - Principe de base du test logiciel - Les différentes étapes de test - Les plans de test - Etude de cas : Test de triangle Cours adapté des travaux de : Philippe Ayrault UPMC / F.X Fornari Esterel Technologie 2

3 C est quoi un Logiciel? Des documents de gestion de projet une spécification d écrivant : la liste des fonctions `a remplir par le logiciel les facteurs qualité du logiciel : sa portabilité, son évolutivité, sa robustesse,... les contraintes : performances temporelles et spatiales,... les interfaces une conception d écrivant : la découpe de la spécification en modules (ou objets) la description des interfaces entre ces modules (ou objets) la description des algorithmes mis en place un code source un exécutable 3

4 Qu est ce que ça veux dire «tester un logiciel»? R: Tentative de définition : «Processus d exécution d un programme avec l intention de détecter des anomalies dans le but de le valider.» 4

5 Qu est ce que ça veux dire «tester un logiciel»? Norme IEEE (Standard Glossary of Software Engineering Terminology) «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.» Validation dynamique (exécution du système) Comparaison entre système et spécification 5

6 Qu est ce que ça veux dire «tester un logiciel»? «Tester peut révéler la présence d'erreurs mais jamais leur absence» Vérification partielle : le test ne peut pas montrer la conformité du système (nécessité d'une infinité de tests) «Tester, c'est exécuter le programme dans l'intention d'y trouver des anomalies ou des défauts» Objectif : détection des bugs 6

7 Qu est-ce que un bug? Anomalie (fonctionnement) : différence entre comportement attendu et comportement observé Défaut (interne) : élément ou absence d'élément dans le logiciel entraînant une anomalie Erreur (programmation, conception) : comportement du programmeur ou du concepteur conduisant à un défaut Erreur Défaut Anomalie 7

8 Y-a-t-il plusieurs types de tests? R: Essentiellement deux types de tests: Tests fonctionnels: vérifier que le logiciel respecte sa spécification (correction, facteurs qualité spécifies, les performances, interfaces avec les équipements externes) Tests structurels : le but est de détecter les fautes d implémentation. Par conséquent, de vérifier que le logiciel n en fait pas plus que sa spécification et qu il n existe pas de cas de plantage(overflow, non initialisation,...) 8

9 Y-a-t-il une alternative aux tests? R: Malheureusement non, c est la seule activité de vérification dynamique du logiciel. Méthodes formelles : il reste le problème de l adéquation entre le modèle formel et la réalité. Relecture de code : elle permet de détecter les principales erreurs statiques dans le code mais pas les erreurs dynamiques Analyses de sécurité : elles permettent de valider une architecture mais pas de la vérifier. 9

10 Combien coûte le teste logiciel? R: Le test représente de 30 à 40% des coûts de développement d un logiciel suivant son niveau de criticité. environ 30% du développement d'un logiciel standard plus de 50% du développement d'un logiciel critique - Phase de test souvent plus longue que les phases de spécification, conception et implantation réunies 10

11 Attention : Le test logiciel est un métier à part entière! Dans l industrie, c est la seule activité dans le cycle de développement ou l on peut voir toutes les fonctionnalités d un produit logiciel. Letestestuneactivitécréatrice: Imaginer des scénarios plausibles pouvant mettre un logiciel en défaut Imaginer et construire des bancs de tests permettant de vérifier les fonctionnalités Nécessité d avoir plusieurs compétences: automatisme, électronique, réseau,... 11

12 Exemple Vous devez tester le logiciel d acquisition de la vitesse d un train utilisant un capteur odométrique, comment tester ce logiciel? Capteur de distance inductif pour véhicule sans câble odométrique à monter sur le cardan de transmission de tous véhicules 12

13 Exemple Vous devez tester le logiciel d acquisition de la vitesse d un train utilisant un capteur odométrique, comment tester ce logiciel? Sol1: Prendre le véritable capteur tachymétrique et le monter sur un moteur que l on peut piloter à plusieurs vitesse / simuler le ou les signaux du capteur avec une carte électronique ou un autre logiciel?!? 13

14 Difficulté du test (1) Le test exhaustif est en général impossible à réaliser!!! En test fonctionnel, l'ensemble des données d'entrée est en général infini ou très grande taille. Exemple : un logiciel avec 5 entrées analogiques sur 8 bits admet 240valeurs différentes en entrée 14

15 Difficulté du test (1) Le test exhaustif est en général impossible à réaliser!!! Enteststructurel, leparcoursdugraphedeflotdecontrôleconduitàuneforte explosion combinatoire! 15

16 Difficulté du test (1) Le test exhaustif est en général impossible à réaliser!!! Le test est une méthode de vérification partielle de logiciels La qualité du test dépend de la pertinence du choix des données de test 16

17 Difficulté du test (2) Difficultés d'ordre psychologique ou «culturel» Le test est un processus destructif : un bon test est un test qui trouve une erreur alors que l'activité de programmation est un processus constructif -on cherche à établir des résultats corrects Les erreurs peuvent être dues à des incompréhensions de spécifications ou de mauvais choix d'implantation 17

18 Evolution des tests Aujourd'hui, le test de logiciels : est la méthode la plus utilisée pour assurer la qualité des logiciels fait l'objet d'une pratique trop souvent artisanale Demain, le test de logiciels devrait être : une activité rigoureuse fondée sur des modèles et des théories de plus en plus automatique 18

19 Quelques principes de base : P1: Un programmeur ne doit pas tester ses propres programmes. => Indépendance P2: Ne pas effectuer des tests avec l hypothèse de base qu aucune erreur ne va être trouvée. => Paranoïa P3: La définition des sortie ou résultats attendus doit être effectuée avant l exécution d un test. => Prédiction - C'est nécessaire pour des développements certifies - Les données sont fournies parfois au niveau système (ex: Matlab), mais les résultats seront différents à l'implémentation. - Parfois les données sont trop complexes a fournir directement (éléments de compilation, environnement complexe...) 19

20 Quelques principes de base : P4: Inspecter minutieusement les résultats(trace) et la pertinence de chaque test. C'est la séparation de l'exécution et de l'analyse. => Vérification P5: Les jeux de tests doivent être écrits pour des entrées invalides ou incohérentes aussi bien que pour des entrées valides. => Robustesse P6: Vérifier un logiciel pour détecter qu il ne réalise pas ce qu il est supposé faire n est que la moitié du travail. Il faut aussi vérifier ce que fait le programme lorsqu il n est pas supposé le faire. => Complétude 20

21 En cas de bug que faire? 1) Vérifier que le testest bien correct(revenir à la phase 4) 2) Vérifier que le problème n'est pas déjà répertorié(base de bugs par exemple) 3) Etablir un rapport de bug a) Donner un synopsis précis b) Donner une description claire, avec tous les détails de reproduction du bug 21

22 Les différentes étapes du test des logiciels Q. Quand commencer? R.Le test commence de suite! Ici, le cycle en V. mais aussi approches incrémentale, agile.. 22

23 Les différentes étapes du test des logiciels Q. Les différents niveaux? Tests de recette: test de réception du logiciel chez le client final Tests intégration système: test de l'intégration du logiciel avec d'autres logiciels Tests système: test d'acception du logiciel avant livraison (nouvelle version par exemple) Tests Intégration: test de l'intégration des différents composants (avec ou sans hardware) Tests Unitaires: tests élémentaires des composants logiciels (une fonction, un module,...) 23

24 Les différentes étapes du test des logiciels Q. La planification? Ces différents niveaux de tests doivent être planifies(c'est l'objet du plan projet). Théoriquement, on prépare les tests en même temps que le développement correspondant au niveau. On peut aussi le faire d une manière incrémentale, ou en pipeline. En Extreme-Programmming: paire de développeurs/paires de testeurs. De toute façon, il y a re-bouclage permanent 24

25 Les différentes étapes du test des logiciels Q. La planification? 25

26 Les plans de test Plan Qualité du Logiciel: L organisation mise en place Les responsabilités et les interfaces des personnes intervenant dans le processus de test Les objectifs de tests fixer pour chaque niveaux de tests du logiciel Tests Unitaires(TU) Tests d Intégration(TI) Tests de Validation(TV). 26

27 Les plans de test Pour chaque phase du définition du logiciel(spécification, architecture, conception): Apartirdudocumentdedéfinition; Dossier de Spécification du Logiciel(DSL), Dossier de Conception Préliminaire(DCP), Dossier de Conception Détaillée(DCD), le testeur doit écrire dans les plans de tests correspondant: Plan de Tests de Validation(PTV)*** Plan de Tests D Intégration(PTI), Plan de Tests Unitaires(PTU)) 27

28 Le PVT : Une démarche d assurance qualité L étape la plus importante en début de projet, c est la définition d un Plan de Test et Validation - PTV 28

29 Les plans de test Ils doivent: Définir les moyensà mettre en place pour tester le logiciel Décrire la stratégie de tests à mettre en place pour tester la première version, tester les versions suivantes, critères d arrêt des tests. Décrire les fiches de tests (détecter des incohérences et des incomplétudes des documents). 29

30 Les fiches de test Elles sont constituées: (1)Desvaleursàpositionneràl entréedutestoulesactionsàeffectuer (2)Des valeurs de sortie attendues ou la description du comportement du logiciel (3)Démontrer la couverture atteintes(traçabilité) 30

31 Les plans de test Pour chaque plan de test(tu, TI,TV): letesteurdoitélaborerlerapportdetests: -Exécuter les fiches de tests spécifiées (consiste à positionner les valeur d entrées ou à effectuer les actions décrites dans la fiche de tests) -Analyser les résultats obtenus (comparer les résultats attendus avec les résultats obtenus et décider du statu du tests OK / KO) - Emettre des fiches de non conformité si nécessaire 31

32 Autre type de test (1) Tests unitaires : Test de procédures, de modules, de composants Tests d'intégration: Test de bon comportement lors de la composition de procédures et modules Tests de conformité ou test système : Validation de l'adéquation aux spécifications Tests de non-régression Vérification que les corrections ou évolution dans le code n'ontpas créées d'anomalies nouvelles 32

33 Autre type de test (2) Tests nominal ou Test de bon fonctionnement : Les cas de test correspondent à des données d entrée valide. Test-to-pass Tests de robustesse : Les cas de test correspondent à des données d entrée invalide Test-to-fail Règle : Les tests nominaux sont passés avant les tests de robustesse. Test de performance : Load testing(test avec montée en charge) Stress testing(soumis à des demandes de ressources anormales) 33

34 Etude de cas : Test des triangles - Soit la spécification suivante : Un programme prend en entrée trois entiers. Ces trois entiers sont interprétés comme représentant des longueurs des cotés d un triangle. Le programme rend un résultat précisant si il s agit d un triangle scalène, isocèle ou équilatéral. -Produire une suite de cas de tests pour ce programme! 34

35 Solution 1: Test des triangles 35

36 Solution 2: Test des triangles 36

37 Solution 2: Test des triangles 16 cas correspondant aux défauts constatés dans des implantations de cette spécification Moyenne des résultats obtenus par un ensemble de développeurs expérimentés : 55% La construction de tests est une activité difficile, encore plus sur de grandes applications 37

38 Solution 2: Test des triangles 14 casde test GJ Myers «The Art of Software Testing» Cas scalène valide (1,2,3 et 2,5,10 ne sont pas valides) 2. Cas équilatéral valide 3. Cas isocèle valide (2,2,4 n est pas valide) 4. Cas isocèle valide avec les trois permutations (e.g. 3,3,4; 3,4,3; 4,3,3) 5. Cas avec une valeur à0 6. Cas avec une valeur négative 7. Cas ou la somme de deux entrées est égale àlatroisième entrée 8. 3 cas pour le test 7 avec les trois permutations 9. Cas ou la somme de deux entrées est inférieur àlatroisième entrée cas pour le test 9 avec les trois permutations 38

39 Solution 2: Test des triangles 14 casde test GJ Myers «The Art of Software Testing» Cas avec les trois entrées à0 12. Cas avec une entrée non entière 13. Cas avec un nombre erronée de valeur (e.g. 2 entrées, ou 4) 14. Pour chaque cas de test, avez-vous défini le résultat attendu? Chacun de ces 14 tests correspond à un défaut constaté dans des implantations de cet exemple triangle. La moyenne des résultats obtenus par un ensemble de développeurs expérimentés est de 7.8 sur 14. La conception de tests est une activité complexe, à fortiori sur de grandes applications 39