|
Isolating Failure-Inducing Input
Andreas Zeller
|
|
Universität Passau, Februrary 2001. Submitted for publication.
Abstract
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
working and a failing test case.
In a case study, the Mozilla web browser crashed after 95 user
actions. Our prototype implementation automatically simplified the
input to 3 relevant user actions. Likewise, it simplified 896 lines
of HTML to the single line that caused the failure. The case study
required 139 automated test runs, or 35 minutes on a 500 MHz PC.
This is an expanded and revised version of the paper
Simplifying Failure-Inducing
Input, appeared in Proc. ACM SIGSOFT
International Symposium on Software Testing and Analysis
(ISSTA 2000), Portland, Oregon, August 2000,
pp. 135-145.
Categories and Subject Descriptors
D.2.5 [Software Engineering]: Testing and debugging -
debugging aids, diagnostics, testing tools, tracing
General Terms
Automated debugging, combinatorial testing
Contents
- Introduction
- Testing for Change
- The Change that Causes a Failure
- Decomposing Changes
- Test Cases and Tests
- Minimizing Test Cases
- Minimal Test Cases
- A Minimizing Algorithm
- Properties of ddmin
- Case Studies
- GCC gets a Fatal Signal
- Mozilla Cannot Print
- Minimizing Fuzz
- The Precision Effect
- Isolating Failure-Inducing Differences
- Isolation Illustrated
- An Isolating Algorithm
- Properties of dd
- Case Studies Revisited
- Isolating GCC Input
- Isolating Fuzz Input
- Related Work
- Future Work
- Conclusion
Download
PDF version
(362k)
PostScript version
(127k, compressed)
Slides of ISSTA 2000 talk
(PDF, 218k)
Related Work
Ralf's diploma thesis with lots of material on the case studies
More on Delta Debugging