Entwicklung mit KI-Agenten (ADLC): wo GUI Test Studio seinen Platz hat

Was der agentische Entwicklungslebenszyklus (ADLC) ist

Jahrzehntelang wurde Software entlang des Lebenszyklus der Softwareentwicklung gebaut, des SDLC: Ein Team plant, ein Entwickler codiert, ein Tester testet, jemand behebt, jemand liefert aus, und der Zyklus beginnt von vorn.KI-Programmieragenten haben diesen Zyklus nicht ersetzt.Sie haben seinen inneren Kreislauf übernommen.

In einem agentischen Entwicklungslebenszyklus, dem ADLC, liest ein Agent wie Claude Code, Codex, Claude Desktop oder Copilot im Agentenmodus die Aufgabe, plant die Änderung, schreibt den Code, führt die Tests aus, die er ausführen kann, behebt, was fehlschlägt, und öffnet einen Pull-Request, oft mehrmals pro Stunde.Menschen setzen das Ziel, prüfen, was herauskommt, und entscheiden, was ausgeliefert wird.Der Kreislauf dreht sich viel schneller als früher, und die Qualität dessen, was ausgeliefert wird, hängt von der Qualität dessen ab, was der Agent selbst prüfen kann.

Agenten sind gut in den Prüfungen, die im Code leben: Unit-Tests, Typprüfungen, Linter.Blind sind sie für das Eine, was ein Nutzer sieht: die laufende Anwendung, auf einem echten Bildschirm, über ihre echte Oberfläche.Genau dort haben End-to-End-Tests ihren Platz, und genau dort haben die meisten Agentenkreisläufe noch eine Lücke.

Wo End-to-End-Tests ihren Platz haben

Ein End-to-End-Test bedient die Anwendung so, wie ein Nutzer es tut: Er öffnet sie, klickt und tippt sich durch einen ganzen Ablauf und prüft, was der Bildschirm zeigt.Für einen Agenten ist er die Grundwahrheit, die der Code nicht liefern kann: Hat die Schaltfläche die Neugestaltung überstanden, lässt sich das Formular noch absenden, stimmt die Gesamtsumme noch.

Drei Dinge haben End-to-End-Tests aus den Kreisläufen der Agenten herausgehalten.Sie waren langsam zu schreiben, also schrieb niemand einen für eine Änderung von zehn Minuten.Sie waren selbst Code, also brachen sie bei jedem umbenannten Element.Und ihre Ergebnisse waren eine Wand aus Protokollen, aus der ein Agent raten musste.

GUI Test Studio räumt alle drei aus dem Weg.Ein Test wird aufgezeichnet oder beschrieben, nie programmiert.Er findet Elemente mit der GTS Engine + AI, über das, was die Anwendung über sie sagt, ihre Barrierefreiheitsinformationen, und am Aussehen, wenn sie nichts sagt, sodass ein geänderter Klassenname nichts zerbricht.Und jeder Lauf endet in einem Konfidenzbericht in einfachen Worten, den ein Agent so leicht liest wie ein Mensch.Der Rest dieses Artikels folgt dem Kreislauf, Stufe für Stufe.

Erstellen: ein End-to-End-Test aus einem Prompt

Installieren Sie GUI Test Studio und verbinden Sie Ihren Assistenten einmal: Im GUI Test Runner-Recorder zeigt Test aus Prompt erstellen Claude Desktop, Claude Code und VS Code, jedes mit einer Schaltfläche Verbinden.Jeder andere Assistent, der das Protokoll des Connectors spricht, ist einen Befehl entfernt.

Dann beschreiben Sie den Test.Der Agent zeichnet ihn so auf, wie ein Tester es täte: Er öffnet die Anwendung oder die Webseite, klickt auf die echten Schaltflächen, tippt in die echten Felder und prüft dabei laufend, was er sieht, über den Connector.Jede Prüfung wird an Ort und Stelle ausgewertet, auf dem echten Bildschirm, und abgelehnt, wenn sie jetzt gerade nicht bestehen würde, sodass der Agent nie eine Prüfung speichert, die schon am ersten Tag falsch ist.

Heraus kommt ein gewöhnlicher Test von GUI Test Studio, mit derselben Aufzeichnung, denselben Schritten und Prüfungen, die ein Mensch gemacht hätte, gespeichert, wo Sie es wünschen.Unterwegs kann der Agent innehalten, um nachzudenken, einen misslungenen Schritt rückgängig machen, Schritte zu Szenarien gruppieren, ein Warten oder eine Notiz hinzufügen und den Test am Ende ausführen, um zu belegen, dass er besteht.

With GUI Test Studio, create an end-to-end test of the shop at http://localhost:8080:
sign in as [email protected], add the "Desk lamp" to the cart, open the cart,
and verify that the total reads "$49.00" and that the "Checkout" button is shown.

Der Agent testet, worauf Sie ihn richten: den gesamten Bildschirm, eine Anwendung, einen Bereich davon, eine Webseite im Browser Ihrer Wahl oder ein angeschlossenes Smartphone.Er erkundet nichts ungefragt.Wie Sie jeden Assistenten verbinden und was Sie ihn fragen, steht in Einen Test aus einem Prompt erstellen.

Bearbeiten: einen Test per Prompt ändern, oder wie ein Video

Tests altern mit der Anwendung.Wenn der Agent eine Schaltfläche umbenennt oder ein Feld hinzufügt, sollte er auch den Test aktualisieren, statt einen neuen aufzuzeichnen.

Über den Connector listet der Agent die Schritte eines Tests nach Nummern auf und ändert sie an Ort und Stelle: einen Schritt umbenennen, den Text ändern, den eine Prüfung erwartet, einer Prüfung mehr Zeit geben, einen Schritt entfernen oder ignorieren, ein Warten hinzufügen, festlegen, was geschieht, wenn eine Prüfung fehlschlägt.Nichts wird geschrieben, bevor der Agent die Änderungen zeigt und Sie sie bestätigen, und der Test behält alles andere genau so, wie es war.

Ein Mensch tut dasselbe in GUI Test Studio, auf einer Zeitleiste: Schritte sind Blöcke, die Sie verschieben, kürzen, umbenennen und gruppieren, mit Rückgängig für alles und dem Frame der Aufzeichnung unter jedem einzelnen.Der Test des Agenten und der Test des Testers sind dieselbe Datei, wie Einen Test aktualisieren zeigt.

Ausführen: ohne Fenster, parallel, in jeder CI/CD-Pipeline

gtr-cli führt jeden Test von GUI Test Studio ohne Fenster aus, aus einem Skript oder einer Pipeline, und antwortet so, wie eine Pipeline es erwartet: ein Exitcode, eine JUnit-Datei für das CI-Werkzeug, eine JSON-Datei für ein Skript, eine Markdown-Zusammenfassung für den Pull-Request.

gtr-cli run tests --countdown 0 --format github --junit results\junit.xml ^
  --json results\run.json --summary results\summary.md --artifacts results\artifacts ^
  --jira on-failure

Ein einmal aufgezeichneter Webtest kann für andere Browser und Geräte erzeugt werden: Chrome, Edge und Firefox, Smartphones, Tablets und Bildschirmgrößen, eine andere Sprache, ein langsames Netz, eine Zoomstufe.Die Browser und Geräte, die kein Fenster brauchen, laufen nebeneinander, jedes in einem eigenen Prozess, und ein Desktop-Test läuft danach in seinem Fenster.Siehe Browser und Geräte.

Die Ausgabe spricht das eigene Protokoll jedes Werkzeugs: --format teamcity, azure, github oder einfacher Text.Derselbe Befehl funktioniert in TeamCity, Jenkins, GitHub Actions, GitLab, Azure DevOps oder einem eigenen Skript, wie End-to-End-Tests bei jedem Build ausführen Schritt für Schritt zeigt.

Lesen: ein Ergebnis, das ein Agent und ein Mensch gleichermaßen verstehen

Jeder Lauf endet in einem Konfidenzbericht.Für jede Prüfung sagt er in einfachen Worten, ob das Element gefunden wurde, ob das Gefundene der Aufzeichnung entspricht und wie viel Spielraum blieb: Eine Prüfung, die knapp bestanden hat, ist eine Warnung, bevor sie zum Fehlschlag wird.

Die Intelligente KI-Analyse, die KI-Seite der GTS Engine + AI, sieht sich eine Prüfung an, die an Pixeln gescheitert ist, und unterscheidet eine echte Regression von Rauschen: Ein geändertes Wort, ein fehlendes Badge oder eine andere Farbe ist eine Regression; eine Schattierung oder eine Verschiebung um ein Pixel ist es nicht.Ihre Antwort ist das endgültige Ergebnis, und sie kommt mit einem Satz, nach dem ein Agent handeln kann: was sich geändert hat, wo und um wie viel.

Ein Agent liest die JSON-Datei und die Markdown-Zusammenfassung, die der Lauf schreibt; ein Mensch öffnet den Bericht, mit den Bildern nebeneinander, dem Video des Laufs und dem Verlauf des Tests.Beide sagen dasselbe.Der Bericht ist in Den Konfidenzbericht lesen beschrieben.

Beheben: ein Jira-Bug, den der Agent aufgreifen kann

Mit --jira on-failure wird ein fehlgeschlagener Test von selbst zu einem Jira-Vorgang: ein Titel, die nummerierten Schritte zur Reproduktion, das Bild, das der Test erwartet hat, das Bild, das er gefunden hat, und dieses Bild noch einmal mit jeder Änderung umrandet, dazu ein PDF und die Nachweise.Derselbe Fehler, erneut gesehen auf einem anderen Build, Browser oder Gerät, fügt seinem offenen Vorgang einen Kommentar hinzu, nie ein Duplikat.

Dieser Vorgang ist für einen Entwickler geschrieben, und er erweist sich als genau das, was ein Programmieragent braucht: ein reproduzierbarer Weg, eine präzise Erwartung und ein Bild des Unterschieds.Richten Sie den Agenten auf den Vorgang, und er hat alles, um eine Korrektur vorzuschlagen.Wie Jira verbunden wird, aus dem Konfidenzbericht oder aus einer Pipeline, steht in Jeder fehlgeschlagene End-to-End-Test wird zu einem Jira-Bug.

Der geschlossene Kreislauf: ein Demo-Shop

Wir haben eine kleine Demo gebaut, um den ganzen Kreislauf laufen zu sehen: einen Online-Shop, seinen End-to-End-Test, einen TeamCity-Server, ein Jira-Projekt und einen KI-Programmieragenten.Jean ist der Entwickler, Pierre hat den Test geschrieben, James kümmert sich um das Backlog, John betreibt TeamCity.

1. 1

   Eine Änderung beschädigt die Kasse

   Jean pusht eine Neugestaltung der Schaltflächen der Kasse.TeamCity führt den End-to-End-Test des Shops mit gtr-cli aus, ohne Fenster, auf jedem Browser und Gerät, für das der Test erzeugt wurde.

2. 2

   Der Lauf sagt, was gebrochen ist, und wo

   Der Konfidenzbericht findet die Schaltfläche der Kasse, aber nicht wie aufgezeichnet.Die Intelligente KI-Analyse bestätigt eine echte Regression: Die Schaltfläche hat ihre Beschriftung verloren. gtr-cli legt einen Jira-Vorgang an, mit den Schritten, dem erwarteten und dem gefundenen Bild und der Änderung umrandet, und das Build-Protokoll von TeamCity nennt den Vorgang.

3. 3

   Der Agent behebt ihn

   Der Agent greift den Vorgang auf, liest die Schritte und die Bilder, findet die Stilregel, die die Beschriftung verborgen hat, und schlägt eine Korrektur auf einem eigenen Branch vor.

4. 4

   Der Test belegt die Korrektur

   TeamCity führt denselben Test auf dem Branch aus.Er besteht.Der bestandene Lauf wird dem Jira-Vorgang hinzugefügt, und James schließt ihn, sobald ein Mensch die Änderung geprüft und gemergt hat.Niemand hat einen Test, einen Fehlerbericht oder eine Reproduktion von Hand geschrieben.

Die menschliche Seite

Ein ADLC besteht nicht aus Agenten allein.Die Menschen, die ihn steuern, müssen dem vertrauen können, was die Agenten prüfen, und es selbst prüfen können, wenn es darauf ankommt.Dafür wurde GUI Test Studio gebaut: Derselbe Test dient dem Agenten und dem Menschen.

Vor Ort oder in der Cloud ist Ihre Wahl, Prüfung für Prüfung.Ein Agent, der Tests erstellt, ein Tester, der sie liest, und eine Pipeline, die sie ausführt, sehen auf dieselbe Datei, in denselben Worten.

Wo Sie anfangen