Plan

1. Plan • Problématique du test • Rappels test de logiciel • Test de composants unitaires OO • Test d'intégration • Test système • Diagnostic

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

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

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

5. 4.1. L’intégration: approches classiques

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. 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. Unité à tester Dépendance à tester Architecture de dépendances

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

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

12. Plan • Problématique du test • Rappels test de logiciel • Test de composants unitaires OO • Test d'intégration • L’intégration: approches classiques • Le test d’intégration de classes par l’exemple • L’approche à objets et l’intégration • Modélisation et stratégies d’ordonnancement • Test système • Diagnostic

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

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. A B E D C F Graphe de dépendances acyclique Cas simple : un graphe acyclique Ordre partiel pour le test: F, (C, D), E, B, A

16. Étape 1

17. Étape 2

18. Étape 3

19. Étape 4

20. Étape 5

21. Operation Account Display Bank WOp DOp Person Cas moins simple: présence de cycles

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. 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. 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. 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. 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. Account Person Exemple Banque • Exemple, pour tester en présence de ce cycle Regarder quelles sont les méthodes de Person utilisées par 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”);} }

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. Plan • Problématique du test • Rappels test de logiciel • Test de composants unitaires OO • Test d'intégration • L’intégration: approches classiques • Le test d’intégration de classes par l’exemple • L’approche à objets et l’intégration • Modélisation et stratégies d’ordonnancement • Test système • Diagnostic

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

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

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

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

37. Interdépendance • Interdépendances • Cycle de dépendances • Composantes fortementconnexes (CFC) • Intégration • Big-Bang • Décomposer des CFCs – Utilisation de bouchons

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

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

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

41. Plan • Problématique du test • Rappels test de logiciel • Test de composants unitaires OO • Test d'intégration • L’intégration: approches classiques • Le test d’intégration de classes par l’exemple • L’approche à objets et l’intégration • Modélisation et stratégies d’ordonnancement • Test système • Diagnostic

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

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. Modélisation et algorithmes d’ordonnancement

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

47. 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 …

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

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

50. Modélisation statique 1/2 B A B A h 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