27
Integration testing • Integrate two or more module.i.e. communicate between the modules. • Follow a white box testing (Testing the code)

Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

Embed Size (px)

Citation preview

Page 1: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

Integration testing

• Integrate two or more module.i.e. communicate between the modules.

• Follow a white box testing (Testing the code)

Page 2: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

Integration Testing - Overview

System DesignModule Spec

Module Test Doc

Test P lanning

IntegrationTest P lan

Tim

e

Sw Developm entDocum ents

TestActivities

TestDocum ents

Integration TestingOverview

Test Execution

Integrated Modules IntegrationTest Report

Test Case DesignTest Environm ent

InstallationIntegration

Test Specification

Page 3: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

Integration Testing

• The Big-bang Approach.• Incremental Approach.

3

Page 4: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

Integration Testing StrategiesTest methodologies may vary but two basic testing

strategies applied:• Test the software in its entirety

– “Big Bang Testing”• Test the software in modules - Unit Tests,

Integration Tests, Systems Tests – “Incremental testing”

• Two strategies for incremental testing– Bottom - up testing (test harness).– Top - down testing (stubs).

• Sandwich Testing

Page 5: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

Top-Down Integration Testing• Main program used as a test driver and stubs are substitutes for

components directly subordinate to it.• Subordinate stubs are replaced one at a time with real

components (following the depth-first or breadth-first approach).• Tests are conducted as each component is integrated.• On completion of each set of tests and other stub is replaced with

a real component.• Regression testing may be used to ensure that new errors not

introduced.

Page 6: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

Top Down Integration

• Stub is a piece of code emulating a called function

top module is tested with stubs

stubs are replaced one at a time, "depth first"

as new modules are integrated, some subset of tests is re-run

A

B

C

D E

F G

Page 7: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

Top down – Advantages & Disadvantages

• Top-down integration supports fault isolation;• Major design flaws show up early. Modules of a

product can be divided into two groups: – The logic modules and operational modules.– By coding and testing the logic modules before the

operational modules, top-down integration will exploit any major design faults early in the development process

• The main disadvantage of top-down integration is that potentially reusable modules may not be adequately tested.

Page 8: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

Bottom-Up Integration Testing• Low level components are combined in clusters that

perform a specific software function.• A driver (control program) is written to coordinate test

case input and output.• The cluster is tested.• Drivers are removed and clusters are combined moving

upward in the program structure.

Page 9: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

Bottom-Up Integration

• a driver is a piece of code emulating a calling function

drivers are replaced one at a time, "depth first"

worker modules are grouped into builds and integrated

A

B

C

D E

F G

cluster

Page 10: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

Bottom-up – Advantages & Disadvantages

• The operational modules are thoroughly tested when using a bottom-up strategy. It also provides fault-isolation, as does top-down integration.

• Major design faults will be left undetected until late in the development, since the logic module are integrated last.

• This may result in large costs in redesigning and recoding substantial portions of the project.

Page 11: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

Sandwich Testing• Combine the two so as to capitalize upon

their strengths and minimize their weaknesses

• neither top-down nor bottom-up inplemenetation/integration is suitable for all the modules, the solution is to partition them

Page 12: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

Sandwich TestingTop modules aretested with stubs

Worker modules are grouped into builds and integrated

A

B

C

D E

F G

cluster

Page 13: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

Top-Down Integration

13

top module is tested with stubs

stubs are replaced one at a time, "depth first"

as new modules are integrated, some subset of tests is re-run

A

B

C

D E

F G

Page 14: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

Bottom-Up Integration

14

drivers are replaced one at a time, "depth first"

worker modules are grouped into builds and integrated

A

B

C

D E

F G

cluster

Page 15: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

System Testing

• Confirms that the system as a whole delivers the functionality originally required.

• Follows the black box testing.

Page 16: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

System Testing - Goals

• Incorrect or missing feature• Performance errors• Security errors• User interface errors• Configuration and compatibility• Compliance to required standards

Page 17: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

System Testing - Overview

ProductRequirem ents

System Design

Test P lanning

SystemTest P lan

Tim

e

Sw Developm entDocum ents

TestActivities

TestDocum ents

System TestingOverview

Test Execution

Integrated System SystemTest Report

Test Case DesignTest Environm ent

InstallationSystem

Test Specification

Page 18: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

System Testing - Overview

• System Tests:– Define test procedures and instructions– Review test plans– Execute test plans– Record results

Page 19: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

System Testing - Strategy

• Developing System Tests– stress tests– security tests– recovery tests– performance tests

Page 20: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

System Testing

• System Functional Test– Test entire system against the functional requirements.

• System Performance Test– Test the non-functional requirements of the system. For

example,– Response times, load testing etc.

• System Acceptance Test– Set of tests that the software must pass before it is

accepted by the client.

20

Page 21: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

Regression Testing

• Change do not always effect the entire program.

• Change in one part of system can effect other part.

• After each change– Entire test suite of a system must be run again.

21

Need for an automatic test suite execution.

Page 22: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

Test Activities

• Boils down to selecting and executing test cases. Test case consists of……– Set of test inputs, of if the program is non-

terminating, a sequence of test inputs.– Expected results when the inputs are executed;

and – Execution conditions or execution environment in

which the inputs are to be executed.

22

These steps generally remain same from unit testing to system testing.

Page 23: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

Test Case Selection

• Coverage criterion;– Equivalence Partitioning– Boundary-Value Analysis– Coverage-Based Testing

• Control-flow• Data-flow

• Expected behavior of every test input to be generated. (Test Oracles)

• Testing environment.

23

Page 24: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

Test Oracles

• Determines whether or not the program has passed or failed the test case.

• A test oracle is – A program– A process– A body of data

• In many cases - directly form the requirements. • For example, a test case assessing performance -

performance threshold.

24Difficult to automate or to assess their quality

Page 25: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

Test Evaluation

• Compare the actual behavior with the expected behavior.

25

Generally can be automated to an extend !!!!

Page 26: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

Test Reporting

• Report the outcome of the testing.– Developers– Project Mangers etc.

26

Generally can be automated to an extend !!!!

Page 27: Integration testing Integrate two or more module.i.e. communicate between the modules. Follow a white box testing (Testing the code)

Testing Techniques

• White Box• Black Box• Incremental• Thread