Testfälle für die Anmeldeseite: Die vollständige Checkliste

Im Folgenden erhalten Sie 80 Testfälle für die Anmeldeseite-Validierung in einer Tabelle mit IDs, erwarteten Ergebnissen und Prioritäten, die Sie direkt in Ihr Test-Management-Tool einfügen können. Nach der Checkliste werden Sie sich mit den Kategorien befassen, bei denen das erwartete Ergebnis einer Erklärung bedarf, von Session-Sicherheit über WebAuthn, PKCE bis hin zur Kontowiederherstellung.

Ein solider Login-Testfall benennt ein Szenario, gibt seine Vorbedingungen und Daten an und definiert ein Ergebnis, das Ihr Team auf Client und Server verifizieren kann.

Ein Szenario pro Fall hält Ihre Fehler diagnostizierbar, denn wenn ein Durchlauf fehlschlägt, sagt die ID allein Ihrem Team, welches Verhalten defekt ist. Jeder, der lernen möchte, wie man Testfälle für die Anmeldeseite erstellt, sollte von dieser Struktur ausgehen, und unser Leitfaden zum Erstellen von Testfällen behandelt das Format vollständig.

Hier ist die vollständige Checkliste, gruppiert nach Kategorien und geordnet nach der Reihenfolge, in der Ihr Team sie ausführen würde. Diese Beispiele für Testfälle für die Anmeldeseite kombinieren positive und negative Szenarien mit Prioritäten, die ein kundenorientiertes Produkt mit Passwort-Login, MFA und mindestens einer föderierten Option voraussetzen.

Kopieren Sie die Tabelle in Ihr Tool, löschen Sie die Zeilen für Funktionen, die Sie nicht ausliefern, und arbeiten Sie dann die folgenden Abschnitte für die Kategorien durch, bei denen das erwartete Ergebnis Kontext benötigt.

Zwei funktionale Bereiche produzieren die meisten Vorfälle, die Ihre Produktionsumgebung erreichen.

• Return-URL-Handhabung teilt sich in zwei Fälle auf. LOGIN-002 bestätigt, dass Ihr Benutzer auf der ursprünglich angeforderten internen Seite landet, während LOGIN-003 bestätigt, dass eine manipulierte oder externe URL abgelehnt wird. Da dies unterschiedliche Fehler mit unterschiedlichen Fixes sind, bleiben sie getrennt.
• Nebenläufigkeit. Ein doppelt geklickter Submit-Button in LOGIN-004 und eine Zurück-Taste nach Logout in LOGIN-005 erzeugen beide Zustände, die ein einzelner geskripteter Durchlauf nie erreicht, aber Ihre Benutzer treffen täglich darauf.

Formularverhalten verdient seine eigene Kategorie, da diese Defekte jeden Ihrer Benutzer erreichen, während sie auf dem Server nichts kaputt machen.

• Passwort-Manager Autofill, LOGIN-010. Skripte, die Autofill blockieren, treiben Menschen zu Passwörtern, die sie aus dem Gedächtnis eingeben können, welche per Definition schwächer sind.
• Fokusplatzierung nach einem Fehler, LOGIN-012. Tastatur- und Screenreader-Nutzer benötigen den Fokus auf dem fehlgeschlagenen Feld, damit sie einen Tippfehler korrigieren können, ohne danach suchen zu müssen.
• Button-Status, LOGIN-011. Wenn Ihr Formular während der Übermittlung keinen deaktivierten Zustand hat, erhalten Sie die doppelten Anfragen, die von LOGIN-004 abgedeckt werden.

Diese möglichen Testfälle für die Anmeldeseite-Härtung beweisen, dass fehlerhafte Eingabe auf Ihrem Server sicher fehlschlägt und nicht nur im Browser.

• Das Entfernen von maxlength in Dev-Tools dauert zehn Sekunden, daher ist jedes Limit, das Ihre UI allein erzwingt, dekorativ.
• Injection-Fälle gehören in eine dedizierte Sicherheits-Suite, getrennt von Ihren Login-Smoke-Tests, da die Vermischung beider beide schwerer wartbar macht.
• Validierungstext lässt Status durchsickern. Eine Nachricht, die ein ungültiges Benutzernamenformat während eines falschen Passwortversuchs markiert, bestätigt einem Angreifer, dass das Konto existiert.

KI-generiertes Bild.

Enumeration sickert durch vier Kanäle durch, daher vergleicht Ihr Team alle nebeneinander.

• Fehlertext. OWASP empfiehlt eine generische Nachricht, die unbekannte Benutzer, falsche Passwörter und deaktivierte Konten abdeckt.
• HTTP-Statuscodes. Ein 404 für fehlende Benutzer gegen 401 für falsche Passwörter ist Enumeration eine Ebene tiefer.
• Antwortzeit. Eine sofortige Ablehnung für einen unbekannten Benutzer gegen 200 ms für eine echte Passwortprüfung wird über Tausende von Versuchen messbar.
• Weiterleitungsverhalten. Unterschiedliche Ziele oder Antwortgrößen geben dieselbe Information preis.

Zeichnen Sie die sichtbare Nachricht neben der rohen Netzwerkantwort für jeden Kontostatus auf und wiederholen Sie dann jeden Durchlauf, um Netzwerkrauschen auszumitteln. Da identisches Timing in der Praxis unmöglich ist, zielt LOGIN-029 auf die Abwesenheit eines konsistenten, ausnutzbaren Unterschieds ab.

Diese drei Muster lösen unterschiedliche Verteidigungen aus, daher benötigen sie separate Fälle gegen kontrollierte Konten in einer dedizierten Umgebung.

OWASP warnt, dass rein IP-basierte Kontrollen bei verteilten Angriffen versagen, was genau LOGIN-033 für Sie misst. LOGIN-031 deckt dann das entgegengesetzte Risiko ab: Wenn fünf falsche Passwörter jedes Konto für eine Stunde sperren, kann ein Skript und eine Liste von E-Mail-Adressen Ihre gesamte Nutzerbasis aussperren.

Session Fixation gelingt, wenn der Identifikator die Authentifizierung überlebt, daher zeichnet LOGIN-035 Ihre anonyme Session-ID auf und vergleicht sie nach dem Login. Unter allen Testfällen für die Anmeldeseite im Software-Testing erfasst dieses Cluster die Defekte, die statische Reviews am häufigsten übersehen.

Transport-Fälle bleiben im Vergleich einfach: Öffnen Sie Ihre Anmeldeseite über HTTP, senden Sie das Formular über HTTP ab, schreiben Sie die Formularaktion um und bestätigen Sie, dass Anmeldedaten nie in Query-Parametern erscheinen, da URLs in Browser-Historie, Server-Logs und Analytics-Pipelines landen.

Ein funktionierender Login-Screen sagt nichts über die Ressourcen dahinter aus, da Web-Interfaces routinemäßig anonyme Benutzer weiterleiten, während die zugrunde liegende API auf unauthentifizierte Anfragen antwortet. Fordern Sie /account, /admin und jede API-Route an, die Ihr Frontend ohne Session überhaupt aufruft, und wiederholen Sie dann den Durchlauf mit bearbeitetem client-seitigen Status wie isLoggedIn im Local Storage oder einem modifizierten Rollenparameter.

Replay-Schutz hat eine veröffentlichte Anforderung dahinter: OWASP ASVS 5.0 besagt, dass Lookup Secrets, Out-of-Band-Codes und TOTPs erfolgreich nur einmal verwendbar sind.

• LOGIN-046. Authentifizieren Sie mit einem Code und wiederholen Sie dann sofort denselben Wert vor Ablauf. Erfolg bei diesem zweiten Versuch ist ein Defekt mit angehängter Standardreferenz.
• LOGIN-050. Unsere Experten raten, die MFA-Entfernung mit denselben Identitätsprüfungen zu testen, die Ihr Enrollment erforderte, da ein per E-Mail versandter Link ohne Verifizierung Ihren zweiten Faktor jedem übergibt, der die Mailbox besitzt.
• Methoden-Downgrade. Der Wechsel von einem Hardware-Key zu SMS sollte Autorisierung erfordern, da Angreifer immer den schwächsten Faktor angreifen, den Sie zulassen.

Ihre sicherheitsrelevanten Passkey-Fälle liegen in der Zeremonie selbst, wo der Server die Challenge, den Origin und die Signatur verifiziert.

• Niemals den Callback mocken. Frontend-Automatisierung, die eine erfolgreiche WebAuthn-Antwort vortäuscht, beweist nichts, da LOGIN-051 bis LOGIN-055 alle serverseitige Validierung bestätigen.
• Conditional UI. Wenn Ihr Formular Passkeys inline mit dem Passwortfeld anbietet, bestätigen Sie, dass es verfügbare Credentials erkennt, sauber degradiert, wenn das Gerät nicht erreichbar ist, und niemals Passworteingabe blockiert.
• Sessions bleiben identisch. Jeder Fall von LOGIN-035 bis LOGIN-040 gilt für Ihre Passkey-Logins unverändert.

Magic Links verschieben die Sicherheitsgrenze zum E-Mail-Kanal und zum Token, behandeln Sie daher jeden Link als Einmal-Credential mit Ablauf.

Token-Ausstellung benötigt ebenfalls eine dokumentierte Policy, die Ihr Fall bestätigen kann. Wenn Ihr Benutzer einen zweiten Link anfordert, während der erste noch gültig ist, stirbt entweder das alte Token sofort oder beide bleiben bis zum Ablauf verwendbar, und LOGIN-057 bis LOGIN-060 verifizieren welches Verhalten auch immer Ihr Produkt verspricht.

Ein „Mit Google fortfahren“-Button verschiebt die Credential-Handhabung zu einem Identity Provider, während die Session-Sicherheit bei Ihrer App verbleibt, sodass die Protokollfehler nie in reinen Browser-Tests erscheinen.

• State, Nonce und PKCE. LOGIN-062 deckt CSRF-Schutz beim Callback ab, LOGIN-064 lehnt eine ungültige oder wiederverwendete OIDC-Nonce ab, und LOGIN-065 lässt den Token-Exchange fehlschlagen, wenn der PKCE code_verifier nicht mit der ursprünglichen Challenge übereinstimmt.
• Code-Replay. LOGIN-063 übermittelt denselben Authorization-Code zweimal, was Ihr Token-Endpunkt ablehnen muss.
• Striktes Redirect-URI-Matching. Lockeres Matching hinterlässt Ihnen eine offene Weiterleitung, die auf Traffic wartet.
• SAML-Attribut-Mapping. Bereitgestellte Konten benötigen korrekte Gruppen- und Rollen-Claims sowie definiertes Verhalten, wenn die Provider-Session vor Ihrer abläuft.
• Föderierter Logout. Nicht übereinstimmende Erwartungen hier generieren Support-Tickets, die Ihr Team danach monatelang beantwortet.

Diese Fälle unterstützen WCAG 2.2 AA-Konformität und können auch von Barrierefreiheitsregeln gefordert werden, die für Ihr Produkt gelten, einschließlich Accessible Authentication (Minimum).

• W3C dokumentiert blockiertes Einfügen als Fehler F109, daher versagt ein Passwortfeld, das manuelle Eingabe erzwingt, es sei denn, Sie bieten eine barrierefreie Alternative an. Geteilte OTP-Boxen schaffen dieselbe Barriere, wenn ein eingefügter Code nur das erste Feld ausfüllt.
• Automatisierte Scanner erkennen fehlende Labels und defekte ARIA-Attribute, obwohl sie nicht bestätigen können, was ein Screenreader tatsächlich ansagt. Manuelle Durchläufe mit NVDA, JAWS oder VoiceOver bleiben daher in Ihrem Umfang.
• Einfache Sprache gilt auch für Ihren Fehlertext. „Falscher Benutzername oder Passwort“ dient allen, während „Authentifizierung aufgrund ungültiger Anmeldedaten, die während des Login-Versuchs bereitgestellt wurden, fehlgeschlagen“ niemandem dient.

Führen Sie diese in einer kontrollierten Umgebung mit dedizierten Konten aus, da ein Lasttest gegen die Produktion Ihr eigenes Rate Limiting auslöst und jede Zahl, die Sie sammeln, verzerrt.

• Authentifizierungslatenz im Median und 95. Perzentil, plus Ihre Fehlerrate während eines Traffic-Spikes.
• Identity-Provider-Antwortzeit, MFA-Lieferlatenz und Session-Store-Durchsatz unter gleichzeitigen Logins.
• Fehlerverhalten: Eine langsame Kontodatenbank läuft mit klarer Nachricht ab, ein MFA-Provider-Ausfall lässt Ihre Backup-Codes verwendbar, und eine abgebrochene Verbindung erscheint Ihrem Benutzer nie als „falsches Passwort“.

Weisen Sie jeden Fall der günstigsten Ebene zu, die ihn beweisen kann, da das Ausführen von 80 Szenarien durch einen Browser langsam und spröde ist.

Eine Änderung spart Ihrem Team mehr Zeit als jede andere: Hören Sie auf, sich vor jedem Test durch die UI einzuloggen. Erstellen Sie stattdessen authentifizierten Status durch API-Aufrufe oder wiederverwendbare Fixtures, behalten Sie eine kleine Suite bei, die Ihr Login-Interface selbst ausübt, und lassen Sie alles andere von einer authentifizierten Session aus starten. Das Dokumentieren von 80 Fällen von Hand kostet Tage, weshalb ein KI-Testfall-Generator, der von Ihren eigenen Anforderungen ausgeht, Teil des Workflows geworden ist.

KI-generiertes Bild.

Fünf Cluster tragen den höchsten Schaden, wenn sie bei Ihnen fehlschlagen.

• LOGIN-027 bis LOGIN-029. Ein einzelner Unterschied in Text, Status oder Timing übergibt Angreifern Ihre Benutzerliste.
• LOGIN-043. Ein funktionierender Login-Screen und ein offener API-Endpunkt koexistieren weit häufiger, als Ihr Team erwartet.
• LOGIN-035 und LOGIN-037. Ohne ID-Rotation und serverseitigen Logout bleiben platzierte oder gestohlene Sessions gültig.
• LOGIN-030 und LOGIN-031. Nachweis, dass Brute Force gestoppt wird, während Ihre legitimen Benutzer nicht gesperrt bleiben.
• LOGIN-010 und LOGIN-074. Authentifizierung blockiert nicht Passwort-Manager oder Copy-Paste ohne Bereitstellung einer barrierefreien Alternative.

LOGIN-013: Ungültiges Passwort

• Szenario: Registrierter Benutzer gibt falsches Passwort ein
• Vorbedingungen: Aktives Konto, korrekter Benutzername, Passwort WrongPass999!
• Schritte: Anmeldeseite öffnen → Benutzername eingeben → falsches Passwort eingeben → absenden
• Erwartetes Ergebnis: Generischer „Ungültige Anmeldedaten“-Fehler, kein Session-Cookie, Fehlerzähler erhöht sich, Antworttext und HTTP-Status identisch zu unbekanntem-Benutzer-Versuch
• Priorität: Kritisch

LOGIN-030: Throttling-Schwellenwert

• Szenario: Rate Limiting greift bei konfigurierter Anzahl von Fehlern
• Vorbedingungen: Aktives Konto, Policy auf 5 Versuche gesetzt
• Schritte: Fünfmal ein falsches Passwort eingeben → korrektes Passwort eingeben → Cooldown abwarten → korrektes Passwort erneut eingeben
• Erwartetes Ergebnis: Throttling greift bei Versuch 5, korrektes Passwort während Cooldown gemäß Policy behandelt, Zugang danach wiederhergestellt, Zähler bei Erfolg zurückgesetzt
• Priorität: Kritisch

Halten Sie Ihre erwarteten Ergebnisse so spezifisch, denn ein Fall mit der Lesart „Verifizieren Sie gesperrtes Kontoverhalten“ ohne Schwellenwertdaten lässt jeden stocken, der ihn erbt. Weitere Formate finden Sie in unserer Testfall-Template-Sammlung.

Die Abdeckung skaliert mit den Authentifizierungsmethoden, die ein Produkt ausliefert, daher hängt die Gesamtzahl von seiner Architektur und regulatorischen Exposition ab. Ein reines Passwort-Formular ohne Federation erfordert etwa 40 Fälle. Das Hinzufügen von MFA, SSO, Passkeys und Magic Links bringt die Suite auf alle 80 in der obigen Checkliste.

Diese Zahlen sind Planungsschätzungen und keine Quote. Fünfzig oberflächliche Fälle, die bestätigen, dass ein Login-Button rendert, werden einen Session-Fixation-Defekt übersehen, während die sechs Session-Fälle in dieser Checkliste ihn beim ersten Durchlauf erkennen.

Drei Faktoren passen die Gesamtzahl an. Produkte in Zahlungen oder Gesundheitswesen fügen dokumentierte Nachweise für SOC 2 oder PCI DSS hinzu, was sowohl die Fallzahl als auch die Rückverfolgbarkeit erhöht, die Prüfer erwarten. Das Verknüpfen dieser Nachweise mit Anforderungen innerhalb von aqua cloud verhindert das Neuerstellen des Papier-Trails in jedem Zyklus. Testfälle für Registrierungsseiten-Flows gehören zu einer separaten Suite und bleiben außerhalb dieser Zählung. Nicht unterstützte Fähigkeiten wie SAML-Bereitstellung oder Hardware-Keys kommen vollständig aus der Tabelle heraus, da Abdeckung unerreichbarer Szenarien nichts demonstriert.

Authentifizierung ist die eine Komponente, auf die jeder Benutzer trifft, und das erste Ziel von automatisiertem Traffic. Die 15 kritischen Zeilen in der Checkliste decken Enumeration, Session-Rotation, Throttling und Bypass ab, was sie zum ersten Sprint macht. Sechs bis acht UI-Fälle genügen für das Formular selbst, während Kontostatus und Cookie-Assertions auf API- und Protokollebene schneller laufen. Jede architektonische Änderung erweitert die Liste: Passkeys fügen LOGIN-051 bis LOGIN-056 hinzu, OIDC fügt die Nonce- und PKCE-Fälle hinzu, und jeder Audit-Zyklus konvertiert diese erwarteten Ergebnisse in Nachweise.