A number of path selection criteria have been proposed throughout the years. Unfortunately, little work has been done on comparing these criteria. To determine what would be an effective path selection criterion for revealing errors in programs, we have undertaken an evaluation of these criteria. This paper reports on the results of our evaluation of path selection criteria based on data flow relationships. We show how these criteria relate to each other, thereby demonstrating some of their strengths and weaknesses. In addition, we suggest minor changes to some criteria that improve their performance. We conclude with a discussion of the major limitations of these criteria and directions for future research.

The testing process is

No abstract

To appear in Transactions on Software Engineering.

Few would question that software testing is a necessary activity for assuring software quality, yet the typical testing process is a human intensive activity and as such, it is unproductive, error-prone, and often inadequately done. Moreover, testing is seldom given a prominent place in software development or maintenance processes, nor is it an integral part of them. Major productivity and quality enhancements can be achieved by automating the testing process through tool development and use and effectively incorporating it with development and maintenance processes. The TAOS toolkit, Testing with Analysis and Oracle Support, provides support for the testing process. It includes tools that automate many tasks in the testing process, including management and persistence of test artifacts and the relationships between those artifacts, test development, test execution, and test measurement. A unique aspect of TAOS is its support for test oracles and their use to verify behavioral correctness of test executions, TAOS also supports structural/dependence coverage, by measuring the adequacy of test criteria coverage, and regression testing, by identifying tests associated or dependent upon modified software artifacts. This is accomplished by integrating the ProDAG toolset, Program Dependence Analysis Graph, with TAOS, which supports the use of program dependence analysis in testing, debugging, and maintenance. This paper describes the TAOS toolkit and its capabfities as well as testing, debugging and maintenance processes based on program dependence analysis.We also describe our experience with the toolkit and discuss our future plans.

Abstract. In this paper, we describe a testing technique, called structural specification-based testing (SST), which utilizes the formal specification of a program unit as the basis for test selection and test coverage measurement. We also describe an automated testing tool, called ADLscope, which supports SST for program units specified in Sun Microsystems' Assertion Definition Language (ADL). ADLscope automatically generates coverage conditions from a program's ADL specification. While the program is tested, ADLscope determines which of these conditions are covered by the tests. An uncovered condition exhibits aspects of the specification inadequately exercised during testing. The tester uses this information to develop new test data to exercise the uncovered conditions.We provide an overview of SST's specification-based test criteria and describe the design and implementation of ADLscope. Specification-based testing is guided by a specification, whereby the testing activity is directly related to what a component under test is supposed to do, rather than what it actually does. Specification-based testing is a significant advance in testing, because it is often more straightforward to accomplish and it can reveal failures that are often missed by traditional code-based testing techniques. As an initial evaluation of the capabilities of specification-based testing, we conducted an experiment to measure defect detection capabilities, code coverage and usability of SST/ADLscope; we report here on the results.1.

No abstract

No abstract