💻 computer science

Heterogeneous Prompting and Execution Feedback for SWE Issue Test Generation and Selection

Dieses Paper stellt e-Otter++ vor, einen neuartigen Testgenerator, der die Herausforderung fehlenden oder fehlerhaften Codes bei Software-Engineering-Problemen durch die Nutzung von heterogenem Prompting und Ausführungs-Feedback überwindet, um automatisch Reproduktionstests zu erstellen, wobei eine State-of-the-Art-Fail-to-Pass-Rate von 63 % auf dem TDD-Bench Verified Benchmark erreicht wird.

Ursprüngliche Autoren: Toufique Ahmed, Jatin Ganhotra, Avraham Shinnar, Martin Hirzel

Veröffentlicht 2026-01-26

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Toufique Ahmed, Jatin Ganhotra, Avraham Shinnar, Martin Hirzel

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, unordentlichen Bibliothek (dem Softwarecode) zu lösen. Ein Besucher (der Entwickler) kommt zu Ihnen und sagt: „Mit diesem Buch stimmt etwas nicht, aber ich kann nicht genau erklären, was, und ich habe kein spezifisches Beispiel für den Fehler.“

In der Welt der Software wird dies als SWE-Issue bezeichnet. Normals braucht man, um einen Bug zu beheben, einen „Reproduktionstest“ – ein spezielles Skript, das besagt: „Wenn man X tut, stürzt die Bibliothek ab.“ Dies beweist, dass der Bug existiert. Aber oft existieren diese Skripte noch nicht.

Dieses Paper stellt ein neues Detektiv-Werkzeug namens e-Otter++ vor. Seine Aufgabe ist es, automatisch dieses „Crash-Skript“ (den Test) zu schreiben, indem es nur die unordentliche Beschreibung des Problems liest, noch bevor der eigentliche Fix geschrieben wurde.

Hier ist die Funktionsweise von e-Otter++, erklärt durch einfache Analogien:

1. Das Problem: Der „blinde“ Detektiv

Normalerweise, wenn man eine kluge KI (ein Large Language Model) bittet, einen Test zu schreiben, versucht sie zu raten. Wenn man sie einmal fragt, könnte sie falsch liegen. Wenn man sie 10 Mal mit exakt denselben Anweisungen fragt, liefert sie einem vielleicht einfach 10 leicht unterschiedliche Versionen derselben falschen Vermutung. Es ist, als würde man einen Freund bitten, einen Film zu beschreiben, den er nur einmal gesehen hat; wenn man ihn 10 Mal fragt, wiederholt er vielleicht nur immer wieder denselben Fehler.

2. Der erste Trick: „Heterogeneous Prompting“ (Die Kostümparty)

Um bessere Vermutungen zu erhalten, stellt e-Otter++ der KI nicht einfach 10 Mal dieselbe Frage. Stattdessen ändert es die Art und Weise, wie die Frage gestellt wird, als würde es die KI in verschiedene Kostüme stecken oder ihr unterschiedliche Perspektiven geben.

Die „Masken“: Stellen Sie sich vor, die KI betrachtet ein Puzzle. Manchmal deckt e-Otter++ Teile des Puzzles (den Code-Kontext) ab, sodass die KI basierend auf weniger Informationen raten muss. Ein andermal zeigt es nur spezifische Teile. Dies zwingt die KI, das Problem aus einem anderen Blickwinkel zu betrachten.
Die „Morphs“: Stellen Sie sich vor, der Bugbericht ist in verwirrendem Jargon geschrieben. e-Otter++ bittet die KI, den Bericht in verschiedenen Stilen umzuschreiben:
- Der „Standardisierer“: Verwandelt eine unordentliche Notiz in einen formellen, strukturierten Bericht.
- Der „Vereinfacher“: Entfernt verwirrenden technischen Jargon, um es leicht verständlich zu machen.
- Der „Dropper“ (Entferner): Entfernt spezifische Code-Schnipsel, die irreführend sein könnten (wie der Anweisung an die KI, ein Tool zu verwenden, das die Bibliothek eigentlich gar nicht besitzt).
- Der „Pre-Thinker“ (Vordenker): Bittet die KI, zuerst eine Lösung zu erraten, und dann diese Vermutung zu nutzen, um den Test zu schreiben.

Durch das Mischen dieser „Masken“ und „Morphs“ generiert e-Otter++ einen riesigen, vielfältigen Pool an potenziellen Tests. Es ist, als würde man 10 verschiedene Personen bitten, einen Tatort zu beschreiben, aber jeder gibt ihnen dabei unterschiedliche Hinweise und eine andere Art zu sprechen. Dies erhöht die Chance, dass mindestens einer von ihnen richtig liegt.

3. Der zweite Trick: „Execution Feedback“ (Der Testlauf)

Sobald die KI einen Test generiert hat, vertraut e-Otter++ ihm nicht einfach blind. Es führt den Test auf dem alten Code (der fehlerhaften Version) aus.

Das Ziel: Der Test muss fehlschlagen. Aber er muss aus dem richtigen Grund fehlschlagen.
Das Problem: Manchmal schlägt der Test aufgrund eines banalen Fehlers fehl (wie einem Tippfehler), nicht wegen des eigentlichen Bugs.
Die Lösung: e-Otter++ besitzt einen „Kritiker“ (eine andere KI), der den Fehler analysiert. Wenn der Test aus dem falschen Grund fehlgeschlagen ist, sagt der Kritiker: „Nein, das ist nicht der Bug. Hier ist die spezifische Zeile, die falsch ist, und hier ist zusätzlicher Code, den du dir ansehen musst.“ Dann schreibt das System den Test mit diesen neuen Informationen neu. Es wiederholt diese Schleife so lange, bis der Test exakt so fehlschlägt, wie es die Bugbeschreibung vorgibt.

4. Der dritte Trick: Der „Surrogate“ Patch (Der Dummy-Fix)

Hier ist der schwierigste Teil: Um zu wissen, ob ein Test gut ist, muss er am neuen Code (dem Fix) bestehen. Aber der Fix existiert noch gar nicht! Wie kann man also den besten Test auswählen?

e-Otter++ nutzt einen cleveren Umweg:

Es bittet ein anderes KI-System (genannt Agentless), eine Reihe von vorläufigen Fixes (Surrogate Patches) zu generieren. Diese sind nicht perfekt, aber sie kommen dem Ziel nahe.
Es führt alle Kandidaten-Tests gegen diese vorläufigen Fixes aus.
Wenn ein Test bei dem vorläufigen Fix besteht, ist es wahrscheinlich ein guter Test.
Schließlich wählt es den einen besten Test basierend darauf aus, welcher die wichtigsten Teile des Codes am besten abdeckt.

Die Ergebnisse: Ein großer Sprung nach vorn

Das Paper hat dieses System auf zwei großen Benchmarks getestet (TDD-Bench und SWT-bench).

Bisheriger Bestwert: Die führenden Systeme konnten einen funktionierenden Test etwa 37 % bis 38 % der Zeit generieren.
e-Otter++: Durch den Einsatz dieser neuen Tricks (die Art der Fragestellung ändern und vorläufige Fixes zur Filterung der Antworten nutzen) steigerte e-Otter++ die Erfolgsquote auf 63 % bei einem Benchmark und auf 52,5 % beim anderen.

Warum das wichtig ist

Die Autoren sagen, dass dies in zwei Hauptaspekien hilft:

Für Menschen: Es automatisiert den langweiligen Teil der „Test-Driven Development“ (das Schreiben von Tests vor der Behebung von Bugs), was es Entwicklern erleichtert, Bugs zu bestätigen und zu beheben.
Für KI-Agenten: Viele KI-Coding-Agenten verlassen sich auf diese Tests, um zu wissen, ob sie einen Bug behoben haben. Indem e-Otter++ bessere Tests bereitstellt, hilft es auch anderen KI-Agenten, ihre Aufgaben besser zu erfüllen.

Kurz gesagt: e-Otter++ ist eine intelligentere, kreativere und gründlichere Methode, um eine KI anzuweisen, den „Beweis“ zu schreiben, dass ein Software-Bug existiert und behoben wurde, ohne dass ein Mensch diesen Beweis zuerst schreiben muss.

Technische Zusammenfassung: Heterogenes Prompting und Ausführung-Feedback für die Generierung und Selektion von SWE-Issue-Tests

Problemstellung
Software Engineering (SWE)-Issues, welche Bugs oder fehlende Features beschreiben, sind oft von informellen Beschreibungen begleitet, denen automatisierte Reproduktionstests fehlen. Das Fehlen solcher Tests behindert die Verifizierung von Issues und die Akzeptanz von Code-Patches. Die spezifische Herausforderung, die in dieser Arbeit adressiert wird, ist die automatische Generierung von „Fail-to-Pass“ ( $F \to P$ )-Reproduktionstests direkt aus Issue-Beschreibungen und dem bestehenden (Pre-Patch) Code ( $c_{old}$ ), ohne Zugriff auf den lösungsorientierten Code-Patch ( $c_{new}$ ). Ein gültiger $F \to P$ -Test muss bei der Ausführung auf $c_{old}$ fehlschlagen (das Issue reproduzieren) und bei der Ausführung auf $c_{new}$ bestehen (die Behebung bestätigen). Diese Aufgabe ist schwierig, da Issue-Beschreibungen informell sind und der Zielcode für das Bestehen des Tests noch nicht existiert.

Methodik: e-Otter++
Die Autoren führen e-Otter++ ein, ein System, das das vorangegangene Otter++-Framework erweitert. Das System operiert durch drei primäre Komponenten: einen Testgenerator, einen Code-Patch-Generator und einen Testselektor.

Testgenerierung mittels heterogenem Prompting:
Anstatt sich ausschließlich auf die Erhöhung der Decoding-Temperaturen von LLMs zu verlassen, um diverse Kandidaten zu generieren (eine gängige Praxis, die oft an Diversität mangelt), verwendet e-Otter++ heterogenes Prompting. Dies beinhaltet zwei systematische Variationen:
- Issue-Description-Morphs: Ein LLM schreibt die ursprüngliche Issue-Beschreibung in fünf distinkten Arten um, bevor die Testgenerierung erfolgt: standard (Formatierung), simple (Vereinfachung von Fachjargon), dropCode (Entfernen potenziell irreführender Code-Snippets), initTest (Inkorporation eines initialen Tests) und initPatch (Inkorporation eines initialen Patch-Vorschlags).
- Kontext-Masken: Der Prompt für die Testgenerierung wird modifiziert, indem spezifische Lokalisationskontexte (z. B. Planner-Outputs, Test-Lokalisierung, Patch-Lokalisierung) ein- oder ausgeschlossen werden, was fünf distinkte Prompt-Variationen erzeugt.
  Durch die Kombination dieser Methoden generiert das System einen diversen Pool von 10 Kandidatentests pro Issue.
Ausführungs-augmentierte Test-Reparatur:
Generierte Kandidatentests werden auf $c_{old}$ ausgeführt. Während sie erwartet werden zu fehlschlagen, können sie aus den falschen Gründen fehlschlagen (z. B. Syntaxfehler oder unbezogene Exceptions) anstatt das beschriebene Issue zu reproduzieren. e-Otter++ führt einen Critic-Mechanismus ein:
- Ein LLM analysiert die Issue-Beschreibung und das Ausführungsprotokoll, um zu bestimmen, ob der Test aus dem „richtigen Grund“ fehlschlägt.
- Falls der Fehler unkorrekt ist, identifiziert der Critic den notwendigen Kontext (z. B. spezifische fehlerhafte Zeilen, relevante Code-Snippets oder Funktionssignaturen) und augmentiert den Reparatur-Prompt.
- Das System repariert den Test iterativ (bis zu 10 Versuche) unter Verwendung dieses angereicherten Kontexts, bis der Test aus dem korrekten Grund fehlschlägt oder das Iterationslimit erreicht ist.
Testselektion via Surrogat-Patches:
Da $c_{new}$ nicht verfügbar ist, kann e-Otter++ nicht direkt verifizieren, ob ein Test auf dem wahren Fix besteht. Um dies zu lösen, nutzt das System Agentless, um 40 Kandidaten-Code-Patches (Surrogate für $c_{new}$ ) zu generieren und diese auf die 5 häufigsten zu filtern.
- Der Testselektor führt die Kandidatentests auf diesen Surrogat-Patches aus.
- Tests, die auf den Surrogat-Patches ein $F \to P$ aufweisen, werden priorisiert.
- Ein regelbasierter Selektor klassifiziert Fehler (Assertion-Fehler vs. Errors) und nutzt die Code-Abdeckung (der Anteil der durch den Patch hinzugefügten/entfernten Zeilen, die der Test abdeckt) als Tie-Breaker, um den einzelnen finalen Test auszuwählen.

Wesentliche Beiträge
Das Paper leistet drei neuartige Beiträge:

Ausführungs-augmentierte Test-Reparatur: Eine Methode, um die Testkorrektheit durch die Nutzung von Ausführung-Feedback zur Abfrage von verwandtem Code und zur Augmentierung des Reparatur-Prompts zu erhöhen, wodurch sichergestellt wird, dass Tests aus den in der Issue spezifizierten Gründen fehlschlagen.
Heterogenes Prompting für Diversität: Erhöhung der Diversität der Testkandidaten durch Issue-Beschreibung-Morphs und Kontext-Masken, anstatt sich rein auf High-Temperature-Sampling zu verlassen.
Surrogat-Patch-basierte Selektion: Eine Technik zur Selektion des finalen Tests unter Verwendung von Ausführung-Feedback aus imperfekten, generierten Code-Patches als Proxy für den Ground-Truth-Fix.

Ergebnisse
Das System wurde auf TDD-Bench Verified (449 Samples) und SWT-bench Lite (276 Samples) evaluiert, die beide von SWE-bench abgeleitet sind.

Performance: e-Otter++ erreichte eine State-of-the-Art Fail-to-Pass ( $F \to P$ ) Rate von 63,0 % auf TDD-Bench Verified und 52,5 % auf SWT-bench Lite (unter Verwendung des Claude-3.7-Sonnet Modells). Dies übertrifft die bisherigen besten veröffentlichten Ergebnisse (Otter++ mit 37,0 % bzw. 29,0 %) signifikant.
Effektivität der Komponenten:
- Die ausführungs-augmentierte Reparatur verbesserte die $F \to P$ Raten um 11,1 % auf 74,3 % über verschiedene Konfigurationen hinweg.
- Heterogenes Prompting (Morphs + Masken) steigerte die $F \to P@N$ Rate (Rate von mindestens einem erfolgreichen Test unter $N$ Kandidaten) um über 13 % im Vergleich zur alleinigen Verwendung von Masken.
- Die Verwendung generierter Code-Patches als Pre-Filter für die Testselektion lieferte einen signifikanten Performance-Boost (z. B. eine Steigerung von 32,9 % bei $F \to P$ auf TDD-Bench Verified).
Generalisierbarkeit: Der Ansatz wurde auf SWE-rebench, einem kontaminationsfreien Benchmark, validiert, wo er die $F \to P$ Rate im Vergleich zum Basis-Otter-System relativ um 75 % verbesserte, was die Robustheit gegenüber Datenkontamination demonstriert.
Validierungsnutzen: Es wurde gezeigt, dass die generierten Tests Code-Patches anderer SWE-Agenten effektiv validieren können, was die Präzision der von Top-Leaderboard-Systemen vorgeschlagenen Lösungen signifikant verbessert.

Bedeutung und Ansprüche
Die Autoren behaupten, dass e-Otter++ einen substanziellen Sprung im State-of-the-Art für die Generierung von Reproduktionstests aus SWE-Issues darstellt. Das Paper argumentiert, dass die Kombination aus heterogenem Prompting und Ausführung-Feedback – insbesondere die neuartige Nutzung von Surrogat-Patches für die Selektion und kontext-augmentierter Reparatur – die Limitationen vorangegangener Methoden überwindet, die mit Test-Diversität und dem Mangel an einer Ziel-Codebasis zur Verifizierung zu kämpfen hatten.

Die Arbeit zielt darauf ab, die Praxis der Test-Driven Development (TDD) durch die Automatisierung der mühsamen Erstellung von Reproduktionstests zu festigen, um sowohl menschliche Ingenieure als auch automatisierte SWE-Agenten bei der Problemlösung und langfristigen Qualitätssicherung zu unterstützen. Die Autoren bleiben hinsichtlich des Umfangs bescheiden und merken an, dass das System derzeit einzelne Testdateien handhabt und primtär auf Python evaluiert wird, betonen jedoch, dass die relativen Verbesserungen darauf hindeuten, dass die Techniken selbst auf nicht-kontaminierten, diversen Datensätzen effektiv sind.