The focus of my research is on automated debugging, in particular on applying delta debugging to find failure-inducing circumstances automatically—circumstances such as the program input, changes to the program code, or program executions. For my diploma thesis, I applied delta debugging to determine failure-inducing code changes. For my PhD thesis, I used delta debugging and other dynamic techniques to find failure-inducing program interactions. As postdoc, I have been working on methods that help test and debug Web 2.0 applications.
As postdoc, I have been developing an automated debugging tool for complex Web 2.0 applications (joint work with Valentin Dallmeier): WebMate enables you to automatically test arbitrary Web 2.0 applications. Agents systematically explore all interactions and devise a usage model with all distinct behaviors of the application. The test generator then creates tests that cover all distinct behaviors in the usage model enabling WebMate to provide fully automatic cross-browser compatibility testing for whole applications.
The sole mandatory input to WebMate is the URL of the web application to test. (If the application requires special inputs such as login data, then the user has to provide this data to WebMate) Using the URL as a starting point, WebMate explores the web application and learns a usage model that captures how a user can interact with the web application. In this step, WebMate examines all buttons, links, forms or any other element with a JavaScript event handler that can be triggered by a user interaction. The resulting usage model represents these interactions as a graph where nodes correspond to different states of the application, and edges represent user interactions. Users of WebMate can leverage the usage model to systematically generate executions of the application and to perform analyses in all states recorded in the model—such as cross-browser-compatibility testing.
Using its feasibility to explore state-of-the-art Web 2.0 applications, WebMate is able to automatically compute comprehensive cross-browser compatibility analyses for modern web apps.
For my PhD thesis, I used capture/replay techniques to isolate failure-inducing interactions within programs; e.g., component or object interactions.
When a program fails, developers need to solve two issues: (a) reproducing the failure, and (b) fixing the defect such that the failure no longer occurs. Reproducing is crucial because one can examine the problem and eventually decide whether it has been fixed. Fixing is difficult because the developer needs to search the defect that causes the failure—a search in space and time which becomes the more difficult the larger the program state, and the distance between defect and failure.
Capture and replay techniques can be used to reproduce a failure. So, developers can analyze the problem. In addition, these techniques can be used to capture and replay selected parts of the program. Especially, parts that are involved in the failure. However, even if developers can focus on relevant parts of the program, the behavior (or, interactions as method calls, field accesses, etc.) within these parts to be analyzed can be very complex. By combining replay with minimization algorithms (e.g., with delta debugging) the captured interactions can be simplified until only the failure-inducing interactions remain. If the number of remaining interactions is sufficiently small, it is fairly easy to fix the defect.
Indeed, at the end, these methods can pinpoint the actual
defect: "Out of the 187,532 interactions in the
addressbook component, two incoming method calls
suffice to faithfully reproduce the failure at will."
In the context of my diploma thesis, I applied delta debugging on program changes to debug regressions automatically. The corresponding framework DDchange was developed in cooperation with 1&1 Internet AG, where I worked as intern.
A regression is a common type of failure that occurs while changing source code of a working program: "Yesterday, your program worked. Today, it does not. Why?" Manual debugging of regressions is costly in terms of labor and time, it annoys developers, and costs organizations a lot of money.
DDchange provides a platform that seamlessly integrates automated determination of failure-inducing code changes with common development processes. Automated determination may increase efficiency, improve productivity, while saving time and money. Because established processes need not to be adapted, start-up costs and risks are low.
The platform supplies two tools in the form of plug-ins. (1) The Eclipse plug-in integrates automated determination of failure-inducing changes with a prominent IDE. As soon as a unit test fails, it can be debugged automatically. (2) The Maven plug-in enriches continuous building and testing with automated debugging. Instead of a simple failure report, we obtain valuable information about failure-inducing changes-without lifting a finger: "The failure cause is the change in line 37 of file StringUtils.java."
The plug-ins are instances of the DDchange framework that contains all the basic functionality that allows to build tools that enable automatic determination of failure-inducing changes. Using that framework, implementing new tools that debug other types of failure is quite easy and simple—again saving time and money.