560 likes | 743 Views
Test d’intégration pour des systèmes à objets. Yves Le Traon yletraon@irisa.fr. 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. Test d’intégration. Objectif
E N D
Test d’intégration pour des systèmes à objets Yves Le Traon yletraon@irisa.fr
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.
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).
Unité à tester Dépendance à tester Architecture de dépendances
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)
Unité à tester Dépendance à tester Unité sous test Dépendance sous test Bouchon de test (stub) Dépendance simulée Unité testée Dépendance testée Approche classique : De haut en bas
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
Analyse détaillée Analyse préliminaire « (de risque) » Conception V1 V2 Réalisation Validation Intégration (…) Cycle de vie en « spirale » Synergie avec approche par objets
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
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.
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
Efficient Strategies for Integration and Regression Testing of OO Systems Where to begin with ? How to organize test ? • Integration plan - What we have to deal with... problem interdependencies loops of dependencies between components into an architecture
S pck1 pck2 pck4 pck3 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
Interdépendance • Interdépendances • Cycle de dépendances • Composantes fortementconnexes (CFC) • Intégration • Big-Bang • Décomposer des CFCs – Utilisation de bouchons
A CA A A C C C’ C B CB B B Bouchon spécifique Bouchon réaliste CFC 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.
C Test depends on C’ A stub Test depends on B 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
C Test depends on Test depends on Test depends on C’ A A B stub Test depends on C’’ B stub Efficient Strategies for Integration and Regression Testing of OO Systems • Minimizing the number of stubs • specific stub => deterministic component behavior A stub for A and a stub for B
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.
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
A A Class A Class node A … mA1(…) ... A mA1 Method mA1 in Class A Method node in a class node Efficient Strategies for Integration and Regression Testing of OO Systems The Test Dependency Graph preliminary modeling 2 types of nodes • class node • method node
Semantic of a directed edge A is test dependent from B A B Efficient Strategies for Integration and Regression Testing of OO Systems The Test Dependency Graph preliminary modeling 3 types of edges • class_to_class • method_to_class • method_to_method …
Efficient Strategies for Integration and Regression Testing of OO Systems Method_to_class A ... +mA1(...v1: B...) … mA2(…v: A…) ... B A mA1 mA2 refinement Method_to_method A +mA1(...v: B...) {… v.mB1 …} +mA2(...v: A...) {… v.mA1 …} B A mB1 mA1 mA2 … an action language (ASL/OCL) code level
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 Efficient Strategies for Integration and Regression Testing of OO Systems Class-to-class A A B B aggregation composition
Modélisation statique 1/2 B A B A A A Une classe Un nœud A A A A A A A A A A B B B B B B B B B B
Modélisation statique 2/2 A A B B A A B B B A A B T A AB «bind» A A A <B> B B B B
Modélisation dynamique A C A C A C A C B B B B A «abstract» BA A F et E CA F E DA B C D
Éliminer les doublons A A A A B B B B A A A A B B B B
Efficient Strategies for Integration and Regression Testing of OO Systems pD1 D E D - pD1(v1:E, v2 : F) A E +mA1(v1: C) {….} #pA1(…) {…} A F F pA1 C C mA1 B +mB1(v1: C) … -pB1(v: C) -pB2(v: G) …. #redefine pA1 {…} H B pA1 mB1 pB1 G G H pB2 Implementation dependency Client contractual dependency Inheritance contractual dependency
Efficient Strategies for Integration and Regression Testing of OO Systems D pD1 E A F A pA1 C mA1 mA1 D Delete non-reusable part B B pA1 mB1 C mB1 pB1 G H pB2 Contractual graph Implementation-dependent graph
Loss of information B A A B Problem : Not a classical graph mB1 mA1 mB2 mA2 class-to-class graph mB3 Preliminary test dependency graph solution 1 solution 2 A mA1 B homomorphism mA2 mB2 mB1 mB3 mixed classes and methods graph No loss of information Efficient Strategies for Integration and Regression Testing of OO Systems Normalization rules
a f b i g e c j h d k l Efficient Strategies for Integration and Regression Testing of OO Systems • An efficient strategy (1) Optimal ordering => NP-complete complexity = n!
a f b i g e c j h d Determination and ordering of connected components k l Efficient Strategies for Integration and Regression Testing of OO Systems a B f • An efficient strategy (2) 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
Efficient Strategies for Integration and Regression Testing of OO Systems 5 f Bourdoncle’s algorithm • An efficient strategy (3) 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]
a c i b j f e h l Efficient Strategies for Integration and Regression Testing of OO Systems • Result = a partial ordered tree • all possible strategies g Optimized algorithm d #specific stubs = 4 #realistic stubs = 3 Random selection k #specific stubs = 9.9 Partial ordered tree #realistic stubs = 5
D F H I J G Exo • Plan de test d’intégration pour : A E C B
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)
Case study SMDS UML diagram
Case study SMDS Test Dependency Graph
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
Efficient Strategies for Integration and Regression Testing of OO Systems • Specific stubs 60 48 47 50 39 38 36 40 34 Min 28 27 26 26 26 30 #stubs 25 Mean 20 20 20 Max 20 10 0 RC MC RT MT Optim. Strategies
Efficient Strategies for Integration and Regression Testing of OO Systems • Realistic stubs 35 30 29 30 27 25 24 25 21 Min 18 19 19 19 19 20 #stubs Mean 13 15 Max 9 9 9 10 5 0 RC MC RT MT Optim. Strategies
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
Variantes possibles • Mixte Big-Bang/Incrémental strict • Planifier aussi le contexte dont on dépend (Pascale Thévenod)
Subsystem that can be integrated in one block (would need at least 1 stub) Remaining part of the system
D F H I J G • Mixte Big-Bang/incrémental strict A E C B
F H I J G Mixte Big-Bang/incrémental strict • 3 classes par composante : problème NP-complet … encore ! D A E C B
J Mixte Big-Bang/incrémental strict • 6 classes par composante D A E C F B H I G
Taille max SCC 1 5 SMDS, 37 classes, 72 connects 9 9 SmallEiffel, 104 classes, 140 connects 1 1 InterViews, 146 classes, 419 connects 6 3 Pylon, 50 classes, 133 connects 3 1 Java, 588 classes, 1935 connects 7 6 Swing, 694 classes, 3819 connects 14 1 Mixte Big-Bang/incrémental strict