💻 computer science

IssueExec: A Test-Driven Approach for Localizing Software Engineering Issues

Dieses Paper schlägt IssueExec vor, einen neuartigen testgetriebenen Ansatz, der domänenerweiterte Testrepräsentationen und hierarchische Trace-Analyse nutzt, um die semantische Lücke zwischen Issue-Beschreibungen und Code zu schließen, wodurch durch eine signifikante Verbesserung der Recall- und Lösungsraten eine Spitzenleistung bei der Lokalisierung von Software-Engineering-Issues erzielt wird.

Ursprüngliche Autoren: Jiawei Liu, Yun Lin, Chenyan Liu, Yu Qian, Yiming Liu, Jiaxin Chang, Weinan Zhang, Linpeng Huang

Veröffentlicht 2026-07-21

📖 6 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Jiawei Liu, Yun Lin, Chenyan Liu, Yu Qian, Yiming Liu, Jiaxin Chang, Weinan Zhang, Linpeng Huang

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie sind ein Detektiv, der versucht, ein Rätsel in einer riesigen, chaotischen Bibliothek zu lösen. Die Bibliothek repräsentiert eine große Software, und das Rätsel ist ein „Bug“ – ein Fehler, der die Software seltsam reagieren lässt. Normalerweise, wenn jemand einen Bug meldet, schreibt er eine Notiz in einfacher Sprache, wie zum Beispiel: „Die Karte lädt nicht, wenn ich hier klicke.“ Ihre Aufgabe ist es, genau die Seite in der Bibliothek zu finden, auf der sich der Fehler versteckt, damit Sie ihn beheben können. Dies nennt man „Issue Localization“.

Lange Zeit versuchten Detektive, dies zu lösen, indem sie die einfache englische Notiz lasen und erraten, welche Seite in der Bibliothek dazu passt. Aber das ist so, als würde man versuchen, ein bestimmtes Buch zu finden, indem man nach dem Wort „Karte“ in einer Bibliothek sucht, in der die Bücher nach „Geografie“, „Kartografie“ und „Navigation“ organisiert sind, und die Notiz nur „Karte“ sagt. Die Wörter passen nicht zusammen, und die Bibliothek ist zu groß, um jedes Regal zu durchsuchen. Das Papier, das Sie gleich lesen werden, schlägt einen brillanten neuen Weg vor, um dieses Problem zu lösen: Anstatt zu raten, nutzen Sie die eigenen „Übungstests“ der Bibliothek. Dies sind wie Probenotizen, die Bibliothekare durchlaufen lassen, um sicherzustellen, dass die Bücher in der richtigen Reihenfolge stehen. Die Autoren schlagen vor, dass diese Skripte als geheime Brücke fungieren, die die unordentliche menschliche Notiz in die präzise Sprache der Bibliotheksregale übersetzt und die Suche nach dem Bug dadurch viel schneller und genauer macht.

Das Problem: Die „Vokabular-Lücke“

Die Autoren dieser Arbeit, ein Team von Forschern aus China und Singapur, haben ein frustrierendes Muster in der Art und Weise bemerkt, wie Computer versuchen, Software-Bugs zu beheben. Wenn ein Mensch sagt: „Das Serverless-Feature funktioniert nicht“, sucht der Computer oft nach dem Code namens „serverless“. Aber in der realen Welt könnte der Code technisch benannt sein, wie etwa _get_db_cluster_kwargs (was nur eine schicke Art ist zu sagen: „die Einstellungen für den Datenbank-Cluster abrufen“).

Es ist, als würde man einen Bibliothekar nach einem „Buch über den Weltraum“ fragen, und er sucht nur nach Büchern, die das Wort „Weltraum“ im Titel tragen, und übersieht dabei die Bücher, die tatsächlich über „Astronomie“ oder „Kosmologie“ handeln. Diese Diskrepanz zwischen dem, was Menschen sagen (Anforderungen), und der Art, wie Programmierer Dinge benennen (Code), erzeugt eine enorme „semantische Lücke“. Bestehende Werkzeuge versuchen, diese Lücke direkt zu überbrücken, stolpern aber oft, was zu langen, teuren Suchen führt, bei denen der Computer falsch rät.

Die neue Idee: Tests als „ausführbare Anforderungen“

Das Papier schlägt einen klugen Umweg vor. Anstatt direkt von der Fehlermeldung zum Code zu springen, schlagen die Autoren vor, über die Tests zu gehen.

Betrachten Sie einen Software-Test als eine Art „Probelauf“ oder eine „Rehearsal“. Ein Programmierer schreibt einen Test, um zu prüfen, ob eine Funktion funktioniert. Entscheidend ist, dass der Name des Tests oft genau wie die Fehlermeldung klingt. Wenn der Bug etwas mit „Serverless“ zu tun hat, könnte der Test zum Beispiel test_create_serverless_db_cluster heißen.

Die Autoren argumentieren, dass Tests der perfekte Vermittler sind, weil sie ausführbare Anforderungen sind. Sie sind in einer menschenlesbaren Sprache geschrieben (wie die Fehlermeldung), sind aber gleichzeitig eng mit dem eigentlichen Code verknüpft (da sie ausgeführt werden müssen und bestehen müssen). Indem man zuerst den richtigen Test findet, erschafft man einen „Zwei-Sprung-Pfad“:

Fehlermeldung $\rightarrow$ Test (Einfacher Match: Beide verwenden Wörter wie „serverless“).
Test $\rightarrow$ Code (Garantierter Match: Der Test führt den Code tatsächlich aus).

Die Theorie: Reduzierung der „Verwirrung“

Bevor sie ihr Werkzeug bauten, führten die Autoren mathematische Berechnungen durch, um zu sehen, ob diese Idee tatsächlich Sinn ergibt. Sie nutzten ein Konzept namens „Entropie“, ein Fachbegriff für das Maß an Verwirrung oder Unsicherheit. Stellen Sie sich vor, Sie suchen eine Nadel im Heuhaufen.

Direkte Suche: Wenn Sie nur basierend auf der Fehlermeldung raten, müssen Sie vielleicht 10.000 Nadeln absuchen. Das ist hohe Verwirrung.
Test-vermittelte Suche: Wenn Sie zuerst die richtige „Box“ (den Test) finden, die die Nadel enthält, müssen Sie vielleicht nur 100 Nadeln absuchen.

Ihre Berechnungen zeigten, dass die Verwendung von Tests als Vermittler die „Verwirrung“ im Durchschnitt um 7,73 Bits reduziert. Auf Deutsch gesagt: Der Suchraum wird signifikant kleiner und fokussierter, was es viel einfacher macht, die richtige Stelle zu finden.

Die Lösung: IssueExec

Um diese Theorie in die Praxis umzusetzen, entwickelte das Team ein Werkzeug namens IssueExec. Es arbeitet in drei Hauptschritten:

Intelligente Test-Abfrage (Smart Test Retrieval): Das Tool betrachtet die Fehlermeldung und versucht, den passenden Test zu finden. Dabei weiß es jedoch, dass Programmierer Abkürzungen und Insider-Witze verwenden. Daher durchsucht es die Historie des Projekts (wie z. B. alte Commit-Nachrichten), um zu lernen, dass „tz“ für „Timezone“ steht oder „ovr“ für „OneVsRestClassifier“. Dies hilft ihm, die Testnamen besser zu verstehen, als es eine Standard-Computersuche könnte.
Trace-Analyse (Trace Analysis): Sob falls es den richtigen Test gefunden hat, hört es nicht einfach auf. Es führt den Test aus und beobachtet genau, welche Codezeilen der Test berührt. Dies erzeugt einen „Trace“ (einen Pfad), wie eine Spur aus Brotkrumen. Allerdings berühren Tests oft zu viel Code, einschließlich langweiliger Infrastruktur-Elemente, die nichts mit dem Bug zu tun haben.
Rauschfilterung (Noise Filtering): Das Tool nutzt eine intelligente KI, um den Pfad der Brotkrumen zu betrachten und den „Rauschen“ (Noise) herauszufiltern. Es fragt sich: „Welche dieser berührten Zeilen haben tatsächlich das Problem verursacht?“ Es ignoriert die langweiligen Teile und hebt die spezifischen Funktionen hervor, die wahrscheinlich die Verursacher sind.

Die Ergebnisse: Ein großer Sieg

Das Team testete IssueExec auf einem berühmten Benchmark namens SWE-bench Lite, der 300 reale Software-Bugs enthält. Die Ergebnisse waren beeindruckend:

Bessere Genauigkeit: IssueExec fand den korrekten Code-Ort (auf Funktionsebene) 41,57 % häufiger als die bisher beste Methode.
Mehr Fehlerbehebungen: Als sie IssueExec in ein automatisiertes System zur Fehlerbehebung (genannt „Agentless“) einspeisten, löste dieses System 17,72 % mehr Bugs als zuvor.
Kosteneffizienz: Obwohl es zusätzliche Arbeit leistet (Tests ausführen und Traces analysieren), sparte es im Vergleich zu anderen komplexen Methoden tatsächlich Geld und kostete pro Bug im Durchschnitt etwa 35 % weniger.

Was es nicht kann (Die Grenzen)

Die Autoren sind ehrlich darüber, wo ihr Werkzeug scheitern könnte.

Fehlende Tests: Wenn ein Softwareprojekt keinen Test besitzt, der den spezifischen fehlerhaften Code abdeckt, kann IssueExec ihn nicht finden. Ihre Studie zeigte, dass bestehende Tests etwa 96,98 % der zu reparierenden Dateien abdecken, aber das hinterlässt immer noch eine kleine Lücke (etwa 33,30 % der spezifischen Funktionen), an der das Tool scheitern könnte.
Tiefe Labyrinthe: Manchmal ist der Code-Pfad so lang und verschlungen (wie ein tiefes unterirdisches Tunnelsystem), dass das Tool in den mittleren Schichten verloren geht und das eigentliche Ziel verpasst.

Warum das wichtig ist

Dieses Papier legt nahe, dass wir Computer nicht unbedingt lehren müssen, besser in der menschlichen Sprache zu raten. Stattdessen sollten wir sie lehren, die Werkzeuge zu nutzen, die Entwickler bereits besitzen: die Tests. Indem wir Tests als Brücke zwischen menschlichen Beschwerden und Computercode nutzen, verwandelt IssueExec eine chaotische Suche in eine geführte Tour. Es deutet darauf an, dass die Zukunft der Behebung von Software-Bugs nicht darin besteht, größere KI-Modelle blind raten zu lassen, sondern in klügerem, schrittweisem Denken unter Verwendung der bereits vorhandenen Beweise.

Technisches Resümee: IssueExec – Ein Test-getriebener Ansatz zur Lokalisierung von Software-Engineering-Problemen

1. Problemstellung

Die automatisierte Softwarewartung stützt sich maßgeblich auf die Problem-Lokalisierung (Issue Localization), also die Aufgabe, spezifische Code-Stellen (Dateien, Module oder Funktionen) zu identifizieren, die modifiziert werden müssen, um ein gemeldetes Problem zu beheben. Bestehende Ansätze folgen überwiegend einem direkten Issue–Code-Alignment-Paradigma, das versucht, Beschreibungen natürlicher Sprache direkt mit Code-Elementen abzugleichen (z. B. via Retrieval oder LLM-Agenten).

Diese Methoden kämpfen jedoch häufig mit einer Abstraktionslücke: Issue-Beschreibungen drücken verhaltensbezogene Erwartungen (Anforderungen) aus, während Code-Identifikatoren technische Implementierungsdetails widerspiegeln. Wie in der Arbeit illustriert, kann ein Issue, das „ServerlessV2-Unterstützung“ anfordert, semantisch nicht mit einer Funktion namens _get_db_cluster_kwargs (Parameter-Extraktion) übereinstimmen, was zu einer schwachen semantischen Ausrichtung und Lokalisierungsfehlern führt. Während die Dokumentation von Anforderungen theoretisch diese Lücke schließen könnte, weicht sie oft von der Implementierung ab. Die Autoren postulieren, dass Test-Suites, die synchron zur Implementierung bleiben müssen, um zu bestehen, ein überlegenes intermediäres Signal darstellen.

2. Methodik: Das IssueExec-Framework

Die Autoren schlagen IssueExec vor, ein test-mediiertes Lokalisierungs-Framework, das Test-Suites als „ausführbare Anforderungen“ behandelt. Das Framework operiert auf einem Zwei-Hop-Pfad: Issue $\rightarrow$ Tests $\rightarrow$ Code. Es besteht aus drei Hauptphasen:

A. Theoretische und empirische Motivation

Bevor sie das Framework detailliert beschreiben, untermauern die Autoren die Durchführbarkeit dieses Ansatzes:

Theoretische Analyse: Unter Verwendung der Hartley-Entropie modellieren die Autoren die Lokalisierungsunsicherheit. Sie zeigen, dass der Zwei-Hop-Pfad (Issue $\rightarrow$ Tests $\rightarrow$ Trace-eingeschränkter Code) die Unsicherheit im Vergleich zum direkten Retrieval um durchschnittlich 7,73 Bits reduziert, primär durch die Komprimierung des Suchraums.
Empirische Studie: Eine Untersuchung von 18 Python-Repositories (929 Issues) zeigt:
- Bestehende Tests decken 96,98 % der Ground-Truth-Dateien und 66,70 % der Ground-Truth-Funktionen ab.
- Der Zwei-Hop-Pfad liefert in 82,4 % der Fälle eine stärkere semantische Konnektivität als das direkte Matching.

B. Kernkomponenten von IssueExec

Um die Herausforderungen der semantischen Lücken und des Ausführungsrauschens zu adressieren, implementiert IssueExec die folgende Pipeline:

Anreicherung des Domänenwissens (Offline-Preprocessing):
- Herausforderung: Generische Embeddings erfassen keine domänenspezifische Terminologie (z. B. „tz“ für Timezone) oder projektspezifische Aliase.
- Lösung: Das System analysiert die historische Commit-Historie, um Domänenwissen ( $D_t$ $D_{t}$ ) für jeden Test zu extrahieren. Dies umfasst:
  - Commit-Nachrichten, die den Test eingeführt haben (liefern kontextbezogene Anforderungen).
  - Co-geänderte Entitäten (Code, der häufig zusammen mit dem Test geändert wurde).
- Ergebnis: Eine angereicherte Test-Repräsentation $repr(t) = [sig(t); doc(t); D_t]$ , welche die Terminologielücke zwischen Issues und Tests schließt.
Relevante Test-Retrieval (Zwei-Phasen-Filterung):
- Lexikalische Filterung: Verwendet BM25, um den Suchraum von tausenden Tests auf eine handhabbare Kandidatenmenge ( $N$ ) zu reduzieren.
- Semantische Selektion: Ein LLM analysiert die angereicherten Repräsentationen, um eine kleine, qualitativ hochwertige Teilmenge von Tests ( $k \ll N$ ) auszuwählen, die am relevantesten für die Intention des Issues sind.
Trace-gestützte Lokalisierung:
- Herausforderung: Ein einzelner Test kann tausende Funktionen ausführen, einschließlich irrelevanter Infrastruktur-Code, was Rauschen erzeugt.
- Lösung: Das System führt die ausgewählten Tests in einer containerisierten Umgebung aus, um dynamische Ausführungstraces zu sammeln. Es konstruiert einen gerichteten Trace-Graphen ( $G_t$ ), der die Aufrufer-Aufgerufenen-Beziehungen darstellt.
- Denoising (Rauschunterdrückung): Ein LLM analysiert den Trace-Graphen zusammen mit der Issue-Beschreibung, um „verdächtige Orte“ zu identifizieren. Es filtert inkidente Infrastruktur heraus und hebt anforderungsorientierten Code hervor, wobei Konfidenzniveaus (kritisch, hoch, mittel) zugewiesen werden.
Verfeinerung und Reranking:
- Der initiale verdächtige Satz wird erweitert, indem struktureller Kontext (Modul-Skelette) für Dateien mit verdächtigen Stellen abgerufen wird.
- Ein finaler LLM-gestützter Reranking-Schritt nutzt den vollständigen Quellcode, um Kandidaten zu priorisieren, indem er über Ursachen, kausale Zusammenhänge und architektonische Angemessenheit schlussfolgert, um die finale Rangliste der Edit-Locations ( $L^*$ ) zu erstellen.

3. Kernbeiträge

Formalisierung von ausführbaren Anforderungen: Die Arbeit formalisiert das Konzept, Test-Suites als ausführbare Proxies für Anforderungen zu nutzen, und zeigt auf, wie die semantische Ausrichtung auf Test-Ebene und die Ausführungs-Verankerung zur Laufzeit gemeinsam die Issue–Code-Lücke schließen.
Das IssueExec-Framework: Ein prozedurales Framework, das domänenwissen-angereicherte Test-Repräsentationen (via Commit-Mining) und hierarchische Trace-Analysen (via dynamischer Ausführungs-Graphen) integriert, um Issues zu lokalisieren.
State-of-the-Art Performance: Empirische Validierung, die signifikante Verbesserungen gegenüber bestehenden Baselines sowohl in der Lokalisierungsgenauigkeit als auch bei der nachgelagerten Issue-Lösung zeigt.

4. Experimentelle Ergebnisse

Das Framework wurde auf SWE-bench Lite (300 Issues aus 11 Python-Repositories) evaluiert.

Lokalisierungsleistung (RQ1):
- IssueExec erreicht 70,07 % File-Level Recall@1 und übertrifft damit die stärkste Baseline (Agentless) um 17,78 %.
- Auf Funktions-Ebene erreicht es 41,07 % Recall@1, eine Verbesserung von 41,57 % gegenüber der stärksten Baseline (MoatlessTools).
- Die Verbesserungen sind konsistent über verschiedene LLM-Backbones (GPT-4o und Claude-3.5-Sonnet) hinweg.
Issue-Lösungsleistung (RQ2):
- Integriert in die Agentless-Pipeline löst IssueExec 17,72 % mehr Issues (37,67 % vs. 32,00 % Lösungsrate).
- Die Autoren führen dies auf die Bereitstellung von hochfokussiertem, funktionsbasiertem Kontext zurück, der die Ablenkung für nachgeschaltete Patch-Generierungs-Modelle reduziert.
Kosteneffizienz (RQ3):
- IssueExec reduziert die durchschnittlichen Kosten pro Issue um etwa 35,47 % im Vergleich zu komplexen agentenbasierten Methoden (z. B. SWE-Agent, OrcaLoca), während es eine überlegene Genauigkeit beibehält.
- Es ist etwas teurer als die prozedurale Baseline Agentless aufgrund des Overheads der Trace-Analyse, aber die Autoren argumentieren, dass dies durch die Leistungssteigerungen gerechtfertigt ist.
Ablationsstudie (RQ4):
- Das Entfernen des testbasierten Zwischenschritts („w/o Tests“) führt zu einem signifikanten Abfall der F1-Scores (z. B. -12,94 % auf Funktions-Ebene), was die Zentralität des test-mediierten Ansatzes bestätigt.
- Das Entfernen der Trace-Analyse oder des Domänenwissens führt ebenfalls zu erheblichen Leistungsverschlechterungen, was die Notwendigkeit sowohl der dynamischen Ausführungs-Verankerung als auch der semantischen Anreicherung validiert.

5. Bedeutung und Limitationen

Bedeutung:
Die Arbeit argumentiert, dass eine präzise, anforderungsbewusste Lokalisierung ein kritischer Enabler für die automatisierte Softwarewartung ist. Durch die Verschiebung vom direkten Issue–Code-Matching hin zu einem test-mediierten Ansatz schließt IssueExec effektiv die Abstraktionslücke und reduziert die Entropie des Suchraums. Die Ergebnisse legen nahe, dass die Nutzung bestehender Test-Suites als ausführbare Anforderungen einen robusten, kosteneffizienten Pfad für die automatisierte Problemlösung bietet, insbesondere für komplexe, Multi-File-Issues.

Limitationen und Fehlermodi:
Die Autoren räumen zwei primäre Fehlermodi explizit ein:

Fehlende Testabdeckung: Wenn die bestehenden Tests eines Repositories den fehlerhaften Code nicht ausführen (33,30 % der Ground-Truth-Funktionen fallen in der Studie außerhalb der vollen Testabdeckung), kann die Trace-gestützte Lokalisierung das Ziel nicht erreichen. Dies ist eine strukturelle Limitation der Abhängigkeit von präexistierenden Tests.
Lange Aufrufketten: In Projekten mit tiefen Ausführungspipelines (z. B. Build-Systeme) kann der Ground-Truth-Ort unter hochfrequenten Orchestrierungsknoten verborgen sein. Der Trace-Graph kann von diesen Infrastrukturschichten dominiert werden, was die spezifische Fix-Stelle verschleiert, obwohl der Ort technisch abgedeckt ist.

Die Autoren schlagen vor, zukünftige Arbeiten mit Issue-to-Test-Generierungstechniken zu kombinieren, um bug-auslösende Tests für Fälle mit unzureichender Abdeckung zu synthetisieren, um die Anwendbarkeit des Paradigmas zu erweitern.