integration testing beyond unit testing. 2 testing in the v-model requirements detailed design...
TRANSCRIPT
Integration Testing
Beyond unit testing
2
Testing in the V-Model
Requirements
DetailedDesign
Moduleimplementation
Unit test
Integration test
System test
Acceptancetest
Run
tes
tsW
rite tests
CustomerDeveloper
Functional(BB)
Structural(WB)
ArchitecturalDesign
3
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
Testing stages
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
1
A 10 B
D E 11 12 13 14 15
2 3 4 5 6 7 8 9
C
16 17 F 22
18 19 20 21 23 24 25 26 27
Example functional decomposition
7
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
10
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
11
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
Bottom-Up Integration
Top Subtree(Sessions 29-32)
Second Level Subtree(Sessions 25-28)
Bottom Level Subtree(Sessions 13-17)
13
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
Sandwich Integration
16
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
1
5
7
20
21
9
10
12
11
16
17 18 19
22
2324
2526
142 36 8
4
13
15
27
18
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
Some Pair-wise Integration Sessions
1
5
7
20
21
9
10
12
11
16
17 18 19
22
2324
2526
142 36 8
4
13
15
27
20
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
1
5
7
20
21
9
10
12
11
16
17 18 19
22
2324
2526
14 2 36 8
4
13
15
27
Two Neighborhood Integration Sessions
22
Pros and Cons of Call-Graph Integration 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
1
2
3 4
5
6
A B1
2
3
4
C1
2
5
4
3 3
4
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
MM-Path Example
28
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>
Module execution paths
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
MEP(A,2)
MEP(B,1)
MEP(C,1)
MEP(B,2)
MEP(A,3)
MEP(A,1)
MEP(C,2)
The MM-Path graph for our example.
The solid arrows indicate messages and the corresponding returns are indicated by dotted arrows.
MM-Path Graph Example
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