0% found this document useful (0 votes)
3K views

Testing Lecture 15 - Call Graph, Path-Based Integration

The document discusses different integration testing techniques based on call graphs. It describes pairwise integration which tests all pairs of units without stubs/drivers. Neighborhood integration selects units in a depth-first order to avoid stubs/drivers. Path-based integration uses module execution paths and messages to define MM-paths between units for testing. The techniques aim to reduce testing effort compared to traditional decomposition-based integration.

Uploaded by

ahmad
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
3K views

Testing Lecture 15 - Call Graph, Path-Based Integration

The document discusses different integration testing techniques based on call graphs. It describes pairwise integration which tests all pairs of units without stubs/drivers. Neighborhood integration selects units in a depth-first order to avoid stubs/drivers. Path-based integration uses module execution paths and messages to define MM-paths between units for testing. The techniques aim to reduce testing effort compared to traditional decomposition-based integration.

Uploaded by

ahmad
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 29

Software Testing & Implementation

Lecture No. 15
Last Lecture Review

 Integration Testing
 Based on Functional Decomposition
 Top-Down
 Bottom-up
 Sandwich
 Big Bang

2 Software Testing
What Will You Learn Today?

 Call Graph-Based Integration


 Pair-Wise Integration
 Neighborhood Integration
 Path-Based Integration

3 Software Testing
Call Graph-Based Integration

4 Software Testing
Call Graph-Based Integration

 One of the drawbacks of decomposition


based integration is that the basis is the
functional decomposition tree
 Call graph mitigate this deficiency
 Behavioral testing
 Two approaches to integration testing
 Pair-wise integration
 Neighborhood integration

5 Software Testing
Pair-Wise Integration

 The idea behind pair-wise integration is to


eliminate the stub/driver development effort

 Similar to top-down or bottom-up integration

 Uses real code instead of stubs / drivers

 Reduces testing effort (no need to write


stubs/drivers)
6 Software Testing
Pair-Wise Integration

7 Software Testing
Neighbourhood Integration

 Typical top-down or bottom-up strategy


testing selects nodes in the breadth-first
order

 Neighbourhood integration selects nodes in


the depth-first order

 Avoids the need to write stubs / drivers

8 Software Testing
Neighbourhood Integration

 The neighborhood of a node in a graph is the


set of nodes that are one edge away from the
given node

 In a directed graph, this includes all the


immediate predecessor nodes and all the
immediate successor nodes (these
correspond to the set of stubs and drivers of
the node)

9 Software Testing
Neighborhood Integration

2 3 5
4

6
7 8 9 10 11 12 13 14 15 16

25 26 27 28 29 30 31 32 33
17 18 19 20 21 22 23 24

10 Software Testing
Neighborhood Integration

Node Predecessors Successors


…. …. ….
3 1 8, 9, 10
16 5 29, 30, 31, 32, 33
… … …
… … …
… … …
… … …

11 Software Testing
Neighbourhood Integration

 Source node: a node with indegree= 0


 Sink node: a node with outdegree= 0
 Interior nodes = nodes-(source nodes + sink nodes)

Neighborhoods = interior nodes + source nodes

Neighborhoods = nodes – (source nodes + sink


nodes) + source nodes

Neighborhoods =nodes –sink nodes

12 Software Testing
Pros & Cons

+ Eliminate the stub/driver development effort.


+ Matches well with developments
characterized by build and composition

‒ The biggest drawback is the fault isolation


problem, specially for large neighborhood.
Resolving a fault in a node means changing
the unit’s code which in turn means that all
previously tested neighborhoods that contain
the changed node need to be tested
13 Software Testing
Path-Based Integration

14 Software Testing
Path-Based Integration

 A source node in a program is a statement


fragment at which program execution begins
or resumes
 A sink node in a program is a statement
fragment at which program execution
terminates
 A Module Execution Path (MEP) is a
sequence of statements that begins with a
source node and ends with a sink node
15
Path-Based Integration

 A message is a programming language


mechanism by which one unit transfers
control to another unit – Examples: procedure
call, function references

 An MM-path is an interleaved sequence of


module execution paths and messages

16 Software Testing
Path-Based Integration

 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

17
MM Paths

1
1 1
2

2 2 3

3 4
3 4
5

5
4
6

18
Source Nodes and Sink Nodes
A sink node in a program is a statement fragment at
which program execution terminates
Source Nodes
1

Sink Nodes 2

3 4

A source node in a program is a statement fragment


at which program execution begins or resumes
19
MM Paths
A sink node in a program is a statement fragment at
which program execution terminates
Source Nodes

Sink Nodes

A source node in a program is a statement fragment


at which program execution begins or resumes
20
MM Paths
A sink node in a program is a statement fragment at
which program execution terminates
Source Nodes

1
Sink Nodes
2 3

A source node in a program is a statement fragment


at which program execution begins or resumes
21
MM Paths
A sink node in a program is a statement fragment at
which program execution terminates
Source Nodes
1
1 1
Sink Nodes 2

2 2 3

3 4
3 4
5

5
4
6

A source node in a program is a statement fragment


at which program execution begins or resumes
22
Module Execution Path (MEP)

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


 MEP (A, II) = < 1, 2, 4 >
 ….
 ….
 ….
 ….
 ….

23
Module Execution Path (MEP)

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


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

24
MM Paths

1
1 1
MEP (A, II)
MEP (B, I) MEP (C, II)
2

MEP (A, I) 2 2 3

3 4
MEP (C, I)
3 4
5

5
4
6
MEP (B, II)
MEP (A, III)

25
Pros & Cons

+ MM-Paths are a hybrid of functional and


structural testing

+ Path-based integration works equally well for


software developed in the traditional waterfall
process or with one of the composition-based
alternative life cycle models

+ Path-based integration testing is closely


coupled with the actual system behavior
26
Pros & Cons

‒ More effort is needed to identify the MM-


Paths. This effort is probably offset by the
elimination of stub and driver development.

27
Recap

 Call Graph-Based Integration


 Pair-Wise Integration
 Neighbourhood Integration
 Path-Based Integration

28
Questions

29

You might also like