Diplom-/Masterarbeit

Automatische Beurteilung des Ad-Hoc-Testens nach einer Codeänderung

Projekt

Analyse des Programmierprozesses zwecks Vermeidung von Defekten

Art

30% Theorie, 50% Implementation, 20% Evaluation

Beschreibung

In dem oben genannten Projekt wird die Hypothese geprüft, ob die Tätigkeiten eines Programmierers Hinweise auf entstehende Fehler (= Fehlverhalten) und Defekte geben können. Eine selbstverständlich häufige Tätigkeit ist das Ändern von Code, vor allem auch in Form eher kleiner Anpassungs- und Defektbehebungen. Anschließend testet der Programmierer in der Regel kurz, ob seine Änderung funktioniert.

Wir nennen dies das "Ad-hoc-Testen". In dieser Arbeit soll untersucht werden, in welcher Form und in welchem Umfang in der Praxis Ad-Hoc-Testen durchgeführt wird. Insbesondere stellt sich die Frage, ob der Test überhaupt die geänderte Codestelle durchläuft. Man kann dies vergleichen mit dem im Bild dargestellten: Wird an der richtigen Stelle getestet, ob der Flicken auf dem Fahrradreifen auch dicht hält?

Dazu sind drei Fragenbereiche zu klären:

1. Welches sind die Kriterien, die an ein solches Ad-Hoc-Testen zu stellen sind? Diese leiten sich nahe liegender Weise aus klassischen funktionalen und strukturellen Abdeckungskriterien ab.
2. Wie kann man die Aktion des Ad-Hoc-Testens automatisch erkennen? Und wie kann man daraufhin die jeweils erzielten Gütekriterien automatisch erheben, also beurteilen, welche Güte ein Ad-Hoc-Test hatte?
3. Wie reagieren Programmierer in der Praxis, welche Heuristiken wenden Sie an und welche Güte wird in der Regel erreicht?

Aufgabe

Ziel dieser Arbeit ist es, der Antwort zu diesen drei Fragen möglichst nah zu kommen:

1. Einarbeitung in die Standardliteratur zu Testkriterien und Anpassung der Kriterien an die Abdeckung von kleinen Änderungen (anstatt ganzer Module).
2. Implementation der Güteevaluation anhand der Kriterien auf Basis einer schon vorhandenen (in Java auf Basis der Eclipse IDE implementierten) Mikroprozessaufzeichnung, die Elementarereignisse beinhaltet wie das Codeändern, Ausführen eines Programms, etc. Zu diesem Zweck ist vermutlich weitere Software einzusetzen wie etwa eine Hilfe zum Berechnen des "Code Coverage".
3. Einsatz des entstandenen Werkzeuges in der Praxis eines realen Projekts oder im Rahmen der Lehre zur Programmiereinführung mit Aufbereitung und Kommentierung der Ergebnisse.

Erste Schritte zur Implementation wurden in unserem Projekt schon begonnen und können genutzt werden.

Wie üblich schließt die Arbeit mit einer schriftlichen Ausarbeitung und einem Vortrag ab. Die Erstellung eines Beitrags im Rahmen einer wissenschaftlichen Konferenz wird unterstützt.

Kontakt

Diese Arbeit wird betreut von SebastianJekutsch und LutzPrechelt.

Quellen

• Für eine Definition von Gütekriterien eines Tests kann man die klassische Theorie der Strukturtests heranziehen, zu finden in jedem Lehrbuch des Software Engineering, siehe z.B. http://www.bullseye.com/coverage.html.
• Zur Ermittlung der Abdeckung eines Programmlaufs kann man die für die JVM definierte Profiling-Schnittstelle JVMPI nutzen. Ein Beispiel für ein einsetzbares "Code Coverage" Werkzeug ist JCoverage.
• Markus Mohnen. An Open Framework for Data–Flow Analysis in Java. Aachener Informatik Berichte, RWTH Aachen 2002. Hier wird ein Rahmen vorgestellt für datenflussbasierte Programmanalyse.
• Ebenfalls interessant sind Arbeiten zur automatischen Generierung von Testfällen aus dem Code oder aus Programmläufen. Eine von vielen in diesem Bereich ist Norbert Oster. Automatische Generierung optimaler datenflussorientierter Testdaten mittels Evolutionärer Verfahren. Lehrstuhl für Software Engineering (Informatik 11). Erlangen 2004.