Info iconThis preview shows pages 1–2. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 28, NO. 2, FEBRUARY 2002 1 Simplifying and Isolating Failure-Inducing Input Andreas Zeller, Member, IEEE Computer Society , and Ralf Hildebrandt 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 simpliFes 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 web browser crashed after 95 user actions. Our prototype implementation automatically simpliFed the input to 3 rel- evant user actions. Likewise, it simpliFed 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. Index Termsautomated debugging, debugging aids, testing tools, com- binatorial testing, diagnostics, tracing. I. INTRODUCTION Often people who encounter a bug spend a lot of time investigating which changes to the input Fle will make the bug go away and which changes will not affect it. Richard Stallman, Using and Porting GNU CC F you browse the Web with Netscape 6, you actually use a variant of Mozilla , Netscapes open source web browser project [1]. As a work in progress with big exposure, the Mozilla project receives several dozens of bug reports a day. The rst step in processing any bug report is simpliFcation, that is, elim- inating all details that are irrelevant for producing the failure. Such a simplied bug report not only facilitates debugging, but it also subsumes several other bug reports that only differ in ir- relevant details. In July 1999, Bugzilla, the Mozilla bug database, listed more than 370 open bug reportsbug reports that were not even sim- plied. With this queue growing further, the Mozilla engi- neers faced imminent doom [2]. Overwhelmed with work, the Netscape product manager sent out the Mozilla BugAThon call for volunteers [2]: people who would help process bug reports. For 5 bug reports simplied, a volunteer would be invited to the launch party; 20 bugs would earn her or him a T-shirt signed by the grateful engineers. Simplifying meant: turning these bug reports into minimal test cases , where every part of the input would be signicant in reproducing the failure. As an example, consider the HTML input in Figure 1. Loading this HTML page into Mozilla and printing it causes a segmen- tation fault. Somewhere in this HTML input is something that makes Mozilla failbut where? If we were Netscape program- mers, what we wanted here is the simplest HTML page that still produces the failure....
View Full Document

This note was uploaded on 10/04/2011 for the course CEN 5016 taught by Professor Workman,d during the Spring '08 term at University of Central Florida.

Page1 / 17


This preview shows document pages 1 - 2. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online