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 denjenigen aus, der zu der zu testenden Anwendung passt:
| Modus | Verwendung, wenn… |
|---|---|
| Keine | Die Anwendung erfordert keinen Login (öffentliche Seiten). |
| Passwort (Basic Auth) | Standard-Login mit Benutzername und Passwort (der häufigste Fall). Ein Variante-Dropdown wählt aus, wie die Anmeldedaten übermittelt werden. |
| OAuth + TOTP | Login mit einem zeitbasierten Einmalpasswort (Stil von 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 sowie ö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 für instabile Tests (Flakiness).
Details zu den Modi
Keine
Es wird kein Login-Schritt durchgeführt. Der Test startet direkt auf seiner Start-URL. Verwenden Sie diesen Modus für öffentlich zugängliche Seiten oder wenn Sie die Authentifizierung bewusst umgehen möchten.
Sie können einen Login-losen Ablauf auch erzwingen, indem Sie Login erforderlich auf der Registerkarte „Allgemein“ eines spezifischen Tests deaktivieren, selbst wenn der zugewiesene Benutzer eigentlich authentifiziert wäre.
Passwort (Basic Auth)
Der Standardmodus. Sie geben eine Benutzer-ID und ein Passwort ein, und ein Variante-Dropdown legt fest, wie die Anmeldedaten die Anwendung erreichen:
| Variante | Verhalten |
|---|---|
| Login-Seite | Ein echtes Login-Formular auf der Anmeldeseite der Anwendung. Der KI-Agent lokalisiert die Felder, gibt die Anmeldedaten ein und klickt auf „Anmelden“. |
| HTTP-Header (Basic) | Anmeldedaten werden im nativen HTTP-Authorization-Header des Browsers gesendet (der kleine Browser-native Dialog, der bei HTTP Basic Auth erscheint). |
| 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 Anwendungen, die beides kombinieren. |
Varianten, die Anmeldedaten in HTTP-Headern senden, hängen diese an jede Anfrage an, die der Browser während des Tests stellt. Wenn Ihr Test eine externe API aufruft, würden die Basic-Auth-Anmeldedaten auch an diese API gesendet. Bevorzugen Sie die Variante Login-Seite, wann immer die Anwendung ein echtes Formular bietet.
OAuth + TOTP
Benutzername + Passwort plus ein TOTP-Geheimnis (das gemeinsame Geheimnis, das Sie bei der Einrichtung der Zwei-Faktor-Authentifizierung in der Zielanwendung sehen). Einrichtung:
- Melden Sie sich bei der Zielanwendung mit dem Benutzer an, den Sie für Tests 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-Geheimnis beim Benutzer ein.
- Klicken Sie auf die Schaltfläche Aktualisieren neben dem Geheimnis, um das aktuelle Einmalpasswort zu generieren.
- Geben Sie dieses Einmalpasswort in der Zielanwendung ein, um das Gerät zu bestätigen.
Von nun an schlägt jeder Testlauf das TOTP-Geheimnis nach, generiert den aktuellen Code und übergibt ihn für den zweiten Faktor an den KI-Agenten.
msg.ZenTestAI geht davon aus, 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 zu Benutzer-ID, Passwort und HOTP-Geheimnis müssen Sie möglicherweise eine PIN angeben, falls Ihr Authentifizierungsanbieter eine solche verlangt.
Der Benutzer-Editor enthält eine kleine Bearbeiten-Schaltfläche neben dem Geheimnis, mit der 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 die Schaltfläche „Aktualisieren“ drücken, um eine Vorschau eines Tokens zu sehen, erhöht sich der Zähler. Wenn der Zähler bei msg.ZenTestAI und dem Authentifizierungsanbieter nicht synchron sind, schlägt der Login fehl; verwenden Sie die Bearbeiten-Schaltfläche, 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 in Hex)
- Yubikey Public ID (das Präfix des öffentlichen Identifikators)
- Yubikey Private ID (der private Identifikator, 6 Bytes Hex)
...plus Benutzer-ID und Passwort. Eine optionale PIN ist verfügbar, wenn der Anbieter diese verlangt.
Ablauf des Logins bei der Ausführung
Wenn ein Test startet und Login erforderlich für den Test aktiviert ist (dies ist standardmäßig der Fall, sobald der zugewiesene Benutzer einen anderen Authentifizierungsmodus als Keine hat), führt msg.ZenTestAI Folgendes aus:
- Fügt einen Login-Schritt als Schritt 0 der Testausführung ein.
- Navigiert zur Start-URL des Tests (oder der URL, auf die die Anwendungseinstellungen für diesen Host zeigen).
- Sucht nach einer Shortcut-Login-Strategie, die zum Host passt (msg.ZenTestAI liefert deterministische Strategien für mehrere gängige Identitätsanbieter mit). Wenn eine Übereinstimmung gefunden wird, wird diese 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“-Schaltflächen, bis der Login abgeschlossen ist.
- Wenn der Login nicht innerhalb von ca. 30 Sekunden abgeschlossen ist, versucht msg.ZenTestAI es ein weiteres Mal (mit einem frischen Browser-Kontext). Wenn auch der zweite Versuch 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-Geheimnis des Benutzers ab. Es ist kein zusätzlicher Schalter erforderlich.
- Host-spezifische Anpassungen (Timeouts, „Schritt 0: Ausführung vor Login“, „Schritt 0: Ausführung nach Login“) befinden sich in den Zusatzfunktionen → Anwendungseinstellungen, nicht beim Benutzer. Verwenden Sie diese, um deterministische Schritte einzufügen, die die KI nicht selbst herausfinden muss.
Speichern Sie keine Anmeldedaten in Testschritten oder Snippets. msg.ZenTestAI verschlüsselt den Schritt-Text nicht; der verschlüsselte Geheimnisspeicher des Benutzers ist der einzige sichere Ort dafür.
Wiederverwendung von Logins zwischen Tests
Der Anmeldevorgang ist einer der zeitaufwendigsten Prozesse eines Tests, daher speichert msg.ZenTestAI den Zustand nach dem Login zwischen und verwendet ihn, wenn möglich, über mehrere Läufe hinweg wieder:
- Der Cache wird nach Benutzer + Host sortiert.
- Zwischengespeicherte Einträge sind 10 Minuten gültig, danach laufen sie ab und beim nächsten Lauf wird ein frischer 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 Anwendung den Zustand in einer langlebigen Sitzung beibehält, sind die einfachsten Lösungen, die 10 Minuten abzuwarten, das Benutzerpasswort zu ändern (was den zwischengespeicherten Hash ungültig macht) oder pro Lauf einen anderen Benutzer zu verwenden.
Wenn die Anwendung Daten in Cookies oder localStorage über Logins hinweg beibehält (z. B. ein zustandsbehafteter Einkaufswagen), kann die Wiederverwendung der zwischengespeicherten Sitzung den Zustand zwischen Tests vermischen. Entwerfen Sie Tests so, dass sie unabhängig sind – gehen Sie beim Start von keinen Inhalten im lokalen Speicher aus.
Szenarien mit mehreren Benutzern
Ein Testfall hat genau einen Benutzer. Der Login ist immer der erste Schritt. Um Szenarien mit mehreren Akteuren zu testen:
- Über verschiedene Tests hinweg – teilen Sie den Ablauf in mehrere Tests auf, jeder mit seinem eigenen Benutzer, und verketten Sie diese mit einem Ausführungsplan. Verwenden Sie Merken-Schritte und Parameterbindungen, um Kontext (z. B. eine Bestell-ID) von einem Test zum nächsten zu übertragen.
- Innerhalb eines Tests – kapseln Sie den sekundären Login in einem Snippet mit aktiviertem Login erforderlich und dem Schalter Isoliert. 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 Anwendung einen Authentifizierungsablauf verwendet, der in keinen der oben genannten Modi passt (SAML, benutzerdefiniertes SSO, zertifikatsbasiert, …), kontaktieren Sie den msg.ZenTestAI-Support unter hello@zentest.ai – wir helfen Ihnen gerne weiter.