1. Integration Testing
This is the step after the individual pieces of code or modules (programs) are tested.
A set of programs do not exist in vacuum. They are inter-related mostly in some manner through:
Calling and passing controls
Calling and passing data or “pointers” to data
Types of Integration :
Decomposition Based Integration Testing
Call Graph Based Integration
Path Based Integration.

2. There are 4 major types of integration test for Decomposition Based test:
Top- down
Bottom-up
Combination (Sandwich)
Big Bang

3. 1.Top-down i) Once the root modules is “completed”,
we need to build 3 stubs to perform
integration test of root module with
stubs.
ii) Stub is “through away” code which acts like an original code.
iii) As the next level module is completed,
we would build more stubs to perform
the next level of integration test
vi) Continue this process until all the modules are tested

4. 2.Bottom-UP i) Once a set of bottom modules are
completed we would build a driver, at the
next higher level, to run the integration test.
ii) Driver is “through away” code which acts like an original code
iii) Continue this process until all the modules are tested

5. 3.Combination (Sandwich)
If this is completed
first, we may choose
to build 3 stubs to test
- Once a module is completed, we would
build the appropriate driver or stubs to
perform the integration test.
- Continue this process until all the modules
are tested
If these two are completed,
we may choose to build
a driver to test .

6. 4.Big-Bang - Wait for all the modules to be completed
and perform one integration (one link-edit).
Then test all the integrated modules
together.

7. Formula to calculate no.of integration sessions
number of test sessions = n – v + edges
n is no.of nodes
v is no.of leaves

8. 2.Call Graph Based Integration 2.1.Pair-Wise Integration
One of the key drawbacks to top-down or bottom-up testing is the need for constructing drivers and stub.
Pair wise integration testing waits for a “related pair” of modules to be completed and then test them. Thus it eliminates the stubs and drivers.

9. Example of Pair-wise TestingB E B C D E C D
Pair-wise test sessions : 4
1. A – B
2. B – C
3. B – D
4. A – E
Pair-wise test sessions : 4
1. A – B
2. A – C
3. A – D
4. A – E

10. 2.2“Neighborhood” Integration Testing
Neighborhood of a node is the set of nodes that are one edge away from the given node.
Thus the neighborhood of a node, n, are all the predecessors and successor nodes of n.
Number of neighborhoods is equal to number of interior nodes plus source nodes .

11. Number of “neighborhoods”
Numerically:
Neighborhoods = interior nodes + source node
substitute
Interior nodes = all nodes – ( source node + sink nodes)
Finally
Neighborhoods = all nodes – sink nodes

12. 3. Path based integration testing Some Definitions for Path-based Integration Test
Source node is the point where program execution starts
Sink node is the point where the program execution stops
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.
A message is a “mechanism” with which one unit of code transfers control to another unit of code; control return is also a message
An MM-path (module-to-module path) is an interleaved sequence of i) module execution paths and ii) messages
Sequence of “nodes” represent a module execution path
Sequence of “edges” represent the messages
An MM-Path Graph is the directed graph in which nodes are module execution paths and edges are messages.

13. A Simple Example of an MM-Path from text page 214
(Module A)
(Module B)
(Module C) 1 1 1 2 2 3 2 4 3 3 4 5 6 4 5
Source nodes :
A1 and A5
Sink nodes:
A4 and A6
Source nodes :
B1 and B3
Sink nodes:
B2 and B4
Source nodes : C1
Sink nodes: C5
A1= <1,2,3,6>; A2=<1,2,4> ; A3 = <5,6>
Module Execution Paths: B1= <1,2> ; B2 = <3,4>
C1= <1,2,4,5> ; C2= <1,3,4,5>

14. Simple Example of MM-Path Graph (from previous slide)B1 A1 C1 B2 C2 A3