SOFT 3406

Software Verification and

Validation
Week XI Part 2
Ahmet Feyzi Ateş

Işık University Faculty of Engineering and Natural Sciences

Department of Computer Science Engineering 
2022-2023 Spring Semester
Integration Testing
(cont’d)
Agenda:
- Decomposition Based Integration
- Call Graph Based Integration
- Path Based Integration
Call Graph Based Integration

✧ One of the drawbacks of decomposition-based integration

is that it leads to impossible test pairs.
✧ For example, Calendar main never directly refers to either
isLeap or weekDay, so those test sessions could not
occur.
✧ This deficiency can be resolved If call graph is used
instead,
✧ A Call Graph is developed by considering units as nodes
of a graph:
▪ if unit A calls (or uses) unit B, there is an edge from node A to node
B.
▪ this also applies to object-oriented software, in which nodes are
o-o units, and edges are method calls (messages).
✧ The call graph for the Calendar program is show below.

3
Call Graph of Calendar Program

4
 Call graph-based top-down integration
✧ Since edges in the Call Graph refer to actual
execution-time connections, one can repeat the discussion
made before based on stubs and drivers in the units of the
call graph.
✧ This will work, and also preserve the fault isolation feature
of the decomposition-based approaches.
▪ while avoiding its deficiencies.

First step in call graph based top-down integration.

5
Pairwise Integration

✧ The idea behind pairwise integration is to eliminate the

stub/driver development effort.
✧ Instead of developing stubs and/or drivers, why not use
the actual code?
✧ One integration test session for each edge in the call
graph.
▪ Every edge represents a pair of units to test.
✧ Results in an increased number of integration sessions
when a node (unit) is used by two or more other units.
✧ In the Calendar example;
▪ 15 separate sessions for top-down integration (one for each
stub replacement),
▪ increases to 19 sessions for pairwise integration (one for each
edge in the call graph).

6
Three pairs for pairwise integration.
- getDate and getDigits,
- nextDate and dayNumToDate, and
- weekDay and isFriday.

✧ Advantages:
▪ Higher degree of fault isolation.
▪ If a test fails, the fault must be in one of the two units.
✧ Disadvantage:
▪ For units involved on several pairs, a fix that works in
one pair may not work in another pair.

7
Neighborhood Integration

✧ The neighborhood of a node in a graph is the set of

nodes that are one edge away from the given node.
▪ Technically, this is a neighborhood of radius 1; in larger
systems, it makes sense to increase the neighborhood radius.

✧ In a directed graph, this includes all the immediate

predecessor nodes and all the immediate successor
nodes
▪ notice that these correspond to the set of stubs and drivers of
the node.

8
Three neighborhoods (of radius 1) for
Calendar
The neighborhoods for nodes:
- isValidDate,
- nextDate, and
- memorialDay
are shown

9
Calculating Neighborhoods

✧ We can always compute the number of neighborhoods

for a given call graph.
✧ Each interior node will have one neighborhood;
▪ An interior node has a nonzero indegree and a nonzero
outdegree.
✧ We have:
▪ Interior nodes = nodes – (source nodes + sink nodes)
▪ Neighborhoods = interior nodes + source nodes
▪ which combine to:
▪ Neighborhoods = nodes – sink nodes
✧ Neighborhood integration usually yields a reduction in
the number of integration test sessions, and it reduces
stub and driver development.

10
Pros and Cons of Call Based Integration

✧ Advantages:
▪ Call Graph based integration techniques move from a purely structural
basis toward a behavioral basis.
▪ Call graph integration is slightly better than the decomposition tree-based
approach.
▪ Neighborhood-based techniques reduce the stub/driver development
effort.
▪ call graph-based integration matches well with developments
characterized by builds and composition.
▪ this supports the use of neighborhood-based integration for systems
developed by life cycles in which composition dominates.
✧ Disadvantages:
▪ The biggest drawback to call graph-based integration testing is the fault
isolation problem, especially for big neighborhoods.
▪ What happens if (when) a fault is found in a node (unit) that appears in
several neighborhoods?
▪ For nodes which involve in several neighborhoods, resolving the fault in
one neighborhood; by changing the unit’s code in some way, means that
all the previously tested neighborhoods that contain the changed node
need to be retested.
11
Path Based Integration
✧ We already know that the combination of structural and
functional testing is highly desirable at the unit level;
✧ It would be nice to have a similar capability for integration
testing, as well.
✧ Instead of just testing interfaces among separately
developed and tested units,
▪ which is attempted by both decomposition and call based
approaches
✧ We shall focus on interactions among these units.
▪ Interfaces are structural; interaction is behavioral.
✧ When a unit executes, some path of source statements is
traversed.
✧ It is always possible that a call can go to another unit
along such a path. At that point, control is passed from the
calling unit to the called unit.
12
Some Definitions about program graphs

✧ A source node in a unit is a statement fragment at which

unit execution begins or resumes.
▪ The first executable statement in a unit is clearly a source
node.
▪ Source nodes also occur immediately after nodes that transfer
control to other units.
✧ A sink node in a unit is a statement fragment at which
unit execution terminates.
▪ The final executable statement in a program is clearly a sink
node
▪ so are statements that transfer control to other units.
✧ A module execution path is a sequence of statements
that begins with a source node and ends with a sink
node, with no intervening sink nodes.

13
Definitions (cont’d)

✧ A message is a programming language mechanism by

which one unit transfers control to another unit and
acquires a response from the other unit.
▪ Depending on the programming language, messages can be
interpreted as subroutine invocations, procedure calls, function
references, and the usual messages (method calls) in an
object-oriented programming language.
▪ We assume that the unit that receives a message (the
message destination) always eventually returns control to the
message source.
▪ Messages can pass data to other units.
✧ An MM-Path (Module-Message Path) is an interleaved
sequence of module execution paths and messages.

14
Example

In unit A;
- nodes a1, a5, and a6
are source nodes.
- nodes a4 and a8 are
sink nodes.
in unit B;
- nodes b1 and b3 are
source nodes,
- nodes b2 and b5 are
sink nodes.
Unit C has a single source
node;
- c1, and
- a single sink node, c9.

15
Example

Unit A contains three

module execution paths:
- <a1, a2, a3, a4>,
- <a4, a5, a7, a8>, and
- < a4, a6, a7, a8>.
The solid edges are edges
actually traversed in this
hypothetical example.
The dashed edges are in the
program graphs of the units as
stand-alone units, but they did
not “execute” in the
hypothetical MM-Path.

16
Definitions (cont’d)

✧ Given a set of units, their MM-Path graph

is the directed graph in which nodes are
module execution paths and edges correspond
to messages and returns from one unit to another.
▪ MM-Path graphs are defined with respect to a
set of units.
✧ Relationships among module execution
paths, program paths, DD-Paths, and
MM-Paths.
▪ A program path is a sequence of DD-Paths,
▪ An MM-Path is a sequence of module execution
paths.
MM-Path Graph of the above example.
17
Path Based Integration Applied

✧ MM-Paths are a hybrid of functional and structural testing.

✧ They are functional in the sense that they represent actions with inputs
and outputs.
✧ As such, all the functional testing techniques are potentially applicable.
✧ The net result is that the cross-check of the functional and structural
approaches is consolidated into the constructs for path-based
integration testing.
✧ Path-based integration testing works equally well for software
developed in the traditional waterfall process or with one of the
alternative life cycle models.
✧ Besides, the MM-Path concept applies directly to object-oriented
software.

18
Pros and Cons of Path Based Integration

✧ The most important advantage of path-based integration testing is

that it is closely coupled with actual system behavior,
▪ İnstead of the structural motivations of decomposition and call
graph-based integration.

✧ However, the advantages of path-based integration come at a

price:
▪ more effort is needed to identify the MM-Paths.
✧ This effort is probably offset by the elimination of stub and driver
development.

19
Drivers and Stubs

20
Drivers and Stubs

21
 Example: NextDate from Calendar

A main program with a functional

decomposition into several
procedures and functions.

the source code, the program

graphs, and the cyclomatic
complexity of the units in the
procedural version of NextDate is
given.

22
23
24
Decomposition Based Integration of
NextDate

✧ Integration based on the decomposition in given above is

problematic,
✧ The isLeap and lastDayOfMonth functions are never directly called
by the Main program, so these integration sessions would be
empty.
✧ The pairs involving integrationNextDate and GetDate,
IncrementDate, and PrintDate are all useful (but short) sessions.

25
Call Graph Based Integration

msg7
ValidDate
msg6

✧ Neighborhood integration based on the call graph would likely

proceed with the neighborhood of lastDayOfMonth, neighborhood
of ValidDate, followed by the neighborhood of integrationNextDate.

26
Integration Based on MM-Paths
✧ The four MM-Paths for May 27, 2020 :
Main (1, 2, 3)
msg1
GetDate (34, 56, 57-65, 66)
msg 7
validDate(35, 36, 37, 39, 40, 41, 42)
msg 6
LastDayOfMonth(22, 23, 24, 25, 33)
msg 6 return
validDate(42, 43, 45, 46, 47, 48, 50, 51, 52, 54, 55)
msg7 return
GetDate (66, 67)
msg1 return
Main(3, 4)
msg2
PrintDate(58, 59, 60)
msg2 return
Main(4, 5)
msg3
IncrementDate(68, 69)
msg 8
LastDayOfMonth(22, 23, 24, 25, 33)
msg 8 return
IncrementDate(70, 72, 75, 76, 77, 78)
msg 3 return
Main(5, 6)
msg4
PrintDate(58, 59, 60)
msg4 return
Main (6, 7)
27
MM-Path Graph of NextDate
msg3

msg3 return
IncrementDate

msg8 return

msg8

Module execution paths and messages

towards and back from PrintDate (msg2,
and msg4) are omitted to make the graph
less cluttered. 28
Coverage Metrics for MM-Paths

✧ Given a set of MM-Paths:

▪ MMP0: Every message sent
• Design test cases so that every message is sent at least once in
the MM-Path Graph
▪ MMP1: Correct response received for every message sent.
• Design test cases so that every message is sent at least once in
the MM-Path Graph, and a correct response is received for every
sent message.
▪ MMP2: Every unit execution path is traversed
• Design test cases so that every execution path in the MM-Path
Graph is traversed.

29
Comparison of Integration Testing Strategies

✧ Table below summarizes the comparisons between various

integration testing approaches.
✧ The significant improvement of MM-Paths as a basis for
integration testing is due to their exact representation of
dynamic software behavior.

Strategy Basis Ability to test Ability to test fault isolation

Interfaces interactions resolution
(co-functionality)

Functional acceptable but can be limited to pairs of units good, down to faulty unit
Decomposition based deceptive

Call Graph based acceptable limited to pairs of units good, down to faulty unit

Path based acceptable complete excellent, down to faulty

unit execution path

30