Yves Le Traon

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