 Yves Le Traon 2005 1 Plan 1.Problématique du test 2.Rappels test de logiciel 3.Test de composants unitaires OO 4.Test d'intégration 5.Test système 6.Diagnostic.

Présentation au sujet: " Yves Le Traon 2005 1 Plan 1.Problématique du test 2.Rappels test de logiciel 3.Test de composants unitaires OO 4.Test d'intégration 5.Test système 6.Diagnostic."— Transcription de la présentation:

1  Yves Le Traon 2005 1 Plan 1.Problématique du test 2.Rappels test de logiciel 3.Test de composants unitaires OO 4.Test d'intégration 5.Test système 6.Diagnostic

2 Test d’intégration pour des systèmes à objets Yves Le Traon yletraon@irisa.fr Yves.letraon@francetelecom.com

3  Yves Le Traon 2005 3 Plan 1.Problématique du test 2.Rappels test de logiciel 3.Test de composants unitaires OO 4.Test d'intégration 1.L’intégration: approches classiques 2.Le test d’intégration de classes par l’exemple 3.L’approche à objets et l’intégration 4.Modélisation et stratégies d’ordonnancement 5.Test système 6.Diagnostic

4  Yves Le Traon 2005 4 Plan 1.Problématique du test 2.Rappels test de logiciel 3.Test de composants unitaires OO 4.Test d'intégration 1.L’intégration: approches classiques 2.Le test d’intégration de classes par l’exemple 3.L’approche à objets et l’intégration 4.Modélisation et stratégies d’ordonnancement 5.Test système 6.Diagnostic

5 4.1. L’intégration: approches classiques

6  Yves Le Traon 2005 6 Contexte 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.

7  Yves Le Traon 2005 7 Test d’intégration Objectif  Vérifier l’interaction entre unités (méthode, classe ou package). 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 d’unités (ex. risque d’utilisation hors domaine).

8  Yves Le Traon 2005 8 Architecture de dépendances Unité à testerDépendance à tester

9  Yves Le Traon 2005 9 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)

10  Yves Le Traon 2005 10 Approche classique : De haut en bas Unité à testerDépendance à tester Dépendance sous test Unité sous test Bouchon de test (stub) Dépendance simulée Unité testée Dépendance testée

11  Yves Le Traon 2005 11 Approche classique : De bas en haut Unité à testerDépendance à testerUnité sous testUnité testéeDépendance sous testDépendance testée

12  Yves Le Traon 2005 12 Plan 1.Problématique du test 2.Rappels test de logiciel 3.Test de composants unitaires OO 4.Test d'intégration 1.L’intégration: approches classiques 2.Le test d’intégration de classes par l’exemple 3.L’approche à objets et l’intégration 4.Modélisation et stratégies d’ordonnancement 5.Test système 6.Diagnostic

13 4.2. Le test d’intégration de classes par l’exemple

14  Yves Le Traon 2005 14 Intégration But : tester les interactions entre classes Lien entre test d’intégration et unitaire:  il faut ordonner les classes pour le test Il faut identifier les dépendances entre classes  Problème dans le cas de cycles de dépendances

15  Yves Le Traon 2005 15 Cas simple : un graphe acyclique Ordre partiel pour le test: F, (C, D), E, B, A A B E D C F Graphe de dépendances acyclique

16  Yves Le Traon 2005 16 Étape 1

17  Yves Le Traon 2005 17 Étape 2

18  Yves Le Traon 2005 18 Étape 3

19  Yves Le Traon 2005 19 Étape 4

20  Yves Le Traon 2005 20 Étape 5

21  Yves Le Traon 2005 21 Cas moins simple: présence de cycles DisplayBank Person Account Operation DOp WOp

22  Yves Le Traon 2005 22 Intégration avec cycles Il faut casser les cycles  développer des simulateurs de classes (« bouchon de test » ou « stub »)  un simulateur a la même interface que la classe simulée, mais a un comportement contrôlé Exemple

23  Yves Le Traon 2005 23 Exemples de stub /** * Creates an account for the person named name * If no client has this name, a new client object is created and is added to the list of clients, then the account is created * If the client exists the account is created, added to the bank's and the client's list of accounts */ public int addAccount(String name, float amount, float overdraft) { this.accountNumbers++; Person p = getClient(name); //if a client named name already exists in the bank's set of clients if (p!=null){ Account a = new Account(p, amount, overdraft, accountNumbers); p.addAccounts(a); this.addAccounts(a); } //if the client does not exist, add it tp the bank's list of clients and create account else{ Person client = new Person(name); this.addClients(client); Account a = new Account(client, amount, overdraft, accountNumbers); client.addAccounts(a); this.addAccounts(a); } return accountNumbers; }

24  Yves Le Traon 2005 24 Exemples de stub Stub 1 /** * Creates an account for the person named name * If no client has this name, a new client object is created and is * added to the list of clients, then the account is created * If the client exists the account is created, added to the bank's and the client's list of accounts */ public int addAccount(String name, float amount, float overdraft) { return 0; } Stub 2 /** * Creates an account for the person named name * If no client has this name, a new client object is created and is * added to the list of clients, then the account is created * If the client exists the account is created, added to the bank's and the client's list of accounts */ public int addAccount(String name, float amount, float overdraft) { return 1; }

25  Yves Le Traon 2005 25 Exemples de stub /** * Looks for a person named name in the set of clients. * Returns the Person object corresponding to the client if it exists * Returns null if there is no client named name */ public Person getClient(String name) { Iterator it = this.clientsIterator(); while (it.hasNext()){ Person p = (Person)it.next(); if(p.getName()==name){ return p; } return null; }

26  Yves Le Traon 2005 26 Exemples de stub Stub 1 /** * Looks for a person named name in the set of clients. * Returns the Person object corresponding to the client if it exists * Returns null if there is no client named name */ public Person getClient(String name) { return null; } Stub 2 /** * Looks for a person named name in the set of clients. * Returns the Person object corresponding to the client if it exists * Returns null if there is no client named name */ public Person getClient(String name) { return new Person(“toto”); }

27  Yves Le Traon 2005 27 Exemple Banque Exemple, pour tester en présence de ce cycle Person Account public class Person { /* * Initializes the name of the person with the param n * Creates a new vector to intialize the acounts set */ public Person(String n){ name = n; accounts = new Vector(); } public String getName(){return name;} } Stub de la classe Person public class Person { /* * Initializes the name of the person with the param n * Creates a new vector to initialize the accounts set */ public Person(String n){ } public String getName(){return (“toto”);} } Regarder quelles sont les méthodes de Person utilisées par Account

28  Yves Le Traon 2005 28 Exemple Banque Etape 1  Tester la classe Account avec le stub de Person Etape 2  Tester la classe Person avec Account Etape 3  Retester la classe Account avec la vraie classe Person

29  Yves Le Traon 2005 29 Plan 1.Problématique du test 2.Rappels test de logiciel 3.Test de composants unitaires OO 4.Test d'intégration 1.L’intégration: approches classiques 2.Le test d’intégration de classes par l’exemple 3.L’approche à objets et l’intégration 4.Modélisation et stratégies d’ordonnancement 5.Test système 6.Diagnostic

30 4.3. L’approche à objets et l’intégration

31  Yves Le Traon 2005 31 (…) Cycle de vie en « spirale » Intégration Réalisation Conception Analyse détaillée Analyse préliminaire « (de risque) » V1V2 Validation Synergie avec approche par objets

32  Yves Le Traon 2005 32 Test unitaire et d’intégration Classiquement  Étapes séparées Dans un cycle en spirale  Un composant unitaire ne peut pas être testé hors de son contexte d’exécution  > conséquence : test unitaire et test d’intégration sont des activités inséparables

33  Yves Le Traon 2005 33 Efficient Strategies for Integration and Regression Testing of OO Systems The problem domain: Use OO modeling for early Test Planning  Integration »deduced from UML models »to master integration cost and duration  Regression »separation of reusable tests from implementation  the test model must be refinable with design refinement stages.

34  Yves Le Traon 2005 34 Efficient Strategies for Integration and Regression Testing of OO Systems A OO test model must  be as simple as possible  easy to understand  limited to its purpose  catch all the information concerning test  test dependencies between components  from a rough to a precise level of detail –(class method)  determine design parts due to implementation choices  test cases reuse  test cases enhancement with system evolution Integration Regression

35  Yves Le Traon 2005 35 Efficient Strategies for Integration and Regression Testing of OO Systems Integration plan - What we have to deal with... Where to begin with ? How to organize test ? problem interdependencies loops of dependencies between components into an architecture

36  Yves Le Traon 2005 36 Efficient Strategies for Integration and Regression Testing of OO Systems A simple solution, with constraints on the design  no loops in an architecture  often possible but local optimizations are not always optimal for the architecture but designing interdependent components may also be relevant The solution presented here  takes any model  optimizes the way to deal with loops of interdependent components pck1pck2 pck3 pck4 S

37  Yves Le Traon 2005 37 Interdépendance Interdépendances  Cycle de dépendances  Composantes fortement connexes (CFC) Intégration  Big-Bang  Décomposer des CFCs – Utilisation de bouchons

38  Yves Le Traon 2005 38 Décomposition des CFCs – Bouchon Bouchon : une unité qui  simule le comportement d’une unité  évite l’utilisation des services d’autres unités de la même CFC. A B CC’ Bouchon réaliste A B C CFC A B C CACA CBCB Bouchon spécifique

39  Yves Le Traon 2005 39 Efficient Strategies for Integration and Regression Testing of OO Systems Integration Testing Based on a TDG, how to order components ?  Minimizing the number of stubs  realistic stub => dedicated simulator, « old component » C’ stub simulates the behavior of C when A and B are tested A Test depends on C’ C stub B Test depends on

40  Yves Le Traon 2005 40 Efficient Strategies for Integration and Regression Testing of OO Systems  Minimizing the number of stubs  specific stub => deterministic component behavior A Test depends on C B A C’ stub B Test depends on C’’ stub A stub for A and a stub for B

41  Yves Le Traon 2005 41 Plan 1.Problématique du test 2.Rappels test de logiciel 3.Test de composants unitaires OO 4.Test d'intégration 1.L’intégration: approches classiques 2.Le test d’intégration de classes par l’exemple 3.L’approche à objets et l’intégration 4.Modélisation et stratégies d’ordonnancement 5.Test système 6.Diagnostic

42 4.4. Modélisation et stratégies d’ordonnancement

43  Yves Le Traon 2005 43 Problème de test d’intégration Modéliser la structure de dépendances Décomposer des composantes fortement connexes en minimisant le coût de création des bouchons Planifier le test.

44  Yves Le Traon 2005 44 Modélisation et algorithmes d’ordonnancement

45  Yves Le Traon 2005 45 Efficient Strategies for Integration and Regression Testing of OO Systems The Test Dependency Graph preliminary modeling inheritance  Two basic types of test dependencies client/provider Contractual dependencies =  specified in the public part of classes  included in the body of internal methods Implementation dependencies = not contractual ones

46  Yves Le Traon 2005 46 Efficient Strategies for Integration and Regression Testing of OO Systems 2 types of nodes  class node  method node A A A … mA1(…)... A mA1 Class A Class node Method mA1 in Class A Method node in a class node The Test Dependency Graph preliminary modeling

47  Yves Le Traon 2005 47 Efficient Strategies for Integration and Regression Testing of OO Systems 3 types of edges  class_to_class  method_to_class  method_to_method … A B A is test dependent from B Semantic of a directed edge Semantic of a directed edge The Test Dependency Graph preliminary modeling

48  Yves Le Traon 2005 48 Efficient Strategies for Integration and Regression Testing of OO Systems Method_to_class A... +mA1(...v1: B...) … mA2(…v: A…)... A mA1 mA2 B Method_to_method A +mA1(...v: B...) {… v.mB1 …} +mA2(...v: A...) {… v.mA1 …} A mA1 mA2 B mB1 an action language (ASL/OCL) code level refinement …

49  Yves Le Traon 2005 49 Efficient Strategies for Integration and Regression Testing of OO Systems Class-to-class A B A B association A B composition A B aggregation A B navigability dependency A B A C B association class A B Interfaces Interface Name A B A B inheritance A BC

50  Yves Le Traon 2005 50 Modélisation statique 1/2 B A B A Une classeUn nœud A A A B A B A B A B B A A B A B B A A B A B h

51  Yves Le Traon 2005 51 Modélisation statique 2/2 A B A B B A B A «bind» <B><B> AB B A T A B B A B A B A A B

52  Yves Le Traon 2005 52 Modélisation dynamique C B AC B AC B AC B A A «abstract» BA BCD CA DA E AF FE et h hh h

53  Yves Le Traon 2005 53 Éliminer les doublons B A B A B A B A B A B A B A B A h h

54  Yves Le Traon 2005 54 Efficient Strategies for Integration and Regression Testing of OO Systems B +mB1(v1: C) … -pB1(v: C) -pB2(v: G) …. #redefine pA1 {…} D - pD1(v1:E, v2 : F) E F C H G +mA1(v1: C) {….} #pA1(…) {…} A F E B GH pA1 mB1 pB1 pB2 A C D mA1 pD1 pA1 Implementation dependency Client contractual dependency Inheritance contractual dependency

55  Yves Le Traon 2005 55 Efficient Strategies for Integration and Regression Testing of OO Systems Implementation-dependent graph F E B GH pA1 mB1 pB1 pB2 A C D mA1 pD1 pA1 Delete non-reusable part C D A mA1 B mB1 Contractual graph

56  Yves Le Traon 2005 56 Efficient Strategies for Integration and Regression Testing of OO Systems Normalization rules mB1 mB2 mB3 Preliminary test dependency graph A mA1 mA2 B Problem : Not a classical graph AB class-to-class graph solution 1 Loss of information A mA1 mA2 B mB1 mB2 mB3 mixed classes and methods graph solution 2 No loss of information homomorphism

57  Yves Le Traon 2005 57 Efficient Strategies for Integration and Regression Testing of OO Systems An efficient strategy (1) a b e k f d c i j g h l Optimal ordering => NP-complete complexity = n!

58  Yves Le Traon 2005 58 Efficient Strategies for Integration and Regression Testing of OO Systems An efficient strategy (2) Tarjan’s algorithm Determination and ordering of connected components A B C [(e) or C][A or B][(a)]then a b e k f d c i j g h l a b e k f d c i j g h l Complexity linear with #nodes

59  Yves Le Traon 2005 59 Efficient Strategies for Integration and Regression Testing of OO Systems An efficient strategy (3) Bourdoncle’s algorithm Break the connected component Reapply Tarjan [(e) or C][A or B][(a)]then f i j g h 2 3 4 5 [g, h, j, i, f][c, b, d][l, k] Candidate node = # max(fronds) B f i j g h 1

60  Yves Le Traon 2005 60 Result = a partial ordered tree  all possible strategies a b e k f d c i j g h l #specific stubs = 4 #realistic stubs = 3 Random selection Optimized algorithm #specific stubs = 9.9 #realistic stubs = 5 Partial ordered tree Efficient Strategies for Integration and Regression Testing of OO Systems

61  Yves Le Traon 2005 61 Exo Plan de test d’intégration pour : B E F H G A C D IJ

62  Yves Le Traon 2005 62 Cases Studies SMDS  Telecommunication Switching System: Switched Multimegabits Data Service  running on top of connected networks such as the Broadband Integrated Service Digital Network (B- ISDN)  based on the asynchronous transfer mode (ATM).  22 Kloc Gnu Eiffel Compiler  open-source Eiffel compiler  70 Kloc of Eiffel code  (http://SmallEiffel.loria.fr)

63  Yves Le Traon 2005 63 Case study SMDS UML diagram

64  Yves Le Traon 2005 64 Case study SMDS Test Dependency Graph

65  Yves Le Traon 2005 65 SMDS realistic stubs

66  Yves Le Traon 2005 66 Gnu Eiffel Compiler

67  Yves Le Traon 2005 67 Efficient Strategies for Integration and Regression Testing of OO Systems A comparison with 4 strategies  RC : Random Components selection  MC : Most Used Components  RT : Random Thread of Dependencies  MT : Most Used Components Threads of Dependencies (intuitive integration) 100 000 times for random strategies

68  Yves Le Traon 2005 68 Efficient Strategies for Integration and Regression Testing of OO Systems 25 26 27 28 20 36 26 39 34 20 48 26 47 38 20 0 10 20 30 40 50 60 RCMCRTMTOptim. Strategies #stubs Min Mean Max Specific stubs

69  Yves Le Traon 2005 69 Efficient Strategies for Integration and Regression Testing of OO Systems 13 19 18 19 9 21 19 25 24 9 29 19 30 27 9 0 5 10 15 20 25 30 35 RCMCRTMTOptim. Strategies #stubs Min Mean Max Realistic stubs

70  Yves Le Traon 2005 70 Results summary 22 25 22 32 25 35 28 9 43 46 34 0 10 20 30 40 50 RCMCRTMTOptim. #stubs 40 38 27 63 28 63 34 17 87 85 27 0 20 40 60 80 100 RCMCRTMTOptim. #stubs Min Mean Max SMDS case study GNU Eiffel case study Specific stubs countingRealistic stubs counting 25 27 28 36 26 39 34 20 48 47 38 0 10 20 30 40 50 60 RCMCRTMTOptim. #stubs 13 18 19 21 19 25 24 9 29 30 27 0 10 20 30 RCMCRTMTOptim. #stubs

71  Yves Le Traon 2005 71 Variantes possibles Mixte Big-Bang/Incrémental strict Planifier aussi le contexte dont on dépend (Pascale Thévenod)

72  Yves Le Traon 2005 72 Subsystem that can be integrated in one block (would need at least 1 stub) Remaining part of the system

73  Yves Le Traon 2005 73 Mixte Big-Bang/incrémental strict B E F H G A C D IJ

74  Yves Le Traon 2005 74 3 classes par composante : problème NP- complet … encore ! B E F H G A C D IJ Mixte Big-Bang/incrémental strict

75  Yves Le Traon 2005 75 6 classes par composante B E F H G A C D I J Mixte Big-Bang/incrémental strict

76  Yves Le Traon 2005 76 Taille max SCC 15 SMDS, 37 classes, 72 connects 99 SmallEiffel, 104 classes, 140 connects 11 InterViews, 146 classes, 419 connects 63 Pylon, 50 classes, 133 connects 31 Java, 588 classes, 1935 connects 76 Swing, 694 classes, 3819 connects 141 Mixte Big-Bang/incrémental strict

77  Yves Le Traon 2005 77 Efficient Strategies for Integration and Regression Testing of OO Systems A new problem  Testing Resources Optimal Repartition Using the partial ordered tree (acyclic) Assumption: a tester needs 1 time unit to integrate 1 component  to simplify presentation  Heuristic to reduce integration duration

78  Yves Le Traon 2005 78 Minimum steps >=max (A, B) A= longest_path B= [nb_nodes/nb_testers] +1 4 testers 37 nodes max length = 8 Minimum steps= 10 10 Property

79  Yves Le Traon 2005 79 Efficient Strategies for Integration and Regression Testing of OO Systems An optimal solution components steps testers 203318614 1422271624 12571734 24122344 1513293754 3110342864 211993274 83036584 263541194 23101 Reaches the optimal A Test Resources Driven example SMDS

80  Yves Le Traon 2005 80 Efficient Strategies for Integration and Regression Testing of OO Systems Allocate the needed resources to obtain the minimum integration duration : at least (88 div 7 +1 = ) 13 testers Minimum delay : 7 steps A Delay Driven example GNU Eiffel 1 2 3 4 5 7 6

81  Yves Le Traon 2005 81 Efficient Strategies for Integration and Regression Testing of OO Systems A Delay Driven example GNU Eiffel 7 steps = Optimum delay

82  Yves Le Traon 2005 82 Efficient Strategies for Integration and Regression Testing of OO Systems Conclusions  an adapted test model  Test Dependency Graph  efficient algorithms  for early stage test planning (UML)  integration  non-regression  evolving with design evolution  test economics criterion (early repartition of testing resources)