Integration testing is important process to ensure the functional correctness of the design items as it verifies performance and reliability of the integrated system. Integration testing is one automated testing technique to test the design program via computer system by increasing tested modules. There are four typical methods to test which are Top-down approach, Bottom-up approach, Big bang approach, and Sandwich approach. This paper provides a summarization of integration testing topic including background of integration testing and the benefit that integration testing provide to the area of software engineering.
Introduction
Software defects are introduced in all phases of software development - requirements, design, and coding. Therefore, testing should be carried out in all the phases. It thus has its own lifecycle and coexists with the software development lifecycle. We recall that the waterfall model has a specific phase assigned to testing and is possibly the main reason why this aspect of the model has been subjected too much criticism. Testing is fundamental to the success of a software system. Although it is a field of active research, it lacks a strong theoretical rigor and a comprehensive theory. One reason for the absence of a theory of testing is that are quite a few testing-related problems that are inherently unsolvable. System testing involves integrating two or more components that implement system functions or features and then testing this integrated system. In an iterative development process, system testing is concerned with testing an increment to be delivered to the customer; in a waterfall process, system testing is concerned with testing the entire system.
Software Testing Background
The aim of the component testing stage is to discover defects by testing individual program components. These components may be functions, objects or reusable components. During system testing, these components are integrated to form sub-systems or the complete system (Sommerville, 2004). At this stage, system testing should focus on establishing that the system meets its functional and non-functional requirements, and does not behave in unexpected ways. Certainly, defects in components that have been missed during earlier testing are discovered during system testing. According to Sommerville, I, 2004, the software testing process has two distinct goals. First, is to demonstrate to the developer and the customer that the software meets its requirements. For custom software, this means that there should be at least one test for every requirement in the user and system requirements documents. For generic software products, it means that there should be tests for all of the system features that will be incorporated in the product release. Some systems may have an explicit acceptance-testing phase where the customer formally checks that the delivered system conforms to its specification. Second, is to discover faults or defects in the software where the behavior of the software is incorrect, undesirable or does not conform to its specification. Defect testing is concerned with rooting out all kinds of undesirable system behavior, such as system crashes, unwanted interactions with other systems, incorrect computations and data corruption. The first goal leads to validation testing, where we expect the system to perform correctly using a given set of test cases that reflect the system's expected use. The second goal leads to defect testing, where the test cases are designed to expose defects. The test cases can be intentionally vague and need not reflect how the system is normally used. For validation testing, a successful test is one where the system performs correctly. For defect testing, a successful test is one that exposes a defect that causes the system to perform incorrectly. Testing cannot demonstrate that the software is free of defects or that it will behave as specified in every circumstance. It is always possible that a test that we have overlooked could discover further problems with the system. Overall, therefore, the goal of software testing is to convince system developers and customers that the software is good enough for operational use. Testing is a process intended to build confidence in the software. Test data are the inputs that have been devised to test the system. Test data can sometimes be generated automatically. Automatic test case generation is impossible. People who understand what the system should do can only predict the output of the tests. Exhaustive testing, where every possible program execution sequence is tested, is impossible. Testing, therefore, has to be based on a subset of possible test cases. Ideally, software companies should have policies for choosing this subset rather than leave this to the development team. These policies might be based on general testing policies, such as a policy that all program statements should be executed at least once. Alternatively, the testing policies may be based on experience of system usage and may focus on testing the features of the operational system. It is clear that comparable guidelines are normally used during product testing. When features of the software are used in isolation, they normally work.
Integration Testing
The process of system integration involves building a system from its components and testing the resultant system for problems that arise from component interactions. The components that are integrated may be off-the-shelf components, reusable components that have been adapted for a particular system or newly developed components (Sommerville, 2004). For many large systems, all three types of components are likely to be used. Integration testing checks that these components actually work together are called correctly and transfer the right data at the right time across their interfaces. System integration involves identifying clusters of components that deliver some system functionality and integrating these by adding code that makes them work together. Systems analysts usually develop the data they use in integration testing (Shelly & Rosenblantt, 2009, page 517). Sometimes, the overall skeleton of the system is developed first, and components are added to it. This is called top-down integration. Alternatively, we may first integrate infrastructure components that provide common services, such as network and database access and then add the functional components. This is bottom-up integration. In practice, for many systems, the integration strategy is a mixture of these, with both infrastructure components and functional components added in increments. In both top-down and bottom-up integration, we usually have to develop additional code to simulate other components and allow the system to execute. A major problem that arises during integration testing is localizing errors. There are complex interactions between the system components and, when an anomalous output is discovered, we may find it hard to identify where the error occurred. To make it easier to locate errors, we should always use an incremental approach to system integration and testing. Initially, we should integrate a minimal system configuration and test this system. We then add components to this minimal configuration and test after each added increment.
Recall that integration testing corresponds to the preliminary design of a program. In the preliminary design of a program, various modules, along with their individual functions, are identified and their interfaces are specified. In the structured design approach, the output of the preliminary design phase is the structure chart that shows the modules of a program and their interfaces. During integration testing, various unit-tested modules are integrated and tested in order to ensure that module interfaces are compatible with one another in such a way that desired outputs are obtained.
Testing Method
1. Top-down integration is a form of incremental approach where the modules are combined from the top (the main control module) downwards according to their position in the control hierarchy (such as a structure chart), and tested (Mohapatra, 2010). Thus, the main module is integrated with one of its immediate subordinate modules. Choice of the subordinate modules can follow either a depth-first or a breadth-first strategy. In the former, the subordinate modules are integrated one after another. Thus it results in a vertical integration. In the latter strategy, the modules that appear in the same hierarchical level are integrated first, resulting in a horizontal integration. In a top-down approach, there is no need to have a fictitious driver module. Nevertheless, it requires the use of stubs in the place of lower level modules. The functions of stubs are to receive data from the modules under test and pass test case data to the modules under test. Even stubs play important role in top-down strategy. However, the design of a stub can be quite complicated because it involves passing a test case to the module being tested. In case the stub represents an output module, then the output of the stub is the result of the test being conducted for examination. More than one test case is required for testing a module. In such a case, multiple versions of a stub are required. An alternative is for the stub to read data for test cases from an external file and return them to the module during the call operation.
2. A bottom-up strategy (Myers, 1979), In the bottom-up integration, drivers are needed to call subordinate clusters, pass test input data to the clusters, both receive from and pass data to the clusters, and display outputs and compares them with the expected outputs. They are much simpler in design and therefore easy to write, compared to the stubs. Unlike stubs, drivers do not need multiple versions. A driver module can call the module being tested multiple number of times. There is no unanimity of opinion as to whether the top-down strategy is better or the bottom-up strategy is better. That the top-down strategy allows the main control module to be tested repeatedly is its main strength, but it suffers from the fact that it needs extensive use of stubs. The main advantages of bottom-up testing are that drivers are simple to design and a driver module is placed directly on the module being tested with no intervening variables separating the two. The main disadvantage of bottom-up testing is that the working program evolves only when the last module is integration-tested.
3. The big-bang method means testing the complete software with all the modules combined. This is the worst form of carrying out an integration test. Here a lot of errors surface simultaneously at one time and it is almost impossible to find out their causes. Thus, it is not at all advisable to adopt a big-bang approach to integration testing.
4. According to Pfleeger and Atlee, 2006, Sandwich integration is a testing approach that combines a top-down method and bottom-up. This method looks like three layer sandwich that has target layer in the middle. The top layer uses top-down strategy and the layer below the target layer uses bottom-up approach. The target layer is layer where testing unites by based on foundation of system characteristics and the component hierarchy’s structure. Sandwich includes the good point of top-down and bottom-up and let the integration testing start early in the testing process. The main advantage of sandwich integration is the use of less number of stubs and drivers.
Summary
Integration testing is used in order to detect fault by focusing on small group of components which unit testing has not detected. There are two majors of approach in integration testing: top-down and bottom-up and there are two mixed integration strategies: big-bang and sandwich. In Top-down strategy, stubs play important role in top-down strategy. However, the design of a stub can be quite complicated because it involves passing a test case to the module being tested. The main advantages of bottom-up testing are that drivers are simple to design and a driver module is placed directly on the module being tested with no intervening variables separating the two. The main advantage of sandwich integration is the use of less number of stubs and drivers.
