Delta debugging: Difference between revisions

Revision as of 11:45, 22 July 2015

Revision as of 11:47, 22 July 2015

Line 8:

'''Delta Debugging''' is a methodology to automate the [[debugging]] of programs using a scientific approach of hypothesis-trial-result loop. This methodology was first developped by Andreas Zeller of the Saarland University in 1999<ref>{{cite book|last1=Zeller|first1=Andreas|title=Yesterday, my program worked. Today, it does not. Why?|date=1999|publisher=Springer Berlin Heidelberg|edition=Software Engineering—ESEC/FSE’99}}</ref>.

In practice, the Delta Debugging algorithm builds on [[unit testing]] to isolatesisolate failure causes automatically - by systematically narrowing down failure-inducing circumstances until a minimal set remains. For example, if you can supply a test case that will produce the bug you are looking for, then you can feed that to the Delta Debugging algorithm, which will then simply try to trim useless functions and lines of code that are not needed to reproduce the bug, until a 1-minimal program is found.

Delta Debugging has been applied to isolate failure-inducing program input (e.g. an HTML page that makes a Web browser fail), failure-inducing user interaction (e.g. the keystrokes that make a program crash), or failure-inducing changes to the program code (e.g. after a failing regression test).

Later, some software development tools have been inspired by Delta Debugging, such as the bisect commands of [[revision control]] systems (eg, git-bisect, svn-bisect, hg-bisect, etc.), which, instead of working on the program's code, apply the delta debugging methodology on the code history by comparing various versions until the faulty change is found.

== Software ==