Lecture
Integration testing is designed to verify communication between components, as well as interaction with different parts of the system (the operating system, hardware, or communication between different systems).
Integration testing (build testing) Tests the entire system or subsystems made up of assembled components. Integration testing should be black-box testing with tests based on the specification. The main task is to localize errors. Step-by-step integration testing reduces the number of problems
The interaction between the system's components is checked after component testing has been performed.
The interaction between different systems is checked after system testing has been performed.
All low-level modules, procedures or functions are assembled together and then tested. After that, the next level of modules is assembled to carry out integration testing. This approach is considered useful if all or nearly all modules of the level being developed are ready. This approach also helps determine, from the test results, the readiness level of the application (see also Integration testing - Bottom Up)
First all high-level modules are tested, and low-level ones are gradually added one by one. All lower-level modules are simulated with stubs having similar functionality, then, as they become ready, they are replaced with real active components. This is how we carry out top-down testing. (see also Top Down Integration)
All or nearly all developed modules are assembled together as a complete system or its main part, and then integration testing is carried out. This approach is very good for saving time. However, if the test cases and their results are not recorded correctly, the integration process itself becomes much more complicated, which becomes an obstacle for the testing team in achieving the main goal of integration testing (see also Integration testing - Big Bang)
Architecture validation
Top-down integration testing is better at finding errors in the system architecture
System demonstration
Top-down integration testing provides a partial demonstration of the system at early stages of development
Test development
Often simpler for bottom-up integration testing
As a rule, integration testing is carried out after unit testing has been completed for all modules being integrated. However, this is far from always the case. There are several methods for carrying out integration testing:
All these techniques are based on knowledge of the system's architecture, which is often depicted as structural diagrams or function call diagrams [10]. Each node on such a diagram represents a software module, and the arrows between them represent call dependencies between modules. The main difference between integration testing techniques lies in the direction of traversal across these diagrams and in the breadth of coverage per iteration.
Bottom-up testing. When using this method, it is assumed that all software modules that make up the system are tested first, and only then are they combined for integration testing. With this approach, localizing errors is significantly simplified: if the modules have been tested individually, then an error in their joint operation is a problem of their interface. With this approach, the tester's search area for problems is fairly narrow, and therefore the probability of correctly identifying the defect is much higher.
However, the bottom-up testing method has a significant drawback - the need to develop a driver and stubs for unit testing before carrying out integration testing, and the need to develop a driver and stubs when integration testing part of the system's modules (Fig. 20.1)
On one hand, drivers and stubs are a powerful testing tool, on the other, developing them requires significant resources, especially when the composition of the modules being integrated changes - in other words, a separate set of drivers may be needed for unit testing each module, a separate driver and stubs for testing the integration of two modules from the set, a separate one for testing the integration of three modules, and so on. This is primarily because, when modules are integrated, some stubs become unnecessary, and the driver also needs to be modified to support new tests that involve several modules.
Monolithic testing assumes that the individual components of the system have not undergone serious testing. The main advantage of this method is that there is no need to develop a test environment, drivers or stubs. After all the modules have been developed, they are integrated, and then the system is checked as a whole. This approach should not be confused with system testing, which is the subject of the next lecture. Although monolithic testing checks the operation of the entire system as a whole, the main task of this testing is to determine the problems of interaction between the individual modules of the system. The task of system testing, on the other hand, is to evaluate the qualitative and quantitative characteristics of the system from the point of view of their acceptability for the end user.
Monolithic testing has a number of serious drawbacks.
Top-down testing assumes that the integration testing process follows the development process. First, only the topmost control level of the system is tested, without the lower-level modules. Then, gradually, lower-level modules are integrated with the higher-level ones. As a result of applying this method, the need for drivers disappears (the role of a driver is played by a higher-level module of the system), but the need for stubs remains (Fig. 20.2).
Different testing specialists have different opinions about which of the methods is more convenient for real-world testing of software systems. Yourdon argues that top-down testing is the most appropriate in real situations [27], while Myers believes that each of the approaches has its own advantages and disadvantages, but overall the bottom-up method is better [28].
The literature often mentions a method of integration testing of object-oriented software systems, which is based on identifying clusters of classes that together have some closed and complete functionality [10]. In essence, this approach is not a new type of integration testing, it just changes the minimal element obtained as a result of integration. When integrating modules in procedural programming languages, any number of modules can be integrated provided that stubs are developed. When integrating classes into clusters, there is a fairly loose constraint on the completeness of the cluster's functionality. However, even in the case of object-oriented systems, it is possible to integrate any number of classes using stub classes.
Regardless of the integration testing method used, the degree of coverage of the system's functionality by integration tests must be taken into account. In [17], a method was proposed for evaluating the degree of coverage, based on control calls between functions and data flows. With this evaluation, the code of all modules on the system's structural diagram must be executed (all nodes must be covered), all calls must be executed at least once (all connections between nodes on the structural diagram must be covered), all call sequences must be executed at least once (all paths on the structural diagram must be covered) [10].
Comments