integration testing beyond unit testing. 2 testing in the v-model requirements detailed design...

31
Integration Testing Beyond unit testing

Upload: clyde-atkinson

Post on 18-Jan-2016

263 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

Integration Testing

Beyond unit testing

Page 2: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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

Page 3: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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

Page 4: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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

Page 5: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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

Page 6: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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

Page 7: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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

Page 8: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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

Page 9: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System
Page 10: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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

Page 11: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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

Page 12: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

Bottom-Up Integration

Top Subtree(Sessions 29-32)

Second Level Subtree(Sessions 25-28)

Bottom Level Subtree(Sessions 13-17)

Page 13: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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

Page 14: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

14

Sandwich Integration Combines top-down strategy with

bottom-up strategy Less stub and driver development

effort Added difficulty in fault isolation

Page 15: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

Sandwich Integration

Page 16: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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

Page 17: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

1

5

7

20

21

9

10

12

11

16

17 18 19

22

2324

2526

142 36 8

4

13

15

27

Page 18: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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

Page 19: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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

Page 20: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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

Page 21: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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

Page 22: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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

Page 23: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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

Page 24: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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.

Page 25: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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.

Page 26: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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.

Page 27: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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

Page 28: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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

Page 29: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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

Page 30: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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

Page 31: Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

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