Joseph Robert Horgan

Dynamic program slicing

Program slices are useful in debugging, testing, maintenance, and understanding of programs. The conventional notion of a program slice, the static slice, is the set of all statements that might affect the value of a given variable occurrence. In this paper, we investigate the concept of the dynamic slice consisting of all statements that actually affect the value of a variable occurrence for a given program input. The sensitivity of dynamic slicing to particular program inputs makes it more useful in program debugging and testing than static slicing. Several approaches for computing dynamic slices are examined. The notion of a Dynamic Dependence Graph and its use in computing dynamic slices is discussed. The Dynamic Dependence Graph may be unbounded in length; therefore, we introduce the economical concept of a Reduced Dynamic Dependence Graph, which is proportional in size to the number of dynamic slices arising during the program execution.

A study of effective regression testing in practice

The purpose of regression testing is to ensure that changes made to software, such as adding new features or modifying existing features, have not adversely affected features of the software that should not change. Regression testing is usually performed by running some, or all, of the test cases created to test modifications in previous versions of the software. Many techniques have been reported on how to select regression tests so that the number of test cases does not grow too large as the software evolves. Our proposed hybrid technique combines modification, minimization and prioritization-based selection using a list of source code changes and the execution traces from test cases run on previous versions. This technique seeks to identify a representative subset of all test cases that may result in different output behavior on the new software version. We report our experience with a tool called ATAC (Automatic Testing Analysis tool in C) which implements this technique.

Incremental regression testing

The purpose of regression testing is to ensure that bug fixes and new functionality introduced in a new version of a software do not adversely affect the correct functionality inherited from the previous version. Efficient methods of selecting small subsets of regression test sets that can be used to ensure correct functionality are explored.<<ETX>>

Effect of test set minimization on fault detection effectiveness

Size and code coverage are important attributes of a set of tests. When a program P is executed on elements of the test set T, we can observe the fault detecting capability of T for P. We can also observe the degree to which T induces code coverage on P according to some coverage criterion. We would like to know whether it is the size of T or the coverage of T on P which determines the fault detection effectiveness of T for P. To address this issue we ask the following question: While keeping coverage constant, what is the effect on fault detection of reducing the size of a test set? We report results from an empirical study using the block and all-uses criteria as the coverage measures.

Achieving software quality with testing coverage measures

Coverage testing helps the tester create a thorough set of tests and gives a measure of test completeness. The concepts of coverage testing are well-described in the literature. However, there are few tools that actually implement these concepts for standard programming languages, and their realistic use on large-scale projects is rare. In this article, we describe the uses of a dataflow coverage-testing tool for C programs-called ATAC for Automatic Test Analysis for C/sup 3/-in measuring, controlling,and understanding the testing process. We present case studies of two real-world software projects using ATAC. The first study involves 12 program versions developed by a university/industry fault-tolerant software project for a critical automatic-flight-control system. The second study involves a Bellcore project of 33 program modules. These studies indicate that coverage analysis of programs during testing not only gives a clear measure of testing quality but also reveals important aspects of software structure. Understanding the structure of a program, as revealed in coverage testing, can be a significant component in confident assessment of overall software quality.<<ETX>>

An analytical approach to architecture-based software reliability prediction

Prevalent approaches to software reliability modeling are black-box based, i.e., the the software system is treated as a monolithic entity and only its interactions with the outside world are modeled. However with the advancement and widespread use of object oriented systems design and web-based development, the use of component-based software development is on the rise. Software systems are being developed in a heterogeneous fashion using components developed in-house, contractually, or picked off-the-shelf and hence it may be inappropriate to model the overall failure process of such systems using the existing software reliability growth models. Predicting the reliability of a heterogeneous software system based on its architecture, and the failure behavior of its components is thus absolutely essential. In this paper we present an analytical approach to architecture-based software reliability prediction. The novelty of this approach lies in the idea of parameterizing the analytic model of the software using measurements obtained from testing. To facilitate this we use a coverage analysis tool called ATAC (Automatic Test Analyzer in C), which is a part of a Software Understanding and Diagnosis System (/spl chi/Suds) developed at Bellcore. We demonstrate the methodology by predicting the reliability of an application called as SHARPE (Symbolic Hierarchical Automated Reliability Predictor), which has been used to solve stochastic models of reliability, performance and performability.

Locating program features using execution slices

An important step towards effective software maintenance is to locate the code relevant to a particular feature. We report a study applying an execution slice-based technique to a reliability and performance evaluator to identify the code which is unique to a feature, or is common to a group of features. Supported by tools called ATAC and /spl chi/Vue, the program features in the source code can be tracked down to files, functions, lines of code, decisions, and then c- or p-uses. Our study suggests that the technique can provide software programmers and maintainers with a good starting point for quick program understanding.

Data flow coverage and the C language

This paper reviews some of the difficulties and decisions in implementing data flow coverage criteria for the C language as realized in ATAC, a data flow coverage testing tool for C. We also address a particular, language independent problem with the concept of the all-du-paths data flow coverage criterion and suggest a solution.

Mining system tests to aid software maintenance

Maintainers can use information from test analysis tools to help them understand, debug, and retest programs. The authors describe techniques and tools in Bellcores /spl chi/Suds, a system for understanding and diagnosing software bugs, including Y2K problems in legacy applications.

Quantifying the closeness between program components and features

Abstract One of the most important steps towards effective software maintenance of a large complicated system is to understand how program features are spread over the entire system and their interactions with the program components. However, we must first be able to represent an abstract feature in terms of some concrete program components. In this paper, we use an execution slice-based technique to identify the basic blocks which are used to implement a program feature. Three metrics are then defined, based on this identification, to determine quantitatively , the disparity between a program component and a feature, the concentration of a feature in a program component, and the dedication of a program component to a feature. The computations of these metrics are automated by incorporating them in a tool ( χ Suds), which makes the use of our metrics immediately applicable in real-life contexts. We demonstrate the effectiveness of our technique by experimenting with a reliability and performance evaluator. Results of our study suggest that these metrics can provide an indication of the closeness between a feature and a program component which is very useful for software programmers and maintainers to better understand the system at hand.