1 / 73

Test et diagnostic : des objets aux modèles

Test et diagnostic : des objets aux modèles. Yves Le Traon « in God we trust, for the rest we test » (A. Petrenko). Une « vision » de la recherche en génie logiciel. Monde pas idéal => génie logiciel

erno
Download Presentation

Test et diagnostic : des objets aux modèles

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 et diagnostic : des objets aux modèles Yves Le Traon « in God we trust, for the rest we test » (A. Petrenko)

  2. Une « vision » de la recherche en génie logiciel • Monde pas idéal => génie logiciel • Compromis entre une solution idéale en pratique inapplicable et solution imparfaite mais praticable • Test et génie logiciel : difficile alchimie pratique actuelle solution idéale bon dosage ? 0 1 « Testing can prove the presence of bugs, but never their absence » Dijkstra Bienvenue dans le domaine de l’incertitude !!!

  3. Le test de logiciels • 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 • cas de test / oracle

  4. Problématique conformité du produit par rapport à sa spécification Le test Vérification/preuve tests

  5. Problématique du test Le coût du test dans le développement analyse des besoins Implém. spécification Spécif. Test An. b Implémentation test + maintenance = 100 % du coût global de développement !!!

  6. Problématique du test Pourquoi ? Coût Effort Confiance

  7. Génération de données de test Oracle Diagnostic Le test dynamique : processus Donnée de test Programme P Exécution Résultat Spécification S Oracle Localisation / Mise au point faux Verdict Problèmes vrai non vérifié Critère d’arrêt

  8. Le test : c’est un peu désordre • Autant de techniques que de domaines d’application • Nombreux problèmes (génération/oracle/environnement, étape du processus/critère) • Psychologiquement redoutable

  9. Le test des logiciels à objets Au départ… une certaine méfiance des testeurs…

  10. 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() Sentiment mitigé au niveau du code Method calls flow for processing C.m1() The Yo-yo Effect (Binder, Offut) C.m1()

  11. Et pourtant …. • OO fonctionne aussi bien que le procédural classique • Culture test • Environnement pour assister la réalisation des tests: Junit • Test-first development

  12. JUnit • Permet de structurer les cas de test • cas de test / suite de test • Permet de sauvegarder les cas de test • important pour la non régression • quand une classe évolue on ré-exécute les cas de test

  13. Test-first development • Xtreme programming • On écrit les tests d’abord, on réalise ensuite • Les cas de test servent de support à la documentation • Tester avec une intention précise • Retours rapides sur la qualité du code • itérations courtes dans le cycle de développement • on exécute le code tout de suite (avant même de l’avoir écrit) • On ne code que quand un test a échoué • refactorings fréquents • Approche « anti-modèle »

  14. Test-first development Écrire un cas de test Exemple : ajout dans une liste chainée public void testAdd(){ list.add("first"); assertTrue(list.size()==1); } Exécuter les cas de test succès échec public void add (String it){ Node node = new Node(); node.setItem(it); node.setNext(null); if (firstNode == null) { node.setPrevious(null); this.setFirstNode(node); } lastNode = node; this.setCurrentNode(node); } public void add (String it){} développement continue Faire un petit changement Exécuter les cas de test échec développement s’arrête

  15. refactoring refactoring Tissage composition code Des objets aux modèles

  16. Système Intégration Analyse Unitaire Conception globale Conception détaillée Test transfo modèles Implémentation Des étapes de test…au test des étapes Exigences

  17. Plan • Test de composants • Assemblage de composants • Test « système » • Diagnostic • Test et modèles

  18. Composants et test

  19. Component Composants de confiance • Du point de vue utilisateur... ? Components “off-the-shelf”

  20. Component Composants de confiance Du point de vue utilisateur... “replay” selftests 100% 85% 100% 55% Components “off-the-shelf”

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

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

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

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

  25. Population de prédateurs Classe A Test1 Population de proies Test6 mutantA9 mutantA2 mutantA7 mutantA6 mutantA1 mutantA3 mutantA4 mutantA8 mutantA5 Test Test2 Test5 Test3 Test4 mutantA14 mutantA11 mutantA18 mutantA12 mutantA13 mutantA17 mutantA10 Amélioration des tests

  26. Étude d’un parser C#

  27. Résultats • Approche composant autotestable • Algorithme original pour la génération de cas de test • Développement d’outils pour les expériences

  28. Assemblage de composants

  29. Test d’intégration • Plan de test • ordonnancement • minimiser le nombre de « testing stubs »

  30. Autres travaux: conception testable • Testabilité d’un diagramme de classes • identification d’ « anti-patterns » • Transformations de modèles pour supprimer les ambiguïtés d’une architecture • Application aux design patterns courants • refactorings

  31. Test « système »

  32. Les exigences… attention ! terrain instable • Point d’entrée d’un projet • Premières approches • Fonctionnelles • Extra-fonctionnelles ? • Techniques ? • Comment valider du flou, de l’informel ? • Comment s’en servir pour valider la conception/implémentation

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

  34. Métamodèle Métamodèle statique d’exigences 1 2 requirement 1.1 "Register a book" the "book" becomes "registered" C1 C3 after the "librar ian" did 0..1 * "register" the "book". the "book" is "available" after the "librarian" did "register" the Métamodèle "book". C2 d’objectifs de tests 4 6 :C1 :C2 :C3 CallAction 5 CallAction Métamodèle de configuration 3 8 :C1 Métamodèle de cas status="on" Métamodèle UCTS d’utilisation :C1 <<precondition>> observable="dummy" {true} :C2 Package s4 s1 /a2 UseCase 7 /a1 /a3 Actor /a5 <<postcondition>> s2 s3 {observable(x)="dummy"} /a4 if the mode of the system is dummy or real and the user did deselect Example function then the phase of the system is no phase and the status of the component is released implies the presence of the component is false. Traçabilité MModèles indépendants

  35. Expérimentations • Question de base • Des cas de test générés à partir des exigences peuvent-ils tester correctement un système ? • Etudes de cas • Deuxième question • applicable au niveau industriel (ROI) ? • % des exigences couvert pour un vrai système ?

  36. Nominal code

  37. Exigences … • Stabiliser les concepts grâce à la métamodélisation • Se servir des métamodèles pour • La vérification • La simulation • La dérivation des tests

  38. Diagnostic« mais où ? »

  39. Diagnostic et Design-by-contract

  40. Diagnostic et Design-by-contract • Design by Contract : Robustesse / Vigilance • Capacité d’un composant à détecter un état interne erroné • Design by Contract : Diagnosabilité • Facilité à localiser une faute dans un composant sachant qu’une défaillance est détectée

  41. A B C A Combinaison améliore la qualité Robustesse contrats Robustesse locale capacité des contrats à détecter des erreurs Det(A,C) Robustesse globale

  42. Un exemple Eiffel

  43. p_date.e p_time.e p_date_time.e Total number of mutants 673 275 199 Nbr equivalent 49 18 15 Mutation score 100% 100% 100% Initial contracts efficiency 10,35% 17,90% 8,7% Improved contracts 69,42% 91,43% 70,10% efficiency First version test size 106 93 78 Reduced tests size 72 33 44 Exemple

  44. Exemple • Robustesse des autotests contre un environnement infecté • p_date_time selftest

  45. Robustesse

  46. Logiciel classique Logiciel conçu par contrats Traitement d’exception Zone de diagnostique Zone de diagnostique Diagnosabilité

  47. 1000 Efficacité des contrats 900 800 700 0.2 600 0.4 Diagnosabilité 500 0.6 400 0.8 300 200 100 0 0 0,2 0,4 0,6 0,8 1 Densité des contrats Diagnosabilité

  48. Résultats • Étude qualitative de la conception par contrats • Bilan L’ajout de contrats, même peu efficaces, améliore la qualité du composant L’efficacité améliore plus que la densité

  49. Diagnostic et test

More Related