🤖 machine learning

Autonomous QA Agent: A Retrieval-Augmented Framework for Reliable Selenium Script Generation

Das Papier stellt den Autonomous QA Agent vor, ein Retrieval-Augmented Generation-Framework, das die Genauigkeit von Selenium-Skripten erheblich verbessert, indem es die Codegenerierung auf projektspezifische Dokumentation und tatsächliche HTML-Strukturen stützt und eine Ausführungserfolgsrate von 90 % im Vergleich zu 30 % bei Standard-LLMs erzielt.

Ursprüngliche Autoren: Dudekula Kasim Vali

Veröffentlicht 2026-05-05

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Dudekula Kasim Vali

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 versuchen, einem sehr intelligenten, aber etwas ungeschickten Roboter beizubringen, wie er ein bestimmtes Haus navigiert, um eine Aufgabe zu erfüllen, wie zum Beispiel „eine Tasse Kaffee zubereiten".

Das Problem: Der ungeschickte Roboter
In der Welt des Softwaretestens ist dieser Roboter eine Künstliche Intelligenz (KI), ein sogenanntes Large Language Model (LLM). Wenn Sie eine Standard-KI bitten, ein Skript zu schreiben, um „den Kaufen-Button auf einer Website zu klicken", wird sie ihr Bestes geben. Da sie jedoch die spezifische Website, von der Sie sprechen, noch nie gesehen hat, muss sie raten.

Sie könnte raten, dass der Button #submit-button heißt. Doch auf Ihrer tatsächlichen Website heißt der Button #btn-pay-now. Die KI „halluziniert" – sie erfindet Details, die richtig klingen, aber völlig falsch sind. In dem Papier ist dies vergleichbar mit einem Roboter, der versucht, eine Tür mit einem selbst erfundenen Schlüssel zu öffnen, anstatt mit dem Schlüssel, der tatsächlich ins Schloss passt. Wenn der Roboter versucht, seinen falschen Schlüssel zu verwenden, stürzt das Skript ab und der Test schlägt fehl.

Die Lösung: Der „Autonome QA-Agent"
Die Autoren dieses Papiers haben ein intelligenteres System entwickelt, das Autonome QA-Agent genannt wird. Stellen Sie sich diesen Agenten als einen Roboter vor, der nicht nur rät; er geht zuerst in die Bibliothek, um die Baupläne zu lesen und das tatsächliche Haus zu betrachten, bevor er mit der Arbeit beginnt.

So funktioniert es, anhand einer einfachen Analogie:

Die Bibliothek (Die Wissensbasis): Bevor der Roboter etwas tut, nimmt das System zwei Dinge und legt sie in eine digitale Bibliothek ab:
- Die Anweisungen: Die schriftlichen Anforderungen (wie ein Rezept oder eine Benutzeranleitung).
- Die Baupläne: Die tatsächliche Code-Struktur der Website (das HTML), die genau zeigt, wo sich jeder Button und jedes Feld befindet.
Die Suche (Retrieval): Wenn Sie den Roboter bitten, „den Checkout-Prozess zu testen", rät er nicht einfach. Er durchsucht sofort seine Bibliothek. Er findet die spezifische Seite über „Checkout" und holt sich die exakten Baupläne für diese Seite. Er sieht: „Ah, der Button 'Zahlen' hat die ID btn_pay, nicht submit."
Das Schreiben (Generation): Nun schreibt der Roboter das Skript unter Verwendung der echten Informationen, die er gerade gefunden hat. Er rät nicht mehr; er folgt der Karte.

Die Ergebnisse: Ein Rennen zwischen zwei Robotern
Die Forscher testeten dieses neue System gegen einen Standard-KI-Roboter mit 20 verschiedenen Einkaufsszenarien (wie das Hinzufügen von Artikeln zum Warenkorb oder das Bezahlen).

Der Standard-Roboter (Ohne Bibliothek): Er bekam die Skript-Syntax richtig (die Grammatik war gut), scheiterte aber in 70 % der Fälle daran, die Buttons zu finden, weil er riet. Er bestand nur 30 % der Tests.
Der Autonome Agent (Mit Bibliothek): Da er die echten Button-Namen nachschlug, bestand er 90 % der Tests. Er bekam die Grammatik zu 100 % richtig.

Warum dies wichtig ist
Das Papier argumentiert, dass das größte Problem beim automatisierten Testen nicht darin besteht, dass KI keinen Code schreiben kann; es besteht darin, dass die KI die spezifische „Adresse" der Dinge nicht kennt, auf die sie klicken muss. Indem sie der KI ein „Retrieval-Augmented"-System gaben (eine Möglichkeit, Fakten nachzuschlagen, bevor sie spricht), verhinderten sie, dass der Roboter falsche Adressen erfindet.

Was das Papier NICHT behauptet
Es ist wichtig zu beachten, was dieses Papier nicht sagt:

Es wird nicht behauptet, dass dies für jeden Softwaretyp (wie Banken- oder Gesundheits-Apps) funktioniert; sie testeten es nur an einem gefälschten Online-Shop.
Es wird nicht gesagt, dass sich der Roboter selbst reparieren kann, wenn sich die Website morgen ändert (obwohl sie dies als zukünftige Idee erwähnen).
Es wird nicht behauptet, dass es besser ist als teure kommerzielle Tools, die von Menschen manuell eingerichtet werden müssen; sie verglichen es nur mit einer „rohen" KI ohne Bibliothek.

Zusammenfassung
Das Papier stellt ein Werkzeug vor, das verhindert, dass KI beim Testen von Websites rät. Indem die KI gezwungen wird, vor dem Schreiben von Code die tatsächlichen „Baupläne" (HTML) und „Anweisungen" (Dokumente) der Website zu lesen, erstellt das System zuverlässige Tests, die tatsächlich funktionieren, und verwandelt einen ungeschickten Rater in einen präzisen Arbeiter.

Technische Zusammenfassung: Autonomer QA-Agent

Problemdefinition

Die Arbeit adressiert den kritischen Engpass in der modernen Softwareentwicklung, bei dem das Quality Assurance (QA) hinter schnellen Agile- und DevOps-Zyklen zurückbleibt. Eine Hauptherausforderung ist die „semantische Lücke" zwischen menschenlesbaren Anforderungen (natürliche Sprache, Mockups) und maschinell ausführbarem Testcode (Selenium-Skripte). Während Large Language Models (LLMs) Code generieren können, leiden sie unter einem Problem des „blinden Coders": Ohne Wissen über die spezifische zu testende Anwendung (AUT) halluzinieren sie häufig nicht existierende UI-Elemente (z. B. eine ID wie #submit erraten, während die tatsächliche ID #btn-confirm lautet). Dies führt zu hohen Ausfallraten bei der Skriptausführung. Bestehende Ansätze wie modellbasiertes Testen (MBT) sind zu komplex zu warten, während die Standard-LLM-Generierung die notwendige Verankerung in spezifischen Anwendungskontexten vermissen lässt.

Methodik

Die Autoren schlagen den Autonomen QA-Agenten vor, ein Retrieval-Augmented Generation (RAG)-Framework, das die Generierung von Testskripten sowohl in funktionalen Anforderungen als auch in der tatsächlichen strukturellen Realität der Anwendung verankert.

Systemarchitektur

Das System ist eine modulare, auf Microservices basierende Architektur, die aus fünf Schichten besteht:

Frontend: Eine Streamlit-Schnittstelle zum Hochladen von Dokumenten und Generieren von Tests.
API: Eine FastAPI-Schicht, die die Orchestrierung und RESTful-Endpunkte handhabt.
Service: Kapselt die Geschäftslogik, einschließlich Dokumentenparsen und der RAG-Pipeline.
Datenebene: Nutzt ChromaDB als Vektordatenbank zur Speicherung hochdimensionaler Embeddings.
Modellebene: Integriert Llama 3.1-8b-instant über die Groq-API für Inferenz mit geringer Latenz.

RAG-Pipeline und Ingestion

Die Kerninnovation ist eine multimodale Ingestion-Pipeline, die verarbeitet:

Textuelle Anforderungen: PRDs und Spezifikationen in Markdown, PDF und JSON.
Struktureller Kontext: Roh-HTML-Dateien, die das DOM der AUT repräsentieren.

Die Vorverarbeitungsstrategie umfasst einen Recursive Character Text Splitter (1000-Zeichen-Blöcke, 200-Zeichen-Überlappung) für Text. Für HTML werden Skripte und Styles entfernt; es werden nur strukturelle Tags (div, input, button) und Attribute (id, class, name) beibehalten, die für Selenium-Selektoren essenziell sind.

Generierungsprozess

Die Pipeline folgt einer strengen mathematischen Formulierung:

Embedding: Text- und HTML-Blöcke werden mithilfe von all-MiniLM-L6-v2 in einen 384-dimensionalen Vektorraum abgebildet.
Retrieval: Für eine Benutzerabfrage (z. B. „Checkout-Flow testen") ruft das System die Top- $k$ (typischerweise $k=3$ ) Blöcke mit der höchsten Kosinus-Ähnlichkeit ab. Entscheidend ist, dass es sowohl Dokumentations- als auch HTML-Blöcke filtert und zusammenführt.
Kontextfusion & Prompting: Das System konstruiert einen Prompt, der die abgerufenen Dokumentationen ([DOCUMENTATION]) explizit von der HTML-Struktur ([HTML STRUCTURE]) trennt.
Einschränkungen: Der Prompt erzwingt Einschränkungen wie „Verwende NUR IDs aus dem bereitgestellten HTML" und „Füge WebDriverWait für dynamische Elemente hinzu".
Generierung: Das LLM generiert ein Python-Selenium-Skript basierend auf diesem verankerten Kontext.

Hauptbeiträge

Neuartige RAG-Architektur für QA: Ein spezialisiertes System, das zwei verschiedene Kontexttypen abruft: textuelle funktionale Anforderungen und strukturellen HTML/DOM-Kontext, im Gegensatz zu generischen RAG-Systemen, die sich nur auf Code oder Text konzentrieren.
Multimodale Ingestion-Pipeline: Eine robuste Pipeline, die diverse Formate (Markdown, PDF, JSON, HTML) verarbeiten kann, um eine umfassende Wissensbasis aufzubauen.
Kontextbewusste Skriptgenerierung: Eine demonstrierte Methode zur Generierung von Selenium-Skripten, die in tatsächlichen HTML-Strukturen verankert sind und Fehler bei der Elementlokalisierung erheblich reduzieren.
Reproduzierbare Evaluierung: Ein detailliertes experimentelles Setup mit statistischer Analyse an 20 Testszenarien, das einen Benchmark für KI-gestütztes Testen liefert.

Experimentelle Ergebnisse

Das System wurde an einer benutzerdefinierten E-Commerce-Anwendung mit 127 DOM-Elementen über vier Seiten hinweg evaluiert. Die Evaluierung verglich den Autonomen QA-Agenten (RAG) mit einem Standard-LLM-Baseline (Llama 3.1-8b ohne Kontext).

Schlüsselkennzahlen (Mittelwert über 3 Durchläufe):

Syntaxvalidität: RAG erreichte 100% (vs. 95% für Baseline).
Elementauflösung: RAG erreichte 95% (vs. 40% für Baseline). Diese Kennzahl misst die Genauigkeit der Selektoren beim Auffinden von Ziel-DOM-Elementen.
Ausführungserfolg: RAG erreichte 90% (vs. 30% für Baseline). Dies misst Skripte, die ohne Ausnahmen von Anfang bis Ende ausgeführt werden.

Statistische Signifikanz:
Zweistichproben-t-Tests bestätigten, dass die Verbesserungen statistisch signifikant sind ( $p < 0.001$ ) mit großen Effektstärken (Cohens $d = 3.2$ für Auflösung, $d = 3.8$ für Ausführung).

Ablationsstudie:

Nur-Text-RAG: 60% Auflösung.
Nur-HTML-RAG: 85% Auflösung.
Voll-RAG (Text + HTML): 95% Auflösung.
Dies bestätigt, dass das strukturelle Verständnis des DOM für die UI-Automatisierung zwingend erforderlich ist, da semantische Anforderungen allein nicht ausreichen.

Fehleranalyse:
Die 10%ige Ausfallrate beim RAG-Agenten wurde folgenden Faktoren zugeschrieben:

Timing dynamischer Elemente: Elemente, die erst nach JavaScript-Animationen erscheinen, die in statischen HTML-Schnappschüssen nicht erfasst sind.
Mehrdeutiger Kontext: Unzureichender disambiguierender Kontext, wenn mehrere ähnliche Elemente existierten.

Bedeutung und Behauptungen

Die Arbeit behauptet, dass das Halluzinationsproblem bei der LLM-basierten Codegenerierung durch eine domänenspezifische RAG-Architektur effektiv gemildert werden kann. Indem die AUT als eine zu ingestierende Wissensquelle und nicht als Blackbox behandelt wird, ermöglicht das System LLMs, als kompetente QA-Ingenieure zu agieren.

Die Autoren schätzen eine Reduktion der Skriptschreibzeit für QA-Ingenieure um 60–70% durch die Automatisierung der Selektoridentifikation und der Generierung von Boilerplate-Code. Sie argumentieren, dass zwar das Standard-LLM schneller ist (4 s vs. 13,2 s End-to-End-Latenz), der RAG-Ansatz jedoch kosteneffektiver ist, wenn man die manuelle Debugging-Zeit berücksichtigt, die für die 70%ige Ausfallrate der Baseline erforderlich ist.

Die Arbeit positioniert sich als Grundlage für „selbstschreibende, selbstheilende" Test-Suiten, wobei die Autoren jedoch bescheiden Einschränkungen bezüglich der statischen HTML-Ingestion (herausfordernd für Single-Page-Anwendungen) und die Notwendigkeit weiterer Validierung über E-Commerce hinaus in diversen Domänen anerkennen.