DDchange:Fehlerverursachende

Änderungen

Martin Burger

Diplomarbeit

• “Eine Plattform zum automatischen Bestimmen von fehlerverursachenden Änderungen”

• In Kooperation

• Lehrstuhl für Softwaretechnik (Prof. Zeller)

• WEB.DE AG, Karlsruhe

Bisherige Arbeit

Grundlagen

Änderungen am Code

JUnit9:30

Kunde PremiumKunde

Änderungen am Code

JUnit

JUnit14:00

9:30

Kunde PremiumKunde

Zeit

Schuldner

Änderung

fehlerrelevant

Änderungen am Code

JUnit

JUnit27.10.

30.09.

Zeit??

Wie finden wirdie alternative Welt?

Delta-Debugging auf Versionsunterschieden

Alte Version

JUnit Test funktioniertAtkuelle Version

JUnit Testfunktioniert nicht

Ursachen

“Why Programs Fail, A Guide to Systematic Debugging” von Andreas Zeller

• Verfahre nach binärer Suche: Wende die Hälfte der Änderungen an und überprüfe, ob der Fehler noch auftritt.

• Wenn nicht, gehe einen Schritt zurück und wende die andere Hälfte der Änderungen an.

Binäre Suche

Menge der Änderungen

!"!!!"“Why Programs Fail, A Guide to Systematic Debugging” von Andreas Zeller

Simplifying

"

!Änderungen

!!

!…

Fehler-Ursache

“Why Programs Fail, A Guide to Systematic Debugging” von Andreas Zeller

Isolating

"

!Änderungen

!

"

!"

……Fehler Ursache

“Why Programs Fail, A Guide to Systematic Debugging” von Andreas Zeller

DDchangeFramework

Domain Framework

• Programmrahmen für einen bestimmten Problembereich

• Verfolgt Black-Box-Ansatz

• Wiederverwendbarkeit und Erweiterbarkeit

• Ist Open-Source, nutzt Open-Source

• Muss im Unternehmenseinsatz bestehen

Allgemeines Vorgehen1. Historie aufbauen

DDchange: Datenbank

• Domäne: Persistenz von Test-Ergebnissen

• Persistenz-Framework: Hibernate

• Zentrale Datenbank

• “Mitgelieferte” Datenbank HSQLDB

• Hot-Spots: Data Access Object zum Zugriff auf Historie

Allgemeines Vorgehen1. Historie aufbauen

2. Im Fehlerfall Änderungen ermitteln

DDchange: Di!/Patch

• Domäne: Erstellung von Diffs und Patches

• Zerlegt diff in “hunks”

• Hot-Spots: Erstellen und Anwenden der Deltas

DDchange: Subversion

• Domäne: Working Copy und Repository

• update, revert, diff

• Kann JavaSVN oder SvnClientAdapter nutzen

• Hot-Spots: Durch Interface abstrahiert

Allgemeines Vorgehen1. Historie aufbauen

2. Im Fehlerfall Änderungen ermitteln

3. Delta Debugging Test

1. Änderungen anwenden

Allgemeines Vorgehen1. Historie aufbauen

2. Im Fehlerfall Änderungen ermitteln

3. Delta Debugging Test

1. Änderungen anwenden

2. Bauen

DDchange - Debugger

• Framework enthält AntCompiler

• Übersetzen von veränderten Klassen

scrub! ! - ! Baut alle Klassen neu

depend" - " Betrachtet Abhängigkeiten " " " " " " der (geänderten) Klassen

• Hot-Spots: Interfaces für Builder

Allgemeines Vorgehen1. Historie aufbauen

2. Im Fehlerfall Änderungen ermitteln

3. Delta Debugging Test

1. Änderungen anwenden

2. Bauen

3. Test ausführen

DDchange: Test

• Domäne: Ausführen von Tests

• Führt JUnit-Tests in eigener VM via RMI aus

• Verteilte Tests

• Eigener Class Loader lädt veränderte Klassen neu

• Hot-Spots: Interfaces für Tester, Beschreibung und Ergebnis

Allgemeines Vorgehen1. Historie aufbauen

2. Im Fehlerfall Änderungen ermitteln

3. Delta Debugging Test

1. Änderungen anwenden

2. Bauen

3. Test ausführen

4. Änderungen rückgängig machen

Allgemeines Vorgehen1. Historie aufbauen

2. Im Fehlerfall Änderungen ermitteln

3. Delta Debugging Test

1. Änderungen anwenden

2. Bauen

3. Test ausführen

4. Änderungen rückgängig machen

5. Ergebnis zurück geben

DD-Algorithmus

• Implementierung des Algorithmus von Philipp Bouillon “A Framework for Delta Debugging in Eclipse”

• Änderungen für DDchange

• Abhängigkeit von Eclipse gelöst

• Um Cache-Interface und Implementierung erweitert (Hashtable und LRU)

Test-Abdeckung

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Conditionals Statements Methods TOTAL

Clover-Coverage

78 %84 % 86 % 84 %

DDchangeMaven

Apache Maven

• Software-Werkzeug für einfach(er)en Build-Prozess und Projektmanagement

• Einheitliches Buildsystem - vom Projektbeginn bis zum Deployment

• Einfaches Erstellen der Projekt-dokumentation

• Durch Plugins erweiterbar

Lebenszyklus

Compilieren, Testen

test

Projekt initialisieren

eclipsescm

Codemetriken für QS

checkstyleclover

Integrationstest

jbosscactus

Report-Generierung

sitechanges

Deployment

distjar

Lebenszyklus

Compilieren, Testen

testddchange

Projekt initialisieren

eclipsescm

Codemetriken für QS

checkstyleclover

Integrationstest

jbosscactus

Report-Generierung

sitechanges

Deployment

distjar

CruiseControl

• Framework zur kontinuierlichen Integration

• Automatisiertes und reproduziertes Bauen von Projekten

DDchange in CruiseControl

Cruise Control Repository

Entwicklungsteam

Commit

Update

Ant /Maven

Bauen / Testen

Ergebniss

“Publisher” Email

Informieren

Nach demBauen / Testen

DDchange in CruiseControl

Cruise Control Repository

Entwicklungsteam

Commit

UpdateErgebniss

DDchange Maven

“Publisher”

EmailInformieren

Bauen / Testen

Nach demBauen / Testen

Ant /Maven

Erweiterungen am Framework

• Keine Erweiterungen

• “Out-of-the-Box”

• Bezieht Änderungen von Subversion

• Zentrale MySQL-Datenbank bei WEB.DE

DDchange Maven: Nutzen

• Automatische Fehlersuche im automatischen Buildprozess

• Frühzeitiges Aufzeigen von Fehlern und deren Ursache

• Zentral und automatisch bei der ständigen Integration

• Für den Entwickler transparent

• Ergebnis (XML) kann weiter verarbeitet werden

DDchangeEclipse

Erweiterungen am Framework

• Local History statt Subversion

• Subversion denkbar

• Compiler von Eclipse statt AntCompiler

• Sehr schnell, inkrementell

DDchange Eclipse: Nutzen

• Automatische Fehlersuche im Hintergrund

• Schneller als DDchange Maven

• Frühzeitiges Aufzeigen von Fehlern und deren Ursache

• Fehlerrelevante Änderungen können auf Knopf-Druck zurückgenommen werden

• Nahtlose Integration in Eclipse

Lines of Code

0

7.000

14.000

21.000

28.000

35.000

Framework Maven Plugin Eclipse Plugin

Lines of Code

Zusammenfassung• Framework zur automatischen Bestimmung

von fehlerrelevanten Änderungen

• Schnelle und einfache Entwicklung von Werkzeugen

• Sich ergänzende Werkzeuge vorhanden

• DDchange EclipseLocal History "- lokal am Arbeitsplatz

• DDchange MavenSubversion "" - kontinuierliche Integration

Ausblick

Möglichkeiten

• Änderungen in Bezug auf funktionierenden Test

• “diff” (isolation) statt “min” (simplification)

• Verteilte bzw. parallele Fehlersuche

• Ergebnis verwandter Arbeiten nutzen

Optimierungen• Historie" Gruppierung von Änderungen anhand der " zeitlichen Abfolge

• Bauen / Compilieren" Übersetzte Klassen cachen

• Gruppieren" “Gültigkeitsbereich” beachten

• Auflösung von Fehlern" Fehlermeldungen geben Hinweis auf " Beseitigung

Continuous Testing

Stand:"Nicht alle Tests werden ständig " " " " " ausgeführtFolge: " Fehlschlagen fällt erst später auf, mehr " " " Änderungen

• Continuous Testing führt Tests im Hintergrund aus

• Nutzen: Suchraum wird kleiner

“Continuous testing in Eclipse” von David Saff und Michael D. Ernst

Change Impact Analysis

Stand:" Syntaktische Abhängigkeiten der " " " " " Änderungen werden ignoriertFolge:" Interferenz und Innkonsistenz

• Analyse bestimmt voneinander abhängige Änderungen anhand des AST

• Nutzen: Anzahl der “unresolved” Ergebnisse wird kleiner und somit die Anzahl der Tests

“Chianti: A tool for change impact analysis of Java programs”by Xiaoxia Ren, Fenil Shah, Frank Tip, Barbara Ryder, and Ophelia Chesley

Change Impact Analysis

Stand:" Änderungen ohne Einfluss auf den Test " " " werden betrachtetFolge:" Unnötig große Menge der Änderungen

• Analyse bestimmt Änderungen mit Einfluss auf den Call Graph der Tests

• Nutzen: Suchraum wird kleiner

Change Classification

Stand:" Historie der Testläufe wird nur sehr " " " " eingeschränkt betrachtetFolge:" Vorhandenes Wissen wird nicht " " " " " eingebracht

• Klassifizierung bestimmt Wahrscheinlichkeit der Fehlerrelevanz von Änderungen

• Nutzen: Suchraum wird kleiner

“Finding Failure-Inducing Changes using Change Classification”Maximilian Stoerzer, Barbara Ryder, Xiaoxia Ren, Frank Tip