Login und Authentifizierung
Wenn ein Test als Benutzer ausgeführt wird, für den eine Authentifizierung konfiguriert ist, meldet sich msg.ZenTestAI zu Beginn des Tests automatisch an. Diese Seite erläutert die verfügbaren Authentifizierungsmodi, die erforderlichen Felder und den Ablauf zur Laufzeit.
Authentifizierungsmodi
Der Bereich Authentifizierung eines Benutzers bietet fünf Modi. Wählen Sie den Modus, der für die zu testende Applikation geeignet ist:
| Modus | Verwendung wenn... |
|---|---|
| Keine | Die Applikation kein Login erfordert (öffentliche Seiten). |
| Passwort (Basic Auth) | Standard-Login mit Benutzername und Passwort (der häufigste Fall). Ein Varianten-Dropdown wählt aus, wie die Anmeldedaten übermittelt werden. |
| OAuth + TOTP | Login mit einem zeitbasierten Einmalpasswort (Stil: Google Authenticator / Microsoft Authenticator). |
| HOTP | Zählerbasiertes Einmalpasswort (Token erhöht sich bei jeder Verwendung), optional mit einer PIN. |
| Yubikey OTP | Simulation eines Hardware-Yubikey-Tokens unter Verwendung eines AES-Schlüssels und öffentlicher/privater Identifikatoren. |
Halten Sie den Login bei End-to-End-Tests so einfach wie möglich. Jeder zusätzliche Faktor kostet bei jedem Testlauf Zeit und ist eine häufige Fehlerquelle (Flakiness).
Details zu den Modi
Keine
Es wird kein Login-Schritt durchgeführt. Der Test startet direkt auf der Start-URL. Verwenden Sie diesen Modus für öffentlich zugängliche Seiten oder wenn Sie die Authentifizierung gezielt umgehen möchten.
Sie können einen Login-losen Durchlauf auch erzwingen, indem Sie Login erforderlich auf dem Tab Allgemein (General tab) eines spezifischen Tests deaktivieren, selbst wenn der zugewiesene Benutzer normalerweise authentifiziert ist.
Passwort (Basic Auth)
Der Standardmodus. Sie geben eine Benutzer-ID und ein Passwort an, und über ein Varianten-Dropdown wird festgelegt, wie die Anmeldedaten die Applikation erreichen:
| Variante | Verhalten |
|---|---|
| Login-Seite | Ein echtes Login-Formular auf der Anmeldeseite der Applikation. Der KI-Agent lokalisiert die Felder, gibt die Daten ein und klickt auf den Absenden-Button. |
| HTTP-Header (Basic) | Anmeldedaten werden im nativen HTTP-Authorization-Header des Browsers gesendet (der kleine browser-native Dialog bei HTTP-Basic-Auth). |
| HTTP-Header (Bearer) | Anmeldedaten werden als Bearer-Token im Authorization-Header gesendet. |
| NTLM Auth | Windows-NTLM-Authentifizierung, die im Hintergrund ohne Login-Seite erfolgt. |
| NTLM Auth + Login-Seite | NTLM-Authentifizierung, gefolgt von einem zusätzlichen Login-Formular, für Applikationen, die beides kombinieren. |
Varianten, die Anmeldedaten in HTTP-Headern senden, fügen diese an jede Anfrage an, die der Browser während des Tests stellt. Wenn Ihr Test eine externe API aufruft, werden die Basic-Auth-Anmeldedaten auch an diese API gesendet. Bevorzugen Sie die Variante Login-Seite, wann immer die Applikation ein echtes Formular anbietet.
OAuth + TOTP
Benutzername + Passwort sowie ein TOTP-Secret (der gemeinsame Schlüssel, den Sie beim Einrichten der Zwei-Faktor-Authentifizierung in der Zielapplikation sehen). Einrichtung:
- Melden Sie sich bei der Zielapplikation mit dem Benutzer an, den Sie für den Test verwenden möchten.
- Fügen Sie ein neues Authentifizierungsgerät hinzu (Authenticator-App / TOTP).
- Sie erhalten einen QR-Code oder einen geheimen Schlüssel. Kopieren Sie den geheimen Schlüssel (oder dekodieren Sie den QR-Code) und fügen Sie ihn in das Feld TOTP-Secret beim Benutzer ein.
- Klicken Sie auf den Aktualisieren-Button neben dem Secret, um das aktuelle Einmalpasswort zu generieren.
- Geben Sie dieses Einmalpasswort in der Zielapplikation ein, um das Gerät zu bestätigen.
Von nun an schlägt jeder Testlauf das TOTP-Secret nach, generiert den aktuellen Code und übergibt ihn an den KI-Agenten für den zweiten Faktor.
msg.ZenTestAI erwartet, dass das konfigurierte TOTP-Gerät das einzige (oder erste) im Benutzerkonto ist – der KI-Agent wählt kein Gerät aus einer Liste mehrerer Authentifikatoren aus.
HOTP
Wie TOTP, aber zählerbasiert. Token bleiben gültig, bis sie verwendet werden; der Zähler erhöht sich nach jeder Verwendung. Zusätzlich zur Benutzer-ID, dem Passwort und dem HOTP-Secret müssen Sie möglicherweise eine PIN angeben, falls Ihr Authentifizierungsanbieter diese verlangt.
Der Benutzer-Editor enthält einen kleinen Bearbeiten-Button neben dem Secret, mit dem Sie den HOTP-Zähler manuell anpassen können – nützlich, wenn er nicht mehr mit dem Zielsystem synchron ist.
Jedes Mal, wenn Sie auf den Aktualisieren-Button klicken, um eine Vorschau eines Tokens zu erhalten, wird der Zähler erhöht. Wenn der Zähler in msg.ZenTestAI und beim Authentifizierungsanbieter nicht mehr synchron sind, schlägt der Login fehl; verwenden Sie den Bearbeiten-Button, um sie wieder abzugleichen. |
Yubikey OTP
Simuliert einen Hardware-Yubikey. Sie benötigen drei Yubikey-spezifische Werte aus Ihrer Bereitstellung:
- Yubikey AES-Schlüssel (128-Bit AES-Schlüssel als Hex)
- Yubikey öffentliche ID (das Präfix des öffentlichen Identifikators)
- Yubikey private ID (der private Identifikator, 6 Bytes Hex)
…zuzüglich Benutzer-ID und Passwort. Eine optionale PIN ist verfügbar, falls der Anbieter diese verlangt.
Ablauf des Logins während der Ausführung
Wenn ein Test startet und Login erforderlich aktiviert ist (dies ist standardmäßig der Fall, sobald der zugewiesene Benutzer einen anderen Authentifizierungsmodus als Keine hat), führt msg.ZenTestAI folgende Schritte aus:
- Fügt einen Login-Schritt als Schritt 0 in die Testausführung ein.
- Navigiert zur Start-URL des Tests (oder der URL, auf die die Applikationseinstellungen für diesen Host verweisen).
- Sucht nach einer Shortcut-Login-Strategie, die zum Host passt (msg.ZenTestAI enthält deterministische Strategien für mehrere gängige Identitätsanbieter). Wenn eine passt, wird sie verwendet.
- Andernfalls untersucht ein dedizierter Login-Agent die Seite, identifiziert die Benutzer/Passwort- (und OTP-) Felder, füllt sie mit den Anmeldedaten des Benutzers aus und klickt sich durch alle "Weiter" / "Anmelden"-Buttons, bis der Login abgeschlossen ist.
- Wenn der Login nicht innerhalb von ca. 30 Sekunden abgeschlossen ist, führt msg.ZenTestAI einen erneuten Versuch durch (mit einem neuen Browser-Kontext). Wenn der zweite Versuch ebenfalls fehlschlägt, schlägt die Testausführung fehl.
Einige wichtige Eigenschaften dieses Ablaufs:
- Der Login-Schritt ist immer der erste – er kann nicht mitten in den Test verschoben werden.
- Zwei-Faktor-Codes werden automatisch erkannt: Der Login-Agent sucht auf der Seite nach einem OTP-Feld und ruft, falls gefunden, den nächsten Code vom TOTP/HOTP/Yubikey-Secret des Benutzers ab. Es ist kein zusätzlicher Schalter erforderlich.
- Host-spezifische Anpassungen (Timeouts, "Schritt 0: Vor dem Login ausführen", "Schritt 0: Nach dem Login ausführen") befinden sich in Zusätzliche Funktionen → Applikationseinstellungen, nicht beim Benutzer. Verwenden Sie diese, um deterministische Schritte einzufügen, die die KI nicht selbst herausfinden muss.
Geben Sie keine Anmeldedaten in Testschritte oder Snippets ein. msg.ZenTestAI verschlüsselt den Text von Schritten nicht; der verschlüsselte Speicher für Benutzer-Secrets ist der einzige sichere Ort dafür.
Wiederverwendung von Logins zwischen Tests
Der Login-Vorgang ist einer der langsamsten Schritte eines Tests. Daher speichert msg.ZenTestAI den Zustand nach dem Login zwischen und verwendet ihn nach Möglichkeit für weitere Durchläufe wieder:
- Der Cache ist nach Benutzer + Host sortiert.
- Zwischengespeicherte Einträge sind 10 Minuten gültig, danach laufen sie ab und beim nächsten Durchlauf wird ein neuer Login durchgeführt.
- Sowohl Cookies als auch localStorage, die nach dem Login erfasst wurden, werden bei der Wiederverwendung wiederhergestellt.
Die Wiederverwendung erfolgt automatisch – es gibt keinen Schalter. Wenn ein Cache-Treffer zu unerwartetem Verhalten führt, weil Ihre Applikation den Zustand in einer langlebigen Sitzung beibehält, sind die einfachsten Umgehungsmöglichkeiten: 10 Minuten abwarten, das Passwort des Benutzers ändern (was den zwischengespeicherten Secret-Hash entwertet) oder pro Durchlauf einen anderen Benutzer verwenden.
Wenn die Applikation Daten in Cookies oder localStorage über Logins hinweg beibehält (z. B. ein zustandsbehafteter Warenkorb), kann die Wiederverwendung der zwischengespeicherten Sitzung zu einem Leak von Zuständen zwischen Tests führen. Gestalten Sie Tests so, dass sie unabhängig sind – setzen Sie zu Beginn nichts über die Inhalte des lokalen Speichers voraus.
Multi-User-Szenarien
Ein Testfall hat genau einen Benutzer. Der Login ist immer der erste Schritt. Um Szenarien mit mehreren Akteuren zu testen:
- Über mehrere Tests hinweg – teilen Sie den Ablauf in mehrere Tests auf, von denen jeder seinen eigenen Benutzer hat, und verketten Sie diese mit einem Ausführungsplan. Verwenden Sie Merken-Schritte und Parameter-Bindings, um Kontext (z. B. eine Bestell-ID) von einem Test zum nächsten weiterzugeben.
- Innerhalb eines Tests – kapseln Sie den sekundären Login in einem Snippet mit aktiviertem Login erforderlich und dem Isoliert-Schalter. Das Snippet wird in einem eigenen Browser-Kontext mit eigenem Login ausgeführt, und die ursprüngliche Sitzung wird wiederhergestellt, sobald das Snippet beendet ist. Siehe Testfall-Definition → Snippets.
Benötigen Sie ein anderes Authentifizierungsszenario?
Wenn Ihre Applikation einen Authentifizierungsablauf verwendet, der nicht in einen der oben genannten Modi passt (SAML, benutzerdefiniertes SSO, zertifikatsbasiert, ...), kontaktieren Sie den msg.ZenTestAI-Support unter hello@zentest.ai – wir helfen Ihnen gerne weiter.