The simplest application of structured testing to integration is to
combine module testing with integration testing so that a basis set of
paths through each module is executed in an integration context. This
means that the techniques of section 5 can be used without modification
to measure the level of testing. However, this method is only suitable
for a subset of integration strategies.
The most obvious combined strategy is pure "big bang" integration, in
which the entire system is assembled and tested in one step without
even prior module testing. As discussed earlier, this strategy is not
practical for most real systems. However, at least in theory, it makes
efficient use of testing resources. First, there is no overhead
associated with constructing stubs and drivers to perform module
testing or partial integration. Second, no additional
integration-specific tests are required beyond the module tests as
determined by structured testing. Thus, despite its impracticality,
this strategy clarifies the benefits of combining module testing with
integration testing to the greatest feasible extent.
It is also possible to combine module and integration testing with the
bottom-up integration strategy. In this strategy, using test drivers
but not stubs, begin by performing module-level structured testing on
the lowest-level modules using test drivers. Then, perform module-level
structured testing in a similar fashion at each successive level of the
design hierarchy, using test drivers for each new module being tested
in integration with all lower-level modules. Figure 7-1 illustrates the
technique. First, the lowest-level modules "B" and "C" are tested with
drivers. Next, the higher-level module "A" is tested with a driver in
integration with modules "B" and "C." Finally, integration could
continue until the top-level module of the program is tested (with real
input data) in integration with the entire program. As shown in Figure
7-1, the total number of tests required by this technique is the sum of
the cyclomatic complexities of all modules being integrated. As
expected, this is the same number of tests that would be required to
perform structured testing on each module in isolation using stubs and
drivers.
Figure 7-1. Combining module testing with bottom-up integration.