Integration Testing

Testing needed as the elements of a system are being combined.

Types: No incremental (Big-Bang) testing
Incremental testing

No incremental testing
All the elements are combined at once and tested.
It is difficult because errors cannot be easily attributed to particular elements.

Incremental testing
Elements are added and tested incrementally.
In What orders should the elements be integrated.
• Top-down
• Bottom-up
• Threads

Top-Down Strategy
The root module is tested first.
Stubs take the place of other modules called by the root module.
A new module called by one of the already integrated modules is added and tested with others.
The process continues in this manner until all modules have been integrated and tested.
Advantages:
Advantageous if major flaws occur toward the top of the program.
Early skeletal program allows partial demonstration.
Disadvantages:
Before the I/O modules are added, the representation of test cases in stubs can be difficult.
Test cases are possibly in a different form for each level and must be continuously altered.

Bottom-Up Strategy
Lower level modules are tested first using drivers.
Higher-level modules are added after all the modules they call have been added.
The process continues in this manner until all modules have been integrated and tested.
Advantages:
Advantageous if major flaws occur toward the bottom of the program.
Test conditions are easier to create.
Observation of test results is easier.
Disadvantages:
The program as an entity does not exist until the last module is added.
As system sub trees are integrated at higher levels, several modules may be brought together for the first time in one step.

Thread Strategy
A variation of top-down strategy.
Input and output modules are added as early as possible.
Choose a set of modules (the thread) that represents a normal, important case, or a critical path through the system.

Advantages:
Other threads can be integrated in parallel.
Early skeleton versions are available early.
It also improves programmers’ morale.

Reviews

Code Walk-Through

Select some test cases.
Simulate execution of the code by hand.
Guidelines:
The number of people involved should be small (3-5).
The participants should receive written documentation from the designer a few days before the meeting.
The meeting should last a predefined amount of time.
Discussion should be focused on the discovery of errors, not fixing them, nor on proposing alternative design decisions.
Key people should be
• designer, presenting the rationale of the work.
• moderator for the discussion.
• secretary for writing a report.
Managers should not participate in the meeting.

Code Inspections
Similar to the code walk-through.
The analysis is aimed at the discovery of commonly made errors.
A list of some classical programming errors:
Use of uninitialized variables.
Jumps into loops.
Incompatible assignments.
Nonterminating loops.
Array indexes out of bound.
Improper storage allocation-deallocation.
Actual-formal parameter mismatches.
Comparisons of equality for floating point values.