Integration and System Testing
On this page 8 headings
Integration testing
Begin integration testing when a few or all modules have been unit-tested. The objective is to detect interface errors such as parameter passing and communication errors. In the lecture example, M1 calls M2, M3 and M4, with M5 below.
Big bang
In big bang integration, integrate all modules in one step. Errors are hard to localise. This is meaningful only for small systems, never for large systems.
Bottom up
In bottom up integration, integrate each subsystem first: M1, M2 and M3 form one subsystem, and M4 and M5 another. Then combine them. No stubs are needed; drivers simulate the global variables.
Top down
In top down integration, start with the root and one or two subordinate modules, then proceed to the next level: M1 → M2, M3, M4 → M5. No drivers are needed; stubs stand in for modules such as M5.
Mixed integration
Combine bottom up and top down integration as modules become available after unit testing.
System testing
Test the fully integrated system. Alpha testing uses the organisation’s test team; beta testing uses selected customers; acceptance testing lets the customer check requirements or user stories and decide whether to accept delivery.
Smoke testing
Before initial system testing, including alpha or beta, smoke testing runs a few basic cases to check basic functionality, such as adding products to the catalogue or inventory.
Performance and stress testing
Performance testing checks non-functional requirements. Stress testing is a type of performance testing that goes beyond design capacity in input volume, processing time or memory. It checks reliability and robustness, for example by simulating database transactions beyond expected capacity.