Ein grüner Haken beweist nicht, dass der Test stimmt
KI-Agenten schreiben End-to-End-Tests. Eine Erfolgsmeldung beweist aber nicht, dass Daten gespeichert wurden. Prüfen Sie das Ergebnis über einen unabhängigen Weg.
Übersetzte Ausgabe. Technische Kennungen bleiben in ihrer ursprünglichen Form.
Der Test klickt auf "Senden". Eine Meldung erscheint: "Gespeichert". Der Test prüft die Meldung und besteht. Drei Wochen später berichtet ein Nutzer, dass seine Einstellungen nie gespeichert wurden. Das ist ein Beispiel, kein Bericht über einen konkreten Vorfall.
Nichts an dieser Geschichte ist neu und nichts erfordert KI. Das ist die Standardmethode für End-to-End-Tests: Die Prüfung überwacht die Benutzeroberfläche, und die Benutzeroberfläche ist das, was getestet wird. Wenn ein KI-Agent die Tests schreibt, tritt derselbe Fehlermodus im industriellen Maßstab auf, da der Agent durch Beobachtung der Schnittstelle auch lernt, was er behaupten soll.
Das Orakelproblem, in einem Absatz
Jeder Test besteht aus zwei Hälften. Die erste Hälfte macht etwas. Die zweite Hälfte entscheidet, ob das Ergebnis stimmt. Diese zweite Hälfte ist das Orakel, und es ist die Hälfte, auf die es ankommt. Ein schwaches Orakel prüft das nächste sichtbare Signal: einen Bestätigungsmeldung, einen Spinner, der stoppt, eine URL-Änderung. Ein starkes Orakel prüft das Ergebnis aus unabhängiger Richtung: den Datensatz in der Datenbank, die Antwort der API auf die Seitenaufrufe, den Status nach einem erneuten Neuladen.
Der Best-Practices-Leitfaden von Playwright weist auf den angrenzenden Punkt zu Aktionen hin: Tests sollten das Verhalten überprüfen, das der Endbenutzer sehen kann, und eine Kopplung an Implementierungsdetails wie CSS-Klassen vermeiden. Das gleiche Prinzip, das auf Prüfungen angewendet wird, liefert die Regel für das KI-Zeitalter. Machen Sie Aussagen über das Ergebnis, das ein Benutzer überprüfen würde, über einen Pfad, den der Fehler nicht vortäuschen kann.
Warum KI-geschriebene Tests zu schwachen Orakeln tendieren
Ein Agent, der Ihre App erkundet und Tests schreibt, lernt die App von ihrer Oberfläche aus. Es klickt, es beobachtet, was sich ändert, und es kodiert genau das: Klicken Sie darauf, dann ändert sich dies. Ein Bestätigungsmeldung ist ein praktisches, deterministisch aussehendes Signal, also behauptet der Agent den Bestätigungsmeldung. Der Agent ist nicht nachlässig. Es hat einfach keinen Zugriff auf Ihre Absicht, sondern nur auf Ihre Pixel.
Durch die automatische Wartefunktion von Playwright fühlt sich dies sicherer an, als es ist. Umsetzbarkeitsprüfungen bestätigen, dass ein Element sichtbar und stabil ist und Ereignisse empfängt, bevor der Klick erfolgt. Auto-Retry-Assertions warten auf die erwartete Bedingung. Beides reduziert zeitbedingte Ausfälle. Keiner fragt, ob die Bedingung richtig war. Ein Test kann vollkommen stabil und völlig falsch sein.
Drei Oracle-Upgrades, die heute funktionieren
Neu laden und lesen. Navigieren Sie nach dem Speichern weg und zurück oder laden Sie neu und stellen Sie sicher, dass der Wert noch vorhanden ist. Dadurch wird die Persistenz auf die Art und Weise überprüft, wie ein Benutzer ihre Abwesenheit bemerken würde.
Eine Ebene tiefer aktivieren. Playwright kann auf die Netzwerkantwort warten, von der die Benutzeroberfläche abhängt. Koppeln Sie die UI-Assertion mit expect(response).toBeOK() beim API-Aufruf, der tatsächlich speichert, oder fragen Sie die API direkt nach dem UI-Flow ab und vergleichen Sie den gespeicherten Wert.
Überprüfen Sie den Nebeneffekt außerhalb des Bandes. Für eine Anmeldung bestätigen Sie dies im Postausgang, im Audit-Protokoll oder in der Administratorliste, nicht im Willkommensbanner. Das Banner ist so konzipiert, dass es angezeigt wird. Der Datensatz existiert nur, wenn das System funktioniert.
Die Rezensionsfrage, die alles verändert
Wenn Sie Agenten Tests schreiben lassen und sie von Menschen überprüfen lassen, verbringen Sie die Überprüfungszeit mit einer Frage pro Test: Was besagt dieser und könnte er bestehen, während die Funktion nicht funktioniert? Den glücklichen Weg zu überprüfen bedeutet, den Test zu lesen. Die Prüfung des Orakels ist eine Prüfung.
Dies ist auch die ehrliche Art, ein Tool wie AnyTest zu verwenden. Seine Agenten erkunden Ihre App über eine URL, erstellen End-to-End-Tests und überlassen sie Ihrer Überprüfung. Die Überprüfungsoberfläche zeigt jeden Schritt und sein Ergebnis. Bei richtiger Verwendung findet in dieser Überprüfung die Oracle-Prüfung statt: nicht "Hat der Agent auf die richtigen Dinge geklickt", sondern "Hat der von ihm geschriebene Test etwas bewiesen". Das eigene Material des Anbieters besagt, dass immer noch Menschen entscheiden. Das ist die Entscheidung, die zählt.
Ein grünes Häkchen zeigt an, dass der Test ausgeführt wurde. Es sagt einem nie, dass der Test richtig war.
Häufige Fragen
Was ist ein Testorakel?
Der Teil eines Tests, der über Bestehen oder Nichtbestehen entscheidet. Eine Aussage zu einer Erfolgsmeldung ist ein schwaches Orakel. Eine Aussage über den unabhängig verifizierten Status, wie z. B. Daten nach einem Neuladen oder einer API-Abfrage, ist aussagekräftig.
Beweist ein bestandener End-to-End-Test, dass die Funktion funktioniert?
Nein. Es beweist, dass die im Test behaupteten spezifischen Bedingungen wahr waren. Wenn die Prüfung nur die Benutzeroberfläche überwacht, kann die Funktion darunter unterbrochen werden, während der Test grün bleibt.
Wie prüfe ich Tests, die von einem KI-Agenten geschrieben wurden?
Fragen Sie bei jedem Test, was er aussagt und ob er bestanden werden kann, obwohl die Funktion nicht funktioniert. Bevorzugen Sie Tests, die den persistenten Zustand über einen zweiten Pfad überprüfen: Neuladen, API-Abfrage oder einen Out-of-Band-Datensatz.