CS302: Software Engineering

Guidelines for Integration Testing 

The purpose of integration testing is to verify that groups of interacting modules that comprise an execute unit perform in a stable, predictable, and accurate manner that is consistent with all related program and systems design specifications. 

Integration tests are considered distinct from unit tests. That is, as unit tests are successful, integration testing for the tested units can begin. The two primary goals of integration testing are compatibility and intermodule processing accuracy.

FIGURE 17-19 ABC Video Unit Test Example-Rent/Return

Integration tests are considered distinct from unit tests. That is, as unit tests are successful, integration testing for the tested units can begin. The two primary goals of integration testing are compatibility and intermodule processing accuracy. 

Compatibility relates to calling modules in an operational environment. The test verifies first that all modules are called correctly, and, even with errors, do not cause abends. Intermodule tests check that data transfers between modules operate as intended within constraints of CPU time, memory, and response time. Data transfers tested include sorted and extracted data provided by utility programs, as well as data provided by other application modules.

Test cases developed for integration testing should be sufficiently exhaustive to test all possible interactions and may include a subset of unit test cases as well as special test cases used only in this test. The integration test does not test logic paths within the modules as the unit test does. Instead, it tests interactions between modules only. Thus, a black-box strategy works well in integration testing. 

If modules are called in a sequence, checking of inputs and outputs to each module simplifies the identification of computational and data transfer errors. Special care must be taken to identify the source of errors, not just the location of bad data. Frequently, in complex applications, errors may not be apparent until several modules have touched the data and the true source of problems can be difficult to locate. Representative integration test errors are listed in Table 17-7.

Integration testing can begin as soon as two or more modules are successfully unit tested. When to end integration tests is more subjective. When exceptions are detected, the results of all other test processing become suspect. Depending on the severity and criticality of the errors to overall process integrity, all previous levels of testing might be re-executed to re-verify processing. Changes in one module may cause tests of other modules to become invalid. Therefore, integration tests should be considered successful only when the entire group of modules in an execute unit are run individually and collectively without error. Integration test curves usually start low, increase and peak, then decrease (see Figure 17-20). If there is pressure to terminate integration testing before all errors are found, the rule of thumb is to continue testing until fewer errors are found on several successive test runs.

TABLE 1 7-7 Sample Integration Test Errors

ABC Video Integration Test 

Because of the redesign of execution units for more efficient SQL processing, integration testing can be concurrent with unit code and test work, and should integrate and test the unit functions as they are complete. The application control structure for screen processing and for calling modules is the focus of the test.

FIGURE 17-20 Integration Test Errors Found . Over Test Shots

Black-box, top-down testing is used for the integration test. Because SQL does not pass data as input, we predict the sets that SQL will generate during SELECT processing. The output sets are then passed to the control code and used for screen processing, both of which have been unit tested and should work. To verify the unit tests at the integration level, we should: 

1. Ensure that the screen control structure works and that execute units are invoked as intended. 

2. Ensure that screens contain expected data from SELECT processing. 

3. Ensure that files contain all updates and created records as expected. 

4. Ensure that printed output contains expected information in the correct format.

First, we want to define equivalent sets of processes and the sets' equivalent sets of data inputs. For instance, the high level processes from IE analysis constitute approximately equivalent sets. These were translated into modules during design and, with the exception of integrating data access and use across modules, have not changed. These processes include Rent/Return, Customer Maintenance, Video Maintenance, and Other processing. If the personnel are available, four people could be assigned to develop one script each for these equivalent sets of processing. Since we named Rent/Return as the highest priority for development, its test should be developed first. The others can follow in any order, although the start-up and shutdown scripts should be developed soon after Rent/Return to allow many tests of the entire interface. 

First, we test screen process control, then individual screens. Since security and access control are embedded in the screen access structure, this test should be white box and test every possible access path, including invalid ones. Each type of access rights and screen processing should be tested . For the individual screens, spelling, positioning, color, highlighting, message placement, consistency of design, and accuracy of information are all validated (see Figure 17-21).

The integration test example in Figure 17-22 is the script for testing the start-up procedure and security access control for the application. This script would be repeated for each valid and invalid user including the other clerks and accountant. The startup should only work for Vic, the temporary test account, and the chief clerk. The account numbers that work should not be documented in the test script. Rather, a note should refer the reader to the person responsible for maintaining passwords.

1. Define equivalent sets of processes and data inputs. 

2. Define the priorities of equivalent sets for testing. 

3. Develop test scrips for Rent/Return, Other processing, Customer Maintenance, Video Maintenance. 

4. For each of the above scripts, the testing will proceed as follows: 

FIGURE 17-21 ABC Integration Test Plan

FIGURE 17-22 ABC Video Integration Test Script

In the integration portion of the test, multiuser processing might take place, but it is not necessarily fully tested at this point. File contents are verified after each transaction is entered to ensure that file updates and additions are correct. If the integration test is approached as iteratively adding modules for testing, the final run-through of the test script should include all functions of the application, including start-up, shutdown, generation and printing of all reports, queries on all files, all file maintenance, and all transaction types. At least several days and one monthly cycle of processing should be simulated for ABC's test to ensure that end-oi-day and end-of-month processing work. 

Next, we discuss system testing and continue the example from ABC with a functional test that is equally appropriate at the integration, system, or QA levels.