Testfälle für die Anmeldeseite: Die vollständige Checkliste
Anmeldeseiten verzeichnen mehr Traffic als jeder andere Screen in einem digitalen Produkt, und diese Gateways sind oft das erste Ziel, das Angreifer untersuchen. Die meisten Test-Suiten verifizieren Anmeldedaten und Passwörter, mit einigen ergänzenden Prüfungen, die auf Datenschutz- und Cybersecurity-Vorschriften beschränkt sind. Andere Defekte erreichen die Produktion, wenn sie nicht getestet werden, daher sollte eine umfassende Liste von Testfällen für die Anmeldeseite geschrieben und ausgeführt werden, um jedes mögliche Szenario abzudecken.
Ihre Anmeldeseite ist Brute-Force-, Credential-Stuffing-, Session-Hijacking- und User-Enumeration-Angriffen ausgesetzt und benötigt daher eine tiefere Abdeckung als jeder andere Screen in Ihrem Produkt.
Generische Fehler wie „Ungültige Anmeldedaten“ verhindern User Enumeration, während Meldungen wie „Konto existiert nicht“ Angreifern kostenlos gültige Benutzernamen bestätigen.
Rate Limiting muss nach wiederholten Fehlversuchen greifen und dennoch das korrekte Passwort akzeptieren, sonst können Angreifer Ihre legitimen Benutzer absichtlich aussperren.
Session-Identifikatoren müssen sich nach der Authentifizierung ändern. Eine wiederverwendete Session-ID ermöglicht es einem Angreifer, eine Session vorab festzulegen, auf den Login Ihres Benutzers zu warten und sie dann zu kapern.
OWASP ASVS 5.0 verlangt, dass Einmalcodes nur einmal funktionieren, sodass die Wiederverwendung eines abgefangenen OTP innerhalb seines Gültigkeitsfensters als fehlgeschlagener Test gilt.
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.
Was macht einen soliden Login-Testfall aus?
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.
Element
Was es enthält
Login-Beispiel
ID
Stabiler Identifikator für Rückverfolgbarkeit
LOGIN-018
Szenario
Ein zu testendes Verhalten
Login-Versuch bei einem gesperrten Konto
Vorbedingungen
Erforderlicher Zustand vor Schritt 1
Konto nach 5 Fehlversuchen gesperrt
Testdaten
Exakte verwendete Werte
qa.locked@example.com / ValidPass123!
Schritte
Reproduzierbare Aktionen
Anmeldeseite öffnen, Daten eingeben, absenden
Erwartetes Ergebnis
Client- und Server-Ergebnis
Generischer Fehler angezeigt, kein Session-Cookie ausgegeben, Versuch protokolliert
Priorität
Sicherheits- und Business-Impact
Hoch
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.
Ihr Team muss möglicherweise Stunden damit verbringen, alle notwendigen Login-Fälle manuell zu dokumentieren, und dann ist noch mehr Zeit erforderlich, um jeden davon auf eine Anforderung zurückzuführen. aqua cloud, eine KI-gesteuerte Test- und Anforderungsmanagement-Plattform, verfügt über AI Intelligence, die die gesamte Authentifizierungs-Suite aus Ihren vorhandenen Anforderungen in Sekunden generieren kann. Da das domänengeschulte Modell auf Ihre eigene Projektdokumentation trainiert werden kann, passt jeder Fall zu Ihrer Architektur und Terminologie. Credential-Checks und WebAuthn-Szenarien befinden sich in einem Workspace, rückverfolgbar von der Anforderung bis zur Ausführung. Ihr Team erreicht 100% Abdeckung seiner Authentifizierungspfade und kann dies während der Review nachweisen. Wiederverwendbare verschachtelte Fälle halten gemeinsame Login-Schritte konsistent, sodass eine einzelne Bearbeitung sich überall gleichzeitig ausbreitet. Tester in Ihrem Team sparen bis zu 12 Stunden pro Woche. Synchronisieren Sie mit Jira in beide Richtungen und lösen Sie Durchläufe von Jenkins oder Azure DevOps aus. Verbinden Sie Ihre Security-Tools über die REST API und zeichnen Sie dann jede Ausführung als Video und Screenshots mit der kostenlosen Capture-Erweiterung auf.
Sparen Sie 12,8 Stunden pro Test pro Woche mit aquas KI-gesteuerten QA-Fähigkeiten
80 Testfälle für die Anmeldeseite: Die vollständige Checkliste
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.
ID
Kategorie
Testfall
Erwartetes Ergebnis
Priorität
LOGIN-001
Funktional
Gültige Anmeldedaten bei einem aktiven Konto
Session erstellt, Benutzer erreicht das Ziel
Kritisch
LOGIN-002
Funktional
Login nach Anforderung einer geschützten internen URL
Benutzer kehrt zur ursprünglich angeforderten Seite zurück
Hoch
LOGIN-003
Funktional
Return-URL manipuliert zu einer externen Domain
Weiterleitung verweigert, Benutzer bleibt auf Ihrer Domain
Kritisch
LOGIN-004
Funktional
Formular zweimal in schneller Folge abgesendet
Einzelne Session erstellt
Mittel
LOGIN-005
Funktional
Zurück-Taste nach Logout gedrückt
Geschützte Seite nicht aus Cache wiederhergestellt
Hoch
LOGIN-006
UI
Passwortfeld beim Seitenladen
Wert standardmäßig maskiert
Hoch
LOGIN-007
UI
Passwort ein-/ausblenden Umschalter
Wert auf Abruf angezeigt und verborgen
Mittel
LOGIN-008
UI
Enter-Taste im Passwortfeld gedrückt
Formular wird abgesendet, als ob Button geklickt wurde
Mittel
LOGIN-009
UI
Tab-Reihenfolge über Felder, Links und Button
Fokus folgt einer logischen Reihenfolge
Hoch
LOGIN-010
UI
Passwort-Manager Autofill
Beide Felder werden ausgefüllt, kein Skript blockiert das Ausfüllen
Kritisch
LOGIN-011
UI
Button-Status während Absendung
Button deaktiviert, Ladezustand sichtbar
Mittel
LOGIN-012
UI
Fokusplatzierung nach Validierungsfehler
Fokus bewegt sich zum fehlgeschlagenen Feld
Hoch
LOGIN-013
Negativ
Falsches Passwort, existierender Benutzer
Generische Ablehnung, keine Session, Zähler erhöht sich
Kritisch
LOGIN-014
Negativ
Unbekannter Benutzername
Antworttext und Status identisch zu LOGIN-013
Kritisch
LOGIN-015
Negativ
Leeres Benutzernamen-Feld
Feldvalidierung wird ausgelöst, keine Anfrage gesendet
Mittel
LOGIN-016
Negativ
Leeres Passwort-Feld
Feldvalidierung wird ausgelöst
Mittel
LOGIN-017
Negativ
Deaktiviertes Konto mit korrektem Passwort
Generische Ablehnung, kein State-Leak
Hoch
LOGIN-018
Negativ
Gesperrtes Konto mit korrektem Passwort
Policy-definierte Antwort, keine Session
Hoch
LOGIN-019
Negativ
Gelöschtes Konto
Antwort identisch zu unbekanntem Benutzer
Hoch
LOGIN-020
Negativ
Konto wartet auf E-Mail-Bestätigung
Bestätigungsaufforderung, kein geschützter Zugang
Hoch
LOGIN-021
Validierung
Maximale Länge von Benutzername und Passwort
Server erzwingt dokumentiertes Limit
Hoch
LOGIN-022
Validierung
maxlength in Browser-Dev-Tools entfernt
Server lehnt übergroße Eingabe ab
Hoch
LOGIN-023
Validierung
Führende und nachfolgende Leerzeichen in Anmeldedaten
Trimming-Policy konsistent angewendet
Mittel
LOGIN-024
Validierung
Nicht-lateinische Zeichen, z.B. Kyrillisch oder Arabisch
Gültige Benutzer authentifizieren, Kodierung hält
Mittel
LOGIN-025
Validierung
SQL-Syntax im Benutzernamen-Feld
Generischer Fehler, keine Datenbank-Fehlermeldung angezeigt
Kritisch
LOGIN-026
Validierung
Script-Payload im Benutzernamen-Feld
Payload als Text gerendert, nie ausgeführt
Kritisch
LOGIN-027
Enumeration
Fehlertext über alle Fehlertypen
Eine generische Nachricht für alle
Kritisch
LOGIN-028
Enumeration
HTTP-Statuscodes über Fehlertypen
Identischer Status für unbekannten Benutzer und falsches Passwort
Hoch
LOGIN-029
Enumeration
Antwortzeit über Fehlertypen
Kein konsistenter, ausnutzbarer Unterschied bei wiederholter kontrollierter Messung
Hoch
LOGIN-030
Missbrauch
Aufeinanderfolgende ungültige Passwörter bei einem Konto
Throttling greift beim dokumentierten Versuch
Kritisch
LOGIN-031
Missbrauch
Korrektes Passwort während Throttling eingereicht
Zugang gemäß Policy gewährt, z.B. nach Step-up-Check
Hoch
LOGIN-032
Missbrauch
Ein häufiges Passwort über Konten gesprayed
Kontoübergreifende Erkennung wird ausgelöst
Hoch
LOGIN-033
Missbrauch
Versuche von rotierenden Quell-IPs
Kontrollen halten über IP-basierte Limits hinaus
Hoch
LOGIN-034
Missbrauch
Throttling bei OTP- und Recovery-Endpunkten
Gleiche Limits wie Login-Formular
Hoch
LOGIN-035
Session
Session-ID vor und nach Login aufgezeichnet
Identifikator bei Authentifizierung rotiert
Kritisch
LOGIN-036
Session
Session-Cookie-Attribute
Secure, HttpOnly, explizites SameSite
Kritisch
LOGIN-037
Session
Logout-Anfrage
Session serverseitig invalidiert
Kritisch
LOGIN-038
Session
Idle- und absolute Timeout
Session läuft gemäß Policy ab
Hoch
LOGIN-039
Session
Passwortänderung mit anderen aktiven Sessions
Andere Sessions beendet
Hoch
LOGIN-040
Session
Konto während aktiver Session deaktiviert
Session bei nächster Anfrage abgeschnitten
Hoch
LOGIN-041
Transport
Anmeldeseite und Formular über HTTP geladen
Weiterleitung zu HTTPS, keine Anmeldedaten im Klartext
Kritisch
LOGIN-042
Transport
Anmeldedaten in Query-Parametern
Nie in URL, Historie oder Logs vorhanden
Kritisch
LOGIN-043
Bypass
Geschützte Seite und API-Route ohne Session
Anfrage serverseitig abgelehnt
Kritisch
LOGIN-044
Bypass
Client-seitige Flags bearbeitet, z.B. isLoggedIn
Keine Auswirkung auf Zugang
Kritisch
LOGIN-045
MFA
Korrektes OTP nach gültigem Passwort
Vollständige Session gewährt
Kritisch
LOGIN-046
MFA
Gleiches OTP innerhalb seines Gültigkeitsfensters wiederverwendet
Zweite Verwendung abgelehnt
Kritisch
LOGIN-047
MFA
Abgelaufenes OTP
Abgelehnt mit Neuausstellungsoption
Hoch
LOGIN-048
MFA
Anfrage so erstellt, dass MFA-Schritt übersprungen wird
Serverseitig abgelehnt
Kritisch
LOGIN-049
MFA
Backup-Code zweimal verwendet
Zweite Verwendung abgelehnt
Hoch
LOGIN-050
MFA
MFA-Entfernung über Recovery-Flow
Verifizierung entspricht Enrollment-Standard
Kritisch
LOGIN-051
Passkey
Wiederholte WebAuthn-Challenge
Assertion abgelehnt
Kritisch
LOGIN-052
Passkey
Abgelaufene oder veraltete Challenge
Assertion abgelehnt
Kritisch
LOGIN-053
Passkey
Falsche RP-ID oder nicht übereinstimmender Origin
Assertion abgelehnt
Kritisch
LOGIN-054
Passkey
Geänderte Credential-ID in der Antwort
Signaturverifizierung schlägt fehl
Kritisch
LOGIN-055
Passkey
Benutzerverifizierung erforderlich, aber nicht vorhanden
Authentifizierung verweigert
Hoch
LOGIN-056
Passkey
Widerrufene Credential beim Login präsentiert
Abgelehnt, Widerruf respektiert
Hoch
LOGIN-057
Passwordless
Gültiger Magic Link einmal geöffnet
Session erstellt, Link verbraucht
Hoch
LOGIN-058
Passwordless
Magic Link nach Ablauf geöffnet
Abgelehnt mit Neuausstellungsoption
Hoch
LOGIN-059
Passwordless
Magic Link nach erfolgreichem Login wiederverwendet
Abgelehnt
Kritisch
LOGIN-060
Passwordless
Gekürzter oder veränderter Link-Token
Abgelehnt, keine teilweise Übereinstimmung akzeptiert
Kritisch
LOGIN-061
SSO
Erfolgreicher Identity-Provider-Callback
Session erst nach vollständiger Validierung erstellt
Kritisch
LOGIN-062
SSO
Fehlender oder ungültiger State-Token
Callback abgelehnt
Kritisch
LOGIN-063
SSO
Authorization-Code zweimal übermittelt
Zweiter Versuch abgelehnt
Kritisch
LOGIN-064
SSO
Ungültige oder wiederverwendete OIDC-Nonce
Callback abgelehnt
Kritisch
LOGIN-065
SSO
Falscher PKCE code_verifier beim Token-Exchange
Token-Exchange abgelehnt
Kritisch
LOGIN-066
SSO
Modifizierte Redirect-URI
Striktes Matching lehnt Anfrage ab
Kritisch
LOGIN-067
SSO
Provider-Konto nach Verknüpfung deaktiviert
Zugang beim nächsten Login verweigert
Hoch
LOGIN-068
Recovery
Reset für unbekannte vs. existierende E-Mail angefordert
Identische Antwort und Timing
Kritisch
LOGIN-069
Recovery
Reset-Token ein zweites Mal verwendet
Abgelehnt
Kritisch
LOGIN-070
Recovery
Reset-Token nach seinem Ablaufzeitfenster präsentiert
Abgelehnt
Hoch
LOGIN-071
Recovery
Reset-Link bearbeitet, um auf anderes Konto zu zielen
Abgelehnt
Kritisch
LOGIN-072
Recovery
Altes Passwort nach abgeschlossenem Reset
Abgelehnt
Hoch
LOGIN-073
Barrierefreiheit
Vollständiger Login-Flow nur mit Tastatur
Flow abgeschlossen, Fokusindikator sichtbar
Kritisch
LOGIN-074
Barrierefreiheit
Einfügen in Passwort- und OTP-Felder
Einfügen erlaubt oder barrierefreie Alternative angeboten
Kritisch
LOGIN-075
Barrierefreiheit
Vollständiges OTP in geteilte Eingabefelder eingefügt
Jedes Feld wird durch ein Einfügen ausgefüllt
Hoch
LOGIN-076
Barrierefreiheit
Validierungsfehler mit aktivem Screenreader
Fehler angesagt und mit seinem Feld verknüpft
Hoch
LOGIN-077
Barrierefreiheit
200% Zoom auf einem 320-px-Viewport
Layout hält, Steuerelemente bleiben erreichbar
Mittel
LOGIN-078
Performance
Gleichzeitige Logins bei Spitzenlast
Latenz und Fehlerrate innerhalb des Ziels
Hoch
LOGIN-079
Zuverlässigkeit
Identity Provider stockt mitten im Flow
Definiertes Timeout, klare Fehlerseite
Hoch
LOGIN-080
Zuverlässigkeit
Netzwerk bricht während Übermittlung ab
Verbindungsfehler korrekt gemeldet
Mittel
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.
Funktionale Kern-Testfälle für die Anmeldeseite
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.
Als wir ein Login-Skript schrieben, hatten wir wahrscheinlich 10-15 Testfälle. Könnten wahrscheinlich 40-50 erreichen, je nach App.
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.
Eingabevalidierungs-Testfälle: Wo Angreifer Ihre Annahmen prüfen
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.
Testen falscher Anmeldedaten ohne Angreifern zu helfen
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.
Brute-Force-, Password-Spraying- und Credential-Stuffing-Testfälle
Diese drei Muster lösen unterschiedliche Verteidigungen aus, daher benötigen sie separate Fälle gegen kontrollierte Konten in einer dedizierten Umgebung.
Angriffsmuster
Wie es sich verhält
Was Ihr Test beweist
Brute Force
Viele Passwörter gegen ein Konto
Pro-Konto-Throttling greift beim dokumentierten Schwellenwert
Password Spraying
Ein häufiges Passwort über viele Konten
Erkennung funktioniert kontoübergreifend, nicht nur pro Konto
Credential Stuffing
Geleakte Benutzername- und Passwort-Paare
Anomalie-Erkennung oder Step-up-Verifizierung wird ausgelöst
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- und Transport-Sicherheits-Testfälle
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.
Attribut
Erwarteter Wert
Warum die Assertion existiert
Secure
Gesetzt
Cookie reist nie über reines HTTP
HttpOnly
Gesetzt
Client-seitige Skripte können das Session-Token nicht lesen
SameSite
Explizites Lax oder Strict
Browser-Defaults haben sich im Laufe der Zeit verschoben und variieren noch immer
Ablauf
Entspricht Session-Policy
Idle- und absolute Timeouts verhalten sich wie dokumentiert
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.
Authentifizierungs-Bypass-Testfälle
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.
Multi-Faktor-Authentifizierungs-Testfälle
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.
Passkey- und WebAuthn-Testfälle
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-Link- und Passwordless-Testfälle
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.
Social-Login- und SSO-Testfälle
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.
Barrierefreiheits-Testfälle für Anmeldeseiten
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.
Performance- und Zuverlässigkeits-Testfälle
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“.
Wie man Testfälle für die Anmeldeseite über Automatisierungsebenen aufteilt
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.
Cookie-Attribute, Statuscodes, Bypass-Versuche, Token-Replay, PKCE- und WebAuthn-Validierung
30–35 Fälle
Barrierefreiheit
Automatisierte Scans plus manuelle Assistenztechnologie-Durchläufe
5 Fälle plus manuelle Durchgänge
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.
Welche Testfälle für die Anmeldeseite können Sie nicht überspringen?
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.
Beispiele für Testfälle für die Anmeldeseite, die Sie kopieren können
LOGIN-013: Ungültiges Passwort
Szenario: Registrierter Benutzer gibt falsches Passwort ein
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.
Persönlich gehe ich mit: Erwartetes Ergebnis - Aktion - Parameter / Bedingungen. "Falsche Benutzername/Passwort-Aufforderung" - "Einloggen" - "Ungültiges Passwort". Denke, es ist üblich, eine umgekehrte Reihenfolge zu verwenden, da das im Grunde die Given-When-Then-Struktur für einige Sachen wäre, aber mein Gehirn ist einfach.
Wie viele Testfälle werden für Anmeldeseiten-Tests benötigt?
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.
Ausgelieferte Fähigkeit
Fälle, die sie hinzufügt
Laufende Summe
Passwort-Login, funktional und negativ
20
20
UI-Verhalten und Eingabevalidierung
12
32
Enumeration, Throttling, Session, Transport
18
50
MFA mit OTP und Backup-Codes
6
56
Passkeys und Magic Links
10
66
Social Login oder Enterprise SSO
7
73
Barrierefreiheit, Performance, Zuverlässigkeit
7
80
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.
Bei 80 Szenarien, die Sicherheits- und Barrierefreiheitsabdeckung umfassen, wird manuelles Testmanagement zunehmend schwierig. aqua cloud, eine KI-gestützte Test- und Anforderungsmanagement-Lösung, speichert und orchestriert jeden Authentifizierungsfall in einem System. Da aqua Intelligence RAG-Grounding auf Ihren realen Anforderungen verwendet, ist seine Genauigkeit im Vergleich zu ähnlichen auf dem Markt verfügbaren Modellen viel höher. Dashboards zeigen, welche Ihrer Auth-Pfade unbedeckt bleiben, während Audit-Trails für SOC 2- oder PCI-DSS-Review bereit bleiben. aqua cloud hat ISO-27001-Zertifizierung und erfüllt DORA-Anforderungen. Jeder Plan enthält auch kostenlose Gast-Lizenzen mit unbegrenzten Sitzplätzen, sodass Ihre Reviewer und Auditoren Ergebnisse ohne zusätzliche Kosten lesen können. Führen Sie Lastprüfungen über JMeter durch, führen Sie API-Szenarien in SoapUI aus und starten Sie UI-Suites mit Ranorex. Richten Sie Setup in PowerShell oder UnixShell ein und fragen Sie dann MSSQL und Oracle direkt nach Kontostatus ab. Halten Sie Spezifikationen in Confluence abgestimmt und wählen Sie aus über 10 nativen Automatisierungsintegrationen.
Generieren Sie Authentifizierungs-Testfälle, bei denen 42% keine Bearbeitung benötigen und erreichen Sie 100% Abdeckung
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.
Testfälle für eine Anmeldeseite sind dokumentierte Szenarien, die Authentifizierungsverhalten verifizieren und gültige und ungültige Anmeldedaten, Kontostatus, Session-Erstellung, MFA und Barrierefreiheit abdecken. Jeder gibt Vorbedingungen, Testdaten, Schritte und ein verifizierbares erwartetes Ergebnis an.
Wie schreiben Sie Testfälle für Anmeldeseiten-Szenarien?
Beginnen Sie mit einer Risikokategorie, benennen Sie ein Szenario und zeichnen Sie Vorbedingungen, exakte Testdaten, reproduzierbare Schritte und das erwartete Client- und Server-Ergebnis auf. Weisen Sie eine Priorität zu und binden Sie dann Ihre Assertions an Verhalten, damit Redesigns sie nicht brechen.
Was sind positive und negative Testfälle für Anmeldeseiten-Tests?
Positive Fälle bestätigen gültige Anmeldedaten, respektierte Weiterleitungen und korrekte Session-Erstellung. Negative Fälle decken falsche Passwörter, unbekannte Benutzernamen, gesperrte Konten, Injection-Payloads, wiederholte OTP-Codes, wiederverwendete Reset-Token und manipulierte SSO-Callbacks ab.
Was sind die wichtigsten Testfälle für eine Anmeldeseite?
Identische Antworten über Kontostatus hinweg, geschützte Routen, die anonyme Anfragen ablehnen, Session-ID-Rotation mit serverseitigem Logout, Throttling, das der Policy entspricht, und Passwort-Manager-Unterstützung. Jeder Fehler hier verursacht sofortigen Schaden für Sicherheit oder Zugang.
Warum ist Sicherheitstest für Anmeldeseiten wichtig?
Jede Autorisierungs-, Verschlüsselungs- und Logging-Kontrolle hängt davon ab zu wissen, wer die Anfrage gesendet hat. Schwaches Throttling gibt Angreifern unbegrenzte Versuche, Enumeration übergibt ihnen eine Zielliste, und ein Bypass auf einer API-Route exponiert Daten vollständig.
Was sollte jeder Testfall für eine Anmeldeseite beinhalten?
Eine ID, ein Szenario, Vorbedingungen, exakte Testdaten, reproduzierbare Schritte und ein erwartetes Ergebnis, das sowohl Client- als auch Server-Ergebnisse abdeckt. Assertions beschreiben Verhalten über Markup hinaus, sodass ein Redesign den Fall nicht ungültig macht.
Was sollten Passwort-Reset-Testfälle abdecken?
Reset-Abdeckung umfasst identische Antworten für unbekannte und registrierte E-Mails, Einmaltoken, Ablauferzwingung, Rate Limiting auf Ihrem Recovery-Endpunkt, Links, die nicht auf ein anderes Konto zielen können, und alte Passwörter, die nach abgeschlossenem Reset fehlschlagen.
Welche Testfälle für die Anmeldeseite sollten automatisiert werden?
Automatisieren Sie 6 bis 8 UI-Fälle für Ihre kritischen Journeys, verschieben Sie Kontostatus und Eingabekombinationen zu API-Tests und handhaben Sie Cookies, Statuscodes und Token-Replay auf Protokollebene. Assistenztechnologie-Checks bleiben manuell.
Pavel ist Quality-Assurance-Berater und Autor mit tiefem Fachwissen in der Lösung komplexer Testherausforderungen. Sein Hintergrund in der Softwareentwicklung hat Organisationen dabei geholfen, ihre QA-Praktiken von reaktiv zu proaktiv zu entwickeln. Neben der Beratung entwickelt Pavel Best-Practice-Leitfäden und Fallstudien für aqua cloud, die praxisnahe QA-Lösungen demonstrieren…
Nurlan, ein QA-Koordinator, ist stolz darauf, nahtlose QA-Operationen zu orchestrieren. Seine Expertise in der Koordination von QA-zentrierten Projekten und der Integration von QA-Lösungen hat konsequent höchste Kundenzufriedenheit erzielt. Neben seiner Vollzeittätigkeit als QA-Koordinator beinhaltet Nurlans Rolle das Erstellen von überzeugenden Inhalten, die Nutzer über die…
Robert hat mehrere Jahre Erfahrung in der Prozessoptimierung und im Testmanagement. Er ist Experte für die Definition und Implementierung von Arbeitsabläufen durch die Anpassung von aqua an die Prozesse der Kunden.
Beginnen Sie Ihre Arbeit nicht mit gewöhnlichen E-Mails: Fügen Sie eine gesunde Dosis an aufschlussreichen Softwaretest-Tipps von unseren QS-Experten hinzu.
Werden Sie Teil unserer Community von begeisterten Experten! Erhalten Sie neue Beiträge aus dem aqua-Blog direkt in Ihre Inbox. QS-Trends, Übersichten über Diskussionen in der Community, aufschlussreiche Tipps — Sie werden es lieben!
Wir sind dem Schutz Ihrer Privatsphäre verpflichtet. Aqua verwendet die von Ihnen zur Verfügung gestellten Informationen, um Sie über unsere relevanten Inhalte, Produkte und Dienstleistungen zu informieren. Diese Mitteilungen können Sie jederzeit wieder abbestellen. Weitere Informationen finden Sie in unserer Datenschutzrichtlinie.
X
🤖 Neue spannende Updates sind jetzt für die aqua-Intelligenz verfügbar! 🎉
