MASTOR: A Multi-Agent Approach to Semantic Test Oracle Generation for RESTful APIs
MASTOR ist ein Multi-Agenten-Framework, das Quellcode-Analyse und einen Challenger-Agent-Review-Prozess nutzt, um semantische Test-Orakel für RESTful APIs zu generieren, wobei es bestehende Baselines bei der Erkennung von Business-Logik-Verletzungen signifikant übertrifft und eine Mutationsrate von 75,4 % erreicht.
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 stellen ein Inspektionsteam ein, um eine riesige, komplexe Fabrik zu überprüfen, die digitale Produkte (APIs) herstellt. Die Fabrik besitzt hunderte verschiedene Maschinen (Endpoints), die Eingaben entgegennehmen und Produkte ausspucken.
Traditionell prüfen die Inspektoren beim Testen dieser Maschinen nur das Versandetikett. Sie fragen: „Ist die Maschine eingeschaltet? Hat sie einen ‚Erfolg‘-Aufkleber zurückgegeben (HTTP 200)? Hat der Karton die richtige Form?“ Wenn der Aufkleber grün ist und der Karton richtig aussieht, sagt der Inspektor: „Alles bestens!“
Das Problem:
Das Papier argumentiert, dass dies gefährlich ist. Eine Maschine könnte im Inneren defekt sein und das falsche Produkt produzieren, aber dennoch einen perfekten „Erfolg“-Aufkleber auf den Karton kleben und die richtige Form beibehalten. Das Etikett verrät nicht, ob das Produkt im Inneren tatsächlich das ist, was der Kunde bestellt hat. Dies ist ein „semantischer“ Fehler – die Logik ist falsch, auch wenn die Oberfläche perfekt aussieht.
Die Lösung: MASTOR
Die Autoren haben ein neues System namens MASTOR (Multi-Agent Approach to Semantic Test Oracle Generation) entwickelt. Anstatt nur das Versandetikett zu betrachten, schickt MASTOR ein Team spezialisierter Agenten in die Fabrikhalle, die die Baupläne (den Quellcode) liest und genau versteht, wie jede Maschine arbeiten sollte.
So funktioniert MASTOR, unterteilt in einfache Schritte:
1. Der Bauplan-Leser (Quellcode-Analyse)
Bevor der Test beginnt, schickt MASTOR einen Source Extraction Agent in die Fabrik.
- Was er tut: Er betrachtet nicht nur eine einzelne Maschine; er verfolgt jeden Draht, jedes Rohr und jede Anleitung, die mit dieser Maschine verbunden ist (eine „transitive Import-Closure“).
- Das Ergebnis: Er erstellt einen detaillierten „Source Context“ für jede Maschine. Dies ist wie ein Spickzettel, der besagt: „Wenn man eine Zahl kleiner als 2 eingibt, muss die Maschine eine ‚Bad Request‘-Fehlermeldung zurückgeben. Wenn man einen gültigen Namen eingibt, muss sie die spezifische Hauptstadt zurückgeben.“
2. Das Zwei-Spur-Inspektionsteam (Oracle-Generierung)
Sob� nachdem die Spickzettel bereit sind, teilt MASTOR die Arbeit in zwei parallele Teams auf:
- Team A (Single-Operation Path): Diese Agenten betrachten jeweils eine Maschine einzeln. Sie fragen: „Wenn ich dieser Maschine eine fehlerhafte Eingabe gebe, stürzt sie korrekt mit dem richtigen Fehlercode ab? Wenn ich eine gute Eingabe gebe, liefert sie exakt die richtigen Datenfelder zurück?“ Sie nutzen vier verschiedene Strategien (wie das Überprüfen von Grenzwerten und das Umkehren der Logik), um sicherzustellen, dass sie nichts übersehen.
- Team B (Multi-Operation Path): Diese Agenten schauen sich an, wie die Maschinen miteinander kommunizieren. Zum Beispiel: Maschine A erstellt einen Benutzer und vergibt eine ID. Maschine B benötigt diese ID, um das Profil des Benutzers abzurufen. Team B prüft: „Hat Maschine A die ID tatsächlich korrekt gespeichert, damit Maschine B sie später finden kann?“ Dies deckt Fehler auf, die entstehen, wenn Maschinen zusammenarbeiten.
3. Der strenge Editor (Challenger Agent)
Dies ist das Erfolgsgeheimnis. Nachdem die Teams ihre Inspektionsregeln (Oracles) geschrieben haben, übergeben sie diese nicht einfach so.
- Die Überprüfung: Ein dedizierter Challenger Agent (ein strenger Editor) liest jede Regel. Er fragt: „Bist du dir sicher? Hast du wirklich den Bauplan gelesen oder rätst du nur?“
- Die Korrektur: Wenn der Editor eine schwache Regel oder eine Vermutung findet, schickt er sie an das ursprüngliche Team zurück mit der Notiz: „Geh zurück und korrigiere diesen spezifischen Teil.“ Das Team schreibt nur diesen Teil neu. Dies stellt sicher, dass die endgültigen Regeln absolut solide und auf echten Belegen basieren, statt auf Halluzinationen.
4. Der Abschlussbericht (Normalisierung & Ausgabe)
Schließlich bereinigt das System die Regeln, wirft alle weg, die keinen Sinn ergeben, und wandelt sie in drei nützliche Formate um:
- Ausführbarer Code: Bereit, um automatisch in einer CI/CD-Pipeline ausgeführt zu werden (wie ein Roboter, der jede Nacht die Fabrik überprüft).
- Postman-Skripte: Bereit, damit Entwickler manuell testen können.
- Menschenlesbar: Eine Beschreibung in einfachem Englisch, damit ein Mensch lesen und verstehen kann, warum ein Test existiert.
Die Ergebnisse (Die Bestenliste)
Die Autoren testeten das System an 13 realen Fabrikprojekten (mit über 250.000 Zeilen Code und 296 verschiedenen Maschinen).
- Die Punktzahl: MASTOR entdeckte 75,4 % der versteckten Bugs (Mutationen), die in den Code eingebaut wurden.
- Vergleich:
- Im Vergleich zu dem bloßen Einsatz einer intelligenten KI, die basierend auf dem Versandetikett Regeln errät (Direct Prompting), war MASTOR 30 % besser.
- Im Vergleich zu einem Tool, das nur das offizielle Handbuch liest (SATORI), war MASTOR 49 % besser.
- Warum? Weil SATORI und Direct Prompting darauf angewiesen sind, was geschrieben steht oder was geraten wird. MASTOR verlässt sich auf das, was tatsächlich codiert wurde. Wenn das Handbuch sagt: „Gib eine Liste zurück“, aber der Code sagt: „Gib eine Liste nur zurück, wenn der Nutzer ein Admin ist“, dann kennt MASTOR die Wahrheit, weil es den Code gelesen hat.
Die Kosten
Das System ist etwas teurer in der Ausführung als eine einfache Schätzung (es kostet im Durchschnitt etwa 0,56 $ pro API), aber die Autoren argumentieren, dass es den Aufwand wert ist, da es die tiefen, verborgenen Logikfehler findet, die andere Tools übersehen.
Zusammenfassend:
MASTOR ist wie das Einstellen eines Teams von Experten-Detektiven, die nicht nur die Verpackung eines Produkts prüfen, sondern die internen Schaltpläne der Fabrik lesen, um sicherzustellen, dass das Produkt im Inneren exakt das ist, was es sein soll. Sie kontrollieren sich gegenseitig, um sicherzustellen, dass keine Fehler durchrutschen, was zu einem wesentlich höheren Qualitätsnetz für Software führt.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.