Development and application of a white box approach to integration testing

Program testing techniques can be classified in many ways. One classification is that of “black box” vs. “white box” testing. In black box testing, test data are selected according to the purpose of the program independent of the manner in which the program is actually coded. White box testing, on the other hand, makes use of the properties of the source code to guide the testing process. A white box testing strategy, which involves integrating a previously validated module into a software system is described. It is shown that, when doing the integration testing, it is not enough to treat the module as a “black box,” for otherwise certain integration errors may go undetected. For example, an error in the calling program may cause an error in the module's input which only results in an error in the module's output along certain paths through the module. These errors can be classified as Integration Domain Errors, and Integration Computation Errors. The results indicate that such errors can be detected by the module by retesting a set of paths whose cardinality depends only on the dimensionality of the module's input for integration domain errors, and on the dimensionality of the module's inputs and outputs for integration computation errors. In both cases the number of paths that need be retested do not depend on the module's path complexity. An example of the strategy as applied to the path testing of a COBOL program is presented.