Zum Hauptinhalt springen

Benutzer

Ein Benutzer in msg.ZenTestAI ist ein simuliertes Endbenutzerprofil, unter dessen Identität ein Test ausgeführt wird. Es enthält die Anmeldedaten, die Zwei-Faktor-Konfiguration, die Browsersprache, die Zeitzone, die Viewport-Größe – alles, was einen Test für Ihre Anwendung wie eine echte Person wirken lässt.

Jeder Testfall ist mit genau einem Benutzer verknüpft (einzustellen auf dem Allgemein-Tab des Tests). Wenn der Test ausgeführt wird, meldet sich msg.ZenTestAI als dieser Benutzer an (sofern eine Anmeldung erforderlich ist) und verhält sich gemäß der Konfiguration des Benutzers.

hinweis

Verwechseln Sie dies nicht mit der Funktion KI-Assistent. KI-Assistenten sind die konversationsbasierten Assistenten, die Sie beim Schreiben oder Warten von Tests unterstützen. Benutzer (diese Seite) sind die Testakteur-Profile, die zum Zeitpunkt der Ausführung verwendet werden.

Sie verwalten Benutzer in der linken Navigation unter Benutzer. Der Kopfbereich der Listenseite zeigt die Gesamtanzahl an (z. B. "Verfügbare Benutzer (5)"); klicken Sie auf eine Zeile, um den Benutzer-Editor in einer Seitenleiste zu öffnen.

Editor-Layout

Eine Verwendungsnachweise-Schaltfläche im Kopfbereich des Editors zeigt alle Tests an, die diesen Benutzer derzeit verwenden. So können Sie prüfen, wer betroffen wäre, bevor Sie Anmeldedaten ändern oder den Benutzer löschen.

Der Benutzer-Editor ist in vier einklappbare Abschnitte unterteilt:

  • Allgemein — Titel und Beschreibung.
  • Authentifizierung — der Authentifizierungsmodus und die dazugehörigen Anmeldedaten/Geheimnisse. Siehe Anmeldung und Authentifizierung für die vollständige schrittweise Anleitung pro Modus.
  • Viewport — die simulierte Browserumgebung (Sprache, Zeitzone, Bildschirmgröße).
  • Client-Zertifikate — optionales clientseitiges SSL/TLS-Zertifikat und Schlüssel für Websites, die gegenseitige TLS-Authentifizierung (Mutual TLS) erfordern.

Allgemein

FeldBeschreibung
TitelDer Name, der für diesen Benutzer im Auswahlmenü auf dem Tab "Allgemein" des Tests angezeigt wird. Erforderlich.
BeschreibungOptionaler Freitext für Notizen zum Benutzer. Begrenzt auf 300 Zeichen.

Authentifizierung

Der Abschnitt "Authentifizierung" steuert, wie sich der Test anmeldet. Die Menge der sichtbaren Felder hängt vom gewählten Authentifizierungsmodus ab – der Abschnitt ist für Benutzer, die gar keine Anmeldung benötigen, bewusst minimal gehalten.

Die verfügbaren Modi sind:

  • Keine — es erfolgt keine Anmeldung; der Test startet direkt auf der konfigurierten URL.
  • Passwort (Basic Auth) — Benutzername + Passwort. Ein zweites Variante-Dropdown bestimmt, wie die Anmeldedaten übermittelt werden (Anmeldeformular, HTTP Basic-Auth-Header, Bearer-Token-Header, NTLM, NTLM mit Anmeldeseite).
  • OAuth + TOTP — Benutzername + Passwort + ein zeitbasiertes Einmalpasswort (im Stil von Google Authenticator).
  • HOTP — Benutzername + Passwort + ein zählerbasiertes Einmalpasswort, optional mit PIN.
  • Yubikey OTP — Yubikey Hardware-Token-Simulation unter Verwendung von AES-Schlüssel + öffentlicher/privater ID.

Für modusspezifische Felder, den Anmeldeablauf zur Laufzeit und die Einrichtung von Zwei-Faktor-Geheimnissen, siehe Anmeldung und Authentifizierung.

Identifizierungsfelder

Drei optionale Identifizierungsfelder stehen in jedem authentifizierten Modus zur Verfügung:

  • E-Mail — die E-Mail-Adresse des Benutzers. Nützlich, wenn das Anmeldeformular eine E-Mail (statt eines Benutzernamens) erfordert oder zur leichteren Identifizierung in der Liste.
  • Client/Tenant — eine Mandanten- oder Client-Kennung für Multi-Tenant-Anwendungen, bei denen bei der Anmeldung angegeben werden muss, in welchen Bereich eingeloggt werden soll.
  • Berechtigungen — ein Freitext-Label (oder eine kommagetrennte Liste) der Berechtigungen/Rollen, die dieser Benutzer in der zu testenden Anwendung haben sollte. Dient als Metadaten, um Testdaten aus externen Systemen während des Imports dem richtigen Benutzer zuzuordnen und die Liste übersichtlicher zu gestalten.

Geheimnisse werden verschlüsselt gespeichert

Nach dem ersten Speichern werden geheime Felder (Passwort, TOTP-Geheimnis, HOTP-Geheimnis, Yubikey AES-Schlüssel, Yubikey private ID) nicht mehr angezeigt und können nicht über die Benutzeroberfläche abgerufen werden. Sie werden im Ruhezustand (at rest) verschlüsselt. Um ein Geheimnis zu ändern, bearbeiten Sie den Benutzer und geben Sie den neuen Wert ein – wenn das Feld leer gelassen wird, bleibt der bestehende Wert erhalten.

Zwei-Faktor-Hilfsschaltflächen

Wenn ein Zwei-Faktor-Modus ausgewählt ist, erscheint eine kleine Aktualisieren-Schaltfläche neben dem Feld für das Geheimnis. Sie generiert das nächste gültige OTP aus dem konfigurierten Geheimnis, damit Sie den Wert während der Einrichtung schnell bei Ihrem Authentifizierungsanbieter verifizieren (und ein neues TOTP-Gerät beim ersten Mal bestätigen) können.

Für HOTP gibt es eine zusätzliche Bearbeiten-Schaltfläche, mit der Sie den HOTP-Zähler manuell anpassen können – nützlich, wenn der Zähler nicht mehr mit dem Zielsystem synchron ist.

Viewport

Der Abschnitt "Viewport" simuliert die Browserumgebung des Benutzers:

FeldBeschreibung
BrowserspracheDie Sprache, die der Browser der Anwendung mitteilt (z. B. Deutsch – de, English – en). Beeinflusst, welche Lokalisierung die Anwendung unter Test bereitstellt. Wird aus einer festen Liste ausgewählt.
ZeitzoneDie simulierte Browser-Zeitzone, die überall dort verwendet wird, wo die Anwendung die Ortszeit des Benutzers liest. Standard ist UTC (UTC+0). Auswahl aus einer festen Liste von etwa 36 Zeitzonen.
Verwendetes BrowsergerätEine Voreinstellung, die die Viewport-Größe und den Formfaktor definiert. Beinhaltet Desktop-Small / Medium / Large, iPad Landscape / Portrait, iPhone Landscape / Portrait sowie zwei Benutzerdefiniert-Optionen (Desktop oder Phone), mit denen Sie Breite und Höhe in CSS-Pixeln festlegen können.

Client-Zertifikate

Für Anwendungen, die eine gegenseitige TLS-Authentifizierung (Mutual TLS) erfordern, fügen Sie hier das Client-Zertifikat und den privaten Schlüssel des Benutzers hinzu. Der Runner präsentiert das Zertifikat jeder Website, die während der Testausführung danach fragt.

Tipps

tipp

Ein gängiges Muster ist es, einen Benutzer pro Persona (z. B. Administrator, Kunde, Nur-Lese-Betrachter) zu führen und diesen in vielen Tests wiederzuverwenden. Das Wechseln des Benutzers in einem Test ändert dann die gesamte Identität der simulierten Sitzung – einschließlich Viewport und Sprache –, ohne den Test selbst anpassen zu müssen.

warnung

Ein Testfall kann nur mit einem Benutzer verknüpft werden, und die Anmeldung ist immer der erste Schritt des Tests. Um Multi-Benutzer-Szenarien zu prüfen – zum Beispiel "Admin erstellt eine Bestellung, Kunde genehmigt sie" – teilen Sie den Ablauf in mehrere Tests auf und verketten Sie diese mit einem Ausführungsplan. Um zwei Anmeldungen in einem Test durchzuführen, verwenden Sie ein Snippet mit Anmeldung erforderlich und aktiviertem Isoliert-Schalter (siehe Testfall-Definition → Snippets).