Topic: Combining module testing and integration testing

Message

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.

Author	Message
tanu_2006 Newbie Joined: 29Apr2007 Online Status: Offline Posts: 15	Topic: Combining module testing and integration testing Posted: 29Apr2007 at 10:48pm
	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. Post Resume: Click here to Upload your Resume & Apply for Jobs

	IP Logged


One Stop Testing Forum : Types Of Software Testing @ OneStopTesting : Integration Testing @ OneStopTesting