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

Test d’intégration pour des systèmes à objets Yves Le Traon

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

 Yves Le Traon 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.1. L’intégration: approches classiques

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

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

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

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

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

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

 Yves Le Traon 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.2. Le test d’intégration de classes par l’exemple

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

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

 Yves Le Traon Étape 1

 Yves Le Traon Étape 2

 Yves Le Traon Étape 3

 Yves Le Traon Étape 4

 Yves Le Traon Étape 5

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

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

 Yves Le Traon 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; }

 Yves Le Traon 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; }

 Yves Le Traon 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; }

 Yves Le Traon 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”); }

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

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

 Yves Le Traon 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.3. L’approche à objets et l’intégration

 Yves Le Traon (…) 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

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

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

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

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

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

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

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

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

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

 Yves Le Traon 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.4. Modélisation et stratégies d’ordonnancement

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

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

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

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

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

 Yves Le Traon 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 …

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

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

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

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

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

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

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

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

 Yves Le Traon 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!

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

 Yves Le Traon 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 [g, h, j, i, f][c, b, d][l, k] Candidate node = # max(fronds) B f i j g h 1

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

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

 Yves Le Traon 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  (

 Yves Le Traon Case study SMDS UML diagram

 Yves Le Traon Case study SMDS Test Dependency Graph

 Yves Le Traon SMDS realistic stubs

 Yves Le Traon Gnu Eiffel Compiler

 Yves Le Traon 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) times for random strategies

 Yves Le Traon Efficient Strategies for Integration and Regression Testing of OO Systems RCMCRTMTOptim. Strategies #stubs Min Mean Max Specific stubs

 Yves Le Traon Efficient Strategies for Integration and Regression Testing of OO Systems RCMCRTMTOptim. Strategies #stubs Min Mean Max Realistic stubs

 Yves Le Traon Results summary RCMCRTMTOptim. #stubs RCMCRTMTOptim. #stubs Min Mean Max SMDS case study GNU Eiffel case study Specific stubs countingRealistic stubs counting RCMCRTMTOptim. #stubs RCMCRTMTOptim. #stubs

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

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

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

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

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

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

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

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

 Yves Le Traon Efficient Strategies for Integration and Regression Testing of OO Systems An optimal solution components steps testers Reaches the optimal A Test Resources Driven example SMDS

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

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

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