Regression testing is the process of retesting software after modification. Regression testing is a major factor contributing to the high cost of software maintenance. To control this cost, regression testing must be accomplished efficiently through effective reuse of test cases and judicious generation of new test cases.

Fault-based testing focuses on the detection of particular classes of faults. RELAY is a fault-based testing technique that guarantees the detection of errors caused by any fault in a chosen fault classification. RELAY can be used as a regression testing technique to generate the test cases required to demonstrate that a modification is properly made. In addition, the information related to a test case chosen to detect a potential fault guides in choosing previously-selected test cases that should be reused, for a given modification.

This paper presents the concepts behind RELAY and discusses how RELAY could be used as a regression testing technique. It also describes a testing environment that supports reactive regression testing as well as testing throughout the development lifecycle, which is based on integrating the RELAY model with other testing techniques.

The lifetime of many software systems is surprisingly long, often far exceeding initial plans and expectations. During development and maintenance of long-lived software, requirements are analyzed and specified, designs and code modules are developed, testing is planned, and code is tested many times. Consequently, developers and managers frequently lose or gain confidence in software artifacts, especially when existing uncertainties are relieved or when new uncertainties are encountered. Fluctuations in developers' confidences may in turn affect process actions or decisions, for instance determining the impact of change, the need for regression testing, or when to stop testing. In this paper, we present an approach that allows for developers' confidences or "beliefs" regarding software components to be modeled and updated directly. This approach is part of an overall strategy that calls for explicit modeling of software engineering uncertainties using an established technique for uncertainty modeling called Bayesian belief networks. Here, we present several types of software uncertainty and how they may be modeled directly. We also introduce Bayesian belief networks and how they may be used to either confirm, evaluate or predict software uncertainties. We discuss our experiences with constructing Bayesian-network models of uncertainty for an existing system developed at Beckman Instruments. Once constructed, these models may be used by developers and managers in future software understanding, evolution, and maintenance activities. We also list factors affecting levels of confidence in system artifacts, identified in interviews with Beckman developers. Finally, we describe our design and implementation of a Java program that allows software systems and associated beliefs to be modeled explicitly.

Component-based software development technologies have been advocated for years [31]. Recent developments in the software industry are posing to make it as easy to develop a distributable software component as it is to code a traditional software module [21, 23]. An abundance of standard-binding inexpensive software components is about to emerge. It will soon be possible to use redundant software components to enhance application reliability or to improve system performance without doubling or tripling component costs. Component integration cost, however, remains high. Before average software developers can take advantage of the coming abundance of low-cost software components, component integration techniques must be improved so that the benefits of adopting redundant components outweigh component integration cost.

Redundant Arrays of Independent Components (RAIC) is a technology that uses groups of similar or identical distributed software components to provide reliable services to software applications. The RAIC architectural style is a special architectural style designed to take advantage of redundant independent components in a systematic way. The types and relations of components in a RAIC is the basis of how they should be integrated. After component types and various component relations are determined, an appropriate RAIC level and an invocation model can be adopted. The RAIC level and the invocation model dictate how a RAIC controller functions.

RAIC controllers use the just-in-time component testing technique to check component status and detect component failures. RAIC feelers provide other status information to assist decisions in component selection. RAIC allows components in a redundant array to be added or removed dynamically at run-time. Component state recovery techniques are used to bring replacement components or newly added components up-to-date.

Together, these systematic strategies and supporting technologies enable software developers to integrate redundant software components in an array with no or little coding. They can then use the array as a single component. Thus, by following the guidance of the RAIC architectural style, component integration cost can be lowered.

This technical report describes of RAIC and the RAIC architectural style. It presents categorizations and definitions of component types, component relations, RAIC levels, and invocation models. It also discusses the just-in-time testing and component state recovery techniques used in RAIC. A number of examples and scenarios are given to illustrate different types of RAIC. Future research directions in RAIC are also outlined.

Specification-based testing is important because it relates directly to what the program is supposed to do and can detect certain errors that are often not detected by traditional codebased testing techniques such as branch coverage and statement coverage. We have developed an automated testing tool, called ADLscope, that utilizes the formal specification of a program unit as the basis for test coverage measurement. A tester uses ADLscope to test Application Programmatic Interfaces (APIs) written inthe C programming language. The API must be formally specified in the Assertion Definition Language (ADL), a language developed at Sun Microsystems Laboratories. The tester uses ADLscope to generate coverage conditions from a program's ADL specifications. When the API is tested, ADL scope automatically measures how many of the coverage conditions have been covered by the tests. An uncovered condition usually means that certain aspects ofthe specification have not been thoroughly exercised by the implementation. The tester uses this information to develop new test data that exercise the uncovered conditions. In this paper, we focus on the following aspects of ADLscope: the design and implementation of ADLscope and the specification-based coverage metrics used in ADLscope.

Software tests are intellectual assets, too, and are as valuable as source code to a software project. Over the long term, maintainable software tests significantly lower a project's cost. It is very difficult, however, to write maintainable software tests, especially executable ones. Existing approaches - including natural language, tables or forms, test scripts, programming languages, and test description languages - all are problematic, as discussed in this paper. Another solution is a test description language that provides a mechanism to specify software tests while separating different concerns of automated software testing.

In this paper, we analyze the current situation of software test description. We propose a description language just for software testers: TestTalk. We present examples to illustrate the benefits of TestTalk and discuss implementation issues of this language. The primary goal of TestTalk is to enable tests to he written once, and then used by anyone (i.e., they are understandable), anytime (i.e.,they are maintainable as the software evolves), anywhere (i.e.,they can he ported to a new platform), and with anything (i.e., they can be used with any testing tool in any testing environment).

Additional problems of software testing arise when applications under test are developed in the component-based approach. Component misuse is one of them. The component misuse problem occurs when a component is used in a way that differs from the component producer's expectation. This paper explores the cause of the component misuse problem and proposes a technique to discover, specify, and verify component usage. This technique utilizes regular expressions as the formalism to deal with component usage. This research is part of the software retrospector effort, which aims at a better testing solution for component-based software.

Although programming languages are widely used for writing automated software test code, we argue that this is a harmful practice for software quality assurance. Programming languages are designed to implement complex algorithms and do not provide a natural mechanism for describing software tests. Software tests consist of sequences of test actions - such as, inputting test input data, checking test outcomes, and recording test results - and not only executing the application-under-test. We dissect a sample software test written in C++ and identify several harmful effects of writing software tests in programming languages.

We believe that the problems we identify are overcome by using a language specifically designed for describing software tests. We briefly describe TestTalk, a test description language under development, and provide a sample software test written in TestTalk.

RELAY, a model for error detection, defines revealing conditions that guarantee that a fault originates an error during execution and that the error transfers through computations and data flow until it is revealed. This model of error detection provides a framework within which the capabilities of other testing criteria can be evaluated. In this paper, we analyze three test data selection criteria that attempt to detect faults in six fault classes. This analysis shows that none of these criteria is capable of guaranteeing error detection for these fault classes and points out two major weaknesses of these criteria. The first weakness is that the criteria do not consider the potential unsatisfiability of their rules; each criterion includes rules that are sufficient to cause errors for some fault classes, yet when such rules are unsatisfiable, many errors may remain undetected. Their second weakness is failure to integrate their proposed rules; although a criterion may cause a subexpression to take on an erroneous value, there is no effort made to guarantee that the enclosing expression evaluates incorrectly. This paper shows how the test data selection criterion defined by RELAY overcomes these weaknesses.

This paper introduces an automatic tool facilitating software reuse. Reusable software components have the potential to increase productivity and reduce development costs. Several research and industrial experience reports show that practicing and achieving high levels of software reuse post technical and managerial challenges. Researchers advocate using component repository technologies and object-oriented development methods within computer-aided software engineering (CASE) environments to address these challenges. Yet additional research is needed to solve them.

Our approach promotes reuse at the specification level rather than merely at the code level. This paper presents our research in elevating reuse capabilities within TROMLAB, a rigorous development environment for real-time reactive systems. We have developed VISTA (Visual Interface for Software Reuse in TROMLAB Applications), which supports automatic search and retrieval of TROMLAB components. VISTA is a visual interface for practicing software reuse in TROMLAB. VISTA provides facilities to navigate reusable component repositories, to inspect components and their dependencies, and to retrieve and modify components for reuse. VISTA works in conjunction with the graphical user interface of TROMLAB, thus providing an environment for active reuse while developing real-time reactive systems. This paper introduces VISTA in the context of TROMLAB. As background, the paper presents an overview of the TROMLAB environment and the TROM methodology as well as the components modeled by TROM. The primary focus is on VISTA, the interface facilitating software reuse within TROMLAB.