Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Ralf Hildebrandt

dblp:68/4105 · DBLP profile ↗
← Back
3ranked-venue papers
1as first author
1since 2021 · last 2025
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 3 · 1 first-author · 1 since 2021

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
3 papers
Debugging and program repair · 99% Software testing · 1%

Topics — the 4 heaviest of 4, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Debugging and program repair › automated debugging
delta debugging
0.932025
Simplifying and Isolating Failure-Inducing Input: A Retrospective on Delta Debugging · IEEE Trans. Software Eng. 2025
Simplifying and Isolating Failure-Inducing Input · IEEE Trans. Software Eng. 2002
Simplifying failure-inducing input · ISSTA 2000
Debugging and program repair
fault localization
0.932025
Simplifying and Isolating Failure-Inducing Input: A Retrospective on Delta Debugging · IEEE Trans. Software Eng. 2025
Simplifying and Isolating Failure-Inducing Input · IEEE Trans. Software Eng. 2002
Simplifying failure-inducing input · ISSTA 2000
Debugging and program repair
program reduction
0.922025
Simplifying and Isolating Failure-Inducing Input: A Retrospective on Delta Debugging · IEEE Trans. Software Eng. 2025
Simplifying and Isolating Failure-Inducing Input · IEEE Trans. Software Eng. 2002
Software testing › test optimization
test case reduction
0.012000
Simplifying failure-inducing input · ISSTA 2000

Methods — techniques the papers use, named apart from their topics

delta debugging · 0.9delta debugging algorithm · 0.0
YearPublicationVenuePosition
2025 Simplifying and Isolating Failure-Inducing Input: A Retrospective on Delta Debugging
abstract
Delta Debugging is a technique to simplify and isolate failure-inducing changes. Its most popular application is onprogram inputs,where it reduces a failure-inducing input to a minimal input that still triggers the failure. This paper provides a retrospective on Delta Debugging, discussing its origins, applications, and impact. We also discuss the limitations of Delta Debugging and suggest directions for future research.
Andreas Zeller, Ralf Hildebrandt
IEEE Trans. Software Eng.2
2002 Simplifying and Isolating Failure-Inducing Input
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 the 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 simplified the input to three 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.
Andreas Zeller, Ralf Hildebrandt
IEEE Trans. Software Eng.2
2000 Simplifying failure-inducing input
abstract
Given some test case, a program fails. Which part of the test case is responsible for the particular failure? We show how our delta debugging algorithm generalizes and simplifies some failing input to a minimal test case that produces the failure. 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. Categories and Subject Descriptors D.2.5 [Software Engineering]: Testing and Debugging---debug- ging aids, diagnostics, testing tools, tracing General Terms Automated debugging, combinatorial testing 1. INTRODUCTION Often people who encounter a bug spend a lot of time investigating which changes to the input file will make the bug go away and which changes will not affect it. --- Richard Stallman, Using and Port...
Ralf Hildebrandt, Andreas Zeller
ISSTA1