Yesterday, my program worked. Today, it does not. Why?
ESEC/FSE-7 Proceedings of the 7th European software engineering conference held jointly with the 7th ACM SIGSOFT international symposium on Foundations of software engineering
Simplifying failure-inducing input
Proceedings of the 2000 ACM SIGSOFT international symposium on Software testing and analysis
Simplifying and Isolating Failure-Inducing Input
IEEE Transactions on Software Engineering
Mutation analysis to verify feature matrices for isolating errors in simulation models
ACSC '03 Proceedings of the 26th Australasian computer science conference - Volume 16
Random testing of C calling conventions
Proceedings of the sixth international symposium on Automated analysis-driven debugging
Proceedings of the sixth international symposium on Automated analysis-driven debugging
On the automation of fixing software bugs
Companion of the 30th international conference on Software engineering
HVC'07 Proceedings of the 3rd international Haifa verification conference on Hardware and software: verification and testing
On test repair using symbolic execution
Proceedings of the 19th international symposium on Software testing and analysis
Evolutionary repair of faulty software
Applied Soft Computing
A model for spectra-based software diagnosis
ACM Transactions on Software Engineering and Methodology (TOSEM)
Evolving human competitive spectra-based fault localisation techniques
SSBSE'12 Proceedings of the 4th international conference on Search Based Software Engineering
Using automated program repair for evaluating the effectiveness of fault localization techniques
Proceedings of the 2013 International Symposium on Software Testing and Analysis
Injecting mechanical faults to localize developer faults for evolving software
Proceedings of the 2013 ACM SIGPLAN international conference on Object oriented programming systems languages & applications
| Hi-index | 4.10 |
Although software engineers have enjoyed tremendous productivity increases as more of their tasks have become automated, debugging remains as labor-intensive and painful as it was 50 years ago. An engineer or programmer must still set up hypotheses to use in identifying and correcting a failure's root cause. The author describes a new algorithm that promises to relieve programmers of the hit-or- miss approach to debugging. Delta Debugging uses the results of automated testing to systematically narrow the set of failure-inducing circumstances. Programmers supply a test function for each bug and hardcode it into any imperative language. The test function checks a set of changes to determine if the failure is present or if the outcome is unresolved, then feeds that information to the Delta Debugging code. As we discover more about the structure of these circumstances and the resulting causality chain, we come closer to passing much of the boredom and monotony of debugging onto machines. Debugging can be just as disciplined, systematic, and quantifiable as any other area of software engineering--which means that we should eventually be able to automate at least part of it. Ultimately, debugging may become as automated as testing--not only detecting failures, but also revealing how they came to be.