Gewinne:
- Möglichkeit, robusten UI-Testcode mit künstlicher Intelligenz zu erstellen, einschließlich Data-Testid, Open Wait und Assertion, der das tatsächliche Benutzerergebnis überprüft
- Möglichkeit, fragile Tests (schlechter Selektor, blindes Warten) zu vermeiden und die Wartung von Tests in der Struktur des Seitenobjektmodells zu vereinfachen
- Möglichkeit, jeden UI-Test zu testen, der durch das Brechen des Codes erstellt wurde, und falsch bestandene Tests zu erkennen und zu beheben
Jeder Klick, jedes Ausfüllen eines Formulars, jeder Seitenübergang, den ein Benutzer in einem Browser durchführt, kann nicht immer wieder manuell getestet werden – deshalb gibt es die Automatisierung von UI-Tests (Benutzeroberfläche; diese Tests ahmen das Benutzerverhalten nach, indem sie programmgesteuert einen echten Browser steuern). Selenium, Playwright und Cypress sind die gebräuchlichsten Werkzeuge für diesen Job. Künstliche Intelligenz (KI) ist hochqualifiziert darin, den Code für diese Tools zu schreiben: Sie beschreiben einen Testfall, KI liefert Ihnen einen Entwurf eines funktionsfähigen Automatisierungsskripts. Aber hier kommt wieder die zentrale Warnung dieses Moduls ins Spiel: UI-Testcode, den die KI produziert, kann oft fragile Tests sein, die „grün aufleuchten, aber das Falsche verifizieren“ oder im Wind flattern. Ihre Aufgabe besteht nicht darin, diesen Code auszuführen, sondern sicherzustellen, dass er tatsächlich das Richtige zuverlässig überprüft.
In dieser Einheit wollen wir robuste, wartbare und wirklich validierende UI-Tests mit KI erstellen; Sie lernen, fragile Prüfungen zu vermeiden.
Die drei Säulen solider UI-Tests
1. Korrekter Elementfinder. Ein Test verwendet einen Selektor, um das Element auf der Seite zu finden. KI erzeugt oft spröde Selektoren: lange XPath-Pfade (Adresse hängt zu stark von der Seitenstruktur ab), Selektoren, die auf CSS-Klassennamen basieren (brechen ab, wenn sich das Design ändert). Der robustere Weg sind stabile Attribute wie data-testid, die der Entwickler zum Testen hinzugefügt hat. Setzen Sie dies der KI explizit auf.
2. Explizites Warten. Die häufigste Schwachstellenquelle beim UI-Testen ist das Timing. Der ständige Schlaf(3) (blindes Warten) ist eine schlechte Praxis: Manchmal reicht es nicht aus, manchmal ist es Zeitverschwendung. Der richtige Weg besteht darin, explizites Warten zu verwenden, das besagt: „Warten Sie, bis dieses Element erscheint“. Playwright erledigt dies weitgehend automatisch; In Selenium müssen Sie dies explizit anfordern.
3. Aussagekräftige Behauptung. Der Test sollte das Ergebnis überprüfen, das der Benutzer tatsächlich sieht – etwa „Auf dem Bildschirm wurde die Bestellnummer angezeigt“ und nicht nur „Seite geladen“. Wenn der von der KI erstellte Test keine Behauptung enthält oder unwichtig ist, erzeugt dieser Test einen Pseudo-Bestanden (1. Einheit).
Achtung: Wenn Sie zum ersten Mal einen KI-generierten UI-Test sehen, überprüfen Sie höchstens drei Dinge: Sind die Selektoren festgeschrieben (data-testid), sind Wartezeiten aktiv (kein blinder Ruhezustand) und überprüft die Assertion das tatsächliche Benutzerergebnis? Wenn diese drei in Ordnung sind, ist der Test wahrscheinlich solide.
Seitenobjektmodell
Wenn die Tests größer werden, wird das Schreiben von Selektoren in jedem Test zu einem Wartungsalbtraum. Das Seitenobjektmodell (POM – Entwurfsmuster, das Selektoren und Aktionen für jede Seite/jeden Bildschirm in einer einzigen Klasse sammelt) hält den Selektor an einem Ort; Wenn sich die Schnittstelle ändert, aktualisieren Sie sie in einer einzigen Datei. Lassen Sie die KI die Tests in einer POM-Struktur und nicht direkt erstellen. Dies vereinfacht die Wartung erheblich.
Schwache Eingabeaufforderung / Starke Eingabeaufforderung
Schwach: „Schreiben Sie einen Selenium-Test für die Anmeldeseite.“
Strong: „Schreiben Sie einen Login-Flow-Test mit Playwright (TypeScript). Selektoren verwenden nur data-testid; steuern nicht, was der Benutzer sieht, nicht den Seitentitel.“
Leistungsstarke Eingabeaufforderung; Das Tool gibt die Sprache, die Selektorrichtlinie, die Wartestrategie, die Architektur (POM) und die ausdrucksstarke Assert-Erwartung an.
Testdaten- und Umgebungsunabhängigkeit
Ein solider UI-Test wird nicht nur korrekt geschrieben, sondern erstellt und bereinigt auch seine eigenen Testdaten. KI-generierte Tests verweisen häufig auf einen Benutzer oder Datensatz, von dem angenommen wird, dass er bereits in der Umgebung vorhanden ist („Als Admin-Benutzer anmelden“). Diese Annahme wird ungültig, wenn der Test in einer anderen Umgebung oder nach einem anderen Test ausgeführt wird (Reihenfolgeabhängigkeitsproblem in Einheit 9). Die Wahrheit ist, dass jeder Test die Daten, die er benötigt, zu Beginn des Tests erstellt (oder sie mit einem API-Aufruf vorbereitet) und sie am Ende bereinigt. Weisen Sie die KI ausdrücklich an, „alle Daten, von denen dieser Test abhängt, innerhalb des Tests einzurichten; gehen Sie nicht von vorgefertigten Daten von außerhalb aus.“
Ein weiterer kritischer Punkt besteht darin, UI-Tests nicht mit echten Benutzerdaten durchzuführen. Wenn in der Testumgebung eine Produktionsdatenbankkopie verwendet wird, handelt es sich bei diesen Datensätzen um Daten realer Personen; Screenshots und Testaufnahmen können diese Daten offenbaren. Verwenden Sie synthetische (fiktionale) Testkonten; Es schützt sowohl die Vertraulichkeit als auch macht Tests reproduzierbar. Die Durchführung eines „Bestellstornierungstests“ mit einem echten Kundenkonto ist sowohl ein ethischer als auch betrieblicher Fehler.
Tipp: Halten Sie UI-Tests so selten wie möglich; Überlassen Sie die eigentliche Überprüfung der API und den Unit-Tests, die schnell und stabil sind. UI-Tests sind teuer und spröde – verwenden Sie sie nur, um einen wirklich durchgängigen Benutzerfluss zu validieren (Testpyramidenlogik).
Fahrzeugvergleich
Funktion
Selen
Dramatiker
Zypresse
Sprachen
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
Auto-Standby
Nein (von Hand)
Ja (stark)
Ja
Multibrowser
breit
Chromium/Firefox/WebKit
Chromdominant
Neigung zur Sprödigkeit
Hoch (manueller Standby)
niedrig
niedrig
Einfaches Lernen
mittel
einfach
einfach
Parallelbetrieb
Raster erforderlich
eingebaut
Wohnhaft/bezahlt
Wenn Sie einen Code von AI anfordern, geben Sie deutlich an, zu welchem Fahrzeug er gehört; Andernfalls kann es zu verwirrendem, nicht funktionierendem Code kommen.
Vier kopierbare Vorlagen
1) Generierung solider UI-Tests:
Ihre Rolle: Senior Test Automation Engineer. Schreiben Sie Tests mit [Tool + Sprache] für den folgenden Ablauf: [Ablauf]. Regeln: – Selektoren nur data-testid; Verwendung der XPath/CSS-Klasse. - Kein blinder Schlaf; Verwenden Sie explizites/automatisches Warten. - Seitenobjektmodell anwenden. - Lassen Sie jede Behauptung das tatsächliche Benutzerergebnis überprüfen. Kommentieren Sie zu Beginn jedes Tests, welche Akzeptanzkriterien Sie validieren.
2) Zerbrechlichkeitskontrolle:
Untersuchen Sie den folgenden UI-Test auf Sprödigkeit: - Gibt es einen instabilen Selektor (long
3) Konvertierung in Seitenobjekt:
Konvertieren Sie den folgenden einfachen Testcode in die Struktur des Seitenobjektmodells. Verschieben Sie Selektoren und Aktionen in Seitenklassen. Lassen Sie die Testdatei nur den Szenarioablauf lesen. [Tool/Sprache].Code: [Code einfügen]
4) Pseudo-Übergangsbeweis:
Beweisen Sie, dass dieser UI-Test tatsächlich validiert: Welche einzelne Änderung nehme ich am Anwendungscode vor, die diesen Test auf ROT setzt? Wenn Sie keine Änderung finden, die den Test durchbricht, ist der Test unzureichend. Fehlende Asserts hinzufügen.Test: [Test einfügen]
drei Mini-Koffer
Fall 1 – Befreiung vom fragilen Selektor. Von den 40 Tests, die ein Team mit KI erstellte, waren 70 % nach einem Schnittstellen-Update fehlerhaft; Bei keinem davon handelte es sich um echte Fehler, es waren alles fragile XPath-Selektoren. Das Team wandelte die Tests mit der Vorlage „Fragilitätsprüfung“ in eine Daten-Testid-Datenbank um. Im Laufe der nächsten drei Schnittstellenaktualisierungen sank die Anzahl falscher Unterbrechungen auf Null; Die Wartungszeit verringerte sich von 6 Stunden auf 30 Minuten pro Woche.
Fall 2 – Fake-Bestehen des UI-Tests. AI hat einen „In den Warenkorb“-Test erstellt; Der Test war grün. Als die Vorlage „fake-proof-of-passage“ ausgeführt wurde, überprüfte der Test offenbar nur den Klick auf die Schaltfläche und den Seitentitel und überprüfte nie, ob sich der Warenkorbzähler erhöht hatte oder nicht. Selbst wenn die Warenkorblogik völlig kaputt war, wurde der Test bestanden. True Assertion hinzugefügt (Warenkorb-Abzeichen ist „1“).
Fall 3 – Blinde Wartefalle. Im von AI erstellten Selenium-Test gab es nach jedem Schritt Schlaf(2); 60 Tests dauerten 14 Minuten und brachen trotzdem gelegentlich ab. Nach dem Umschalten auf offenes Warten (warten, bis das Element anklickbar ist) sank die Zeit auf 5 Minuten und die Sprödigkeit verschwand. Blindes Warten war langsam und unzuverlässig.
Häufige Fehler
- Zustimmung zu fragilen Selektoren. Die von der KI generierten langen XPaths unverändert verwenden; Tests stürzen beim ersten Schnittstellenwechsel ab.
- Blinden „Schlaf“ hinterlassen. „Auflösen“ des Timings mit einer festen Wartezeit; sowohl langsam als auch unentschlossen.
- Triviale Behauptung. Überprüfen Sie einfach, ob die Seite geladen wurde. Das tatsächliche Benutzerergebnis wird nicht überprüft (Fake-Pass).
- Wachsen Sie ohne POM. Verteilen Sie Selektoren an jeden Test. Manuelle Aktualisierung Dutzender Dateien, wenn sich die Benutzeroberfläche ändert.
- Keine Angabe des Tools. Sagen Sie der KI nicht, welches Tool/welche Sprache Sie wollen; Erhalten Sie unordentlichen, nicht funktionierenden Code.
- Vertrauen, wenn Sie den generierten Code ausführen und bestehen. Nicht testen, indem der Code gebrochen wird.
Zusammenfassend
Die Automatisierung von UI-Tests überprüft das Benutzerverhalten, indem sie den tatsächlichen Browser mit dem Programm steuert. KI generiert diesen Code schnell, aber es gibt zwei große Fallstricke: spröde Tests (schlechter Selektor, blindes Warten) und vorgetäuschte Tests (unvollständige/triviale Behauptung). Die drei Säulen solider UI-Tests sind der Commit-Selektor (data-testid), das explizite Warten und die Bestätigung, die das tatsächliche Benutzerergebnis überprüft. Die Generierung von Tests im Page Object Model vereinfacht die Wartung erheblich. Testen Sie jeden generierten Test mit der Frage „Welche Änderung wird dies verhindern?“
Anwendungsaufgabe
Wählen Sie einen Benutzerfluss aus Ihrem eigenen Projekt (z. B. Anmeldung oder Suche). Lassen Sie die KI Tests mit der Vorlage „Robuste UI-Testgenerierung“ schreiben. Dann: (1) Überprüfen und reparieren Sie die Selektoren und Wartezeiten mit einer „Fragilitätsprüfung“, (2) beweisen Sie, dass jeder Test tatsächlich validiert wird, mit einem „Pseudo-Bestandsnachweis“, (3) brechen Sie den Code und beobachten Sie, dass der Test rot wird. Geben Sie die Anzahl der erstellten und korrigierten Tests sowie die Anzahl der von Ihnen gefundenen Schwachstellen und Pseudofehler an.
Checkliste
- [ ] Ich habe der KI das Tool, die Sprache, die Auswahlrichtlinie und die Architektur (POM) klar gegeben.
- [ ] Ich habe überprüft, dass die Selektoren data-testid sind.
- [ ] Ich habe darauf geachtet, explizites/automatisches Warten anstelle von blindem Schlaf zu verwenden.
- [ ] Ich habe überprüft, ob jede Behauptung das tatsächliche Benutzerergebnis überprüft.
- [ ] Ich habe jeden Test getestet, indem ich den Code gebrochen habe; Ich habe gesehen, wie es rot wurde.
- [ ] Ich habe die Tests in der Page Object Model-Struktur gesammelt.