Normally the dynamic analysis results are reported in

Normally the dynamic analysis results are reported in the form of a
histogram or a pie chart to describe the structural coverage achieved for different
modules of the program. The output of a dynamic analysis tool can be stored and
printed easily and provides evidence that thorough testing has been done. The
dynamic analysis results the extent of testing performed in white-box mode. If the
testing coverage is not satisfactory more test cases can be designed and added
to the test suite. Further, dynamic analysis results can help to eliminate
redundant test cases from the test suite.
Version 2 CSE IIT, Kharagpur

Integration testing
The primary objective of integration testing is to test the module interfaces, i.e.
there are no errors in the parameter passing, when one module invokes another
module. During integration testing, different modules of a system are integrated
in a planned manner using an integration plan. The integration plan specifies the
steps and the order in which modules are combined to realize the full system.
After each integration step, the partially integrated system is tested. An important
factor that guides the integration plan is the module dependency graph. The
structure chart (or module dependency graph) denotes the order in which
different modules call each other. By examining the structure chart the integration
plan can be developed.
Integration test approaches
There are four types of integration testing approaches. Any one (or a mixture) of
the following approaches can be used to develop the integration test plan. Those
approaches are the following:
• Big bang approach
• Top-down approach
• Bottom-up approach
• Mixed-approach
Big-Bang Integration Testing
It is the simplest integration testing approach, where all the modules making up a
system are integrated in a single step. In simple words, all the modules of the
system are simply put together and tested. However, this technique is practicable
only for very small systems. The main problem with this approach is that once an
error is found during the integration testing, it is very difficult to localize the error
as the error may potentially belong to any of the modules being integrated.
Therefore, debugging errors reported during big bang integration testing are very
expensive to fix.
Bottom-Up Integration Testing
In bottom-up testing, each subsystem is tested separately and then the full
system is tested. A subsystem might consist of many modules which
communicate among each other through well-defined interfaces. The primary
purpose of testing each subsystem is to test the interfaces among various
modules making up the subsystem. Both control and data interfaces are tested.
The test cases must be carefully chosen to exercise the interfaces in all possible
manners.