Fundamentals of Software Engineering
- 1. 1 Integration Testing • Defined as a systematic technique for constructing the software architecture • At the same time integration is occurring, conduct tests to uncover errors associated with interfaces • Objective is to take unit tested modules and build a program structure based on the prescribed design • Two Approaches • Non-incremental Integration Testing • Incremental Integration Testing
- 2. 2 Non-incremental Integration Testing • Commonly called the “Big Bang” approach • All components are combined in advance • The entire program is tested as a whole • Chaos (disorder/confusion) results • Many seemingly-unrelated errors are encountered • Correction is difficult because isolation of causes is complicated • Once a set of errors are corrected, more errors occur, and testing appears to enter an endless loop
- 3. 3 Incremental Integration Testing • Three kinds • Top-down integration • Bottom-up integration • Sandwich integration • The program is constructed and tested in small increments • Errors are easier to isolate and correct • Interfaces are more likely to be tested completely • A systematic test approach is applied
- 4. 4 Top-down Integration • Modules are integrated by moving downward through the control hierarchy, beginning with the main module • Subordinate modules are incorporated in either a depth-first or breadth-first fashion • DF: All modules on a major control path are integrated • BF: All modules directly subordinate at each level are integrated • Advantages • This approach verifies major control or decision points early in the test process • Disadvantages • Stubs need to be created to substitute for modules that have not been built or tested yet; this code is later discarded • Because stubs are used to replace lower level modules, no significant data flow can occur until much later in the integration/testing process
- 5. 5 Bottom-up Integration • Integration and testing starts with the most atomic modules in the control hierarchy • Advantages • This approach verifies low-level data processing early in the testing process • Need for stubs is eliminated • Disadvantages • Driver modules need to be built to test the lower-level modules; this code is later discarded or expanded into a full-featured version • Drivers inherently do not contain the complete algorithms that will eventually use the services of the lower-level modules; consequently, testing may be incomplete or more testing may be needed later when the upper level modules are available
- 6. 6 Sandwich Integration • Consists of a combination of both top-down and bottom-up integration • Occurs both at the highest level modules and also at the lowest level modules • Proceeds using functional groups of modules, with each group completed before the next • High and low-level modules are grouped based on the control and data processing they provide for a specific program feature • Integration within the group progresses in alternating steps between the high and low level modules of the group • When integration for a certain functional group is complete, integration and testing moves onto the next group • Reaps the advantages of both types of integration while minimizing the need for drivers and stubs • Requires a disciplined approach so that integration doesn’t tend towards the “big bang” scenario
- 7. 7 Regression Testing • Each new addition or change to baselined software may cause problems with functions that previously worked flawlessly • Regression testing re-executes a small subset of tests that have already been conducted • Ensures that changes have not propagated unintended side effects • Helps to ensure that changes do not introduce unintended behavior or additional errors • May be done manually or through the use of automated capture/playback tools • Regression test suite contains three different classes of test cases • A representative sample of tests that will exercise all software functions • Additional tests that focus on software functions that are likely to be affected by the change • Tests that focus on the actual software components that have been changed
- 8. 8 Smoke Testing • Taken from the world of hardware • Power is applied and a technician checks for sparks, smoke, or other dramatic signs of fundamental failure • Designed as a pacing mechanism for time-critical projects • Allows the software team to assess its project on a frequent basis • Includes the following activities • The software is compiled and linked into a build • A series of breadth tests is designed to expose errors that will keep the build from properly performing its function • The goal is to uncover “show stopper” errors that have the highest likelihood of throwing the software project behind schedule • The build is integrated with other builds and the entire product is smoke tested daily • Daily testing gives managers and practitioners a realistic assessment of the progress of the integration testing • After a smoke test is completed, detailed test scripts are executed
- 9. 9 Benefits of Smoke Testing • Integration risk is minimized • Daily testing uncovers incompatibilities and show-stoppers early in the testing process, thereby reducing schedule impact • The quality of the end-product is improved • Smoke testing is likely to uncover both functional errors and architectural and component-level design errors • Error diagnosis and correction are simplified • Smoke testing will probably uncover errors in the newest components that were integrated • Progress is easier to assess • As integration testing progresses, more software has been integrated and more has been demonstrated to work • Managers get a good indication that progress is being made