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

Présentation au sujet: "Test d’intégration pour des systèmes à objets"— Transcription de la présentation:

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

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

3 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

4 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

5 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).

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

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

8 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

9 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

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

11 (…) 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

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

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

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

15 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

16 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

17 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

18 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

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

20 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

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

22 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

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

24 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

25 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

26 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

27 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

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

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

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

31 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

32 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

33 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

34 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

35 Éliminer les doublons A A A A B B B B A A A A B B B B

36 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é …

37 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

38 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

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

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

41 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

42 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

43 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

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

45 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

46 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

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

48 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

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

50 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

51 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

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

53 Case study SMDS UML diagram

54 Case study SMDS Test Dependency Graph

55 SMDS realistic stubs

56 Gnu Eiffel Compiler

57 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) times for random strategies

58 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

59 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

60 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

61 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

62 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

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

64 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

65 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

66 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

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

68 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

69 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

70 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

71 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

72 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

73 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

74 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

75 Répartition des testeurs: Ex 1
A Test Resources Driven example SMDS An optimal solution components steps testers Reaches the optimal 37 nœuds, 4 testeurs => (minimum = 10)

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

77 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

78 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

79 Le nombre de bouchons réalistes

80 Le nombre de bouchons spécifiques

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

82 Efficacité relative – bouchon spécifique

83 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

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

85 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

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

87 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

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

89 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

90 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

91 Changement de taille maîtrisable

92 Changement de taille maîtrisable

93 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

94 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

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

96 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