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

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