deposit_hagen
Publikationsserver der Universitätsbibliothek
Partitionierung von
Fehlerlokalisierungsproblemen mit Algorithmen aus der ganzzahligen linearen Optimierung
Mathematik und
Informatik
Dissertation
Marcus Frenkel
P F
A
O
Dissertation zur Erlangung des akademischen Grades des
Doktors der Naturwissenschaften (Dr. rer. nat.) der Fakultät für Mathematik und Informatik
der FernUniversität in Hagen Vorgelegt von
Marcus Frenkel
Inhaltsangabe
Softwaretests sind ein bewährtes Mi el zur Feststellung von Fehlern in Programmen. Das Fehlschlagen von Tests einer Testsuite liefert Hinweise darauf, dass in den ausgeführten Me- thoden eventuell Fehler vorhanden sind, bietet jedoch in der Regel keinen Anhaltspunkt für die tatsächliche Anzahl der vorhandenen Fehler, geschweige denn deren Ursprungsort. Das Vorhandensein mehrerer Fehler in realen Programmen ist jedoch nicht unwahrscheinlich – im Gegenteil. Daher werden Strategien benötigt, um die durch die Ausführung einer Testsui- te erhaltenen Informationen in einer Art und Weise auswerten zu können, die das Auffinden möglichst viele Fehler erlaubt. Von Vorteil ist zudem, wenn diese Strategien eine parallele Verarbeitung der Informationen erlauben, so dass mehrere Programmierer gleichzeitig auf Fehlersuche gehen können. Auf diese Weise können die verfügbaren Ressourcen effizient ein- gese t und die Suchdauer minimiert werden.
Ein Ansa zur Parallelisierung der Fehlersuche basiert darauf, dass die Ausführungsstruk- tur einer Testsuite auch als Matrix dargestellt werden kann. Da im Bereich der ganzzahligen linearen Optimierung bereits viele Algorithmen zur Partitionierung von Matrizen entwickelt wurden, liegt die Idee nah, einige von ihnen für die Ableitung von parallel durchführbaren Fehlerlokalisierungsprozessen zu nu en.
Diese Arbeit untersucht daher verschiedene Ansä e aus diesem Forschungsgebiet hinsicht- lich ihrer Eignung zur Parallelisierung und Beschleunigung der Fehlersuche bei Anwesenheit multipler Fehler. Einer der untersuchten Algorithmen wird zudem speziell auf das Fehler- suchproblem hin angepasst, um so noch effektiver zur Parallelisierung der Suche beitragen zu können.
Die Ergebnisse der Arbeit weisen darauf hin, dass die untersuchten Ansä e zu einer signi- fikanten Erhöhung der Anzahl der gefundenen Fehler sowie zu einer erheblichen Beschleu- nigung der Fehlersuche führen können. Zusä lich dazu werden verschiedene Probleme er- läutert, die in Evaluationen im Bereich der Fehlerlokalisierung im Allgemeinen und in dieser Arbeit im Speziellen auftreten können und welche Gegenmaßnahmen getroffen werden soll- ten, um ihre Auswirkungen zu minimieren.
Abstract
Software tests have proven to be a reliable tool for detecting faults in a computer program. A failing test of a test suite hints at a possible fault in the executed methods, but does neither give an indication of the actual number of faults, let alone their origin. Alas, the existence of multi- ple faults in a program is quite likely. It is therefore required to find strategies for interpreting the information given by a test suite execution in a way which allows for finding as much faults as possible. Furthermore, being able to process these information in parallel enables multiple programmers to search for faults at the same time, which minimizes processing times.
One approach to parallelize the search for faults is based on the fact that the execution struc- ture of a test suite can also be represented as a matrix. A vast amount of algorithms for parti- tioning a given matrix have been established in the field of integer linear programming. Why not apply some of them to the problem of parallelizing a fault localization process?
In this work, various algorithms taken from this domain are evaluated regarding their app- licability to parallelize and hence speed up the fault localization process in presence of multi- ple faults. One of the evaluated algorithms is further adapted specifically to the fault localiza- tion problem, allowing for a more effective fault localization approach.
The results of this work suggest that the evaluated approaches can lead to a significant increase in the amount of faults that can be searched at the same time and also to a considerable speed up of the fault localization process. On top of that evaluation, the work outlines various problems that can occur in evaluations, along with their possible solutions.
Danksagungen
Der Weg zur Promotion ist lang und beschwerlich – und auch wenn weite Teile davon allein zurückgelegt werden, so waren doch einige Personen involviert, die mir unterwegs zur Seite gestanden oder mir den Rücken frei gehalten haben. Ihnen allen möchte ich an dieser Stelle für ihre Unterstü ung danken.
Der erste Dank gebührt dem Doktorvater. Die lange Reise zur Promotion führte mich zu Professor Friedrich Steimann, dem ich sowohl für die Gelegenheit und Unterstü ung wäh- rend der Promotion danke, als auch für die Möglichkeit, Beruf, Promotion und Alltag so rei- bungslos zu verbinden.
Die Reise begann in Leipzig bei Professor Karsten Weicker. Auch wenn sie dort nicht ende- te, danke ich ihm für die Inspiration und Motivation, die ich aus seinen Vorlesungen, seiner Betreuung meiner Masterarbeit sowie der nachfolgenden Kommunikation und Zusammen- arbeit ziehen konnte.
Meinen Kollegen Bastian Ulke, Jörg Hagemann und Andreas Thies danke ich dafür, dass sie immer ein offenes Ohr für Fragen ha en und in den Diskussionen darüber oft eine Lösung gefunden werden konnte.
Ein besonderer Dank geht an Daniela Keller. Ihre unermüdliche Arbeit am Lehrgebiet hat für mich eine große Entlastung im alltäglichen Lehrbetrieb bedeutet und die so gewonnene Zeit konnte ich in die Dissertation investieren. Auch ihre Hilfe beim Korrekturlesen und bei der Lösung organisatorischer Fragen und Probleme war von unschä barem Wert.
Meinen Eltern danke ich für die dauerhafte Unterstü ung während meines Studiums – sie haben die Vorausse ungen für diese Dissertation geschaffen.
Der abschließende Dank geht an Katharina Niggemeier für das klaglose Ertragen meiner vielen durchgearbeiteten Abende und Wochenende und für die Rückendeckung im Alltag.
Danke!
Inhaltsverzeichnis
1. Einführung 11
. . Das Problem der Fehlerlokalisierung . . . . . . Beitrag der Arbeit . . . . . . Au au der Arbeit . . . .
2. Stand der Forschung 17
3. Abdeckungsbasierte Fehlerlokalisierung 23
. . Grundlagen . . . . . . Parallelisierung der Fehlersuche . . . . . . Qualitätsmaße . . . . . . Abgeschlossenheit von Tests . . . . . . Clustering . . . .
4. Mathematische Ansätze der Parallelisierung 35
. . Single Unit Tests . . . . . . Blockdiagonalmatrix . . . . . . Maximum Set Packing . . . .
5. Der Weil-Kettler-Algorithmus 41
. . Der originale Algorithmus nach Weil und Ke ler . . . . . . Anwendung des Weil-Ke ler zur Parallelisierung der Fehlersuche . . . . . . Der erste modifizierte Weil-Ke ler-Algorithmus . . . . . . Der zweite modifizierte Weil-Ke ler-Algorithmus . . . .
6. Aufbau der Evaluation 63
. . Probanden . . . . . . Granularität . . . . . . Fehlerinjektion . . . . . . Annahmen . . . . . . Bestimmung des Suchaufwandes . . . . . . Implementierung . . . .
7. Evaluationsergebnisse 77
. . Anzahl der DTs . . . . . . Bug Races . . . . . . Verlorene fehlerhafte UUTs . . . . . . Qualität der Blöcke . . . . . . Verwendung kürzester Tests . . . .
Inhaltsverzeichnis
. . Einfluss von Fehlerlokatoren auf die Qualität von Partitionierungsalgorithmen . . Inhalt des Randes . . . . . . A priori-Abschä ung zur Eignung einer TCM zur Fehlersuche . . . . . . Zusammenfassung . . . .
8. Einflüsse auf die Validität der Evaluation 107
. . Unverschuldete Fehlschläge . . . . . . Heterogenität der Probanden . . . . . . Erzeugung von Stichproben durch Fehlerinjektion . . . . . . Einfluss der Datenmenge . . . . . . Maskierte Fehler . . . . . . Weitere Einflüsse und Probleme . . . .
9. Zusammenfassung und Ausblick 117
A. TCMs nach Projekten 121
B. Aufwand nach Projekten 135
Literatur 139
1. Einführung
Programme enthalten Fehler – an dieser Aussage ist kaum zu rü eln. Sie wird durch zahl- reiche fatale Ereignisse der jüngeren Geschichte belegt, wie etwa dem Verlust der Mariner -Sonde, der ersten Ariane -Rakete und – besonders tragisch – drei Todesfällen, verursacht durch den zur Strahlentherapie verwendeten Therac- -Linearbeschleuniger. Alle drei ge- nannten und etliche weitere Ereignisse wurden durch Fehler in Programmen verursacht und führten im Laufe der Jahre zu erheblichen Verlusten, sowohl monetären als auch an mensch- lichen Leben. Die Suche nach Programmfehlern ist unbestreitbar eine wichtige, wenngleich auch aufwändige Arbeit.
Im Laufe der Zeit wurde eine Vielzahl an verschiedensten Methoden vorgestellt, um die Fehlersuche zu unterstü en und zu erleichtern. Eine der wichtigsten Vorausse ungen für den Einsa der meisten Vorgehensweisen ist natürlich, überhaupt Kenntnisse über das Vor- handensein eines Fehlers zu haben. Fehler treten natürlich spätestens beim Produktiveinsa einer Software auf, wenn die Benu er ein Problem melden – nicht selten ist es in diesem Fall jedoch schon zu spät und der Schaden ist entstanden (so im Falle der oben genannten fatalen Beispiele für Programmfehler). Idealerweise sollten Fehler aus diesem Grund bereits vor der Auslieferung der Software entdeckt werden. Ein probates Mi el hierfür stellt das automati- sierte Testen von Programmen mithilfe von Testsuites dar. Wurde durch Tests ein Hinweis auf einen Programmfehler entdeckt, muss dieser natürlich lokalisiert und beseitigt werden;
insbesondere die Lokalisierung erfordert hierbei viel Aufwand.
1.1. Das Problem der Fehlerlokalisierung
Die Verwendung von Testsuites erlaubt es, das Vorhandensein von Fehlern in Software auf- zuzeigen. Die in der Suite enthaltenen Tests überprüfen dazu bei Teilen eines Programms, ob ihr tatsächliches Ausführungsverhalten zu dem erwarteten passt – gibt es hier Abweichungen, so schlägt der entsprechende Test fehl und weist auf ein potentielles Problem im Programm- code hin. Der genaue Fehlerort wird dabei jedoch üblicherweise nicht gefunden, sondern lässt sich höchstens aus dem (manuell) dokumentierten Zweck des Tests ableiten; die genaue Lo- kalisierung obliegt dem Programmierer. Bei durch fehlerhaften Programmcode ausgelösten Fehlern besteht zwischen Test und Fehler lediglich die Beziehung, dass ein fehlschlagender Test auch eine fehlerhafte Codestelle ausgeführt hat – was allerdings auch nicht immer gilt, wie in Kapitel gezeigt wird.
Eine wichtige Annahme liegt daher darin, dass ein Fehler in der Regel im durch einen fehlschlagenden Test ausgeführten Programmcode, dem sogenannten Trace, liegt. Aus dieser Annahme ist ein ganz eigenes Forschungsgebiet erwachsen, und zwar das der abdeckungsba- sierten Fehlerlokalisierung [Won+ ]. Die grundlegende Idee dieser Methode ist es, die Traces mehrerer Tests zu kombinieren, um so den genauen (oder wenigstens den wahrscheinlichsten) Ort des Fehlers ableiten zu können, der für das Scheitern der Tests verantwortlich ist. Ein oft
. Einführung
verwendeter Ansa ist hier, die Fehlerwahrscheinlichkeit einer Codestelle über das Verhält- nis aus der Anzahl fehlschlagender und nicht fehlschlagender Tests, welche diese Codestelle ausführen, zu berechnen [Won+ ].
In der wissenschaftlichen Literatur zur abdeckungsbasierten Fehlerlokalisierung wurden bereits etliche Algorithmen vorstellt, die unter Ausnu ung von Trace-Informationen mögli- che Fehlerorte berechnen. Ihnen allen ist gemein, dass sie meist nur für den Fall gut funktio- nieren, dass im untersuchten Programmcode lediglich ein einzelner Fehler vorhanden ist – die Möglichkeit mehrerer, voneinander unabhängiger Fehlerstellen wird in den Berechnun- gen oft nicht berücksichtigt. Der Grund hierfür ist, dass diese Algorithmen meist ein einzelnes Ranking sämtlicher durch Tests ausgeführter Codestellen berechnen, die als Fehlerorte infrage kommen – bei Vorhandensein mehrerer Fehler wird jedoch nicht berücksichtigt, ob verschie- dene Tests aufgrund des gleichen oder unterschiedlicher Fehler fehlschlagen. So kann etwa eine Codestelle, die bei Betrachtung sämtlicher Tests einen eher niedrigen Rang hat, bei Be- rücksichtigung nur der Tests, für deren Fehlschlagen sie am wahrscheinlichsten verantwort- lich ist, im Ranking an oberster Stelle stehen.
Ein erster Hinweis auf das Vorhandensein mehrerer Fehler existiert, wenn keine einzelne potentielle Fehlerstelle aus den Traces sämtlicher fehlschlagender Tests auch das Fehlschla- gen aller dieser Tests erklärt. Mathematisch ausgedrückt bedeutet dies, dass die Schni menge aller Traces leer ist und damit keine Programmstelle existiert, die von allen fehlschlagenden Tests ausgeführt wird. Eindeutig ist die Frage nach der Anzahl der Fehler, wenn bestimmte Untermengen von fehlschlagenden Tests keine Schni mengen miteinander haben und damit keine gemeinsamen Codestellen ausführen – in diesem Fall kann davon ausgegangen wer- den, das jede Untermenge von Tests auf einen eigenen Fehler hinweist. Nicht mehr eindeutig ist die Situation, wenn alle Tests wenigstens paarweise eine nichtleere Schni menge haben und damit jeweils zwei Tests eine gemeinsame Codestelle aufrufen, allerdings keine einzelne Codestelle von allen Tests aufgerufen wird – in diesem Fall gibt es zumindest den Hinweis auf mehrere Fehler, jedoch nicht auf deren genaue Anzahl (geschweige denn deren Orte).
Wenn ein Hinweis auf das Vorhandensein mehrerer Fehler im Programmcode existiert, ist dies ein Anreiz, die Fehlersuche nach Möglichkeit zu parallelisieren, um somit den insge- samt benötigten zeitlichen Aufwand zur Fehlerbehebung zu reduzieren. Die Reduktion des Suchaufwandes kann einerseits durch die gleichzeitige Suche nach mehreren Fehlern erreicht werden; andererseits spart es auch Zeit, mehr als einen Fehler zu suchen, bevor die zum Pro- gramm gehörende Testsuite neu ausgeführt werden muss, um Hinweise auf weitere Fehler zu erhalten. Bei eindeutig unabhängigen Untermengen an Tests, die nach Fehlern durchsucht werden können, ist die parallele Suche problemlos möglich. Ist die Unabhängigkeit der Test- mengen allerdings nicht gegeben, besteht bei mangelhafter Parallelisierung die Gefahr, das ein Fehler Teil von mehreren Suchen und dadurch eventuell mehrmals unabhängig gefunden wird, was eine Vergeudung von Arbeitszeit bedeutet. Und selbst in vollständig unabhängigen Testmengen können sich wiederum jeweils mehrere Fehler verbergen, nach welchen bei pas- sender Parallelisierung gesucht werden kann. Benötigt werden demzufolge Algorithmen zur Aufteilung einer gegebenen Menge von Tests, so dass möglichst viele Fehler parallel gesucht werden können, ohne dass dabei ein Fehler allzu oft mehrfach gefunden wird.
Die Schni menge zweier Traces beinhaltet alle Programmstellen, die von beiden zugehörigen Tests ausgeführt werden.
. . Beitrag der Arbeit
1.2. Beitrag der Arbeit
Der Beitrag dieser Arbeit besteht in der Vorstellung, Weiterentwicklung und Evaluation von Algorithmen hinsichtlich ihrer Eignung zur Parallelisierung von Fehlerlokalisierungsproble- men. Konkret wird ihr Potential zur Maximierung der Anzahl an Fehlern, die gleichzeitig gesucht werden können, bei gleichzeitiger Minimierung des hierfür benötigten Suchaufwan- des untersucht. Auch das Risiko einer vergeudeten Suche aufgrund mehrfachen Auffindens des selben Fehlers wird evaluiert.
Die Arbeit betrachtet, au auend auf dem Ansa der abdeckungsbasierten Fehlerlokalisie- rung, verschiedene Algorithmen aus dem Bereich der ganzzahligen linearen Optimierung, da diese eine ähnliche Zielse ung – die Aufteilung eines Problems in unabhängige Teilprobleme – wie die Parallelisierung der Fehlersuche haben. Einer der betrachteten Algorithmen wird so modifiziert, dass er gezielt auf das Fehlerlokalisierungsproblem ausgerichtet ist; zwei Vari- anten des Algorithmus werden beschrieben und mit den restlichen Algorithmen verglichen.
Die Evaluation basiert auf . fehlerhaften Versionen von Programmen; die Versionen wurden eigens zu diesem Zweck per Fehlerinjektion erstellt.
Die Parallelisierung der Fehlersuche wurde unter anderem bereits durch Jones, Bowring und Harrold in [JBH ] unter dem Begriff Clustering betrachtet. Ziel der genannten Arbeit war es, eine Menge von Tests bei Vorhandensein mehrerer Fehler derart aufzuteilen, dass in jeder gefundenen Teilmenge unabhängig von den anderen nach einem Fehler gesucht werden kann. Das Problem beim durch Jones et al. vorgestellten Algorithmus besteht darin, dass sich die gefundenen Fehlercluster überlappen können, so dass ein relativ hohes Risiko einer ver- geblichen Fehlersuche aufgrund mehrfach gefundener Fehler besteht. Generell arbeiten die meisten der in der Literatur vorgestellten Parallelisierungsalgorithmen so, dass sie die Men- ge der (fehlschlagenden) Tests nach ihrer Wahrscheinlichkeit der Zugehörigkeit zur gleichen Fehlerursache partitionieren – streng genommen handelt es sich demzufolge um Partitionie- rungsalgorithmen. Da die Zugehörigkeit jedoch in der Regel nur angenommen und nicht ga- rantiert wird, führt dies zu Überlappungen der Cluster und damit potentiell zu vergeudetem Suchaufwand.
Der Ansa dieser Arbeit unterscheidet sich davon dadurch, dass nicht mögliche Fehleror- te über die Bestimmung ihrer Fehlerwahrscheinlichkeit berechnet werden, sondern die Auf- teilung der Fehlersuche allein auf Grundlage eindeutiger, durch die Programmausführung gesammelter Indizien durchgeführt wird. Im Grunde wird der Kontext der Fehlersuche aus- geklammert und die Parallelisierung der Suche allein auf Basis von in Matrizenform hinter- legten strukturellen Informationen durchgeführt. Der Algorithmus von Jones et al. wird in der Auswertung dieser Arbeit dennoch mit berücksichtigt, da er eine der ersten bedeuten- den Arbeiten in dieser Richtung und eine gute Vergleichsbasis für die restlichen betrachteten Algorithmen darstellt.
Das Ergebnis der Evaluation ist, dass mithilfe von Algorithmen der ganzzahligen linea- ren Optimierung deutliche Verbesserungen bei der Parallelisierung und beim benötigten Auf- wand für die Fehlersuche gegenüber dem Clustering von Jones (welches explizit für die Feh- lerlokalisierung entworfen wurde) erreicht werden können. Je nach Anforderung beim Ein- sa in der Praxis bieten sich verschiedene der untersuchten Algorithmen zur Verwendung an.
Eine überraschende Erkenntnis ist zudem, das ein relativ einfacher Algorithmus der linearen Optimierung sehr gute Ergebnisse bei der Parallelisierung liefert.
. Einführung
Da Evaluationen im Allgemeinen immer gewissen Einflüssen auf ihre Validität ausgese t sind, werden zudem einige der für Auswertungen im Bereich der Fehlersuche einflussreichs- ten Einflüsse betrachtet. Das Kapitel der
”Threats to the Validity“gehört zwar prinzipiell zum Guten Ton wissenschaftlicher Literatur, beinhaltet jedoch oft nur eine theoretische oder sehr knappe praktische Auseinanderse ung mit den Einflussfaktoren; diese Arbeit widmet daher ein Kapitel der detaillierteren Betrachtung möglicher Probleme und unterwirft sie, au auend auf Vorarbeiten aus [SFA ], einer eigenen Evaluation.
Diese Arbeit baut in Teilen auf bereits vorab publizierten Forschungsergebnissen auf (die in der folgenden Übersicht verwendeten Begrifflichkeiten werden in den entsprechenden Kapi- teln detailliert erläutert). In [SB ] wurden (ohne Beteiligung des Autoren dieser Arbeit) Block- diagonalmatrizen verwendet, um ein Fehlersuchproblem mit mehreren enthaltenen Fehlern in unabhängige, kleinere Suchprobleme für die parallele Verarbeitung zu zerlegen.
Darauf au auend wurde in [SF ] eine modifizierte Variante des Algorithmus von Weil und Ke ler [WK ] aus dem Bereich der ganzzahligen linearen Optimierung für eine über Blockdiagonalmatrizen hinausgehende, systematische Parallelisierung der Fehlersuche ver- wendet. Der Algorithmus wurde als interaktiver Ansa implementiert und präsentiert eine Menge von potentiell fehlerhaften Codestellen, die eine weitere Unterteilung des Suchpro- blems verhindern; wenn keine dieser Codestellen als fehlerhaft erkannt wird, kann die weite- re Suche parallelisiert werden. Für [SF ] wurden durch den Autoren der vorliegenden Arbeit die Modifikation des Weil-Ke ler-Algorithmus entwickelt, das Original und die Modifikati- on in einer horizontalen und einer vertikalen Variante implementiert sowie eine größere Da- tenerhebung aufgrund von sieben Probanden durchgeführt. Die umgese te Datensammlung umfasste dabei die Generierung von insgesamt fehlerhaften Programmversionen mi els Fehlerinjektion sowie deren Evaluation hinsichtlich der Anzahl der identifizierten Suchpro- bleme und des zur Suche benötigten Aufwandes mithilfe der Fehlerlokatoren Tarantula und Ochiai. Weiterhin war der Autor an der Interpretation der erhaltenen Ergebnisse beteiligt.
Während der Datensammlung traten zahlreiche technische und systematische Probleme zu- tage, die einen großen Einfluss auf die Validität einer Evaluation ausüben können und daher in einer eigenen Arbeit detailliert behandelt wurden [SFA ]. Der Autor der vorliegenden Arbeit hat viele dieser Probleme identifiziert oder war an deren Identifizierung und Diskussion be- teiligt. So wurden durch ihn zum Beispiel ein systematisches und zwei technische Probleme von Evaluationen – die unverschuldeten Fehlschläge sowie die Behandlung von abstrakten Tests und Parallelität in Testmethoden – identifiziert, welche sich direkt auf die Aussagekraft von berechneten Ergebnissen auswirken und unbedingt berücksichtigt werden müssen; die Hintergründe dieser Problematik werden in den Abschni en . und . im Detail erläutert.
Während sich das Vorhandensein der unverschuldeten Fehlschläge in Form unerwarteter Ef- fekte bei der Datenauswertung bemerkbar machte und lediglich die Gründe für diese Unstim- migkeiten identifiziert werden mussten, ha en fehlerhafte Traces aufgrund abstrakter Tests oder nicht beachteter Parallelität in der Testausführung keine direkt sichtbaren Auswirkun- gen auf die Ergebnisse. Lediglich beim Abgleich der berechneten TCMs mit den Testsuites der untersuchten Probanden fiel auf, dass einige der TCM-Spalten deutlich zu umfangreich wa- ren. Dies wurde als Hinweis darauf interpretiert, dass den zu den Spalten zugehörigen Tests zu viele aufgerufene Methoden zugeordnet wurden, was wiederum eine langwierige Suche nach den Gründen für diese Fehler nach sich zog. Weiterhin hat eine Analyse der evaluier- ten Testsuites durch den Autoren gezeigt, dass deren Qualität beträchtlich schwanken kann
. . Beitrag der Arbeit und damit Auswirkungen auf die Fehlersuche hat. Auch wurde durch ihn festgestellt, dass allgemeine Angaben zur Projektgröße stark vom verwendeten Werkzeug zur Bestimmung dieser abhängen – so liefern etwa verschiedene Eclipse-Plugins zum Zählen der Methoden ei- nes Projektes durchweg unterschiedliche Zahlen. Ein weiteres Problem, an dessen Identifika- tion und Auswertung der Autor beteiligt war, betraf die großen Unterschiede beim Vergleich von absolutem und relativem Aufwand zur Fehlersuche. Aufwandswerte können entweder in absoluten Zahlen oder relativ zur Projektgröße angegeben werden. Die Untersuchungen des Autoren haben gezeigt, dass beide Werte stark vom untersuchten Probanden abhängen; so schwankten die Werte für den Aufwand zwischen Probanden stärker als zwischen verschie- denen Algorithmen, durch deren Nu ung der benötigte Aufwand verursacht wurde. Weiter- hin ha e sich gezeigt, dass einige Probanden, obwohl sie gemessen am absoluten Aufwand scheinbar gut nach Fehlern zu durchsuchen waren, einen sehr hohen relativen Suchaufwand erforderten – und andersherum. Zusä lich hat der Autor den Einfluss der Stichprobengröße auf die Belastbarkeit der Ergebnisse einer Evaluation sowie die Auswirkung der Auswahl von Fehlerinjektoren auf die Länge von Traces untersucht, die Problematik von Fehlerinjektionen in Hilfsmethoden von Tests festgestellt, die Abhängigkeit der Güte von Fehlerlokatoren von der Anzahl der in einem Programm vorhandenen Fehler bei einer Fehlersuche ohne Parti- tionierung evaluiert und die Häufigkeit von maskierten Fehlern untersucht (die Problematik maskierter Fehler wurde in [SFA ] unabhängig von deren erster Diskussion in [JBH ] ent- deckt und ausgewertet). Neben der Identifizierung und Diskussion der genannten Probleme hat der Autor der vorliegenden Arbeit die Datenbasis für [SFA ] um vier Projekte erweitert und ein erweiterbares Evaluations-Framework implementiert, welche für die nun insgesamt Probanden (ein in der Vorarbeit verwendetes Projekt musste aufgrund der abstrakten Tests ausgeschlossen werden) zunächst insgesamt . Mehrfehlervarianten erzeugte und sie an- schließend hinsichtlich der genannten Problemstellungen evaluierte.
Der Ansa der Nu ung von Algorithmen aus der ganzzahligen linearen Optimierung zur Partitionierung von Fehlersuchproblemen aus [SB ] und [SF ] wurde in [HSF ] um die Un- tersuchung eines weiteren Algorithmus erweitert, welcher für die Lösung des Maximum Set Packing-Problems entwickelt wurde. Zusä lich dazu wurden weitere Kennzahlen der Parti- tionierungsalgorithmen, darunter etwa die Menge der provozierten Bug Races, bestimmt und der Fokus der Datenauswertung auf die Parallelisierung der Fehlersuche gelegt. Hierfür wur- de durch den Autoren der vorliegenden Arbeit abermals die Datenbasis um fünf Projekte und damit auf insgesamt . Mehrfehlervarianten erweitert; weiterhin war der Autor auch hier an der Interpretation der Ergebnisse beteiligt. Die zuvor durch ihn implementierte Umset- zung des originalen Weil-Ke ler-Algorithmus sowie das für [SF ] entwickelte Framework für Evaluationen wurden in [HSF ] durch den Erstautoren der Arbeit für die erweiterten Datenauswertungen benu t.
Die hier vorliegende Arbeit stü t sich auf die Vorarbeiten aus [SB ], [SF ], [SFA ] und [HSF ], insbesondere auf die durch den Autoren gefundenen Probanden für die Generierung fehlerhafter Programmversionen und das implementierte Evaluations-Framework. Zusä lich zum originalen Weil-Ke ler und dessen Modifikation wurde für diese Arbeit eine weitere, durch den Autoren entwickelte Variante des Algorithmus vorgestellt und implementiert. Die in den Vorarbeiten gesammelten Kenntnisse führten zudem zu einer Neuimplementierung des Evaluations-Frameworks zur Bestimmung verschiedener Kennzahlen der untersuchten Algorithmen sowie zu einer erneuten Berechnung aller benu ten fehlerhaften Programm-
. Einführung
versionen; dies war nötig, da sich im Laufe der Zeit zahlreiche zumeist kleinere Fehler in den Daten und den Auswertungen gezeigt ha en, die korrigiert werden mussten. Ein wichtiger Beitrag der Arbeit und ihrer Vorarbeiten ist zudem die erstellte und veröffentlichte Datenba- sis, zu deren Verwendung es bereits mehrere Anfragen und zum Zeitpunkt der Abgabe dieser Arbeit auch bereits ein veröffentlichtes Paper [MMP ] gab.
1.3. Aufbau der Arbeit
Die Arbeit ist im Weiteren wie folgt aufgebaut. Das . Kapitel gibt eine Übersicht über den Stand der Forschung mit ausgewählten Literaturbeiträgen im Bereich der abdeckungsbasier- ten Fehlerlokalisierung sowie der Parallelisierung der Fehlersuche. Das . Kapitel führt detail- liert in die in Abschni . nur kurz angerissene Thematik der abdeckungsbasierten Fehlerlo- kalisierung und deren Parallelisierung ein, definiert wichtige Begriffe und stellt das bereits er- wähnte und etablierte Verfahren von Jones zur Parallelisierung vor. Im . Kapitel werden die untersuchten und auf grundlegenden Algorithmen der ganzzahligen linearen Optimierung beruhenden Ansä e zur Parallelisierung der Fehlersuche beschrieben. Im . Kapitel werden ein komplexerer Algorithmus im Detail vorgestellt, seine Adaption für die Fehlersuche be- trachtet sowie zwei Modifikationen des Algorithmus erläutert, welche den Fokus stärker auf die betrachtete Problematik der Fehlersuche legen. In Kapitel wird der Au au der Evaluatio- nen beschrieben, mit welcher die verschiedenen Algorithmen hinsichtlich ihrer Eignung zur Parallelisierung der Fehlersuche untersucht und miteinander verglichen werden sollen. Die Ergebnisse dieser Evaluation werden im . Kapitel vorgestellt und ihre Bedeutung im Detail diskutiert. Kapitel widmet sich wichtigen Einflüssen auf die Validität der Auswertung, wel- che die Aussagekraft dieser und ähnlich ausgerichteter Evaluationen beeinträchtigen können und wie mit diesen Einflüssen umgegangen werden sollte. Das le te, . Kapitel schließlich fasst die Erkenntnisse der Arbeit zusammen und gibt einen Ausblick auf weitere mögliche Evaluierungsansä e. Der Anhang enthält Diagramme und Abbildungen zur Einzelauswer- tung aller in der Evaluation betrachteten Projekte.
h p://www.feu.de/ps/prjs/PD/
2. Stand der Forschung
Zum Thema Fehlerlokalisierung existiert eine große Menge an Literatur – allein das seit sta findende International Symposium on Software Testing and Analysis (ISSTA) weist Veröffentlichungen zum Stichwort”fault localization“ auf. Da auch abseits dieser Konferenz unzählige weitere Publikationen zu diesem Thema existieren, erscheint eine erschöpfende Literaturbetrachtung nicht angebracht. Sta dessen werden in diesem Kapitel ein Überblick über die für diese Arbeit wichtigsten Literaturgrundlagen gegeben, die Anfänge der Paral- lelisierung der Fehlerlokalisierung skizziert sowie die Publikationen aufgelistet, welche die unmi elbare Grundlage für diese Arbeit bilden.
Generell lassen sich in der Literatur zwei Ansä e zur Fehlerlokalisierung unterscheiden:
die modellbasierte Diagnose und die abdeckungsbasierte Fehlerlokalisierung [AZG ].
Modellbasierte Diagnose Die modellbasierte Diagnose wurde im Zusammenhang mit der Fehlerlokalisierung erstmals von Reiter in [Rei ] formal beschrieben. Sie wurde als Möglich- keit vorgestellt, ausgehend von einer formalen Beschreibung eines Programmes diejenigen Programmkomponenten zu bestimmen, die für eine Abweichung eines beobachteten Pro- grammverhaltens vom tatsächlich erwarteten Verhalten verantwortlich sind. Konkrete Um- se ungen der modellbasierten Diagnose wurden zum Beispiel in [FPV ], [WSM ] oder [AZG ] beschrieben, jedoch existiert zu diesem Thema noch weitaus mehr Literatur – allein das Originalpaper von Reiter aus dem Jahr verzeichnet bei der ACM zum Zeitpunkt der Veröffentlichung der vorliegenden mehr Arbeit Zitierungen, und jedes Jahr kommen neue hinzu.
Abdeckungsbasierte Fehlerlokalisierung Im Gegensa zur modellbasierten Diagnose wer- den in der abdeckungsbasierten Fehlerlokalisierung die durch die Ausführung von Tests ge- sammelten Informationen über die Programmausführung genu t, um die wahrscheinlichsten Stellen für einen Fehler zu identifizieren. Seine Anfänge hat der abdeckungsbasierte Ansa unter anderem in der Arbeit von Reps et al. [Rep+ ], in welcher die Möglichkeit untersucht wurde, mithilfe der Ausnu ung von Informationen über die Programmausführung dem Jahr-
-Problem zu begegnen.
h p://dl.acm.org/citation.cfm?id=
Mit der sich nähernden Jahrtausendwende wurde das Problem festgestellt, das viele Programme Jahreszahlen lediglich als zweistellige Angabe der le ten beiden Jahresziffern dargestellt haben. Mit dem Jahreswechsel von zu änderten sich die Jahreszahlen somit von auf – was zu zahlreichen Problemen, etwa bei der Sortierung von Jahren oder bei der Berechnung von Zeitdauern, hä e führen können. Glücklicherweise hielten sich die Auswirkungen des Problems zum Jahrtausendwechsel durch vorhergehende, umfangreiche Soft- und Hardwareaktualisierungen in Grenzen.
. Stand der Forschung
Berücksichtigung multipler Fehler in Programmen Viele abdeckungsbasierte Ansä e (et- wa [Che+ a], [JHS ] oder [DLZ ]) wurden lediglich für den Einfehlerfall – den Fall, dass im Programm lediglich ein einziger Fehler existiert – vorgestellt und analysiert, obgleich sie in der Regel nicht explizit auf dieses Szenario beschränkt wurden. In den Evaluationen wurde und wird oft die Siemens-Testsuite als Grundlage für Experimente genu t, eine Sammlung fehlerhafter Versionen von sieben Programmen, in welche manuell Fehler injiziert wur- den [Hut+ ]. Jede der Programmversionen enthält dabei allerdings nur einen einzelnen Fehler – ein Widerspruch zur Realität, da in der Praxis selbst kleine Programme mehrere Feh- ler enthalten können. Im Gegensa dazu wird die modellbasierte Diagnose üblicherweise im Mehrfehlerszenario evaluiert.
Der von Abreu et al. in [AZG ] vorgestellte Ansa Zoltar-M stellt eine Mischform dar, da er sowohl modellbasierte als auch abdeckungsbasierte Techniken zur Bestimmung von Fehlerorten nu t und explizit für den Mehrfehlerfall entworfen wurde. Der Algorithmus be- rechnet sogenannte ”minimal hi ing sets“ – Mengen von Programmstellen, welche sämtli- che beobachteten Fehlschläge von Tests erklären würden, wenn alle diese Programmstellen tatsächlich fehlerhaft wären. Die Mengen fungieren als Kandidaten zur Erklärung der Fehl- schläge und sind entsprechend einer Heuristik nach ihrer Wahrscheinlichkeit sortiert, die tat- sächliche Erklärung für alle fehlschlagenden Tests zu sein. Die Kandidaten können sequenti- ell entsprechend ihres Ranges und die in den einzelnen Kandidaten enthaltenen Programm- stellen können parallel durchsucht werden. Dieser Ansa entspricht im Prinzip dem le - ten Schri des Quine-McCluskey-Algorithmus zur Minimierung boolescher Funktionen, für den die vollständige Abdeckung der Spalten einer Primimplikanten-Tabelle bestimmt wer- den muss [McC ], was zum Beispiel mithilfe von Petrick’s Method durchgeführt werden kann [Pet ]. Die durch den Algorithmus bestimmten Lösungsmengen an möglichen Kombi- nationen von Primimplikanten entsprechen den Minimal Hi ing Sets von Abreu et. al., mit dem Unterschied, dass die Primimplikanten-Mengen allein strukturell bestimmt und damit unsortiert sind, wohingegen die Minimal Hi ing Sets nach ihrer Wahrscheinlichkeit sortiert werden, alle Fehlschläge erklären zu können. Die Arbeit von Abreu et al. berücksichtigt den Umstand, dass in einem Programm durchaus mehrere Fehler existieren können. Jedoch wird – ebenso wie viele Veröffentlichungen über modellbasierte Diagnosetechniken – nicht unter- sucht, welche Auswirkungen auf den Suchaufwand eine Parallelisierung der Fehlersuche ha- ben können.
Die Anfänge der Parallelisierung der Fehlerlokalisierung Eine der ersten Arbeiten zur ex- pliziten Parallelisierung der Fehlersuche – oder entsprechend des Titels, zum parallelen De- buggen – im Bereich der abdeckungsbasierten Fehlerlokalisierung stammt von Jones, Bowring und Harrold [JBH ; Jon ]. In ihr werden zwei Methoden zur Partitionierung einer Menge von fehlgeschlagenen Tests in Teilmengen, sogenannte Cluster, vorgeschlagen. Jeder dieser Cluster soll dabei auf möglichst einen eigenständigen Fehler im Programmcode hinweisen.
Der Vorteil des Clustering ist, dass jeder gefundene Cluster einem eigenen Programmierer zu- gewiesen werden kann, der in diesem anschließend einen Fehler sucht – das Debugging wird damit parallelisiert. Durch die Einschränkung des Suchraumes auf ausgewählte Tests wird zudem der benötigte Aufwand zum Finden eines Fehlers vermindert. So kann das Clustering auch einen Vorteil bei der Fehlersuche bedeuten, wenn die einzelnen Cluster nicht parallel,
sondern sequentiell durchsucht werden. Zusä lich ergibt sich durch die Anzahl der Cluster ein Hinweis auf die Menge der Fehler, die möglicherweise im Programm enthalten sind. Jones et al. haben ihre zwei Algorithmen an einem einzelnen Probanden evaluiert; dabei haben sie bei sequentieller Fehlersuche Einsparungen bezüglich des Aufwandes von % und % im Vergleich zur Suche nach ebenso vielen Fehlern mit erneuter Ausführung der Testsuite nach jedem beseitigten Fehler nachweisen können. Bei echt paralleler Fehlersuche konnten Ein- sparungen von % beziehungsweise % erreicht werden, wobei in diesem Fall der jeweils längste Suchlauf aus allen Clustern gezählt wurde. Ein Problem des Clusterings ist allerdings, dass die einzelnen Cluster zwar unterschiedliche Fehler adressieren sollten, dies von den Al- gorithmen jedoch nicht erzwungen wird, wie von Jones et al. selber angemerkt [JBH , p. ].
Ein ähnliches Ziel verfolgen Podgurski et al. mit ihrem Ansa , per Clusteranalyse (der Su- che von ähnlichen Daten in einem Datenbestand) von fehlgeschlagenen Programmausfüh- rungen in Anwesenheit mehrerer Fehler diejenigen Ausführungen zu gruppieren, die auf- grund einer ähnlichen Ausführungsstruktur auf die gleichen oder ähnliche Fehler hinweisen [Pod+ ]. Im Gegensa zu Jones gruppiert dieser Ansa keine Tests, sondern gemeldete Feh- ler mit ihren zugehörigen Programmausführungen, wenn diese eine ähnliche Ausführungs- struktur aufweisen. Ziel der Gruppierung ist es, gemeldete Programmfehler automatisch zu klassifizieren und zu priorisieren, so dass die dringendsten Fehler zuerst behoben werden können. Eigentliches Ziel der Arbeit ist die Gruppierung der Fehlermeldungen – die genau- en oder ungefähren fehlerhaften Stellen im Code werden durch den Ansa nicht markiert, weswegen er strenggenommen auch kein Verfahren zur Parallelisierung der Fehlersuche dar- stellt.
Ähnlich zu Podgurski et al. gruppieren Liu und Han fehlgeschlagene Programmausfüh- rungen anhand ihrer Nähe zu ihrem wahrscheinlichsten Fehlerort [LH ]. Liu et al. argu- mentieren jedoch, dass sich gleiche Ursachen für Testfehlschläge nicht aus ähnlichen Ausfüh- rungsstrukturen der fehlschlagenden Tests ergeben (so wie etwa in [Pod+ ] ausgenu t), da auch zwei im Grunde stark unterschiedlich ablaufende Tests aufgrund des gleichen Fehlers fehlschlagen können. Im Unterschied zu Podgurski et al. gruppieren sie daher fehlschlagen- de Tests nicht aufgrund deren Ausführungsstruktur, sondern direkt nach deren Wahrschein- lichkeit, auf den gleichen Fehlerort hinzuweisen. Die wahrscheinlichste Programmstelle für das Fehlschlagen einer Programmausführung wird dabei mithilfe von SOBER [Liu+ ], einem Tool zur automatischen Fehlerlokalisierung von den gleichen Autoren, bestimmt. Zusä lich zur Gruppierung der Programmausführungen weist dieser Ansa durch die Kombination der durch SOBER und die Gruppierung gewonnenen Informationen auch konkret auf mögliche Fehlerorte hin.
Zheng et al. instrumentieren in ihrem Ansa Programmcode mit Prädikaten, deren Wahr- heitswerte während der Programmausführung bestimmt und anschließend benu t werden, um mögliche Fehlerorte abschä en zu können. Die Verwendung von Prädikaten zur Feh- lerlokalisierung wurde durch die Autoren in einer vorherigen Arbeit bereits vorgeschlagen [Lib+ ] und in [Zhe+ ] um die Möglichkeit erweitert, bei Vorhandensein mehrerer Fehler durch geeignete Aufteilung der Prädikate auf verschiedene Fehlerursachen hinweisen zu kön- nen. Weder Podgurski et al., noch Liu et al. noch Zheng et al. adressieren allerdings das Pro- blem der parallelen Fehlersuche explizit.
. Stand der Forschung
Interaktion von Fehlern Debroy und Wong [DW ] sowie DiGuiseppe und Jones [DJ b;
DJ a] haben in ihren Arbeiten die Auswirkungen von miteinander interagierenden Fehlern auf die Fehlerlokalisierung untersucht. Sie haben dabei zwischen drei Arten von Interaktio- nen unterschieden. Zum einen können Fehler derart interagieren, dass Tests, die beim Vor- handensein nur einzelner Fehler nicht fehlschlagen, durch die Kombination der Fehler nun fehlschlagen. Demgegenüber können Fehler auch so interagieren, dass Tests, die für die Ein- zelfehler fehlschlugen, bei gleichzeitigem Vorhandensein aller Fehler nicht mehr fehlschlagen.
Als dri es sind auch kombinierte Effekte denkbar. Beide Forschungsgruppen kamen zu dem Schluss, dass die Auswirkungen dieser Interaktionen in einer nicht zu vernachlässigenden An- zahl auftreten (was auch in einer der Vorarbeiten zu dieser Arbeit bestätigt wurde [SFA ]), Algorithmen zur Fehlerlokalisierung jedoch in der Regel dennoch in der Lage sind, Fehler in derartigen Programmen zu finden.
Fehlerlokatoren Die Grundlage vieler Algorithmen zur abdeckungsbasierten Fehlerlokali- sierung bilden sogenannte Fehlerlokatoren – Formeln, welche Stellen im Programmcode in eine Rangfolge bezüglich ihrer Wahrscheinlichkeit bringen, fehlerhaft zu sein. In der wissen- schaftlichen Literatur wurde bereits eine große Anzahl derartiger Lokatoren vorgestellt; ein Überblick vom theoretischen Standpunkt aus findet sich etwa in [NLR ] und [Xie+ ], wo- hingegen in [AZG ] und [Zha+ ] verschiedene Lokatoren empirisch untersucht wurden.
Die Studien kommen zu unterschiedlichen Ergebnissen bezüglich der Güte der Fehlerlokato- ren, definieren jedoch jeweils einen bestimmten oder eine Klasse von Lokatoren als“die bes- ten“. Im Widerspruch dazu wird in [Yoo+ ] formal bewiesen, dass es keine beste Formel ge- ben kann. Der Grund für diesen Widerspruch liegt darin, dass die Leistung der Lokatoren von vielen verschiedenen externen Faktoren – etwa dem Au au und der Durchführung der Eva- luation oder den untersuchten Probanden – abhängt. Die Suche nach”dem besten“ Lokator klammert diese jedoch aufgrund der Vielzahl der möglichen Faktoren meist komple aus und die Formeln werden in einem sehr begrenzten Umfeld miteinander verglichen. Zusammen- gefasst lässt sich als Erkenntnis aus den (teilweise widersprüchlichen) Studien ableiten, dass die Güte der Fehlerlokatoren von zu vielen externen Faktoren abhängt, als dass die Verwen- dung nur einer kleinen Auswahl von Lokatoren für eine Evaluation, zum Beispiel im Bereich der Parallelisierung der Fehlerlokalisierung, zu einem repräsentativen Ergebnis führen könn- te. Als Alternative wurde daher in [SFA ] ein Algorithmus vorgeschlagen, durch welchen eine untere Schranke für die Performanz von Fehlerlokatoren beschrieben wird – kein Loka- tor sollte Fehler schlechter finden können als dieser Algorithmus. In [HSF ] wurde dieser Algorithmus verwendet, um Möglichkeiten zur Parallelisierung der Fehlersuche unabhängig von einem bestimmten Fehlerlokator evaluieren zu können. Auch in dieser Arbeit wird der Ansa verfolgt, für die Aufwandsabschä ung lediglich eine untere Schranke zu berechnen.
Fehlerinjektion Eine weitere, häufig in der Forschung diskutierte Problematik ist die der Bereitstellung von fehlerhaften Programmversionen zur Evaluation. Viele Untersuchungen – nicht nur im Bereich der Fehlerlokalisierung – greifen dabei oft auf die automatisierte Injek- tion von Fehlern durch Programmmutation zurück (zum Beispiel [BFL ], [FW ], [Hut+ ], [BLW ], [MBN ], [Che+ b], oder [GJS ]). In der Literatur über die Eignung von Muta- tionen zur Generierung fehlerhafter Programme findet sich mehrheitlich die Meinung, dass
Mutanten durchaus als Ersa für reale Fehler benu t werden können (und mangels brauch- barer Alternativen auch müssen), dies jedoch mit Vorsicht zu geschehen hat, da sie unter Umständen reale Fehler nicht im vollen Maße repräsentieren [Ali+ ; NK ; ABL ; Jus+ ; GJG ]. Unter anderem wird diskutiert, ob die wenigen, üblicherweise benu ten Fehlerinjek- toren ausreichen, um die Vielzahl an möglichen Fehlern in realen Programmen ausreichend zu repräsentieren und ob insbesondere die benu ten Injektoren eventuell zu simpel sind – viele Mutationen verändern lediglich einzelne oder wenige zusammenhängende Token, wo- hingegen sich ein realer Fehler über weite Teile eines Programms verteilen kann. Zusä lich unterscheiden sich reale Fehler je nach verwendeter Programmiersprache, so dass nicht pau- schal eine festgelegte Menge von Injektoren für Evaluationen verwendet werden kann, die auf Probanden in unterschiedlichen Programmiersprachen beruhen.
3. Abdeckungsbasierte Fehlerlokalisierung
Ein in der Literatur häufig verwendeter und für die Parallelisierung der Fehlersuche gut ge- eigneter Ansa ist die abdeckungsbasierte Fehlerlokalisierung. In diesem Kapitel werden die theoretischen Grundlagen dieser Methode erläutert, wichtige Begriffe definiert, der Zusam- menhang zur Parallelisierung der Fehlersuche hergestellt und ein in der Literatur bereits eta- blierter, grundlegender Partitionierungsalgorithmus vorgestellt.
3.1. Grundlagen
Alle Programme se en sich aus einzelnen Programmeinheiten, den sogenannten Units zu- sammen. Eine Unit stellt einen klar umrissenen Bestandteil des Codes dar und kann zum Beispiel eine Klasse, eine Methode oder auch nur ein einzelnes Statement sein [IEEE ].
Definition. Eine Programmeinheit oder Unit bezeichnet einen klar abgegrenzten Teil eines Programmcodes, etwa eine Klasse, eine einzelne Methode oder ein Statement.
Zu jeder tatsächlichen Programmausführung mit einer bestimmten Eingabe gehören die Programmeinheiten, welche während der Ausführung aufgerufen wurden; sie werden auch unter dem Begriff Trace zusammengefasst [IEEE ]. Ein Trace wird üblicherweise aus Units der gleichen Ebene gebildet. Wird ein Trace etwa auf Methodenebene bestimmt, so werden al- le Methoden aufgezeichnet, die während der Programmausführung aufgerufen werden. Ein Trace auf Ebene der Statements umfasst dementsprechend sämtliche ausgeführten Anwei- sungen. Die Art der verwendeten Units wird durch die Granularität des Traces beschrieben.
Im Rahmen dieser Arbeit soll gelten, dass ein Trace lediglich Informationen über die aufge- rufenen Units an sich enthält, nicht aber deren Ausführungsreihenfolge oder -häufigkeit.
Definition. Ein Trace beschreibt eine Menge von Units der gleichen Granularität, die während einer bestimmten Ausführung des Programms aufgerufen wurden.
Die abdeckungsbasierte Fehlerlokalisierung, kurz ABFL, befasst sich mit dem Prozess, auto- matisiert potentiell fehlerhafte Stellen im Programmcode durch den Vergleich der Traces von mehreren Programmausführungen mit jeweils spezifischer Eingabe zu identifizieren. Hierbei werden die Informationen, ob die einzelnen Ausführungen jeweils zu ihrem erwarteten Ergeb- nis geführt haben oder nicht, mit berücksichtigt. Eine für den Einsa der Fehlerlokalisierung wichtige Grundlage ist natürlich, das überhaupt Informationen über das Vorhandenseins ei- nes Fehlers in einem Programm vorliegen. Ein Fehler (in der englischen Fachliteratur als fault bezeichnet [IEEE ]) ist dabei Programmcode, welcher im Endeffekt dazu führt, das ein ei- gentlich erwartetes Programmverhalten nicht eintri , das Programm also zum Beispiel eine unerwartete Ausgabe liefert, abstürzt oder sonst ein unerwartetes Verhalten zeigt.
Definition. Ein Fehler ist ein Teil des Programmcodes, welcher bei Ausführung zu einem unerwarteten Verhalten des Programmes führt.
. Abdeckungsbasierte Fehlerlokalisierung
Die Information über das Vorhandensein eines Fehlers kann zum Beispiel in Form eines gemeldeten Bugs durch Nu er des Programms mit dem zugehörigen, durch manuelle Pro- grammausführung gewonnenen Trace bereitgestellt werden. Da jedoch in der Regel mehrere Traces für eine automatisierte Fehlerlokalisierung notwendig sind, wäre auch das mehrfa- che Ausführen des fehlerhaften Programmes mit unterschiedlichen Eingaben nötig. Alterna- tiv dazu kann eine größere Anzahl an Traces auch durch die automatische Ausführung von Testmethoden bestimmt werden, welche eine abgegrenzte Funktionalität (Komponententest) oder zusammenhängende Programmteile (Integrationstest) auf ein erwartetes Verhalten hin überprüfen. In den Komponententests werden in der Regel einzelne Units getestet – daher auch die Bezeichnung Uni est [IEEE ].
Prinzipiell liefern beide Ansä e – sowohl die Bearbeitung von manuellen Fehlermeldungen als auch die automatische Ausführung von Testmethoden – die benötigten Informationen. Im Sinne einer zumindest teilautomatisierten Fehlersuche wird in der abdeckungsbasierten Feh- lerlokalisierung jedoch primär auf Testmethoden gese t, da sie bereits vor der Programmaus- lieferung zur Entdeckung von Fehlern verwendet werden können. Durch ihre automatisierte Ausführbarkeit nehmen sie den Programmierern die Arbeit ab, manuell ein Fehlerverhalten ihrer Anwendung provozieren zu müssen.
Ausgangspunkt für die automatische Ausführung von Testmethoden sind die Testfälle. Die- se sind definiert als die Spezifikation einer Programmeingabe, einer erwarteten Ausgabe sowie einer Menge dazu gehöriger Ausführungsbedingungen [IEEE ]. Ein Test beschreibt dagegen die tatsächliche Ausführung des Testfalls in Form einer Testmethode, das heißt die Anwen- dung der spezifizierten Eingabe auf das zu untersuchende Programm beziehungsweise einen Teil des Programms und den Vergleich des beobachteten Programmverhaltens mit dem er- warteten [IEEE ]. Jedem Test kann auch immer ein Trace, und zwar die Folge der im Zuge der Testdurchführung aufgerufenen Programmanweisungen, zugeordnet werden. Ein Test schlägt fehl, wenn beobachtetes und erwartetes Verhalten nicht zueinander passen; passt bei- des zusammen, so ist der Test erfolgreich [IEEE ].
Definition. Ein Testfall spezifiziert ein Paar aus einer Programmeingabe und dem dazu er- warteten Verhalten. Ein Test beschreibt die tatsächliche Ausführung eines Testfalls und besteht aus dem Trace der Testausführung sowie dem beobachteten Programmverhalten. Entspricht das beobachtete Verhalten nicht dem erwarteten, so wird er als fehlgeschlagener Test bezeich- net, ansonsten als erfolgreicher Test.
Für die ABFL werden immer mehrere Traces benötigt, um aus ihnen durch Anwendung geeigneter Algorithmen eine Fehlerstelle ableiten zu können. Eine wichtige Vorausse ung ist daher das Vorhandensein einer größeren Menge zusammengehöriger Testfälle, einer soge- nannten Testsuite [IEEE ].
Definition. Eine Menge von zum gleichen Programm gehörenden Testfällen wird als Testsui- te bezeichnet.
Da bei der ABFL potentiell fehlerhafte Programmstellen auf Grundlage des Traces identi- fiziert werden, können Fehlerorte nur auf der gleichen Ebene wie die aufgezeichneten Pro- grammeinheiten des Traces bestimmt werden. Die ABFL-Algorithmen sind in der Regel je- doch nicht auf eine bestimmte Trace-Granularität angewiesen, sondern arbeiten unabhängig
. . Grundlagen davon; es genügt demzufolge, bei der Erklärung von Algorithmen von getesteten Programm- einheiten oder – englisch griffig – von Units Under Test (UUTs, abgeleitet vom System Under Test [IEEE ]) zu sprechen. Enthält eine getestete Programmeinheit (also etwa ein ausgeführ- tes Statement oder eine Methode) einen Fehler, so wird diese als fehlerhaft bezeichnet.
Definition. Eine Unit Under Test (UUT) ist eine Programmeinheit, die durch einen Test aus- geführt wird. Enthält sie einen Fehler, so wird sie als fehlerhafte UUT bezeichnet.
Die Ausführung einer Testsuite mit Bestimmung der zu den einzelnen ausgeführten Tests gehörenden Traces führt dementsprechend zu der Information, welche UUTs durch welche Tests ausgeführt werden. Dieser Zusammenhang lässt sich zu Zwecken der Darstellung auf einfache Weise in einer Matrix zusammenfassen, in welcher die Tests durch Spalten und die UUTs durch Zeilen repräsentiert werden. Ein nichtleeres Element in der Matrix (üblicherweise mit dem Wert
” “ markiert) bedeutet, dass die UUT in der entsprechenden Zeile vom Test der zugehörigen Spalte ausgeführt wird. Ein leeres Element (oder, je nach Darstellung, auch eine” “) bedeutet dementsprechend keine Ausführung der UUT durch den Test. Ein Beispiel für eine derartige Matrix findet sich in Abbildung . . Sie repräsentiert Tests (t1bist4) mit insgesamt ausgeführten UUTs (u1 bisu4), von denen der Test t1 die UUTsu1, u2 und u4 ausführt,t2 die UUTsu2undu3,t3die UUTsu2undu4sowiet4die UUTsu1,u3 undu4.
t1 t2 t3 t4
u1 1 1
u2 1 1 1
u3 1 1
u4 1 1 1
Abbildung . .: Testabdeckungsmatrix (TCM)
Eine derartige Matrix wird als Testabdeckungsmatrix oder Test Coverage Matrix (kurz TCM) bezeichnet [SF ].
Definition. Eine Testabdeckungsmatrix oder Test Coverage Matrix (kurz TCM) bezeichnet ei- ne Matrix, deren Spalten die Tests einer ausgeführten Testsuite und deren Zeilen UUTs reprä- sentieren. Eine
” “in einer Zeile und Spalte bedeutet, dass die durch die Zeile repräsentierte Programmeinheit durch den von der Spalte repräsentierten Test aufgerufen wird. Ein leeres Element kennzeichnet eine nicht ausgeführte Unit.
Je nach verwendeter ABFL-Methode ist auch unter Umständen die Betrachtung lediglich der fehlgeschlagenen Tests von Interesse, welche sich ebenfalls in einer Matrix – bezeichnet als Fehlerabdeckungsmatrix oder Failed Test Coverage Matrix (FCM) – zusammenfassen lassen [SF ].
Definition. Eine Abdeckungsmatrix, welche in den Spalten ausschließlich fehlgeschlagene Tests enthält, wird als Fehlerabdeckungsmatrix oder Failed Test Coverage Matrix (kurz FCM) bezeichnet.
. Abdeckungsbasierte Fehlerlokalisierung
Durch die gesammelten Trace-Informationen und unter Zuhilfenahme von Algorithmen zur abdeckungsbasierten Fehlerlokalisierung können Hinweise auf die möglichen fehlerhaf- ten Programmstellen gewonnen werden. Auf Grundlage dieser Hinweise ist im Anschluss die eigentliche Suche nach Fehlern möglich. Die Algorithmen präsentieren hierfür üblicher- weise eine Menge von (geordneten oder ungeordneten) UUTs, von denen ein oder mehrere potentiell fehlerhaft sein können – die Aufgabe des Programmierers ist es, die fehlerhaften aus dieser Auswahl zu identifizieren und die Fehler zu beseitigen. Der Vorgang der manu- ellen (oder im Zuge der Evaluation simulierten, automatisierten) Fehlersuche auf Grundlage automatisch identifizierter UUTs wird im weiteren Verlauf der Arbeit als Suchproblem oder englisch Debugging Task, kurz DT, bezeichnet. Zur Erklärung des Suchvorgangs kann auch davon gesprochen werden, dass ein Fehler in einer TCM, einer FCM, oder einer Submatrix einer dieser beiden Matrizen gesucht wird. Dies stellt natürlich nur eine Abstraktion des ei- gentlichen Suchproblems dar – die betrachteten Matrizen werden hierbei als Abstraktion für die zugrundeliegenden Traces der ausgeführten Testsuite gebraucht. Eine DT ist damit nicht nur Bezeichnung für den eigentlichen Vorgang der Fehlersuche, sondern repräsentiert auch die Menge an UUTs und Tests, die durchsucht werden sollen.
Definition. Unter einem Suchproblem (englisch einer Debugging Task, kurz DT) wird der Vorgang verstanden, aus einer Menge präsentierter UUTs eine oder mehrere fehlerhafte zu identifizieren. Daneben beschreibt eine DT auch die Menge an UUTs und Tests, welche durch- sucht werden sollen.
Ein im Rahmen der abdeckungsbasierten Fehlerlokalisierung übliches Vorgehen zum Ab- leiten eines Suchproblems aus einer TCM oder FCM ist es, sämtliche ausgeführten UUTs an- hand einer Abschä ung ihrer Fehlerhaftigkeit zu sortieren. Ziel ist es, dass diejenigen UUTs, in denen sich mit der höchsten Wahrscheinlichkeit ein Fehler befindet, am Anfang der Sortie- rung stehen. Die eigentliche Aufgabe bei der Fehlersuche durch den Programmierer besteht nun darin, die UUTs entsprechend der Reihenfolge ihrer Sortierung sukzessive zu durchsu- chen, bis eine fehlerhafte gefunden wurde. Ein häufiger Ansa zur Sortierung ist, zu jeder UUT auf Basis des Verhältnisses zwischen erfolgreichen und fehlgeschlagenen Tests, die sie ausführen, einen Verdächtigkeitswert zu berechnen und die UUTs nach ihrer Verdächtigkeit zu sortieren. Die Berechnung dieses Verdächtigkeitswertes erfolgt mithilfe einer als Fehlerlo- kator bezeichneten Formel.
Das bekannteste Beispiel für dieses Vorgehen ist die von Jones et al. vorgestellte Technik Tarantula [JH ], welche sowohl einen Fehlerlokator als auch das zugehörige, ihn benu en- de Werkzeug bezeichnet. Der Tarantula-Lokator berechnet die VerdächtigkeitrT einer UUT ui entsprechend der Formel . . Hierbei stellt f(ui) die Anzahl der fehlschlagenden Tests, welche die UUTui aufrufen, undf die Gesam ahl der fehlschlagenden Tests dar.p(ui)ent- spricht analog dazu der Anzahl deruiaufrufenden, erfolgreichen Tests undpder Anzahl der insgesamt erfolgreich durchlaufenden Tests.
rT(ui) =
f(ui) f p(ui)
p +f(ufi) ( . )
. . Grundlagen Ein alternativer Fehlerlokator, der sich in Studien (zum Beispiel in [SF ]) als gute Alter- native zu Tarantula erwiesen hat, ist der Ochiai-Lokator, dargestellt in Formel . . Er stammt ursprünglich aus dem Bereich der Mikrobiologie [Och ], wurde von Abreu et al. in [AZG ] für die Fehlerlokalisierung übernommen und unabhängig davon ohne Kenntnis der Vorar- beiten in [SES ] entwickelt, begründet und evaluiert .
rO(ui) = f(ui)
√f·(f(ui) +p(ui)) ( . )
Ein Beispiel für die durch Tarantula und Ochiai berechneten Verdächtigkeitswerte findet sich in Abbildung . . Zu sehen ist eine TCM, in welcher die Tests nach ihrem Status – fehlge- schlagen (f, für failed) oder erfolgreich (p, für passed) – gruppiert sind. Der rechte Teil der Ab- bildung zeigt die durch die jeweiligen Lokatoren berechneten Verdächtigkeitswerte. Würden die UUTs entsprechend dieser Werte für die Fehlersuche sortiert, so ergäbe sich für Tarantula die Reihenfolgeu1,u2,u4,u3, wohingegen Ochiai die UUTs zuu2,u1,u4,u3sortieren würde.
f1 f2 f3 f4 | p1 p2 p3
u1 1 |
u2 1 1 | 1
u3 1 | 1 1 1
u4 1 1 | 1 1 1
rT rO 1,00 0,50 0,60 0,58 0,20 0,25 0,33 0,45
Abbildung . .: Verdächtigkeitswerte von UUTs nach Tarantula und Ochiai
Fehlerlokatoren wie Tarantula und Ochiai haben die Eigenschaft, dass sie mehreren UUTs die gleichen Verdächtigkeitswerte zuordnen können. Bei Betrachtung der UUTs in der Rei- henfolge ihrer Verdächtigkeit stellt sich damit die Frage, wie mit UUTs gleicher Verdächtig- keit umgegangen werden soll – eine für die Praxis mögliche Lösung wäre zum Beispiel die Präsentation der UUTs gleicher Verdächtigkeit in zufälliger Reihenfolge.
Die Güte eines Fehlerlokators lässt sich bestimmen, indem die Anzahl der UUTs, die bis zum Auffinden eines Fehlers betrachtet werden müssen, gezählt wird. Diese Anzahl der unter- suchten UUTs wird als der Aufwand bezeichnet, welcher nötig ist, um einen Fehler zu finden [SF ]. Der benötigte Aufwand ist von der durch einen Lokator vorgegebenen Reihenfolge der UUTs abhängig – er stellt damit ein Maß für die Qualität dieser Reihung dar. Je nach Be- trachtungsweise kann dabei die eigentliche fehlerhafte UUT im Aufwand mit enthalten oder jedoch ausgeschlossen sein. Das Ausschließen aus dem Aufwands-Wert hat den Vorteil, dass ein Algorithmus, welcher fehlerhafte UUTs immer sofort lokalisiert (das heißt, mit der höchs- ten Verdächtigkeit versieht), im Falle der Suche nach mehreren Fehlern mit Aufsummieren der Aufwände für die einzelnen Fehler einen Gesamtaufwand von für sämtliche gefunde- nen fehlerhaften UUTs aufweisen würde. Dem gegenüber würde das Einschließen von feh- lerhaften UUTs dazu führen, dass eine Abhängigkeit des Aufwands-Maßes von der Anzahl der gesuchten Fehler bestünde: Je mehr Fehler gesucht würden, desto höher wäre der Auf-
Insbesondere liefert [SES ] auch eine Begründung dafür, warum der Ochiai-Lokator dann am besten arbeitet, wenn sich in der zu untersuchenden Menge an UUTs nur ein Fehler befinden.
. Abdeckungsbasierte Fehlerlokalisierung
wand, unabhängig davon, ob die fehlerhaften UUTs immer sofort gefunden werden würden oder nicht. Aus diesem Grund wird im weiteren Verlauf der Arbeit davon ausgegangen, dass gefundene fehlerhafte UUTs beim Zählen des Aufwandes nicht mit eingerechnet werden.
Definition. Der Aufwand zum Finden eines Fehlers bezeichnet die Menge an UUTs, die aus einer geordneten oder ungeordneten Auswahl betrachtet werden muss, bis eine fehlerhafte gefunden wird. Die fehlerhafte UUT wird dabei selbst nicht mitgezählt.
3.2. Parallelisierung der Fehlersuche
Das Fehlschlagen von Tests ist nur ein Hinweis darauf, dass im zugehörigen Programm gene- rell Fehler vorhanden sind – auf die genaue Anzahl von Fehlern lässt sich daraus jedoch in der Regel nicht schließen. Als Ausnahme gelten hier lediglich Uni ests, wenn sie im strengen Sin- ne ihrer Wortbedeutung implementiert sind: In diesem Fall testen sie eine sehr abgegrenzte Programmeinheit (etwa eine einzelne Methode), so dass ein Fehlschlagen eines solchen Tests dementsprechend eindeutig auf den Fehlerort hinweist. In der Praxis sind echte Uni ests je- doch nur schwer umzuse en, da die meisten Programmeinheiten Abhängigkeiten zu anderen Units besi en. In der objektorientierten Programmierung etwa bestehen oft Abhängigkeiten von Konstruktoren und Zugriffsmethoden (Ge er und Se er), die zum Au au der Testum- gebung und zum Überprüfen der Ergebnisse aufgerufen werden müssen. Zudem rufen viele Methoden weitere Funktionen auf, was echte Uni ests weiter erschwert. Zwar existieren An- sä e zur Vermeidung dieser Probleme – Stichwort Mock-Objekte –, jedoch vermindern sie nur die Abhängigkeiten von Klassen untereinander, nicht jedoch die von Methoden.
Die Abschä ung der Anzahl der möglichen Fehler in einem Suchproblem, zusammen mit einer wenigstens ungefähren Eingrenzung des möglichen Fehlerortes, bringt zwei große Vor- teile für die Fehlersuche. Zum einen führt das Auffinden und Beseitigen mehrerer Fehler dazu, dass die zugrundeliegende Testsuite seltener ausgeführt werden muss, denn das Beseitigen eines Fehlers erfordert eigentlich ein erneutes Ausführen der Tests, um ein eventuelles Vor- handensein weiterer Fehler zu überprüfen. Insbesondere bei langlaufenden Tests lässt sich so viel Zeit sparen. Zum anderen lassen sich so – genügend Programmierer vorausgese t – mehrere Fehler gleichzeitig suchen, was die Gesam eit der Fehlersuche minimiert, da durch die Aufteilung der zu untersuchenden UUTs weniger Codestellen durch jeden Programmierer untersucht werden müssen.
Ansä e wie Tarantula und Ochiai suchen bei ihrer alleinigen Anwendung nur nach einem einzigen Fehler, da sie sämtliche UUTs in ein einzelnes Ranking überführen. Theoretisch könn- te eine von diesen Algorithmen bestimmte Sortierung natürlich nach dem ersten Fund einer fehlerhaften UUT weiter abgearbeitet werden – dies ist jedoch insofern problematisch, als dass in diesem Fall gar nicht bekannt ist (beziehungsweise durch den Lokator gemeldet wird), ob weitere Fehler überhaupt vorhanden sind. Zusä lich berücksichtigen diese Fehlerlokatoren in der Regel nicht explizit, dass verschiedene Tests aufgrund verschiedener fehlerhafter UUTs fehlschlagen können, und die entstehenden Rankings sind damit im Mehrfehlerfall für die Fehlersuche nicht gut geeignet (wie von Jones et al. selber angemerkt [JBH ]). Bei Vorhan- densein eines einzelnen Fehlers erfüllen die Lokatoren zwar ihre Aufgabe; jedoch kann der Einfehlerfall nicht generell angenommen werden, da die tatsächliche Menge an im Programm vorkommenden Fehlern grundsä lich unbekannt ist.
. . Qualitätsmaße Es ist daher notwendig, Hinweise darauf zu gewinnen, dass mehr als ein Fehler im Pro- gramm vorhanden sein muss; idealerweise lässt sich außerdem auch die ungefähre Anzahl der Fehler abschä en. Zudem muss die Fehlersuche so organisiert werden, dass gezielt (und parallel) nach verschiedenen Fehlern gesucht werden kann, da die alleinige Kenntnis über das Vorhandensein mehrerer Fehler noch keine strukturierte Suche zulässt. Beide Ziele werden im Folgenden unter dem Begriff der Parallelisierung der Fehlersuche zusammengefasst.
Definition. Die Parallelisierung der Fehlersuche ist die Aufteilung eines Suchproblems in par- tielle Suchprobleme derart, dass sowohl eine Abschä ung über die Anzahl der möglichen findbaren Fehler abgegeben wird, als auch jeder dieser Fehler in einem separaten Teil des Suchproblems unabhängig von den anderen Fehlern gezielt gesucht werden kann.
Ein möglicher Ansa für diese Parallelisierung ist es, die dem Suchproblem entsprechende TCM oder FCM so zu zerlegen oder zu partitionieren, dass disjunkte oder sich nur geringfü- gig überlappende Mengen von Zeilen und Spalten (UUTs und Tests) entstehen. Diese Mengen stellen partielle Suchprobleme dar, welche sich parallel und weitgehend unabhängig von den anderen Mengen durchsuchen lassen . Die Partitionierung einer Matrix entspricht damit der Aufteilung eines Suchproblems in mehrere unabhängige oder sich nur geringfügig überlap- pende Debugging Tasks.
Definition. Unter der Partitionierung oder Zerlegung einer TCM oder FCM wird deren Auf- teilung in mehrere disjunkte oder sich geringfügig überlappende Mengen von UUTs und Tests verstanden, welche als separate Suchprobleme gelöst werden können.
3.3. Qualitätsmaße
Die einzelnen DTs einer partitionierten Matrix müssen entsprechend der Definition nicht zwin- gend disjunkt sein. Damit ergibt sich jedoch die Situation, dass sich verschiedene DTs auch UUTs teilen können. Einerseits bedeutet dies, dass bei paralleler Fehlersuche die gleichen nicht fehlerhaften UUTs unter Umständen mehrmals betrachtet werden, was an sich schon vergeu- dete Zeit bedeutet. Andererseits kann es dazu führen, dass auch fehlerhafte UUTs in zwei DTs enthalten sind und dass dadurch zwei Programmierer den gleichen Fehler finden kön- nen – in diesem Fall war eine von beiden Suchen gänzlich umsonst, da sie zu keinen neuen Erkenntnissen geführt hat. Diese Situation wird als Bug Race bezeichnet [HSF ].
Definition. Mit Bug Race werden Situationen bezeichnet, in denen eine fehlerhafte UUT in zwei oder mehr verschiedenen DTs auftri und in diesen während der Fehlersuche gefunden wird.
Zu beachten ist dabei, dass das Vorhandensein einer fehlerhaften UUT in zwei DTs nicht automatisch das Entstehen eines Bug Race bedingt. Ist in wenigstens einer der beiden DTs mindestens ein weiterer Fehler enthalten, kann natürlich – je nach Reihenfolge der betrachte- ten UUTs – auch dieser gefunden werden und es entsteht kein Bug Race. Die Anzahl der DTs gibt damit zwar einen Hinweis auf die Menge der Fehler, legt jedoch keinen genauen Wert
Abweichend von mathematischer Definition der Partitionierung bzw. Zerlegung, welche disjunkte Teilmengen verlangt, ist in dieser Arbeit auch prinzipiell eine Überlappung erlaubt.
. Abdeckungsbasierte Fehlerlokalisierung
fest, da in einer DT sowohl mehr als ein Fehler enthalten sein kann (was mehr Fehler als DTs bedeutet), als auch Bug Races auftreten können (und damit potentiell weniger Fehler als DTs vorhanden sind).
Die Güte einer Partitionierung lässt sich damit (unter anderem) an drei Werten festmachen:
• der Anzahl der DTs, die durchsucht werden können
• der Anzahl der Bug Races, die bei der Suche auftreten
• dem Aufwand, der in jeder DT notwendig ist, um sie nach einem Fehler zu durchsuchen Eine weitere wichtige Kennzahl einer Partitionierung ist die Anzahl an fehlerhaften UUTs, die während der Aufteilung verloren gehen können. Einige der im weiteren Verlauf der Ar- beit vorgestellten Algorithmen arbeiten so, dass sie Spalten (Tests) identifizieren, die eine Auf- teilung einer TCM oder FCM verhindern und diese im Anschluss aus der Matrix entfernen.
Durch das Entfernen von Spalten kann es allerdings passieren, dass dadurch auch Zeilen (und damit UUTs) in der Matrix nicht mehr abgedeckt werden, diese ebenso entfernt werden und damit in keinem Suchproblem mehr enthalten sind – sie sind verloren [HSF ]. Dies ist vor allem dann nachteilig, wenn es sich hierbei um fehlerhafte UUTs handelt, da diese Fehler bei Auswertung der Matrix-Informationen dementsprechend nicht mehr gefunden werden kön- nen.
Definition. Eine verlorene UUT ist eine UUT, welche nach dem Streichen von Tests aus einer TCM oder FCM nicht mehr abgedeckt wird und damit kein Bestandteil eines Suchproblems mehr ist.
3.4. Abgeschlossenheit von Tests
Eine wichtige Problematik, die bei der Fehlersuche im Allgemeinen und bei Evaluationen in diesem Bereich im Besonderen beachtet werden muss, ist die der Abgeschlossenheit von Tests.
Üblicherweise wird davon ausgegangen, dass jeder Test unabhängig von anderen Tests ist und damit auch keine Abhängigkeiten bei der Ausführungsreihenfolge von Tests bestehen. Kon- kret bedeutet es, dass davon ausgegangen werden kann, dass ein fehlschlagender Test auch mindestens eine fehlerhafte Unit ausgeführt hat und das von allen ausgeführten fehlerhaften Units wenigstens eine für das Scheitern des Testes verantwortlich ist.
Diese Annahme wird jedoch von realen Testsuites verle t, da manche Tests von einem all- gemeinen Programmstatus abhängen, den sie nicht direkt beeinflussen. Eine häufig anzutref- fende Situation ist etwa, dass ein Test vom Inhalt eines statischen Feldes abhängt, welches au- ßerhalb des Testes im Rahmen der Vorbereitung einer Testsuite initialisiert wird. Dieser initia- le Wert kann während der statischen Initialisierung zum Beispiel durch eine Methode gese t werden, welche natürlich potentiell einen Fehler enthalten kann. In Abhängigkeit vom ver- wendeten Testframework für die Ausführung der Tests wird die statische Initialisierung für jeden Test einzeln oder nur einmal zu Beginn der Ausführung einer Testsuite durchgeführt.
In le terem Fall wird die fehlerhafte Initialisierungs-Methode dementsprechend auch nur ein einziges Mal und ohne Zusammenhang mit einem bestimmten Test aufgerufen – das beliebte JUnit-Framework ist ein Beispiel für ein derartiges Vorgehen. Nachfolgend ausgeführte Tests
