Integration Testing
Chapter 13
Integration Testing
Test the interfaces and interactions among separately tested
units
Three different approaches
Based on functional decomposition
Based on call graphs
Based on paths
INT–2
Functional Decomposition
Functional Decomposition
Create a functional hierarchy for the software
Problem is broken up into independent task units, or
functions
Units can be run either
Sequentially and in a synchronous call-reply manner
Or simultaneously on different processors
Used during planning, analysis and design
INT–3
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 15! 1.3.2! Key Sensor
D! 1.1.1! Door Sense & Control C! 1.4! Manage Session
2! 1.1.1.1 ! Get Door Status 16! 1.4.1 ! Validate Card
3! 1.1.1.2 ! Control Door 17! 1.4.2! Validate PIN
4! 1.1.1.3 ! Dispense Cash 18! 1.4.2.1 ! GetPIN INT–4
E! 1.1.2! Slot Sense & Control F! 1.4.3 ! Close Session
5! 1.1.2.1 ! WatchCardSlot 19! 1.4.3.1 ! New Transaction Request
6! 1.1.2.2 ! Get Deposit Slot Status
Decomposition-based integration
Four strategies
Top-down
Bottom-up
Sandwich
Big bang
INT–5
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
INT–6
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
INT–7
Top-Down integration example
Top-Down Integration
Top Subtree
(Sessions 1-4)
Second Level Subtree
(Sessions 12-15)
Botom Level Subtree
(Sessions 38-42)
INT–8
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, stubs and drivers are needed
INT–9
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
Do until all subsystems are included in the testing
Special driver code is needed to do the testing
The driver is a specialized routine that passes test cases to
a subsystem
Subsystem is not everything below current root module,
but a sub-tree down to the leaf level
INT–10
Bottom-up integration example
Bottom Level Subtree
(Sessions 13-17)
Second Level Subtree
(Sessions 25-28)
Top Subtree
(Sessions 29-32)
INT–11
Bottom-Up Integration Issues
Not an optimal strategy for functionally decomposed systems
Tests the most important subsystem (user interface) last
More useful for integrating object-oriented systems
Drivers may be more complicated than stubs
Less drivers than stubs are typically required
INT–12
Sandwich Integration
Combines top-down strategy with bottom-up strategy
Less stub and driver development effort
Added difficulty in fault isolation
Doing big-bang testing on sub-trees
INT–13
Sandwich integration example
INT–14
Integration test metrics
The number of integration tests for a decomposition tree is
the following
Sessions = nodes – leaves + edges
For SATM have 42 integration test sessions, which
correspond to 42 separate sets of test cases
For top-down integration nodes – 1 stubs are needed
For bottom-up integration nodes – leaves drivers are
needed
For SATM need 32 stubs and 10 drivers
INT–15
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
Vertices are program units; e.g. methods
A directed edge joins calling vertex to the called vertex
Adjacency matrix is also used
Do not scale well, although some insights are useful
Nodes of high degree are critical
INT–16
SATM call graph example
Call Graph of the SATM System
5
1 Look a adjacency
7
matrix p204
20
21 22
9 16
4
10
13
12
11 17 18 19 23
24
26
27 25
6 8 2 3
14 15
INT–17
Call graph integration strategies
Two types of call graph based integration testing
Pair-wise Integration Testing
Neighborhood Integration Testing
INT–18
Pair-Wise Integration
The idea behind Pair-Wise integration testing
Eliminate need for developing stubs / drivers
Use actual code instead of stubs/drivers
In order not to deteriorate the process to a big-bang strategy
Restrict a testing session to just a pair of units in the call
graph
Results in one integration test session for each edge in the
call graph
INT–19
Some
Pair-wise Pair-wisesession
integration Integration Sessions
example
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
INT–20
Neighbourhood integration
The neighbourhood of a node in a graph
The set of nodes that are one edge away from the given
node
In a directed graph
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 more difficult
INT–21
Neighbourhood integration example
Two Neighborhood Integration Sessions
5
1
Neighbourhoods
7 for nodes 16 & 26
20
21 22
9 16
4
10
13
12
11 17 18 19 23
24
26
27 25
6 8 2 3
14 15
INT–22
Pros and Cons of Call-Graph Integration
Aim to eliminate / reduce the need for drivers / stubs
Development effort is a drawback
Closer to a build sequence
Neighborhoods can be combined to create “villages”
Suffer from fault isolation problems
Specially for large neighborhoods
INT–23
Pros and Cons of Call-Graph Integration – 2
Redundancy
Nodes can appear in several neighborhoods
Assumes that correct behaviour follows from correct units and
correct interfaces
Not always the case
Call-graph integration is well suited to devising a sequence of
builds with which to implement a system
INT–24
Path-Based Integration
Motivation
Combine structural and behavioral type of testing for
integration testing as we did for unit testing
Basic idea
Focus on interactions among system units
Rather than merely to test interfaces among separately
developed and tested units
Interface-based testing is structural while interaction-based is
behavioral
INT–25
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.
INT–26
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 returns control
to the message source.
INT–27
MM-Path
An interleaved sequence of module execution paths and
messages.
Describes 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.
There is no correspondence between MM-paths and DD-
paths
The intersection of a module execution path with a unit is the
analog of a slice with respect to the MM-path function
INT–28
MM-Path Example
1 A B 1 C
1
2
2 2 3
3 4
3 4
5
4
5
6
MM-path
Source nodes
Sink nodes
MEP(A,1) = <1, 2, 3, 6>
MEP(A,2) = <1, 2, 4>
Module Execution Paths MEP(A,3) = <5, 6>
MEP(B,1) = <1, 2> MEP(C,1) = <1, 2, 4, 5>
MEP(B,2) = <3, 4> MEP(C,2) = <1, 3, 4, 5>
INT–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
INT–30
MM-path graph example
MEP(A,2) MEP(B,1)
MEP(A,1) MEP(C,2) MEP(C,1)
MEP(A,3) MEP(B,2)
Solid lines indicate messages (calls)
Dashed lines indicate returns from calls
INT–31
MM-path guidelines
How long, or deep, is an MM-path? What determines the end
points?
Message quiescence
Occurs when a unit that sends no messages is reached
Module C in the example
Data quiescence
Occurs when a sequence of processing ends in the
creation of stored data that is not immediately used
(path D1 and D2)
Quiescence points are natural endpoints for MM-paths
INT–32
MM-Path metric
How many MM-paths are sufficient to test a system
Should cover all source-to-sink paths in the set of units
What about loops?
Use condensation graphs to get directed acyclic graphs
Avoids an excessive number of paths
INT–33
Pros and cons of path-based integration
Hybrid of functional and structural testing
Functional – represent actions with input and output
Structural – how they are identified
Avoids pitfall of structural testing (???)
Fairly seamless union with system testing
Path-based integration is closely coupled with actual system
behaviour
Works well with OO testing
No need for stub and driver development
There is a significant effort involved in identifying MM-paths
INT–34
MM-path compared to other methods
Strategy Ability to test Ability to test Fault isolation
interfaces co-functionality resolution
Functional Acceptable, can Limited to pairs Good to faulty
decomposition be deceptive of units unit
Call-graph Acceptable Limited to pairs Good to faulty
of units unit
MM-path Excellent Complete Excellent to unit
path level
INT–35
