Written by Super User on . Posted in ERP Domain.
Integration testing is the phase of software testing in which individual software modules are combined and tested as a group. This happens after unit tests and before system tests. Integration testing takes as input modules that have been unit tested, groups them into larger aggregates, applies the tests defined in an integration test plan to those aggregates, and outputs the integrated system ready for system testing .
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into one component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of parts and possibly extend the process to test modules with those from other groups. Ultimately, all the modules making up a process are tested together.
Integration Testing Strategies
The larger the project, the more importance we should attach to the integration strategy. Very small systems are often assembled and tested in a single phase. For most real systems, this is impractical for two main reasons: first, the system would fail in so many places at once that the effort of debugging and retesting would be impractical. Second, it would be very difficult to meet any white box test criteria due to the large amount of detail separating the input data from the individual code modules. Most integration testing has traditionally been limited to “black box” techniques. Large systems may require many phases of integration, starting with assembling modules into low-level subsystems, then assembling subsystems into larger subsystems, and finally assembling higher level subsystems in the complete system.
Top-down integration testing
The top-down approach to integration testing requires the highest-level modules to be tested and integrated first. This allows high level logic and data flow to be tested early in the process and tends to minimize the need for drivers. However, the need for stubs complicates test management, and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is their poor support for early release of limited features.
Bottom-up integration testing
The bottom-up approach requires the lowest level units to be tested and integrated first. These units are frequently referred to as utility modules. By using this approach, utility modules are tested early in the development process and the need for stubs is minimized. The downside, however, is that the need for drivers complicates test management, and high-level logic and data flow are tested late. Like the top-down approach, the bottom-up approach also provides poor support for early release of limited features.
umbrella approach
The umbrella approach requires testing as well as functional data and control flow paths. First, function inputs are built into the bottom-up model described above. The outputs of each function are then integrated downwards. The main advantage of this approach is the degree of early release support for limited functionality. This also helps minimize the need for stubs and pilots. The potential weaknesses of this approach are significant, however, in that it may be less systematic than the other two approaches, requiring more regression testing.
Black box testing
Black box testing takes an external perspective of the test object to drive test cases. These tests can be functional or non-functional, although generally functional. The test designer selects valid and invalid inputs and determines the correct output. There is no knowledge of the internal structure of the test object. This test design method applies to all levels of software testing: unit, integration, functional, system and acceptance testing. The higher the level, and therefore the larger and more complex the box, the more developers are forced to use black box tests to simplify. Although this method can discover unimplemented parts of the specification, one cannot be sure that all existing paths are tested.
Integration testing typically involves the following steps:
Step 1: Create a test plan
Step 2: Create test cases and test data
Step 3: If necessary, create scripts to run test cases
Step 4: Once the components are integrated, run the test cases
Step 5: Fix bugs if there are any and test the code again
Step 6: Repeat the test cycle until the components have been successfully integrated