Wie KI-Agenten UI-Testautomatisierung neu definieren

Das Testen grafischer Benutzeroberflächen (GUIs) ist oft ein Engpass in der Softwareentwicklung. Sie sind in der Regel manuell, zeitaufwändig und spröde. Deshalb ist die Automatisierung von UI-Tests ein so wichtiger Faktor für die Optimierung der Softwareentwicklungskosten bei gleichzeitiger Aufrechterhaltung eines hohen Qualitätssicherungsniveaus.

Bis vor kurzem war es im Grunde unmöglich, die Interaktion zwischen dem Benutzer und der zu testenden Anwendung (AUT) direkt zu simulieren, ohne sich in die AUT selbst (Desktop- oder mobile Anwendungen) oder den Browser, auf dem sie läuft (Webanwendungen), zu hacken, um Benutzeraktionen zu simulieren und/oder den Zustand der AUT abzurufen, um zu überprüfen, ob er dem erwarteten Zustand entspricht. Dabei spielt es keine Rolle, ob das Testautomatisierungswerkzeug (Framework) kodierungsbasiert oder low-code/no-code ist - hinter den Kulissen findet immer eine Low-Level-Kommunikation zwischen dem Werkzeug/Framework und der AUT/dem Browser mit Anweisungen für Aktionen oder Zustandsabfragen statt. Die Hauptursache für die Verwendung eines solchen Ansatzes war der Mangel an Computersprache und Bildverarbeitungsfähigkeiten, die ausreichen, um zu erkennen, was getan werden muss, mit welchen UI-Elementen interagiert werden muss und ob der aktuelle AUT-Zustand dem erwarteten Zustand entspricht - alles nur auf der Grundlage dessen, was auf dem Computerbildschirm geschieht, so wie es ein menschlicher Tester manuell tun würde. Einige Frameworks, wie z. B. Sikuli, versuchten, eine visuelle Erkennung zu verwenden, aber dies erwies sich als instabil und anfällig für Änderungen der Bildschirmauflösung und/oder Elementtransformationen.

Die jüngsten Fortschritte im Bereich der KI haben jedoch die oben genannten Einschränkungen überwunden und es möglich gemacht, dass KI auf der Grundlage von Anweisungen in einfacher menschlicher Sprache korrekt erkennen kann, was zu tun ist, die Benutzeroberfläche ähnlich wie ein Mensch wahrnimmt und die Ergebnisse visuell überprüft.

Um diese Annahme auf die Probe zu stellen, habe ich einen UI-Testautomatisierungsagenten entwickelt und als Open Source zur Verfügung gestellt. Dabei handelt es sich um einen Java-basierten Prototyp, der multimodale KI-Modelle und Retrieval-Augmented Generation (RAG) verwendet, um ein neues Maß an Intelligenz und Flexibilität für automatisierte UI-Tests zu erreichen. Der Agent selbst ist so konzipiert, dass er automatisierte Testfälle ausführt, die in natürlicher Sprache beschrieben sind (keine Codierung erforderlich). Dabei werden sowohl Aktionen (wie Klicks und Tastatur-Eingaben) als auch Verifizierungen (Überprüfung, ob der Zustand der AUT auf der UI-Ebene mit dem erwarteten Zustand übereinstimmt) verarbeitet.

Wenn Sie tiefer in die Implementierungsdetails eintauchen möchten, sind die folgenden Links hilfreich:

• GitHub-Seite
• GitHub Repo

Architektonische Komponenten: Fusion von AI, Vision und RAG

Im Folgenden finden Sie eine Aufschlüsselung der wichtigsten Komponenten des Agenten:

• KI-Modell-Integration: Im Kern verwendet der Agent die LangChain4j-Bibliothek, um sich mit KI-Modellen zu verbinden. Diese werden verwendet, um zu erkennen, welches Tool für die Ausführung einer Aktion verwendet werden muss (ggf. unter Verwendung von Testdaten), mit welchen UI-Elementen interagiert werden muss und um zu entscheiden, ob der aktuelle AUT-Zustand dem erwarteten entspricht.
• Retrieval-Augmented Generation (RAG): Um Assoziationen zwischen der textuellen Beschreibung eines UI-Elements (einschließlich kontextueller Informationen) und seinem visuellen Erscheinungsbild zu erhalten, ähnlich wie es Menschen tun, verwendet der Agent RAG. Details über UI-Elemente (Name, Beschreibung des Elements und der umgebenden Elemente sowie ein Screenshot) werden in einer Vektordatenbank (derzeit Chroma DB) gespeichert. Wenn ein Testschritt die Interaktion mit einem Element beinhaltet (z.B. "Klicken Sie auf die Schaltfläche 'Absenden'"), ruft das RAG-System die relevantesten bekannten UI-Elemente auf der Grundlage der semantischen Ähnlichkeit mit der Aktionsbeschreibung ab.
• Computer Vision: Dies ist eine entscheidende Komponente. Der Agent nutzt die OpenCV-Bibliothek für den visuellen Vorlagenabgleich, indem er den Screenshot des gespeicherten UI-Elements und ein KI-Modell verwendet, um die Beste unter den potenziellen Übereinstimmungen auf dem Bildschirm zu ermitteln.
• GUI-Interaktionswerkzeuge: Die Standardfunktionen der Java-Roboterklasse sind in spezielle Werkzeuge für Mausaktionen (Klicken, Hovern, Ziehen usw.) und Tastaturaktionen (Tippen, Tastendrücken usw.) verpackt. Allgemeine Werkzeuge, wie z. B. das Warten auf eine bestimmte Dauer, sind ebenfalls enthalten.

Ausführungsmodi

Der Agent versucht, bei der Ausführung von Testfällen einen Menschen zu imitieren. Um falsch negative Ergebnisse zu vermeiden, wurde der zentrale Ausführungsworkflow so konzipiert, dass ein menschlicher Bediener als Quelle der Grundwahrheit für die Ausführung von Testfallaktionen verwendet wird. Wenn eine Aktion die Interaktion mit einem UI-Element erfordert, kann der Agent auf diese Weise alle notwendigen Informationen über das Element (einschließlich des Screenshots) vom menschlichen Bediener erhalten, wenn er diesem Element zum ersten Mal begegnet. Wenn das Element dem Agenten bereits bekannt ist, aber auf der Benutzeroberfläche nicht mit einem klassischen Mustervergleichsalgorithmus gefunden wird (mehr dazu später), oder wenn der Screenshot des Elements nicht mit seiner Beschreibung übereinstimmt, kann der menschliche Bediener diese Informationen aktualisieren oder das Element aus dem Speicher des Agenten (d. h. der Vektor-DB) löschen und einen neuen Eintrag mit aktuellen Informationen (einschließlich Screenshot) erstellen. Nach einem solchen geführten Lauf kann der Agent die Aktion mit demselben Element reproduzieren, ohne dass er menschliche Hilfe benötigt.

Überprüfungen werden vom Agenten durchgeführt, ohne dass menschliches Feedback oder Hilfe erforderlich ist. Denn anders als bei der Lokalisierung eines bestimmten Oberflächenelements während der Ausführung einer Aktion umfassen Überprüfungen viel komplexere Vergleiche zwischen dem tatsächlichen und dem erwarteten Zustand. Diese Vergleiche lassen sich nicht ohne Weiteres auf einen einzigen vom Menschen bestätigten Screenshot oder eine textliche Beschreibung des tatsächlichen Zustands abbilden (jede gültige Änderung der Benutzeroberfläche würde eine solche Überprüfung wahrscheinlich zunichte machen). Da dieser Teil ein höheres Risiko für falsch-negative Ergebnisse birgt, wäre eine mögliche Verbesserung die Verwendung eines "Quorums" verschiedener Modelle, um die endgültige Entscheidung zu treffen. Dieser Ansatz ist jedoch noch nicht umgesetzt worden.

Um die oben beschriebene Logik umzusetzen, arbeitet der Agent in zwei verschiedenen Ausführungsmodi:

• Betreuter ("Praktikant") Modus: In diesem Modus fungiert der Agent als virtueller "Auszubildender", der versucht, alle erforderlichen Informationen vom "Mentor" (menschlicher Bediener) abzurufen, um erforderliche Elemente der Benutzeroberfläche zu finden oder vorhandene Informationen zu klären, wenn das Auffinden von Elementen fehlschlägt (z. B. aufgrund gültiger Änderungen der Benutzeroberfläche, einer veralteten Ausführungssequenz oder Logik oder eines tatsächlichen Fehlers). Dieses kollaborative "Training" baut die Wissensbasis auf, die für zukünftige unbeaufsichtigte Läufe benötigt wird.
• Unbeaufsichtigter Modus: Sobald der Agent die erforderliche Wissensbasis erworben hat, kann er den entsprechenden Testfall ohne menschliches Eingreifen ausführen. Er verlässt sich dabei vollständig auf die in seiner RAG-Datenbank und seinen KI-Modellen gespeicherten Informationen. Jeder Fehler oder jede Störung während der Ausführung (z. B. bei dem Auffinden von UI-Elementen, der Werkzeugauswahl, der Verifizierung usw.) unterbricht die Ausführung des Testfalls. Dieser Modus ist ideal für die CI/CD-Integration.

Der beaufsichtigte Modus bietet eine praktische Möglichkeit, das UI-Wissen des Agenten inkrementell aufzubauen und zu aktualisieren, während der unbeaufsichtigte Modus die für Regressionstests erforderliche vollautomatische Ausführung ermöglicht. Der RAG-Workflow wurde speziell für die dynamische Verwaltung von UI-Element-Informationen gewählt, wodurch die Tests im Vergleich zu traditionellen Selektor-basierten Ansätzen weniger anfällig für kleinere UI-Änderungen sind. Die Verwendung separater KI-Modelle für die Ausführung von Testschritt-Anweisungen und Vision-basierten Aktivitäten ermöglicht die Nutzung des besten Modells für jede spezielle Aufgabe.

Der Ausführungsworkflow: Schritt-für-Schritt-Automatisierung

Der Agent beginnt mit dem Laden eines im JSON-Format bereitgestellten Testfalls (entweder in einer Datei oder als Payload einer Anfrage), um alle Testschritte abzurufen, die jeweils eine natürlichsprachliche Beschreibung, optionale Testdaten und erwartete Ergebnisse enthalten.

Bei jedem Testschritt führt der Agent zunächst eine Aktion aus:

1. Macht ein Bildschirmfoto von AUT.
2. Sendet die Aktionsbeschreibung aus dem Testschritt, das Bildschirmfoto und die Testdaten (falls vorhanden) als Teil des Prompts an das KI-Modell. Dieses bestimmt das zu verwendende Werkzeug (z. B. Element anklicken, Text eingeben usw.) und seine Argumente (z. B. Beschreibung des Ziel-UI-Elements, einzugebender Text, Anzahl von Pixeln zum Bewegen der Maus usw.).
3. Führt das vom Modell gewählte Werkzeug aus (z. B. einen Klick).
4. Findet das UI-Element (falls erforderlich) und führt damit die Aktion aus. Dies ist ein wichtiger Teil des Arbeitsablaufs:

• a. Zunächst wird die Vektor-DB anhand der Beschreibung des Ziel-UI-Elements abgefragt, um die besten semantischen Übereinstimmungen zu finden.
• b. Wenn Übereinstimmungen mit hoher Konfidenz gefunden werden:

  • Die OpenCV-Bibliothek wird eingesetzt, um die besten visuellen Übereinstimmungen auf dem Bildschirm zu finden (unter Verwendung der Screenshots der potenziell passenden UI-Elemente).
  • Das Vision-Modell ermittelt, ob eine dieser visuellen Übereinstimmungen mit der Beschreibung des Ziel-UI-Elements übereinstimmt (einschließlich Informationen über umliegende Elemente, die so genannten "Anker").
  • Wenn es mehrere gültige Übereinstimmungen gibt (z. B. mehrere Kontrollkästchen mit identischem Aussehen), disambiguiert das Modell diese und identifiziert die beste Übereinstimmung anhand des Kontexts.
  • Wenn nach diesem Vorgang keine passende Übereinstimmung gefunden wird, hängt das Verhalten vom Ausführungsmodus ab (siehe oben).
• c. Wenn keine Übereinstimmungen mit hoher Wahrscheinlichkeit gefunden werden, aber Übereinstimmungen mit geringer Wahrscheinlichkeit vorhanden sind, wird der Benutzer aufgefordert (im bedienten Modus), die Informationen über das Ziel-UI-Element zu klären, woraufhin die Suche erneut durchgeführt wird.

5. Der Agent wiederholt die Aktion innerhalb einer konfigurierten Timeout-Periode, wenn ein behebbarer Fehler auftritt (z. B. wenn die oben beschriebene Suche nach UI-Elementen fehlschlägt).

Dann führt der Agent die Überprüfung durch:

1. Macht ein Bildschirmfoto von AUT.
2. Sendet die Beschreibung der erwarteten Ergebnisse und den Screenshot als Teil des Prompts an das Bildverarbeitungs-KI-Modell, um zu entscheiden, ob der tatsächliche Zustand der AUT auf der Benutzeroberflächenebene mit dem erwarteten Zustand übereinstimmt.
3. Das Modell meldet "bestanden" oder "nicht bestanden" zusammen mit einer Begründung.
4. Wiederholt die Überprüfung, wenn sie zunächst fehlschlägt, und berücksichtigt dabei eine mögliche Latenzzeit der Benutzeroberfläche.

Die Testdurchführung ist abgeschlossen, wenn alle Testschritte erfolgreich durchgeführt wurden. Tritt ein Fehler oder eine fehlgeschlagene Überprüfung auf, wird die Ausführung angehalten.

Blick in die Zukunft

Dieser KI-Agent ist derzeit ein Prototyp, ein Proof-of-Concept, der das Potenzial der Kombination von generativer KI, RAG und Computer Vision für die UI-Testautomatisierung demonstriert. Das Potenzial für Erweiterungen ist enorm, einschließlich, aber nicht beschränkt auf:

• Generierung von Ausführungsergebnissen, die sich für die Aggregation und Berichterstattung eignen.
• Verbesserung der Fähigkeiten im Servermodus.
• Einführung der Unterstützung von A2A- und MCP-Protokollen.
• Implementierung einer anspruchsvolleren Elementhandhabung, z. B. im Umgang mit datenabhängigen UI-Elementen (Data-Driven Testing).
• Verwendung eines "Quorum"-Modells für Überprüfungen (wie bereits erwähnt).
• Verwendung von RAG, um aggregierte Testschrittaktionen (auf Logikebene) zu speichern, die auf Sequenzen von expliziten Aktionen (auf Aktionsebene) abgebildet sind. Dies würde die Notwendigkeit beseitigen, gemeinsame Einrichtungsaktionen (wie z.B. das Einloggen) in Testvorbedingungen zu duplizieren, was die Verwendung eines einzigen Schrittes auf Logikebene ermöglichen würde (z.B. "Benutzer meldet sich erfolgreich bei der Anwendung mit den Standard-Anmeldedaten an").

Dieses Projekt befindet sich zwar noch in der Entwicklung, bietet jedoch einen faszinierenden Einblick in eine Zukunft, in der die Automatisierung von UI-Tests intuitiver, belastbarer und intelligenter ist.