The basic unit of testing in an object-oriented program is a class. Although there has been much recent research on testing of classes, most of this work has focused on black-box approaches. However, since blackbox testing techniques may not provide sufficient code coverage, they should be augmented with code-based or white-box techniques. Dataflow testing is a codebased testing technique that uses the dataflow relations in a program to guide the selection of tests. Existing dataflow testing techniques can be applied both to individual methods in a class and to methods in a class that interact through messages, but these techniques do not consider the dataflow interactions that arise when users of a class invoke sequences of methods in an arbitrary order. We present a new approach to class testing that supports dataflow testing for dataflow interactions in a class. For individual methods in a class, and methods that send messages to other methods in the class, our technique is similar ...

This paper describes new techniques to help with testing and debugging, using information obtained from path profiling. Apath profiler instruments a program so that the number of times each different loopfree path executes is accumulated during an execution run. With such an instrumented program, each run of the program generates a path spectrum for the execution—a distribution of the paths that were executed during that run. Apath spectrum is a finite, easily obtainable characterization of a program’s execution on adataset, and provides a behavior signature for a run of the program. Our techniques are based on the idea of comparing path spectra from different runs of the program. When different runs produce different spectra, the spectral differences can be used to identify paths in the program along which control diverges in the two runs. By choosing input datasets to hold all factors constant except one, the divergence can be attributed to this factor. The point of divergence itself may not be the cause of the underlying problem, but provides a starting place for a programmer to begin his exploration. One application of this technique is in the “Year 2000 Problem ” (i.e., the problem of fixing computer systems that use only 2-digit year fields in date-valued data). In this context, path-spectrum comparison provides a heuristic for identifying paths in a program that are good candidates for being date-dependent computations. The application of path-spectrum comparison to a number of other software-maintenance issues is also discussed.

After changes are made to a previously tested program, a goal of regression testing is to perform retesting based on the modifications while maintaining the same testing coverage as completely retesting the program. We present a novel approach to data flow based regression testing that uses slicing algorithms to explicitly detect definition-use associations that are affected by a program change. An important benefit of our slicing technique is that, unlike previous techniques, neither data flow history nor recomputation of data flow for the entire program is required to detect affected definition-use associations. The program changes drive the recomputation of the required partial data flow through slicing. Another advantage is that our technique achieves the same testing coverage with respect to the affected definition-use associations as a complete retest of the program without maintaining a test suite. Thus, the overhead of maintaining and updating a test suite is eliminated. 1. Int...

The conventional classification of software fault detection techniques as static or dynamic analysis is inadequate as a basis for identifying useful relationships between techniques. A more useful distinction is between techniques that sample the space of possible executions, and techniques that fold the space. The new distinction provides better insight into the ways different techniques can interact, and is a basis for considering hybrid fault detection techniques including combinations of testing and formal verification.

Abstract The Godzilla automatic test data generator is an integrated collection of tools that implements a relatively new test data generation method, constraint-based testing, that is based on mutation analysis. Constraint-based testing integrates mutation analysis with several other testing techniques, including statement coverage, branch coverage, domain perturbation and symbolic evaluation. Because Godzilla uses a rule-based approach to generate test data, it is easily extendible to allow new testing techniques to be integrated into the current system.

Data-flow-based testing is a well-established approach to program testing. Much object-oriented code is written as libraries; hence data-flow-based testing of object-oriented libraries is of great importance. However, finding def-use relationships in libraries written in object-oriented languages (e.g., Java and C++) is di#cult because of unknown aliasing between parameters, unknown concrete types of the parameters, dynamic dispatch and exceptions. We present the first algorithm for finding def-use relationships in object-oriented libraries that overcomes the above di#culties. We also show how the information computed by our algorithm can be used in generating relevant test cases. Our algorithm is flow- and context-sensitive and based on our earlier points-to analysis [CRL99] 1

After changes are made to a previously tested program, a goal of regression testing is to perform retesting based on the modifications while maintaining the same testing coverage as completely retesting the program. We present a novel approach to data flow based regression testing that uses slicing algorithms to explicitly detect definition-use associations that are affected by a program change. An important benefit of our slicing technique is, unlike previous techniques, neither data flow history nor recomputation of data flow for the entire program is required to detect affected definition-use associations. The program changes drive the recomputation of the required partial data flow through slicing. Another advantage is that our technique achieves the same testing coverage with respect to the affected definition-use associations as a complete retest of the program without maintaining a test suite. Thus, the overhead of maintaining and updating a test suite is eliminated. 1. Introduc...

Condition coverage testing is a family of testing techniques that are based on the logical flow of control through a program. The condition coverage techniques include a variety of requirements, including that each statement in the program is executed and that each branch is executed. Mutation testing is a fault-based testing technique that is widely considered to be very powerful, and that imposes requirements on testing that include, and go beyond, many other techniques. In this paper, we consider the six common condition coverage techniques, and formally show that these techniques are subsumed by mutation testing, in the sense that if mutation testing is satisfied, then the condition coverage techniques are also satisfied. The fact that condition coverage techniques are subsumed by mutation has immediate practical significance because the extensive research that has already been done for mutation can be used to support condition coverage techniques, including automated tool...

The all-du-paths structural testing criterion is one of the most discriminating of the data flow testing criteria. Unfortunately, in the worst case, the criterion requires an intractable number of test cases. In a case study of an industrial software system, we find that the worst case scenario is rare. Eighty percent of the subroutines require ten or fewer test cases. Only one subroutine out of 143 requires an intractable number of tests. However, the number of required test cases becomes tractable when using the all-uses criterion. This paper includes a formal specification of both the all-du-paths criterion and the software tools used to estimate a minimal number of test cases necessary to meet the criterion. Keywords: Software testing, software measures formal specifications, data flow analysis. Department of Computer Science Technical Report #CS--91--105 Colorado State University (Revision of Technical Report #CS--89--118) A version of this paper was published in IEE/BCS Software Engineering Journal, 7(1):43-51, Jan. 1992. This research was partially supported by the NATO Collaborative Research Grants Program under RG. 0343/88. 1

Relay is a model of how a fault causes a failure on execution of some test datum. This process begins with introduction of an original state potential failure at a fault location and continues as the potential failure(s) transfers to output. Here we describe the second stage of this process, transfer of an incorrect intermediate state from a faulty statement to output. Transfer occurs along information flow chains, where each link in the chain involves data dependence transfer and/or control dependence transfer. Relay models concurrent transfer along multiple information flow chains with transfer sets, which identify possible interaction between potential failures, and with transfer routes, which identify actual interactions. Transfer sets, transfer routes, and control dependence transfer are unique to the Relay model. The model demonstrates that the process of potential failure transfer is extremely complex and full analysis of real programs may not be practical. Nonetheless, Relay p...