1. Integration - Application Systems Molderez Tim Van Leuvenhaege Matthias Yilmaz Ozkan

2. Chapter 13 Integration

3. Contents - Integration Definitions Why integration testing? Aspects of integration testing Dependency Analysis Integration Faults Integration Patterns

4. Definitions • System : set of components • Component : can consist of other components • Increment : set of components that correspond with subset of requirements • Stub : partial implementation of a component • Driver : system that applies test cases

5. Why integration testing? • Antidecomposition axiom :System scope test does not cover everything → Insufficient to test as a whole; also test components and the interaction in between. • Components work together→ Show that components are minimally interoperable.

6. Aspects of integration testing • Integration testing : Search for component faults that cause intercomponent failures. • How? • Which components? • In what sequence? • Which test design technique?

7. Aspects - scopes

8. Aspects - flexibility • Flexibility is important: • Not all components are available • Components change

9. Dependency Analysis • Composition and aggregation • Inheritance • Global variables • Calls to an API • Server objects • ...

10. Dependency Analysis

11. Dependency Analysis

12. Integration Faults • Example: 2/3 of the faults in a large C system were interface-related • Typical interface bugs: • Wrong parameters • Missing, overlapping or conflicting functions • Client violates server’s preconditions • Thread X will crash when process Y is running • …

13. Integration Patterns • Big Bang • Bottom-up • Top-down • Collaboration • Backbone • Layer • Client/Server • Distributed Services • High-frequency

14. Big Bang

15. Big Bang - (Dis)Advantages • Requires little effort • Few clues about fault locations • No distinction between critical and peripheral components • Interface faults can be hidden

16. Bottom-up

17. Bottom-up

18. Bottom-up

19. Bottom-up

20. Bottom-up

21. Bottom-up - (Dis)Advantages • Early testing • May proceed in parallel • Well suited to responsibility-based design • Driver development is most significant cost • Error-prone • Highest level of control and component interoperability tested at the end

22. Top-Down

23. Top-Down

24. Top-Down

25. Top-Down

26. Top-Down

27. Top-Down - (Dis)Advantages • Early testing • Reduced driver development (just 1 driver) • Stubs easier to code than drivers • Components may be developed in parallel • Large number of stubs • Complex test cases can require recoding of stubs • Fragile → Last minute changes • Late interoperability testing of all components

28. Collaboration

29. Collaboration

30. Collaboration

31. Collaboration - Advantages • Interface coverage with few test runs • Useful for system scope testing • Minimally coupled components of collaboration • End-to-end coverage sooner than bottom-up • Minimizes driver development costs

32. Collaboration - Disadvantages • Intercollaboration dependencies may be subtle • Not all collaborations may be covered • Scenario-based big bang • May require many stubs • Exercising lower-level components may be difficult • Specified collaborations may be incomplete

33. Backbone Backbone: infrastructure of a system Applications depend on backbone Combines top-down, bottom-up and big bang Known use: Windows NT

34. Backbone – Test backbone components

35. Backbone – Top-down control components

36. Backbone – Big bang the backbone

37. Backbone – Big bang & top-down

38. Backbone – Top-down the leaves

39. Backbone - (Dis)Advantages • Combines advantages of top-down and bottom-up • Begins on early side of the midpoint in development • Development and testing may proceed in parallel • Careful analysis of system structure anddependencies is necessary • Requires both drivers and stubs • Each backbone component must be adequately tested

40. Layer

41. Layer

42. Layer - (Dis)Advantages • Same as bottom-up or top-down Integration • If stack of layers needed as subsystem → Available at the earliest possible date, when using top-down variant • Viability of the stack untested until lowest layer is integrated • Mostly used in time-critical applications → Performance of the stack only tested at the end

43. Client/Server

44. Client/Server

45. Client/Server

46. Client/Server - (Dis)Advantages • Avoids the problems of big bang • Can be sequenced according to priority of risk • Drivers & test cases suitable for reuse • Controllable, repeatable testing • Cost of driver and stub development • Midway or late exercise of end-to-end use cases

47. Distributed Services

48. Distributed Services

49. Distributed Services

50. Distributed Services