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 ...

An Alias occurs at some program point during execution when two or more names exist for the same location. We've investigated the theoretical difficulty of determining the aliases of a program, developed an approximation algorithm for solving for aliases in C like languages, and explored the precision (i.e., closeness of our approximate solution to the actual solution) and time behavior of this algorithm. Myers [Mye81] explored the theoretical difficulty of solving flow sensitive interprocedural data flow problems in the presence of aliasing. However, he did not make any claims about the difficulty of determining aliases. We isolate various programming language mechanisms that create aliases. The complexity of the alias problem (i.e., determining the aliases for a program) induced by each mechanism and their combinations is considered s...

Static type determination involves compile time calculation of the type of object a pointer may point to at a particular program point during some execution. We show that the problem of precise interprocedural type determination is NP-hard in the presence of inheritance, virtual methods and pointers. We highlight the significance of type determination in improving code efficiency and precision of other static analyses. We present a safe, approximate algorithm for C ++ programs with single level pointers, using the conditional analysis technique [LR91]. We discuss the generalization of our approach to analyze programs with multiple levels of pointer dereferencing. 1 Introduction Recent emphasis in the static analysis community has been on expanding compile time analysis to include interprocedural information [Bur90, Cal88, CBC93, MLR + 93, CK88, CK89, HS90, HRB90, LRZ93, Mey81]. Historically, compile time analysis has been used in intraprocedural context for code optimizations. The...

Program-dependence information is useful for a variety of applications, such as software testing and maintenance tasks, and code optimization. Properly defined, control and data dependences can be used to identify semantic dependences. To function effectively on whole programs, tools that utilize dependence information require information about interprocedural dependences: dependences that are identified by analyzing the interactions among procedures. Many techniques for computing interprocedural data dependences exist; however, virtually no attention has been paid to interprocedural control dependence. Analysis techniques that fail to account for interprocedural control dependences can suffer unnecessary imprecision and loss of safety. This article presents a definition of interprocedural control dependence that supports the relationship of control and data dependence to semantic dependence. The article presents two approaches for computing interprocedural control dependences, and empirical results pertaining to the use of those approaches.

Static type determination involves compile time calculation of the type of object a pointer may point to, at a particular program point during some execution. We show that the problem of precise interprocedural type determination is NP-hard in the presence of inheritance, virtual functions and pointers. We highlight the significance of type determination in improving code efficiency and precision of other static analyses. First we present a safe, approximate type determination algorithm for C++ programs with single level pointers, using the conditional analysis technique [LR91]. Then we present a generalization of this approach to simultaneously solve the aliasing and type determination problems for C++ programs with multiple levels of pointer dereferencing, and explain why this is a more complicated analysis.

The current research so far in aspect-oriented software development is focused on problem analysis, software design, and implementation techniques. Even though the importance of software testing is known, it has received little attention in the aspect-oriented paradigm. In this paper, we propose a data-flow-based unit testing approach for aspectoriented programs. Our approach tests two types of units for an aspect-oriented program, i.e., aspects that are modular units of crosscutting implementation of the program, and those classes whose behavior may be affected by one or more aspects. For each aspect or class, our approach performs three levels of testing, i.e., intra-module, intermodule, and intra-aspect or intra-class testing. For an individual module such as a piece of advice, a piece of introduction, and a method, we perform intra-module testing. For a public module along with other modules it calls in an aspect or class, we perform inter-module testing. For modules that can be accessed outside the aspect or class and can be invoked in any order by users of the aspect or class, we perform intra-aspect or intra-class testing. Our approach can handle unit testing problems that are unique to aspect-oriented programs. We use control flow graphs to compute def-use pairs of an aspect or class being tested and use such information to guide the selection of tests for the aspect or class. 1

Form-based visual programming languages, which include electronic spreadsheets and a variety of research systems, have had a substantial impact on end-user computing. Research shows that form-based visual programs often contain faults, and that their creators often have unwarranted confidence in the reliability of their programs. Despite this evidence, we find no discussion in the research literature of techniques for testing or assessing the reliability of formbased visual programs. This paper addresses this lack. We describe differences between the form-based and imperative programming paradigms, and discuss effects these differences have on strategies for testing form-based programs. We then present several test adequacy criteria for formbased programs, and illustrate their application. We show that an analogue to the traditional “all-uses ” dataflow test adequacy criterion is well suited for code-based testing of form-based visual programs: it provides important errordetection ability, and can be applied more easily to formbased programs than to imperative programs. 1.

Spreadsheet languages, which include commercial spreadsheets and various research systems, have had a substantial impact on end-user computing. Research shows, however, that spreadsheets often contain faults. Thus, in previous work, we presented a methodology that assists spreadsheet users in testing their spreadsheet formulas. Our empirical studies have shown that this methodology can help endusers test spreadsheets more adequately and eciently; however, the process of generating test cases can still represent a signi cant impediment. To address this problem, wehave been investigating how to automate test case generation for spreadsheets in ways that support incremental testing and provide immediate visual feedback. We have utilized two techniques for generating test cases, one involving random selection and one involving a goal-oriented approach. We describe these techniques, and report results of an experiment examining their relative costs and bene ts.

Regression testing is a necessary but expensive activity aimed at showing that code has not been adversely affected by changes. A selective approach to regression testing attempts to reuse tests from an existing test suite to test a modified program. This paper outlines issues relevant to selective retest approaches, and presents a framework within which such approaches can be evaluated. This framework is then used to evaluate and compare existing selective retest algorithms. The evaluation reveals strengths and weaknesses of existing methods, and highlights problems that future work in this area should address. 1 Introduction Estimates indicate that software maintenance activities account for as much as two-thirds of the cost of software production[19]. One necessary but expensive maintenance task is regression testing, performed on a modified program to instill confidence that changes are correct, and have not adversely affected unchanged portions of the program. An important diffe...

This paper presents a strategy for structural testing of objectoriented software systems with possibly unknown clients and unknown information about invoked methods. By exploiting the combined points-to and escape analysis developed for compiler optimization, our testing paradigm does not require a whole program representation to be in memory simultaneously for testing analysis. Potential e ects from outside the component under test are easily identi ed and reported to the tester. As client and server methods become known, the graph representation of object relationships is easily extended, allowing the computation of test tuples to be performed in a demand-driven manner, without requiring unnecessary computation of test tuples based on predictions of potential clients. 1.