Integration Testing

Beyond unit testing

 Testing in the V-Model
Requirements Acceptance
Customer test
Developer
Architectural System test
Design

Detailed Integration test

Design Functional
(BB)
Module Structural
Unit test (WB)
implementation

2
Testing stages
 Unit testing
 Testing of individual components
 Integration testing
 Testing to expose problems arising from the combination
of components
 System testing
 Testing the complete system prior to delivery
 Acceptance testing
 Testing by users to check that the system satisfies
requirements. Sometimes called alpha testing

3
Layered Tests

http://www-128.ibm.com/developerworks/java/library/j-aopwork11/
4
Integration Testing
 Testing the interfaces and interactions
among separately tested units
 Three different approaches
 Based on functional decomposition
 Based on call graph
 Based on paths

5
Functional Decomposition
 Functional Decomposition is defined as a
method in which a problem is broken up into
several independent task units, or functions,
which can be run either sequentially and in a
synchronous call-reply manner or
simultaneously on different processors
 This method is used during planning, analysis
and design, and creates a functional
hierarchy for the software

6
 Example functional decomposition
Functional Decomposition of the SATM System

A 10 B C

D E 11 12 13 14 15 16 17 F 22

2 3 4 5 6 7 8 9 18 19 20 21 23 24 25 26 27

Table 1: SATM Units and Abbreviated Names Unit Level Unit Nam
Unit Level Unit Name B 1.3 Terminal Sense & Control
1 1 SATM System 14 1.3.1 Screen Driver
A 1.1 Device Sense & Control 7
15 1.3.2 Key Sensor
Top-Down Integration
 Top-down integration strategy focuses on
testing the top layer or the controlling
subsystem first (i.e. the main, or the root of
the call tree)
 The general process in top-down integration
strategy is to gradually add more subsystems
that are referenced/required by the already
tested subsystems when testing the
application
 Do this until all subsystems are incorporated
into the test
8
Top-Down Integration
 Special code is needed to do the testing
 Test stub
 A program or a method that simulates the
input-output functionality of a missing
subsystem by answering to the
decomposition sequence of the calling
subsystem and returning back simulated
data

9
 Top-Down Integration

Top Subtree
(Sessions 1-4)

Second Level Subtree

(Sessions 12-15)

Botom Level Subtree

(Sessions 38-42)
Top-Down Integration Issues
 Writing stubs can be difficult especially when
parameter passing is complex. Stubs must
allow all possible conditions to be tested
 Possibly a very large number of stubs may be
required, especially if the lowest level of the
system contains many functional units
 One solution to avoid too many stubs:
Modified top-down testing strategy
 Test each layer of the system decomposition
individually before merging the layers
 Disadvantage of modified top-down testing: Both,
11
stubs and drivers are needed
Bottom-Up Integration
 Bottom-Up integration strategy focuses on
testing the units at the lowest levels first
 Gradually includes the subsystems that
reference/require the previously tested
subsystems
 This is done repeatedly until all subsystems
are included in the testing
 Special driver code is needed to do the
testing
 The driver is a “fake” routine that requires a
subsystem and passes a test case to it
12
 Bottom-Up Integration

Bottom Level Subtree

(Sessions 13-17)

Second Level Subtree

(Sessions 25-28)

Top Subtree
(Sessions 29-32)
Bottom-Up Integration Issues
 Not optimal strategy for functionally
decomposed systems:
 Tests the most important subsystem (UI) last
 More useful for integrating object-oriented
systems
 Drivers may be more complicated than stubs
 Less drivers than stubs are typically required

14
Sandwich Integration
 Combines top-down strategy with
bottom-up strategy
 Less stub and driver development effort
 Added difficulty in fault isolation

15
Sandwich Integration
Call Graph-Based Integration
 The basic idea is to use the call graph instead
of the decomposition tree

 The call graph is a directed, labeled graph

 Two types of call graph based integration

testing
 Pair-wise Integration Testing
 Neighborhood Integration Testing

17
 Call Graph of the SATM System
5
1
7

20

21 22

9 16

4
10

13
12

11 17 18 19 23
24

26
27 25

6 8 2 3
14 15
Pair-Wise Integration
 The idea behind Pair-Wise integration testing
is to eliminate the need for developing
stubs/drivers
 The objective is to use actual code instead of
stubs/drivers
 In order not to deteriorate the process to a
big-bang strategy, we restrict a testing
session to just a pair of units in the call graph
 The result is that we have one integration
test session for each edge in the call graph
19
 Some Pair-wise Integration Sessions
5
1
7

20

21 22

9 16

4
10

12 13

11 17 18 19 23
24

26
27 25

6 8 2 3
14 15
Neighbourhood Integration
 We define the neighbourhood of a node in a
graph to be the set of nodes that are one
edge away from the given node
 In a directed graph means all the immediate
predecessor nodes and all the immediate
successor nodes of a given node
 Neighborhood Integration Testing reduces the
number of test sessions
 Fault isolation is harder

21
 Two Neighborhood Integration Sessions
5
1
7

20

21 22

9 16

4
10

13
12

11 17 18 19 23
24

26
27 25

6 8 2 3
14 15
Pros and Cons of Call-Graph
Integration
 Call graph based integration techniques move
towards a behavioral basis
 Aim to eliminate / reduce the need for
drivers/stubs
 Closer to a build sequence
 Neighborhoods can be combined to create
“villages”
 Suffer from the fault isolation problem
especially for large neighborhoods
 Nodes can appear in several neighborhoods
23
Path-Based Integration
 The basic motivation is to combine structural
and behavioral type of testing for integration
testing as we did for unit testing
 The basic idea is to focus on interactions
among system units rather than merely to
test interfaces among separately developed
and tested units
 In this respect, interface-based testing is
structural while interaction-based is
behavioral
24
Extended Concepts (1)
 Source node:
 a program statement fragment at which program
execution begins or resumes.
 for example the first “begin” statement in a
program.
 also, immediately after nodes that transfer control
to other units.
 Sink node:
 a statement fragment at which program execution
terminates.
 the final “end” in a program as well as statements
that transfer control to other units.
25
Extended Concepts (2)
 Module execution path:
 a sequence of statements that begins with a
source node and ends with a sink node with no
intervening sink nodes.
 Message:
 a programming language mechanism by which
one unit transfers control to another unit.
 usually interpreted as subroutine invocations
 the unit which receives the message always
eventually returns control to the message source.

26
MM-Paths
 MM-Path:
 an interleaved sequence of module
execution paths and messages.
 we can describe sequences of module
execution paths that include transfers of
control among separate units.
 MM-paths always represent feasible
execution paths, and these paths cross unit
boundaries.

27
 MM-Path Example
4
1 A B 1 C
1

3 2
2 3
2
3 4
3 4

5
4 5
6

In module A nodes 1 and 5 are source nodes while

nodes 4 and 6 are sink nodes.
<1,2,4> and <1,2,3,6> are module execution paths
An MM-path is shown in bold
28
Module execution paths

 The complete list of module execution

paths:

MEP(A,1) = <1,2,3,6> MEP(B,1) = <1,2>

MEP(A,2) = <1,2,4> MEP(B,2) = <3,4>
MEP(A,3) = <5,6> MEP(C,1) = <1,2,4,5>
MEP(C,2) = <1,3,4,5>

29
MM-Path Graph
 Given a set of units their MM-Path graph is
the directed graph in which
 nodes are module execution paths
 edges correspond to messages and returns from
one unit to another
 The definition is with respect to a set of units
 It directly supports composition of units and
composition-based integration testing

30
 MM-Path Graph Example
MEP(A,2)

MEP(B,1)

MEP(A,1) MEP(C,1)

MEP(B,2)
MEP(C,2)
MEP(A,3)

The MM-Path graph for our example.

The solid arrows indicate messages and the corresponding
returns are indicated by dotted arrows.
31
Pros and cons of path-based
integration
 Path-based integration is closely
coupled with actual system behaviour
 There is a significant effort involved in
identifying MM-Paths
 No need for stub and driver
development

32