Formulare verwandeln Benutzerdaten in Systemaktionen: Registrierung, Bestellungen, Profiländerungen oder Datei-Uploads. Formulartests umfassen daher mehr als Zeichenkombinationen. Verfolgen Sie den Weg von der Eingabe über gespeicherte Daten bis zu einem eindeutigen Ergebnis auf dem Bildschirm.
Gute Validierung hilft bei der Fehlerkorrektur und schützt die Datenintegrität. Schlechte Validierung frustriert und lässt zugleich ungültige Anfragen zu: Die Oberfläche lehnt vielleicht einen zulässigen Nachnamen ab, während die API einen Datensatz ohne vorgeschriebene Zustimmung annimmt.
Zuerst die Regeln klären
Dokumentieren Sie den Vertrag jedes Feldes: Pflichtstatus, zulässige Werte, Längenbereich, Format, Normalisierung, Abhängigkeiten und Validierungszeitpunkt. Erfassen Sie Geschäftsregeln wie Eindeutigkeit, Tarifverfügbarkeit, gültige Datumswerte und Rollenbeschränkungen getrennt.
Normalisierung überführt Eingaben in eine vereinbarte Form, etwa durch Entfernen äußerer Leerzeichen. Erfinden Sie diese Regel nicht im Test. Leerzeichen können in Namen relevant sein; Änderungen an Großschreibung oder Unicode-Zeichen können ein Passwort verändern. Unklare Regeln gehören in die Anforderungsklärung und sind keine auf persönlichen Vorlieben beruhenden Fehler.
Client- und Serverprüfungen trennen
Clientvalidierung liefert schnelle Rückmeldung vor einer Anfrage. Servervalidierung entscheidet abschließend, ob eine Operation erlaubt ist. HTML-Attribute und JavaScript lassen sich umgehen; eine Ablehnung im UI beweist daher keinen Schutz der Backenddaten.
Prüfen Sie dieselbe ungültige Eingabe über das Formular und eine direkte Anfrage in einer Testumgebung. Erwarten Sie die vereinbarte Serverablehnung, keinen neuen Datensatz und korrekte Fehlerbehandlung im UI. Der API-Vertrag bestimmt den genauen HTTP-Status; es gibt keinen universellen Status für jedes Formular.
Testdaten systematisch auswählen
Verwenden Sie Äquivalenzklassen: Eingabegruppen mit erwartet gleichem Verhalten. Bei einer Länge von 2–50 prüfen Sie leere Eingaben, 1, 2, 50 und 51 Zeichen sowie einen gewöhnlichen Wert innerhalb des Bereichs. So entsteht nachvollziehbare Grenzabdeckung.
- →Zahlen: Minimum, Maximum, Nachbarwerte, negative Zahlen, Brüche und ungültige Trennzeichen.
- →Datumswerte: nicht existierende Daten, Schalttage, Periodengrenzen sowie vorgeschriebenes Sprachregions- und Zeitzonenverhalten.
- →Text: Leerzeichen, Zeilenumbrüche, kyrillischer Text, zusammengesetzte Unicode-Zeichen, Einfügen und lange Werte.
- →Auswahlfelder: keine Auswahl, nicht verfügbare Werte und Änderungen abhängiger Listen nach Änderung des übergeordneten Feldes.
Klären Sie die Längeneinheit. Sichtbare Zeichen, Codepoints, UTF-16-Einheiten und Bytes können insbesondere bei Emojis unterschiedliche Anzahlen ergeben.
Eingaben als Interaktion testen
Menschen tippen, fügen ein, verwenden Autofill, bearbeiten die Zeichenkettenmitte und löschen Auswahlbereiche. Eine Telefonmaske, die nur beim fortlaufenden Tippen funktioniert, kann eingefügte Werte beschädigen. Ein Kalender kann ein Datum im Widget akzeptieren, die manuelle Eingabe aber anders behandeln.
Prüfen Sie auch Absenden per Schaltfläche und Enter, Tab-Navigation, Werterhalt nach Fehlern und passende mobile Tastaturen. Platzhalter zeigen Beispiele, verschwinden jedoch bei der Eingabe und ersetzen keine dauerhaften Feldbeschriftungen.
Fehler sollten die Korrektur unterstützen
Meldungen sollen erklären, was passiert ist und wie es sich beheben lässt. Ordnen Sie sie dem richtigen Feld zu, machen Sie sie ohne Farbe verständlich und lassen Sie ausreichend Lesezeit. Bei mehreren Fehlern muss jeder klar erreichbar sein.
Prüfen Sie Fokusreihenfolge, zugängliche Feldnamen und Fehleransagen des Screenreaders. Eine allgemeine Meldung „ungültige Daten“ reicht für eine Lieferadresse möglicherweise nicht aus. Umgekehrt können Loginmeldungen, die vorhandene Konten verraten, Sicherheitsanforderungen verletzen. Der Kontext entscheidet.
Asynchrone Prüfungen und Race Conditions
Benutzernamenverfügbarkeit, Preisberechnungen und Adressvorschläge treffen nach Benutzeraktionen ein. Geben Sie A ein, ersetzen Sie es schnell durch B und verzögern Sie die Antwort für A. Die alte Antwort darf das aktuelle Ergebnis nicht überschreiben.
Zeigen Sie während des Sendens den vereinbarten Zustand. Wiederholte Klicks, Enter und Netzwerk-Retries dürfen keine zusätzlichen Geschäftsvorgänge erzeugen. Das Deaktivieren einer Schaltfläche reduziert Risiken; prüfen Sie den verbindlichen Duplikatschutz dennoch auf Operations- und Serverebene.
Praxisbeispiel: Registrierung
Angenommen, der Vertrag verlangt eine E-Mail-Adresse und ein Passwort mit 12–64 Zeichen, dessen Leerzeichen erhalten bleiben. Das Konto entsteht bei erfolgreicher Serververarbeitung; eine verlorene Antwort bedeutet nicht, dass kein Datensatz existiert.
- 1.Geben Sie gültige Daten ein und senden Sie sie. Erwarten Sie einen neuen Datensatz und einen klaren nächsten Schritt, etwa die E-Mail-Bestätigung.
- 2.Prüfen Sie Passwortlängen von 11, 12, 64 und 65 über UI und API. Erwarten Sie übereinstimmende Grenzen und keine ungültigen Datensätze.
- 3.Verwenden Sie eine vorhandene E-Mail-Adresse. Erwarten Sie die vertragliche Ablehnung und den Erhalt anderer gültiger Felder, sofern die Richtlinie nicht das Löschen geheimer Werte verlangt.
- 4.Simulieren Sie nach dem Senden einen Timeout und wiederholen Sie den Vorgang. Erwarten Sie ein definiertes Ergebnis ohne zweites Konto oder endloses Laden.
- 5.Bearbeiten Sie einen fehlgeschlagenen Sendevorgang mit Tastatur und Screenreader. Der Fehler muss ohne Maus auffindbar und korrigierbar sein.
Dateien und sensible Daten
Prüfen Sie bei Dateiformularen vertragliche Größen und Typen, leere Dateien, unterbrochene Übertragungen und wiederholte Uploads. Das accept-Attribut unterstützt die Auswahl; der Server muss Inhalt und Grenzen unabhängig validieren.
Echte Passwörter, Tokens und persönliche Dokumente gehören nicht in Diagnosedaten. Belegen Sie Fehler mit vorbereiteten Testdaten und bereinigten Anfragen.
Häufige Fehler und Erkenntnisse
Typische Fehler sind die ausschließliche Prüfung von Pflichtfeldern, die Gleichsetzung einer Eingabemaske mit Gültigkeit und die Kontrolle von Meldungen ohne tatsächlichen Datenzustand. Willkürlich einschränkende E-Mail- oder Namensmuster ohne Produktanforderung sind ebenfalls riskant.
Systematische Formulartests verbinden Verträge, Grenzen, Eingabemethoden, Serverentscheidungen und Fehlerbehebung. Bewerten Sie die gesamte Benutzerreise statt der Anzahl eingegebener Zeichenketten.
Weiterführende Informationen
- →MDN: Clientseitige Formularvalidierung
- →W3C WAI: Easy Checks, Formulare und Fehler
- →OWASP: Web Security Testing Guide
Eine Regel, eine konkrete Eingabematrix
Übungsregel: Der Nickname muss 3–12 ASCII-Buchstaben enthalten. Leerzeichen werden abgelehnt statt still entfernt; Unicode-Buchstaben liegen außerhalb dieser bewusst engen Übung. Das vorbereitete HTML-Formular arbeitet ausschließlich im Client und sendet keine Anfrage. Die API-Fixture validiert dieselbe Namensregel separat.
Eingabe Erwartet
(leer) Ablehnen
ab Ablehnen: Länge 2
abc Akzeptieren: Länge 3
abcdefghijkl Akzeptieren: Länge 12
abcdefghijklm Ablehnen: Länge 13
abc Ablehnen: führendes Leerzeichen
абв Ablehnen: nach dieser Regel keine ASCII-ZeichenPrüfen Sie bei abgelehnten Werten eine sichtbare Fehlermeldung, aria-invalid=true und den Fokus auf dem ungültigen Feld. aria-describedby verbindet die Meldung mit der Eingabe. Bei akzeptierten Werten verlangen Sie den Erfolgsstatus und eine leere Fehlermeldung. Übertragen Sie diese ASCII-Regel nicht auf echte Namen oder internationale Produkte.
Clientprüfungen verbessern Rückmeldungen, lassen sich aber umgehen. Senden Sie ungültiges JSON direkt an die lokale API-Fixture und verlangen Sie auch dort eine Ablehnung. Formular- und API-Prüfung sind zwei getrennte Tests; die Demo behauptet keinen durchgängigen Sendevorgang vom Browser zur API.
Weiterlernen
Lokales Übungslabor herunterladen (ZIP)