La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Test et diagnostic : des objets aux modèles Yves Le Traon « in God we trust, for the rest we test » (A. Petrenko)

Présentations similaires


Présentation au sujet: "Test et diagnostic : des objets aux modèles Yves Le Traon « in God we trust, for the rest we test » (A. Petrenko)"— Transcription de la présentation:

1 Test et diagnostic : des objets aux modèles Yves Le Traon « in God we trust, for the rest we test » (A. Petrenko)

2 24/03/20062 Une « vision » de la recherche en génie logiciel 0 1 « Testing can prove the presence of bugs, but never their absence » Dijkstra Bienvenue dans le domaine de l’incertitude !!! 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 solution idéalepratique actuelle bon dosage ?

3 24/03/20063 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 24/03/20064 Problématique Le test Vérification/preuve tests conformité du produit par rapport à sa spécification

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

6 24/03/20066 Problématique du test Pourquoi ? Coût Effort Confiance

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

8 24/03/20068 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 24/03/20069 Le test des logiciels à objets Au départ… une certaine méfiance des testeurs…

10 24/03/200610 Sentiment mitigé au niveau du code C.m1() B.m1()A.m1() C.m4() B.m2() Method calls flow for processing C.m1() A m1() m2() m3() m4() B w m1() m2() m3() C m1() m4() The Yo-yo Effect (Binder, Offut) calls super() calls m4() calls m2() Implements

11 24/03/200611 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 24/03/200612 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 24/03/200613 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 24/03/200614 Test-first development Écrire un cas de test Exécuter les cas de test Faire un petit changement Exécuter les cas de test échec succès échec développement s’arrête développement continue Exemple : ajout dans une liste chainée public void testAdd(){ list.add("first"); assertTrue(list.size()==1); } 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){}

15 24/03/200615 Des objets aux modèles refactoring Tissage composition code refactoring

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

17 24/03/200617 Plan Test de composants Assemblage de composants Test « système » Diagnostic Test et modèles

18 24/03/200618

19 24/03/200619 Composants et test

20 24/03/200620 Composants de confiance Du point de vue utilisateur... Components “off-the-shelf” ?

21 24/03/200621 Composants de confiance Du point de vue utilisateur... Components “off-the-shelf” 85% “replay” selftests 100% 55% 100%

22 24/03/200622 Composant de confiance Spécification Implantation V & V : ensemble de cas de test Confiance fondée sur la cohérence contrats exécutables Composants autotestables

23 24/03/200623 Analyse de mutation R. 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

24 24/03/200624 Analyse de mutation P Génératio n de mutants Mutant 1 Mutant 2 Mutant 3 Mutant 4 Mutant 5 Mutant 6 CT Exécutio n Mutant tué Diagnosti c Mutant vivant Spécification incomplète Automatique Manuel Optimiseu r Mutant équivalent Supprimé de l’ensemble des mutants Ajout de contrats Cas de test insuffisants

25 24/03/200625 Optimisation automatique de cas de test Score de mutation moyen facile à atteindre Comment optimiser ces tests Analogie avec l’évolution

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

27 24/03/200627 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ération – … Classer Mémoriser Filtrer Muter Bouillon bacteriologique Ensemble solution Arrêt La boucle bactériologique

28 24/03/200628 La boucle bactériologique Fonction d’utilité (F) – Indique la pertinence d’un ensemble de bactéries pour le problème considéré Classer Mémoriser Filtrer Muter 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 Bouillon bacteriologique Ensemble solution

29 24/03/200629 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 – … Classer Mémoriser Filtrer Muter Bouillon bacteriologique Ensemble solution

30 24/03/200630 Ensemble solution 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 – … Classer Mémoriser Filtrer Muter Bouillon bacteriologique

31 24/03/200631 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é Classer Mémoriser Filtrer Muter Bouillon bacteriologique Ensemble solution

32 24/03/200632 La boucle bactériologique Fonction d’utilité (F) – Indique la pertinence d’un ensemble de bactéries pour le problème considéré Classer Mémoriser Filtrer Muter 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 Bouillon bacteriologique Ensemble solution

33 24/03/200633 Étude d’un parser C#

34 24/03/200634 Résultats Approche composant autotestable Algorithme original pour la génération de cas de test Développement d’outils pour les expériences

35 24/03/200635 Assemblage de composants

36 24/03/200636 Test d’intégration Plan de test – ordonnancement – minimiser le nombre de « testing stubs »

37 24/03/200637 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

38 24/03/200638 Test « système »

39 24/03/200639 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

40 24/03/200640 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

41 24/03/200641 Métamodèle d’exigences requirement 1.1 "Register a book" the "book" becomes "registered" after the "librarian" did "register" the "book". the "book" is "available" after the "librarian" did "register" the "book". 8 Métamodèle d’objectifs de tests :C1:C2:C3 CallAction 12 Métamodèle statique C1 C2 C3 0..1* Métamodèle UCTS s1 s2s3 s4 /a1 /a5 /a4 /a3 /a2 7 Métamodèle de cas d’utilisation Package Actor UseCase > {observable(x)="dummy"} > {true} 3 4 Métamodèle de configuration :C1 :C2 :C1 observable="dummy" status="on" 5 6 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

42 24/03/200642 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 ?

43 Nominal code

44 24/03/200644 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

45 24/03/200645 Diagnostic « mais où ? »

46 24/03/200646 Diagnostic et Design-by-contract

47 24/03/200647 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

48 24/03/200648 Robustesse A Robustesse localecapacité des contrats à détecter des erreurs Combinaison améliore la qualité Robustesse globale B C A contrats Det(A,C)

49 24/03/200649 Un exemple Eiffel

50 24/03/200650 Exemple p_date.ep_time.ep_date_time.e Total number of mutants673275199 Nbr equivalent491815 Mutation score100% Initial contracts efficiency10,35%17,90%8,7% Improved contracts efficiency 69,42%91,43%70,10% First version test size1069378 Reduced tests size723344

51 24/03/200651 Exemple Robustesse des autotests contre un environnement infecté p_date_time selftest

52 24/03/200652 Robustesse

53 24/03/200653 Zone de diagnostique Logiciel classiqueDiagnosabilité Zone de diagnostique Logiciel conçu par contrats Traitement d’exception

54 24/03/200654 Diagnosabilité 00,20,40,60,81 Densité des contrats Diagnosabilité 0 100 200 300 400 500 600 700 800 900 1000 0.2 0.4 0.6 0.8 Efficacité des contrats

55 24/03/200655 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é

56 24/03/200656 Diagnostic et test

57 24/03/200657 Test et diagnostic : objectifs différents 2 activités à relier Test – générer un minimum de données de test qui satisfont le critère d’arrêt. – Les fautes sont détectées. Diagnostic – les algorithmes de localisation des fautes nécessitent de recouper un maximum d’informations.

58 24/03/200658 Recoupement de traces ? ? Nombre de cas de test + capacité à isoler la faute

59 24/03/200659 Fault localization algorithm Error : it should be p := -y Diagnosis matrix

60 24/03/200660 Précision du diagnostic Diagnosis accuracy. – the number of statements one has to examine before finding a fault. Dynamic Basic Block (DBB). – P the program under test – TS a test suite. – A DBB = {s  statements of P / s hat is covered by strictly the same test cases of TS}

61 24/03/200661 Exemple : la réunion virtuelle Bacteriological algorithm maximizing the number of DBBs

62 24/03/200662

63 24/03/200663 Améliorer la localisation Combiner – contrats – Test – Recoupement de traces/slices

64 24/03/200664 Des objets aux modèles

65 24/03/200665 Des objets aux modèles Tester des modèles ? – Condition: l’exécutabilité – Vérification de propriétés – Typage Tester les transformations de modèles – Quelques pistes

66 24/03/200666 Métamodèle de sortie décrit Modèle de sortie Transformations de modèles Account name EString type EString balance EInt Client name EString age EInt Account name EString type EString balance EInt Client name EString age EInt Transformation de modèles Spécifie RDBMSmodel : Parameter2 direction = output UMLmodel : Parameter1 direction = input T : Transformation Langage : l OCLexpression : pre direction = input OCLexpression : post direction = input Métamodèle d’entrée décrit Modèle d’entrée

67 24/03/200667 Le test des transformations de modèles Les données sont des modèles Nouveaux critères Nouveaux algorithmes Mais la vue en toujours valide

68 24/03/200668 Le test des transformations de modèles Génération des données de test Critère = la mutation Oracle -> contrats

69 24/03/200669 Génération de données de test ClassA String name ClassB Int val *a*a 1b1b random« »null ]1;  [ 10 1 [1;  [ 0 ]-  ;-1] Critère AllPerEC StopCriteria = 2 ClassA name : toto ClassA name : «» ClassB val : 0 a

70 24/03/200670 Le test de transformations de modèles Oracle Le test de transformations de modèles Oracle Le problème de l’oracle – Disposant du modèle attendu : Comparaison de modèles – Conformité du modèle à son métamodèle [travaux de Jim Steel] – Contrats (OCL) Contrats sur le modèle de sortie Contrats de la spécification de la transformation

71 24/03/200671 Oracle Contrat de la spécification fort Oracle Contrat de la spécification fort En OCL: context MetaUmlRdbms inv:self.modelUml.elements ->select(e|e.oclIsTypeOf(Class) and e.stereotype->exists(s|s.name='persistent')) ->collect(ecp|ecp.oclAsType(Class)) ->forAll(cp|self.database.elements ->one(t|t.name=cp.name and cp.feature.union(cp.generalization.parent->collect(p|p.oclAsType(Class)).feature) ->select(f|f.oclIsTypeOf(Attribute))->collect(fa|fa.oclAsType(Attribute)) ->forAll(a|t.columns->one(tc|tc.name=a.name and tc.type=a.type.name)) and t.columns.size()=cp.feature.union(cp.generalization.parent ->collect(p|p.oclAsType(Class)).feature) ->select(f|f.oclIsTypeOf(Attribute)).size())) and self.database.elements.size()=self.modelUml.elements ->select(e|e.oclIsTypeOf(Class) and e.stereotype ->exists(s|s.name='persistent')).size()

72 24/03/200672 Analyse de mutation pour les transformations de modèles Opérateurs classiques – Orientés objet ou non Outil µjava de Offutt Nécessité d’opérateurs spécifiques – Opérateurs sémantiques

73 24/03/200673 L’analyse de mutation Décomposition sémantique Navigation, filtrage, création, modification – Exemple de transformation name : string ID : int A B "persistent" name : string ID : int A B "persistent" name : string ID : int A B "persistent" table B name : string ID : int A ID name table B name : string ID : int A B "persistent" ID name table B ID name table B (a) (b) (c) (d) (e) (f) B "persistent" navigation filtrage création navigation création navigation filtrage modification

74 24/03/200674 Fault models Example for navigation mutations Wrong role to a correct class: from class A, navigate b2 instead of b1 Wrong role to a wrong class: from class A, navigate c instead of b1 Miss one successor: from class A, navigate b1.f instead of b2.f.d Extra successor:from class A, navigate b1.f.d instead of b2.f

75 24/03/200675 Analyse de mutation / Oracle Résultats expérimentaux Analyse de mutation / Oracle Résultats expérimentaux Difficulté du test ++++

76 24/03/200676 Modèles & Aspects Design Model Use Case Model Security Model QoS Model Business Model Object Model Test Model UI Model Plateforme Model Code Model tester Challenges: -Tissage automatique -Product Families (variations) -Réutilisation de transformations Challenges: -Tissage automatique -Product Families (variations) -Réutilisation de transformations

77 24/03/200677 Conclusion modèles Contributions – Génération de données de test – Mutation pour l’IDM – Oracle par contrats

78 24/03/200678 Largeur et perspectives Le facteur dispersion Transformation de modèles Tissages de vues : d’aspects Diagnostic Et composants Traçabilité Raffinement des tests Test guidé par les exigences

79 24/03/200679 Questions ?


Télécharger ppt "Test et diagnostic : des objets aux modèles Yves Le Traon « in God we trust, for the rest we test » (A. Petrenko)"

Présentations similaires


Annonces Google