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
