slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Test à partir de modèles : pistes pour le test unitaire de composant, le test d'intégration et le test système PowerPoint Presentation
Download Presentation
Test à partir de modèles : pistes pour le test unitaire de composant, le test d'intégration et le test système

Loading in 2 Seconds...

play fullscreen
1 / 63

Test à partir de modèles : pistes pour le test unitaire de composant, le test d'intégration et le test système - PowerPoint PPT Presentation


  • 296 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

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


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - 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 • Programme mutant • 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. Optimisation automatique de cas de test • Score de mutation moyen facile à atteindre • Comment optimiser ces tests Analogie avec l’évolution

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

    17. Algorithme génétique • Données • Gène = cas de test • Individu/chromosome= séquence de gènes de taille fixe • Fonction d’utilité = évaluer l’intérêt d’un individu pour le problème • Nouvelle population d’individus • Croisement • Taux de mutation des gènes • Limitations • Taille fixe d’un ensemble de cas de test • Opération de croisement peu utile • Reproduction pas efficace pour garder la mémoire

    18. Étude d’un parser C#

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

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

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

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

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

    24. Étude d’un parser C#

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

    26. 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…

    27. Assemblage de composants

    28. 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).

    29. 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)

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

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

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

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

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

    35. 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é absente

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

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

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

    39. 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]

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

    41. Case study SMDS UML diagram

    42. Case study SMDS Test Dependency Graph

    43. SMDS realistic stubs

    44. 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 : 30-55 % stubs number reduction

    45. Variantes possibles • Mixte Big-Bang/Incrémental strict • Parallèlisation des tâches d’intégration

    46. 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 »

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

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

    49. Test « système »

    50. Test à partir des exigences • Partir des exigences • Soit textuelles • Soit cas d’utilisation étendus avec des contrats (dans une logique proche du B) Générer automatiquement des objectifs/cas de test • Adaptable aux lignes de produits • Expérimentations industrielles