Authentifizierungs-Flows zuverlässig end-to-end testen

1. Warum Authentifizierung einen eigenen Testbereich verdient

Authentifizierung unterscheidet sich von den meisten anderen Testbereichen dadurch, dass sie querschnittlich praktisch jede weitere Funktion einer Anwendung betrifft: Ein defekter Login-Flow blockiert nicht nur den Login-Test selbst, sondern potenziell auch alle nachgelagerten Tests, die einen eingeloggten Zustand voraussetzen, etwa Tests für den Bestellverlauf, das Kundenkonto oder gespeicherte Zahlungsmethoden, was einen einzelnen Fehler im Login-Flow zu einer Kettenreaktion fehlschlagender Tests im gesamten Testreport werden lässt.

Aus diesem Grund lohnt es sich, Authentifizierungs-Tests bewusst als eigenständigen, frühzeitig in der Testsuite laufenden Testbereich zu behandeln, dessen Ergebnis unmittelbar Aufschluss darüber gibt, ob das grundlegende Fundament für alle nachfolgenden, auf Login angewiesenen Tests überhaupt trag fähig ist, statt einen fehlgeschlagenen Login irgendwo in der Mitte eines langen Testlaufs erst spät zu bemerken, nachdem bereits Dutzende Folgetests aus demselben Grund fehlgeschlagen sind.

2. Login und Logout als eigenständige Testfälle

Ein solider Login-Test prüft nicht nur den erfolgreichen Pfad mit korrekten Zugangsdaten, sondern gezielt auch die erwarteten Fehlerzustände: eine falsche Kombination aus E-Mail-Adresse und Passwort, ein gesperrtes Konto nach zu vielen Fehlversuchen, sowie das korrekte Verhalten bei einem noch nicht bestätigten E-Mail-Konto, sofern die Anwendung eine solche Bestätigung verlangt.

Der Logout-Test wiederum sollte nicht nur prüfen, dass der sichtbare Nutzerzustand nach dem Logout korrekt auf ausgeloggt wechselt, sondern auch, dass eine anschliessende direkte Navigation zu einer eigentlich geschützten Seite, etwa dem Bestellverlauf, zuverlässig zur Login-Seite umleitet, statt fälschlich weiterhin geschützte Inhalte anzuzeigen, was auf eine unvollständig invalidierte Session hindeuten würde.

test('Login mit korrekten Zugangsdaten führt zum Kundenkonto', async ({ page }) => {
  await page.goto('/customer/account/login');
  await page.fill('#email', testUser.email);
  await page.fill('#pass', testUser.password);
  await page.click('#send2');
  await expect(page).toHaveURL(/customer\/account/);
});

test('Logout invalidiert die Session vollständig', async ({ page }) => {
  await loginAs(page, testUser);
  await page.click('[data-testid="customer-logout"]');
  await page.goto('/sales/order/history');
  await expect(page).toHaveURL(/customer\/account\/login/);
});

3. Session-Timeout gezielt und ohne echtes Warten testen

Ein Session-Timeout tatsächlich durch reales Warten der konfigurierten Ablaufzeit zu testen, ist in praktisch keiner CI-Pipeline vertretbar, da Session-Laufzeiten in Magento typischerweise mehrere Stunden betragen und ein Test entsprechend nicht stundenlang blockieren darf, weshalb ein anderer Ansatz nötig ist, um dasselbe Verhalten zuverlässig und schnell zu prüfen.

Ein praktikabler Weg ist, die Session-Konfiguration in der Testumgebung gezielt auf einen sehr kurzen Wert von wenigen Sekunden herunterzusetzen, sodass der reale Ablauf innerhalb eines vertretbaren Testzeitfensters tatsächlich stattfindet, statt künstlich simuliert zu werden. Alternativ lässt sich das Session-Cookie im Test direkt manipulieren oder entfernen, um denselben abgelaufenen Zustand ohne tatsächliches Warten zu erzeugen, wobei diese zweite Variante zwar schneller, aber weniger realitätsnah ist, da sie nicht den echten serverseitigen Ablaufmechanismus durchläuft, sondern nur dessen Symptom nachbildet.

4. Zwei-Faktor-Authentifizierung automatisiert testen

Zwei-Faktor-Authentifizierung stellt E2E-Tests vor eine besondere Hürde, da der zweite Faktor typischerweise über einen externen Kanal wie SMS oder eine Authenticator-App ausgeliefert wird, auf den ein automatisierter Test naturgemäss keinen direkten Zugriff hat, weshalb ein direktes Nachbilden des realen Nutzerflusses ohne Zusatzaufwand kaum möglich ist.

In der Praxis hat sich bewährt, für Testzwecke einen deterministischen TOTP-Secret-Schlüssel fest im Testnutzer-Profil zu hinterlegen und den aktuell gültigen Einmalcode im Test selbst über dieselbe TOTP-Bibliothek zu berechnen, mit der auch echte Authenticator-Apps arbeiten, statt auf eine echte SMS oder Push-Benachrichtigung zu warten. Dieser Ansatz testet den tatsächlichen Verifizierungsmechanismus der Anwendung realistisch, ohne von einem externen, nicht kontrollierbaren Kommunikationskanal abhängig zu sein.

import { authenticator } from 'otplib';

test('Login mit 2FA akzeptiert gültigen TOTP-Code', async ({ page }) => {
  await loginAs(page, twoFactorTestUser);
  const code = authenticator.generate(twoFactorTestUser.totpSecret);
  await page.fill('[data-testid="totp-code"]', code);
  await page.click('[data-testid="totp-submit"]');
  await expect(page).toHaveURL(/customer\/account/);
});

5. Testnutzer-Verwaltung im Team ohne gegenseitige Kollisionen

Ein häufiger Fehler in wachsenden Testsuiten ist die Verwendung eines einzigen, fest geteilten Testnutzers für alle Login-Tests im gesamten Team, was zu unvorhersehbaren Kollisionen führt, sobald zwei parallel laufende Testläufe denselben Nutzer gleichzeitig verwenden, etwa wenn ein Testlauf gerade das Passwort dieses Nutzers ändert, während ein zweiter, parallel laufender Testlauf sich mit dem alten Passwort einzuloggen versucht.

Robuster ist die programmatische Erzeugung eines frischen, eindeutigen Testnutzers zu Beginn jedes einzelnen Testlaufs, etwa direkt über die Magento-REST-API statt über die langsamere UI, kombiniert mit einer zuverlässigen Aufräumroutine, die diesen Testnutzer nach Abschluss des Tests wieder entfernt. Dieser Ansatz vermeidet nicht nur Kollisionen zwischen parallelen Testläufen vollständig, sondern hält die Testdatenbank auch langfristig sauber, statt dass sich über Monate hinweg hunderte verwaiste Testkonten in der Produktions- oder Staging-Datenbank ansammeln.

6. Token-Handling in Tests ohne Secrets im Repository

Für API-gestützte Testvorbereitung, etwa das programmatische Anlegen eines Testnutzers über die REST-API vor dem eigentlichen UI-Test, wird ein Admin- oder Integrations-Token benötigt, das unter keinen Umständen direkt im Testcode oder in einer versionierten Konfigurationsdatei stehen sollte, da ein solches Token bei versehentlichem Einchecken dauerhaft in der Git-Historie verbleibt, selbst wenn es später aus dem aktuellen Dateistand wieder entfernt wird.

Der korrekte Ort für solche Zugangsdaten sind Umgebungsvariablen, die ausschliesslich zur Laufzeit der CI-Pipeline oder der lokalen Entwicklungsumgebung gesetzt werden, typischerweise über die Secret-Verwaltung der jeweiligen CI-Plattform, kombiniert mit einer klaren .gitignore-Regel für alle lokalen .env-Dateien, damit ein Token niemals versehentlich mit einem regulären Commit ins Repository gelangt.

Ebenso sollte das Testnutzer-Passwort selbst niemals als fester, wiederkehrender Wert im Quellcode auftauchen, sondern zur Laufzeit zufällig generiert und ausschliesslich innerhalb des Testlaufs verwendet werden, damit selbst ein versehentlich öffentlich einsehbarer Testreport keine tatsächlich wiederverwendbaren Zugangsdaten preisgibt, die sich gegen ein anderes System oder einen anderen Dienst missbrauchen liessen.

7. Passwort-Reset-Flow zuverlässig testen

Der Passwort-Reset-Flow gehört trotz seiner scheinbaren Einfachheit zu den am häufigsten übersehenen Testbereichen, obwohl er im echten Betrieb regelmässig genutzt wird und im Fehlerfall Kundinnen und Kunden dauerhaft aus ihrem eigenen Konto aussperren kann. Ein vollständiger Test deckt sowohl den Versand der Reset-Mail an eine bekannte E-Mail-Adresse als auch das bewusst unauffällige Verhalten bei einer unbekannten Adresse ab, da eine Anwendung aus Sicherheitsgründen nicht verraten sollte, ob eine bestimmte E-Mail-Adresse tatsächlich als Kundenkonto existiert.

Für die automatisierte Prüfung des tatsächlichen Reset-Links, der üblicherweise per E-Mail zugestellt wird, bietet sich ein lokal betriebener Mail-Catcher wie Mailhog oder Mailpit an, der ausgehende Test-Mails abfängt und über eine eigene API programmatisch auslesbar macht, statt auf ein echtes, öffentlich erreichbares Postfach angewiesen zu sein. Der Test extrahiert den in der Mail enthaltenen Reset-Token direkt aus dieser abgefangenen Nachricht, navigiert anschliessend zur entsprechenden Reset-Seite und prüft, dass ein neues Passwort erfolgreich gesetzt werden kann und der zuvor verwendete Token danach nicht erneut verwendbar ist.

8. Parallele Logins und Multi-Device-Sessions

Käuferinnen und Käufer sind heute häufig gleichzeitig auf mehreren Geräten eingeloggt, etwa im Browser am Desktop und zusätzlich in einer mobilen Ansicht auf dem Smartphone, weshalb ein realistischer Testfall prüfen sollte, dass ein Login auf einem zweiten Gerät nicht automatisch die Session auf dem ersten Gerät invalidiert, sofern die Anwendung mehrere gleichzeitige Sessions bewusst unterstützen soll.

Für Anwendungen, die aus Sicherheitsgründen bewusst nur eine einzige aktive Session pro Nutzerkonto erlauben, gilt das Gegenteil: Ein Test sollte in diesem Fall gezielt prüfen, dass ein neuer Login auf einem zweiten Gerät die vorherige Session tatsächlich zuverlässig beendet, statt dass beide Sessions parallel und unbemerkt gültig bleiben, was ein Sicherheitsrisiko darstellen würde, falls das erste Gerät zwischenzeitlich verloren gegangen oder gestohlen worden ist.

9. Authentifizierungs-Testfälle im Überblick

Die folgende Tabelle fasst die vorgestellten Testfälle rund um Authentifizierung zusammen.

10. Zusammenfassung

11. FAQ: Auth-Flow-Tests: Das Wichtigste auf einen Blick