Dr. Martin Burger

I have been maintaining several projects related to my research, as well as to lectures and research projects at the chair.

WebMate - Tests for Web 2.0 Applications (since 2011)

WebMate implements a technique to automatically generate tests for Web 2.0 applications. The approach automatically explores and navigates through arbitrary applications and this way is able to test all distinct functions of the given application. The only requirements to use WebMate are the address of the application and, if necessary, user name and password. WebMate addresses challenges such as interactive elements, state abstraction, and non-determinism in large applications. It can be used for regular application testing as well as for cross-browser testing.

Currently, I am working on a new business venture that will bring WebMate to the market.

JINSI - Failure-Inducing Program Interactions (2006–2011)

JINSI is a debugging tool that allows developers to capture and replay interactions between a program component (set of classes) and its environment, as well as between single objects within that component. JINSI this way enables developers to reproduce failures at will. In addition, JINSI uses dynamic slicing techniques and delta debugging to automatically isolate the subset of the interactions that is relevant for the failure to occur.

The integration of these techniques into one tool can efficiently and effectively pinpoint the actual defect: "Out of the 187,532 interactions in the addressbook component, two incoming method calls suffice to reproduce the failure." You can find further information about JINSI in my PhD thesis.

Fully automated review of student projects (internal project, 2007)

In the chair's "Programming 2" lecture, students have to implement small to mid-size projects in the Java programming language. In 2007, I was responsible for the design and implementation of a fully automated review process for these projects. I implemented a tool that fully automates distribution, submission, building, testing, and grading. Its features include the following highlights:

Individual assignments: To make it difficult for students to cheat by copying from other students, each student project is a variant of a master project: The master includes (a) API, (b) example implementation, and (c) test cases with a high coverage. By deriving variants from the master, each student gets an individual assignment. For example, different students have to implement different subsets of an extensive API that describes a tree implementation. Finally, we use tools to detect software plagiarism.
Submission at the push of a button: Basically, the students have to upload their projects to a central Subversion repository. To simplify the submission, we provided a BlueJ plugin that automates the upload process: the students simply have to push a button. By providing a simple and user-friendly tool, we are able to hide all the technical details from the students. This way, they can concentrate on learning on how to program in Java instead of learning peripheral tools (which is not the focus of this lecture).
Different test scopes: The projects contain public, nightly and secret tests. The public tests can be run by the students at will, as their projects contain the individual test sources. The nightly tests are run by a CruiseControl (a framework for a continuous build process) server, where the source code is not accessible for the students; each morning, the students get a report about their individual test results. Finally, after the project's deadline, the secret tests are run. This process ensures that students cannot solve the assignment using a brute-force method. Instead, because of the delalyed feedback, they are encouraged to think first. At the end of each assignment, the results of all tests are used to automatically calculate the grade for each project.
Automated build and test process: Internally, all projects are Maven projects. This way, building and testing is fully automated as well. However, from the students perspective of view the projects are simple BlueJ projects: the students do neither have to bother with Subversion, nor with the Maven build process. Even the test cases (JUnit tests) can be run within BlueJ at the push of a button.
Fully automated project manager tool: To ease the process of deriving student projects from the master project, publishing the individual projects to the students (via Subversion and the custom BlueJ plugin), adding them to the CruiseControl server, and so on, I implemented a project manager tool that handles these tasks. That way, the different sub-processes can be fully automated. For instance, one single call on the command line is sufficient to (1) derive variants from the master project, (2) to tests these variants against our sample solution, (3) to transform the variants into student projects, and (4) to publish the individual projects to the students.

By combining tools like Maven, Subversion, BlueJ, CruiseControl and in-house tools, I was able to fully automate distribution, submission, building, testing, and grading of student projects.

Publication Management System (internal project, 2006–2012)

For the Software Engineering chair, I implemented and mainainted a publication management system. Using this tool, group members can easily manage their published articles by simply editing an XML file. The web front end at the chair's web site, implemented in PHP, renders that information as HTML (including valid BibTeX entries) and allows visitors to filter the publications; for instance, by author, type, or date. Last but not least, the system allows to download selected articles as PDF file.

The use of XML has several advantages. First of all, the system does not need a database which minimizes maintenance costs. Furthermore, a proper XML Schema Definition ensures that the data provided by the authors is valid. For instance, information as author names and title is mandatory, ISBN numbers must satisfy the respective requirements, and BibTeX keys have to be unique.

All in all, that publication management system has minimal system requirements, is easy to use and maintain, and yet provides an adequate set of features.

DDchange - Failure-Inducing Code Changes (2003–2005)

DDchange is a debugging framework that automatically determines why your program fails: The change in line 45 makes the program fail. In order to compute a diagnosis this precise, DDchange applies delta debugging to program changes.

I developed and maintained the framework and the corresponding tools in the context of my diploma thesis. There are two instances (tools) using the architecture of the DDchange framework: An Eclipse plugin (DDchange Eclipse) and a Maven plugin (DDchange Maven).

DDchange Eclipse won an Eclipse Innovation Grant. Most parts of this work were developed in cooperation with 1&1 Internet AG, where I integrated DDchange Maven into the development process.

AskIgor - Automated Debugging Service (2002–2003)

AskIgor ("Ask Igor") was an experimental automated debugging server that could tell you why your program fails: Igor computed a diagnosis that exactly tells you why your program failed and how the failure came to be, respectively. This diagnosis has the form of a cause-effect chain—first, this happened, therefore, that happened, and therefore the program failed.