Test d’intégration pour des systèmes à objets Yves Le Traon yletraon@irisa.fr et Vũ Lê Hạnh

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. De quoi s’agit-il mon travail ?

Plan Introduction Intégration pour des systèmes à objets Notre solution Modélisation de la structure de dépendances Décomposition des composantes fortement connexes Parallélisation Comparaison des études de cas Stratégie mixte Conclusion et perspectives

Plan Introduction Intégration pour des systèmes à objets Notre solution Modélisation de la structure de dépendances Décomposition des composantes fortement connexes Parallélisation Comparaison des études de cas Stratégie mixte Conclusion et perspectives

Test d’intégration Objectif Difficultés principales de l’intégration 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).

Architecture de dépendances Unité à tester Dépendance à tester

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)

Approche classique : De haut en bas Unité testée Dépendance testée Dépendance sous test Unité sous test Unité à tester Dépendance à tester Bouchon de test (stub) Dépendance simulée

Approche classique : De bas en haut Unité à tester Dépendance à tester Unité sous test Dépendance sous test Unité testée Dépendance testée

Systèmes à objets Forte connectivité Architecture cyclique – Interdépendances

(…) Cycle de vie en « spirale » Intégration Réalisation Conception Analyse détaillée Analyse préliminaire « (de risque) » V1 V2 Validation Synergie avec approche par objets

(…) Composant vs Système? Unit Testing Composant unitaire Intégration Validation Evolution Regression Testing Composant système La vue classique continuité

(…) Composant vs Système? Test d'intégration Component Test de non-régression

(…)Langage UML- plusieurs vues : Operator : Device start( ) stop( ) Class diagram Sequence diagram Statecharts Implementation diagram

UML Unified Modeling Language (…) Langage UML UML Unified Modeling Language Class diagram A B Interfaces Interface Name A B inheritance A B navigability dependency A B Association A B composition A B aggregation A C B Association class

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

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

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 C CA CB Bouchon spécifique A B C CFC A B C C’ Bouchon réaliste

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.

Plan Introduction Intégration pour des systèmes à objets Notre solution Modélisation de la structure de dépendances Décomposition des composantes fortement connexes Parallélisation Comparaison des études de cas Stratégie mixte Conclusion et perspectives

État de l’art David C. Kung et al. – 1995 Kuo Chung Tai et Fonda J. Daniels – 1999 Lionel Briand et al. – 2001 Yvan Labiche et al. – 2000 Yves Le Traon et al. – 2000

D.C. Kung : Modélisation d’ORD B C E D …class A : …class B{ … C g_var_C; …m (…D par_D…){ E l_var_E; }; } Agrégation Héritage Association

D.C. Kung : Exemple d’un ORD A B C F H I E D G Association Agrégation Héritage

D.C. Kung : Décomposition et planification Niveau mineur 1 2 Niveau majeur 2 1 6 3 4 5 A B C F H I E D G Association D Bouchon Agrégation Héritage E F #bouchons specs. : 3 #bouchons réals. : 3

A B C F H I E D G D E F K.C.Tai et F.J. Daniels 2 1 3 Association Héritage Agrégation Association Association 1 2 3 D E Bouchon Agrégation Héritage 2 3 F #bouchons specs. : 4 #bouchons réals. : 3

Résultat Ordre Niveau Nœuds Simulateur Retester 1 1.1 C, A D (A ® D), E (A E) 2 1.2 B 3 2.1 G F (G F) 4 2.2 E ,F 5 E (A ® E), F (G F) 6 2.3 D 7 D (A D) 8 3.1 H 9 3.2 I

L. Briand : Décomposition des CFCs H I E D G Association D Bouchon F Agrégation Héritage 1 4 1 4 #bouchons specs. : 2 #bouchons réals. : 2

Y. Labiche : Traitement dynamique G F FG DA Bouchon Association Agrégation Héritage

Points d’amélioration Kung La modélisation est postérieure à la phase de développement La décomposition n’est pas stable La décomposition ne tient pas compte des étapes de retest L’ordonnancement est utilisé pour un seul testeur Tai-Daniels La décomposition n’est pas efficace Briand La décomposition ne tient pas compte directement de la nature des CFCs Labiche Le traitement dynamique est introduit après la décomposition.

Notre stratégie de planification Modélisation de la structure de dépendances : Dès la phase de conception : à partir d’UML. Traitement statique ainsi que dynamique (comme Labiche). Décomposition des CFCs Tenir compte directement la nature des CFCs : cycle de dépendances. Tenir compte de la nature des relations (comme Kung). Tenir compte des étapes de retest (comme Tai-Daniels). Ordonnancement Répartir le test sur plusieurs testeurs.

Plan Introduction Intégration pour des systèmes à objets Notre solution Modélisation de la structure de dépendances Décomposition des composantes fortement connexes Parallélisation Comparaison des études de cas Stratégie mixte Conclusion et perspectives

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

Modélisation- préliminaire 3 types d’arcs class_to_class method_to_class method_to_method A B A est dépendant de B pour le test Sémantique d’un arc orienté …

Modélisation des méthodes Method_to_class A ... +mA1(...v1: B...) … mA2(…v: A…) A B mA1 mA2 refinement Method_to_method A +mA1(...v: B...) {… v.mB1 …} +mA2(...v: A...) v.mA1 A B mA1 mB1 mA2 … an action language (ASL/OCL) code level

Autre exemple : les arcs class-to-method B Graphe classe-à-classe solution 1 Perte d’information mB1 mB2 mB3 Graphe préliminaire A mA1 mA2 B Pas un graphe classique A mA1 mA2 B mB1 mB2 mB3 Graphe classes et méthodes solution 2 Pas de perte homomorphism

Modélisation au niveau de méthode B A … m1 (…par_b : B…) { …X.m2 (…)… } A.m1 A X.m2 Méthode

Exemple D.mD F E F.mF D A A.mA C B H B.mA B.mB G

Autre exemple: dépendances d’implantation et dépendances contractuelles - pD1(v1:E, v2 : F) pD1 A E +mA1(v1: C) {….} #pA1(…) {…} A F F C pA1 C mA1 B +mB1(v1: C) … -pB1(v: C) -pB2(v: G) …. #redefine pA1 {…} H B pA1 mB1 pB1 G pB2 G H Dépendance d’implantation Dépendance contractuelle de type clientèle Dépendance contractuelle de type héritage

Autre exemple : extraction de la partie publique Graphe dépendant de l’implantation F E B G H pA1 mB1 pB1 pB2 A C D mA1 pD1 C D A mA1 B mB1 Graphe contractuel (spécification) Suppression des parties Non-réutilisables

Plan Introduction Intégration pour des systèmes à objets Notre solution Modélisation de la structure de dépendances Décomposition des composantes fortement connexes Parallélisation Comparaison des études de cas Stratégie mixte Conclusion et perspectives

Minimiser le nombre de bouchons (1/2) Objectif : Minimiser le coût de création des bouchons Minimiser le risque d’utilisation des bouchons Hypothèse Bouchon (Méthode).Coût = const Bouchon (Association).Coût = const Bouchon (Agrégation).Coût = const Bouchon (Association).Coût = Bouchon (Méthode).Coût + 1 Bouchon (Agrégation).Coût = Bouchon (Association).Coût + 2 1  0, 2  0 Bouchon.Coût = const La nature des CFCs : Composer de cycles de dépendances.

Minimiser le nombre de bouchons (2/2) Critère Simuler l’unité qui participe au nombre maximum de cycles Compter le nombre de cycles : Pour un arc : arc d’un des trois types Agrégation/Association/Méthode Pour un nœud : nombre total de tous les arcs entrants

La solution initiale Modélisation depuis UML Sans tenir compte des aspects dynamiques Considère comme unité d’intégration la classe aussi bien que la méthode Décomposition récursive des CFCs avec l’algorithme de Tarjan permettant de déterminer efficacement les CFCs Parallélisation de l’intégration Un premier algorithme

Optimalité ->NP-complet La solution initiale Un graphe de l’architecture (1) a b e k f d c i j g h l Optimalité ->NP-complet complexité = n!

La solution initiale (2) B A C Complexity linear with #nodes a a b e k f d c i j g h l f Tarjan’s algorithm b i g e c j h d k l A C Determination and ordering of connected components [(e) or C] then [A or B] then [(a)] Complexity linear with #nodes

La solution initiale (3) B f 5 f i 4 i g j 3 j g h h 1 2 algorithme de Bourdoncle f i 4 i nœud candidat = # max(fronds) g j 3 j g h h 1 2 B [(e) or C] then [A or B] then [(a)] Briser les SCCs Réappliquer Tarjan [l, k] [c, b, d] [g, h, j, i, f]

La solution initiale Result = a partial ordered tree all possible strategies a g Optimized algorithm d f #specific stubs = 4 b i #realistic stubs = 3 j c Random selection h e k #specific stubs = 9.9 Partial ordered tree #realistic stubs = 5 l

Les études de cas Étude de cas Nombre de classes Nombre de dépendances SMDS 37 72 Pylon 50 133 SmallEiffel 104 140 InterView 146 419 J2SE v1.31 588 1935 Swing de J2EE v1.31 694 3819

Etudes de cas SMDS Gnu Eiffel Compiler 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

SMDS realistic stubs

Gnu Eiffel Compiler

A comparison with 4 strategies 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 36 38 40 34 Min 27 28 #stubs 30 25 26 26 26 Mean 20 20 20 20 Max 10 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 19 19 19 18 19 Min 20 #stubs Mean 15 13 Max 9 9 9 10 5 RC MC RT MT Optim. Strategies

Results summary SMDS case study GNU Eiffel case study 22 25 32 35 28 9 43 46 34 10 20 30 40 50 RC MC RT MT Optim. #stubs 38 27 63 17 87 85 60 80 100 Min Mean Max SMDS case study GNU Eiffel case study Specific stubs counting Realistic stubs counting 36 26 39 48 47 13 18 19 21 24 29

Bouchon Réaliste Spécifique Max #cyclesMéthode Max #cyclesAssociation Max (#cyclesMéthode + #cyclesAssociation + #cyclesAgrégation) Max #cyclesMéthode Max #cyclesAssociation Spécifique Max #cyclesAgrégation

Minimiser le nombre d’utilisations des bouchons Objectif : Minimiser le nombre d’étapes de retest Minimiser le risque d’utilisation des bouchons Hypothèse Bouchon (Méthode).#Appels = const Bouchon (Association).#Appels = const Bouchon (Agrégation).#Appels = const Bouchon (Association).#Appels = Bouchon (Méthode). #Appels + 1 Bouchon (Agrégation).#Appels = Bouchon (Association). #Appels + 2 1  0, 2  0 Bouchon.Coût = const

Minimiser le nombre d’utilisations des bouchons Nombre d’arcs entrants Critère Simuler l’unité qui participe au nombre minimum de arcs entrants

Bouchon Réaliste Spécifique Max #entrantMéthode Min (#entrantMéthode + #entrantAssociation + #entrantAgrégation) Max #entrantMéthode Max #entrantAssociation Spécifique Méthode Association Agrégation

Exemple – bouchon réaliste 4 8 2 D 4 5 6 Bouchon 5 4 6 8 F 2 A B C H I G F E D 8 5 4 6 1 Association Agrégation Héritage

Exemple – bouchon spécifique 4 2 1 A A B C H I G F E D Association 4 1 2 6 4 5 6 2 H Bouchon 1 Agrégation 4 1 2 E Héritage 4 5 6 5 2 1 G 2 1 6

Exemple – comparatif avec Briand sans polymorphisme – notre solution G Association D Bouchon F Agrégation Héritage 1 2 1 2

Exemple – comparatif avec Briand sans polymorphisme – Briand G F E D Association D 1 4 2 3 1 6 Agrégation 1 E 4 2 1 3 H 3 6 2 Bouchon Héritage 2 3 4 1 2 4 1 1 2 4 1 4 1 2 3 1 G 1 6

Plan Introduction Intégration pour des systèmes à objets Notre solution Modélisation de la structure de dépendances Décomposition des composantes fortement connexes Parallélisation Comparaison des études de cas Stratégie mixte Conclusion et perspectives

Répartition des testeurs 1 testeur : Les feuilles d’abord. n testeurs (n > 1) Hypothèse Le temps de test de toutes les unités est identique Exemple n = 2 Un ordre possible : (B, F), (D, G), E, C, A Un ordre optimal : (G, F), (B, E), (C, D), A (B, G), (E, F), (C, D), A A B C D E F G

Répartition des testeurs Property 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

Répartition des testeurs A Delay Driven example GNU Eiffel 7 Allocate the needed resources to obtain the minimum integration duration : at least (88 div 7 +1 = ) 13 testers Minimum delay : 7 steps 6 1 5 3 4 2

Répartition des testeurs Branches : A-B A-C-E-G A-D-F Chemin critique A- C-E-G Répartition totale #testeurs = #branches temps_de_test = temps_de_test_de_chemin_critique A B C D E F G

Répartition des testeurs Condition : #testeurs < #branches Répartition : Choisir la feuille d’un chemin critique. Exemple avec 2 testeurs : 1er : G E C A 2nd : F B D Avantages : Profiter du temps libre d’un testeur sur les branches non-critiques A B C D E F G

Répartition des testeurs: Ex 1 A Test Resources Driven example SMDS An optimal solution components steps testers 20 33 18 6 1 4 14 22 27 16 2 4 1 25 7 17 3 4 24 12 2 3 4 4 15 13 29 37 5 4 31 10 34 28 6 4 21 19 9 32 7 4 8 30 36 5 8 4 26 35 4 11 9 4 23 10 1 Reaches the optimal 37 nœuds, 4 testeurs => (minimum = 10)

Répartition des testeurs: Ex 2 A Delay Driven example GNU Eiffel 7 steps = Optimum delay

Plan Introduction Intégration pour des systèmes à objets Notre solution Modélisation de la structure de dépendances Décomposition des composantes fortement connexes Parallélisation Comparaison des études de cas Stratégie mixte Conclusion et perspectives

Les études de cas Étude de cas Nombre de classes Nombre de dépendances SMDS 37 72 Pylon 50 133 SmallEiffel 104 140 InterView 146 419 J2SE v1.31 588 1935 Swing de J2EE v1.31 694 3819

Le nombre de bouchons réalistes

Le nombre de bouchons spécifiques

Efficacité relative – bouchon réaliste i {Kung, Tai-Daniels, Briand, Nœud, Arc} E = min {xi}/xi

Efficacité relative – bouchon spécifique

Plan Introduction Intégration pour des systèmes à objets Notre solution Modélisation de la structure de dépendances Décomposition des composantes fortement connexes Parallélisation Comparaison des études de cas Stratégie mixte Conclusion et perspectives

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

Stratégie mixte Constat : Objectif Hypothèse Solution Sous-systèmes souvent « très cohérents » Objectif Éviter d’introduire des bouchons dans les sous- systèmes cohérents Hypothèse Un testeur peut maîtriser un ensemble de n unités. Solution Arrête de décomposer quand la taille de CFC est inférieure à n

Mixte Big-Bang/incrémental strict D A E C F B G H I J

Mixte Big-Bang/incrémental strict 3 classes par composante : problème NP-complet … encore ! D A E C F B G H I J

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

Critère final Min poids_entrée Max (#cyclesMéthode + #cyclesAssociation + #cyclesAgrégation) Max #cyclesMéthode Max #cyclesAssociation Max taille_cycle Min (#entrantMéthode + #entrantAssociation + #entrantAgrégation) Max #entrantMéthode Max #entrantAssociation

F A B C H I G F E D Exemple 4 5 6 Bouchon 5 4 6 8 2 8 5 4 6 1 5 6 Bouchon 5 4 6 8 F 2 A B C H I G F E D 8 5 4 6 1 Association Agrégation Héritage

Changement de taille maîtrisable

Changement de taille maîtrisable

Mixte Big-Bang/incrémental strict Taille max SCC 1 5 SMDS, 37 classes, 72 connects 9 SmallEiffel, 104 classes, 140 connects InterViews, 146 classes, 419 connects 7 3 Pylon, 50 classes, 133 connects Java, 588 classes, 1935 connects Swing, 694 classes, 3819 connects 14

Plan Introduction Intégration pour des systèmes à objets Notre solution Modélisation de la structure de dépendances Décomposition des composantes fortement connexes Parallélisation Comparaison des études de cas Stratégie mixte Conclusion et perspectives

Conclusion Stratégie : Application La modélisation complète de la structure dépendance Une décomposition efficace Une parallélisation Application Le module TestStrategy de l’AGL Objecteering (Softeam)

Perspectives Décomposition Parallélisation Obtenir la complexité et le nombre d’utilisation des unités. Traiter la complexité des relations « doublons ». Estimer le seuil de complexité maîtrisable (nombre et poids d’une CFC). Chercher une heuristique pour équilibrer les CFCs décomposées. Parallélisation Chercher une heuristique pour améliorer la parallélisation