DDchange: Fehlerverursachende Änderungen
-
Upload
martin-burger -
Category
Technology
-
view
1.087 -
download
1
description
Transcript of DDchange: Fehlerverursachende Änderungen
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