1 / 65

Yves Le Traon

Test à partir de modèles : pistes pour le test unitaire de composant, le test d'intégration et le test système. Yves Le Traon. Un thème: le test de logiciels. Le test c’est important ! Objectifs du test examiner ou exécuter un programme dans le but d’y trouver des fautes

ruby-lamb
Download Presentation

Yves Le Traon

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Test à partir de modèles : pistes pour le test unitaire de composant, le test d'intégration et le test système Yves Le Traon

  2. Un thème: le test de logiciels • Le test c’est important ! • Objectifs du test • examiner ou exécuter un programme dans le but d’y trouver des fautes • relativement à une spécification • formalisation de critères pour guider la sélection des tests • Confiance mais pas de certitude • sûreté de fonctionnement

  3. Exécution Cas de test Diagnostic Oracle ¬ vérifié ¬ correct correct Critère d’arrêt vérifié Arrêt Le test dynamique : processus Génération cas de test

  4. Le test des logiciels à objets Il était une fois, il y a 6 ans… ou une certaine méfiance des testeurs…

  5. A m1() m2() m3() m4() A.m1() calls m4() calls m2() B.m2() B w m1() m2() m3() B.m1() C m1() m4() calls super() calls super() Implements Implements C.m4() Mixed-feeling at the code level Method calls flow for processing C.m1() The Yo-yo Effect (Binder, Offut) C.m1()

  6. Plan • Test de composants • Assemblage de composants • Plan d’intégration • Test « système »

  7. Composants et test

  8. Composant de confiance Spécification contrats exécutables V & V: ensemble de cas de test Confiance fondée sur la cohérence Implantation Composants autotestables

  9. Component Trusting Components? • The point of view of the user... ? Components “off-the-shelf”

  10. Component Trusting Components? • The point of view of the user... “replay” selftests 100% 85% 100% 55% Components “off-the-shelf”

  11. Intuition • La confiance dépend de la manière dont le composant a été testé • Comment évaluer la qualité des tests ? • Mutation analysis • Les tests doivent au moins être capables de détecter les fautes introduites intentionnellement

  12. Analyse de mutationR. DeMillo, R. Lipton and F. Sayward, "Hints on Test Data Selection : Help For The Practicing Programmer". IEEE Computer 11(4): 34 - 41 April 1978. • Technique pour évaluer l’efficacité d’un ensemble de cas de test • Injection d’erreurs dans le programme sous test • Calcul de la proportion d’erreurs détectées par les cas de test

  13. Quality Estimate = Mutation Score • Q(Ci) = Mutation Score for Ci = di/mi • di = number of mutants killed • mi = number of (non equivalent) mutants generated for Ci • WARNING: Q(Ci)=100% not=>bug free • Depends on mutation operators (see next slide) • Quality of a system made of components • Q(S) = S di / S mi

  14. Mutant 1 Mutant 2 Mutant 3 Génération de mutants Mutant 4 Mutant 5 Mutant 6 Automatique Manuel Exécution Optimiseur Mutant vivant Mutant tué Cas de test insuffisants Mutant équivalent Diagnostic Spécification incomplète Analyse de mutation P CT Supprimé de l’ensemble des mutants Ajout de contrats

  15. Oracle • Oracle par différence de comportements • Des traces • Des objets « programmes » • Oracle embarqués (contrats, assertions) • Interne au composant • Oracle associé aux données de test • Extérieur au composant • Oracle spécifique à la donnée de test

  16. suppression des mutatnts équivalent correction des fautes Optimisation automatique des cas de test Cas de test initiaux (produits par le testeur). reconstruction fonction oracle Contrats ++ mesure efficacité des contrats 2 5 6 contrats contrats contrats 1 contrats 3 4 contrats impl. MS= trust test test impl. impl. test MS=trust MS=trust contrats test impl. test impl. MS= trust test impl. Processus de fiabilisation automatisé

  17. Optimisation automatique de cas de test • Score de mutation moyen facile à atteindre • Comment optimiser ces tests Analogie avec l’évolution

  18. Population de proies Test6 mutantA9 mutantA6 mutantA7 mutantA8 mutantA5 mutantA1 mutantA2 mutantA4 mutantA3 Test Test5 Test1 Test3 Test4 mutantA10 Test2 Optimisation des tests Comp. A

  19. Algorithme génétique • Taille fixe d’un ensemble de cas de test • Opération de croisement peu utile • Reproduction pas efficace pour garder la mémoire

  20. Étude d’un parser C#

  21. 2 ensembles de bactéries Bouillon (population courante) Solution (contruite itérativement) 4 opérations Classer,Mémoriser, Filtrer, Muter Condition d’arrêt Objectif atteint Nb de générations … Ensemble solution La boucle bactériologique Arrêt Mémoriser Classer Filtrer Bouillon bacteriologique Muter

  22. La boucle bactériologique Fonction d’utilité (F) Indique la pertinence d’un ensemble de bactéries pour le problème considéré Ensemble solution Mémoriser Définie pour un ensemble de Bactéries • Utilité d’une bactérie • f(b) = F(bUS) – F(S) • Utilité relative aux bactéries déjà mémorisées Classer Filtrer Bouillon bacteriologique Muter

  23. La boucle bactériologique Fonction de mémorisation Fonction à valeur booléenne indiquant si la meilleure bactérie du bouillon doit être mémorisée. Exemples Seuil de mémorisation Plusieurs itérations sans améliorations … Ensemble solution Mémoriser Classer Filtrer Bouillon bacteriologique Muter

  24. La boucle bactériologique Fonction de filtrage Elimine les bactéries inutiles du bouillon afin de garantir l’efficacité de l’algorithme Exemples Supprimer les bactéries d’utilité nulle Dans le domaine du test : heuristiques de minimisation de suites de test … Ensemble solution Mémoriser Classer Filtrer Bouillon bacteriologique Muter

  25. La boucle bactériologique Opérateur de mutation Permet, à partir d’une bactérie parente, de construire une nouvelle bactérie Fortement dépendant du problème considéré Ensemble solution Mémoriser Classer Filtrer Bouillon bacteriologique Muter

  26. Étude d’un parser C#

  27. Résultats • Approche composant autotestable • Algorithme original pour la génération de cas de test • Résultats expérimentaux : vers des composants robustes • contrats efficaces [15..85] % de taux de détection d’une erreur à l’exécution • réduction de l’effort de localisation des fautes d’un rapport 10 au moins

  28. Dissémination • Principales publis : • "From Genetic to Bacteriological Algorithms for Mutation-Based Testing" , B. Baudry, F. Fleurey, J.-M. Jézéquel and Yves Le Traon, Software Testing, Verification and Reliability journal (STVR), to be published, 2005 • “An Original Approach for Automatic Test Cases Optimization: a Bacteriologic Algorithm”, B. Baudry, F. Fleurey, J.-M. Jézéquel and Y. Le Traon, IEEE Software, to be published, 2005 • “Reliable Objects: a Lightweight Approach Applied to Java”, J.-M. Jézéquel, D. Deveaux, Y. Le Traon, IEEE Software,Vol. 18, N°4, July-August 2001, pp. 76-83. • “ Composants Objets Fiables, une approche pragmatique ”, D. Deveaux, R. Fleurquin, P. Frison, J-M. Jézéquel and Y. Le Traon, L’Objet, Vol. 5, N°3-4, december 1999, pp.469-494 • 7 conférences internationales : ASE, TOOLS, ISSRE…

  29. Assemblage de composants

  30. Test d’intégration • Objectif • Planifier l’ordre d’intégration • Vérifier l’interaction entre composants unitaires • Difficultés principales de l’intégration • Interfaces floues (ex. ordre des paramètres de même type). • Implantation non conforme à la spécification (ex. dépendances entre unités non spécifiées). • Réutilisation de composants (ex. risque d’utilisation hors domaine).

  31. Intégration – Approches classiques • On obtient une architecture arborescente • SADT, SART, SAO (Aérospatiale) • Approches • Big-Bang : non recommandé • De haut en bas (top-down) • De bas en haut (bottom-up)

  32. Unité à tester Dépendance à tester Unité sous test Dépendance sous test Unité testée Dépendance testée Approche classique : De bas en haut

  33. Systèmes à objets • Forte connectivité • Architecture cyclique – Interdépendances

  34. Objectif d’un plan d’intégration • Réalisation d’une « bonne » stratégie : • pour planifier l’intégration des systèmes à objets, • le plus tôt possible dans le cycle de vie, • en minimisant le coût du test.

  35. S pck1 pck2 pck4 pck3 Test d’intégration : les interdépendances • Une solution simple consiste à contraindre le concepteur • pas de boucle dans l’architecture • c’est souvent possible maisles optimisations locales ne sont pas toujours optimales globalement maisconcevoir des composants interdépendants est souvent naturel • La solution que nous préconisons • prend n’importe quel modèle UML • Cherche à optimiser l’effort et la durée de l’intégration

  36. Interdépendance • Interdépendances • Cycle de dépendances • Composantes fortementconnexes (CFC) • Intégration • Big-Bang • Décomposer des CFCs – Utilisation de bouchons

  37. CA A A C C CB B B Bouchon spécifique CFC Bouchon de test • Bouchon : une unité qui • simule le comportement d’une unité

  38. B A A C B C association class A A A A Interface Name B A B B B B inheritance Interfaces dependency navigability A A B B association Modélisation du problème Class-to-class A A B B aggregation composition

  39. a f b i g e c j h d k l Stratégie d’intégration : minimiser les bouchons • Une stratégie (1)

  40. a f b i g e c j h d Determination and ordering of connected components k l Stratégie d’intégration : minimiser les bouchons a B • Une stratégie (2) f Tarjan’s algorithm b i g e c j h d k l A C [(e) or C] then [A or B] then [(a)] Complexity linear with #nodes

  41. Stratégie d’intégration : minimiser les bouchons • Une stratégie (3) 5 f Bourdoncle’s algorithm f i 4 i Candidate node = # max(fronds) g j 3 j g h h 2 1 B [(e) or C] then [A or B] then [(a)] Break the connected component Reapply Tarjan [l, k] [c, b, d] [g, h, j, i, f]

  42. a c i b j f e h l Stratégie d’intégration : minimiser les bouchons • Le résultat = graphe d’ordre partiel g Optimized algorithm d #specific stubs = 4 #realistic stubs = 3 Random selection k #specific stubs = 9.9 Partial ordered tree #realistic stubs = 5

  43. Case study SMDS UML diagram

  44. Case study SMDS Test Dependency Graph

  45. SMDS realistic stubs

  46. Specific stubs counting Realistic stubs counting 60 48 47 50 30 27 29 30 39 38 25 36 24 40 34 21 19 19 26 28 25 18 27 #stubs 20 30 #stubs 13 SMDS case study 20 20 9 10 10 0 0 RC MC RT MT Optim. RC MC RT MT Optim. Min Mean 100 46 85 Max 87 50 43 80 63 63 40 35 34 GNU Eiffel case study 32 60 25 28 30 40 38 #stubs 34 25 22 22 #stubs 28 40 27 27 20 17 20 9 10 0 0 RC MC RT MT Optim. RC MC RT MT Optim. Results summary

  47. Variante possible • Mixte Big-Bang/Incrémental strict • Parallèlisation des tâches d’intégration

  48. Autres travaux : mesures du logiciel « expérimenter-comprendre-mesurer-agir » • Design by Contracts : Robustesse / Vigilance • Capacité d’un composant à détecter un état interne erroné • Design by Contracts : Diagnosabilité • Facilité à localiser une faute dans un composant sachant qu’une défaillance est détectée • Testabilité d’un diagramme de classes • identification d’ « anti-patterns »

  49. Autres travaux: conception testable • transformations de modèles pour supprimer les ambiguïtés d’une architecture • Application aux design patterns courants • refactorings

  50. Dissémination • Principales publications B. Baudry and Y. Le Traon, “Measuring Design Testability of a UML Class Diagram”, to be published in the journal, Information & Software Technology(IST). Y. Le Traon, F. Ouabdesselam, C. Robach and B. Baudry, « From Diagnosis to Diagnosability: Axiomatization, Measurement and Application”, in The Journal of Systems and Software, January 2003, Vol. 1, N°65, pp. 31-50 Y. Le Traon, T. Jéron, J-M. Jézéquel and P. Morel, “ Efficient OO Integration and Regression Testing”, IEEE Transactions on Reliability, March 2000, pp. 12-25. 8 conférences internationales : ECOOP’01, UML’01, Metrics’03, Metrics’02, ISSRE’01 etc. • Module de test d’intégration développé par Softeam pour Objecteering

More Related