Andreas Zeller

Learn More
We apply data mining to version histories in order toguide programmers along related changes: "Programmerswho changed these functions also changed. . . ". Given aset of existing changes, such rules (a) suggest and predictlikely further changes, (b) show up item coupling that is indetectableby program analysis, and (c) prevent errors dueto incomplete(More)
Which is the defect that causes a software failure? By comparing the program states of a failing and a passing run, we can identify the <i>state differences</i> that cause the failure. However, these state differences can occur all over the program run. Therefore, we focus <i>in space</i> on those variables and values that are relevant for the failure, and(More)
Given some test case, a program fails. Which circumstances of the test case are responsible for the particular failure? The Delta Debugging algorithm generalizes and simplifies some failing test case to a minimal test case that still produces the failure; it also isolates the difference between a passing and a failing test case. In a case study, the Mozilla(More)
As a software system evolves, programmers make changes that sometimes cause problems. We analyze CVS archives for <i>fix-inducing changes</i>---changes that lead to problems, indicated by fixes. We show how to automatically locate fix-inducing changes by linking a version archive (such as CVS) to a bug database (such as BUGZILLA). In a first investigation(More)
Imagine some program and a number of changes. If none of these changes is applied (&#8220;yesterday&#8221;), the program works. If all changes are applied (&#8220;today&#8221;), the program does not work. Which change is responsible for the failure? We present an efficient algorithm that determines the minimal set of failure-inducing changes. Our(More)
What is it that makes software fail? In an empirical study of the post-release defect history of five Microsoft software systems, we found that failure-prone software entities are statistically correlated with code complexity measures. However, there is no single set of complexity metrics that could act as a universally best defect predictor. Using(More)
We analyze the version history of 7 software systems to predict the most fault prone entities and files. The basic assumption is that faults do not occur in isolation, but rather in bursts of several related faults. Therefore, we cache locations that are likely to have faults: starting from the location of a known (fixed) fault, we cache the location(More)
To learn what constitutes <i>correct</i> program behavior, one can start with <i>normal</i> behavior. We observe actual program executions to construct <i>state machines</i> that summarize object behavior. These state machines, called <i>object behavior models</i>, capture the relationships between two kinds of methods: <i>mutators</i> that change the state(More)