Jede Nutzer-Interaktion stellt ein potentielles Risiko für die Webanwendung dar. Bei der Handhabe von Formularen gibt es entsprechend viele zu testende Punkte, um reibungsloses Funktionieren zu gewährleisten. Die Sicherheit des Servers, unveränderbarkeit bestimmter Werte, Fehler-Handhabung, korrekte Verarbeitung von Nutzer-Anfragen und die passende Kommunikation von alledem an den Nutzer.
Auf der anderen Seite soll ein Nutzer beim Ausfüllen eines Formulars auch nicht demotiviert werden. Entsprechend sollte man im Auge behalten, wie ein Formular von einem Menschen bearbeitet wird.
Dies hier wird ein allgemeiner Beitrag, um die Testarten aufzulisten, die für Web-Formulare in Betracht gezogen werden sollten. Wenn möglich versuche ich Beiträge mit spezifischen Anwendungen in Frameworks nachzuziehen.
Ressourcen
Der Artikel „A Checklist for Web Form Testing von Pooja Potghan) betrachtet das Testing per Browser, von Hand und mit Hilfe einfacher, bereits vorhandener Werkzeuge.
Dann gibt es die „Form Submission Test Checklist“ mit abstrakten, aber sehr guten Punkten die es beim Testen von Web-Formularen zu beachten gilt.
Außerdem gibt es „Checklist for Better Web Forms“ (von Mert TOL), das sich die besonderen Arten von Eingabefeldern besieht und wie diese korrekt implementiert werden.
There will be resources for whichever specific framework you use, so watch out for them.
And as always, I will happily expand this list.
Test-Plan
Ja, das verdient eine eigene Überschrift. Bei der Konstruktion von Anwendung und Web-Formular sollten auch Ressourcen in die Planung des Testings fließen. TDD (Test Driven Development – Test getriebene Entwicklung) und Richtlinien für Unit-Tests und PR (Pull Requests) etablieren, sowie Ressourcen für manuelles Testen frei stellen und Testgeräte anschaffen.
Weiterhin zu Bedenken: Web-Formulare müssen in verschiedenen Browsern auf verschiedenen Plattformen laufen. Da es nahezu unmöglich ist für ALLE Browser zu programmieren, sollte eine Browser- und Geräte-Matrix fürs Testen erstellt werden. Besonders wenn für einen Steakholder gearbeitet wird. So spezifisch wie möglich sollten die Geräte mit OS-Version und Browsern mit spezifischer oder „aktueller“ Version vermerkt werden.
Unit-Tests
Jede Funktionalität und jedes Eingabefeld sollte einen eigenen Unit-Test erhalten. Wenn eigene Formular-Templates erstellt werden muss jedes Feld exzessiv getestet werden, ebenso wie einzuhaltende Einschränkungen. Es gibt auch Tests die immer noch sinnvoll sind, selbst wenn ein stabiles Framework genutzt wird, um die korrekte Handhabung der Eingabe abzuarbeiten.
Validatoren
Im Beitrag über das Design von Web-Formularen wurden Validatoren bereits erwähnt. Ob sie funktionieren kann überprüft werden, indem leere, unerwartete oder merkwürdig formatierte Eingaben erfolgen, sowie über Grenzfälle. Je nach Art des Feldes und der Information, die es sammeln soll, sind weitere Tests sinnvoll.
Für Namen von Leuten und Orten, wurden benötigte Sonderzeichen erlaubt? (á, ö, …) Wurde die Länge beschränkt und dadurch der Nutzer davon abgehalten, seinen sehr langen Namen einzugeben? Wurde der Text mit trim von Leerzeichen befreit?
Bei Auswahlmöglichkeiten, gibt es einen Default-Wert? Ist dieser Default auch valide und wird durch das Formular übergeben?
Datums-Eingaben sind für sich schon eine Herausforderung. Neben guter Bedienbarkeit, wie reagiert die Anwendung auf verschiedenste Datums-Eingaben? Heute? In der Zukunft? In der Vergangenheit? Geburtsdaten, die den Benutzer 2 oder 200 Jahre alt sein lassen?
Absenden
Nur valide Formulare sollten abgesendet werden. Deswegen…
- Teste, dass ein leeres Formular nicht abgesendet werden kann und entsprechend keine Anfrage an das Backend schickt.
- Teste, dass ein nur teilweise ausgefülltes Formular (mit leeren Pflichtfeldern) nicht abgesendet werden kann und entsprechend keine Anfrage an das Backend schickt.
- Ein komplett ausgefülltes Formular sollte nur dann abgesendet werden können, um eine Anfrage an das Backend abzusetzen, wenn es valide ist. Formulare mit Fehlern nicht.
- Teste, dass ein korrekt ausgefülltes Formular abgesendet werden kann und entsprechend eine Anfrage an das Backend schickt.
Denk daran, dass es mehr als eine Art gibt, ein Formular auszufüllen – valide oder invalide;
MVP
Wenn das verwendete Framework MVC als Pattern nutzt, dann kann MVP (Model View Presenter) eingesetzt werden. Das lohnt sich ggf. nur für große Projekte, macht dann das Testen aber deutlich einfacher.
Bedingungen
In der Designphase kann das Formular dahingehend kompliziert gemacht werden, dass es optional sichtbare Elemente, Abhängigkeiten zwischen Feldern und dynamische Validatoren gibt. In den zugehörigen Tests sollten positive und negative Testfälle enthalten sein um sicher zu stellen, dass diese korrekt funktionieren.
Manuelle Tests
Dies beinhaltet Tester, die sich von den Entwicklern unterscheiden. Das Problem ist nämlich, dass sich Entwickler darauf konzentrieren, wie der Weg durch das Formular zu einem Erfolg führt, sodass es manchmal einen frischen Blickwinkel braucht.
UI/UX Tests
Das Formular sollte einfach zu bedienen sein. Pflichtfelder und optionale sollten leicht zu unterscheiden sein. Ein Nutzer sollte das Formular ausschließlich per Tastatur bedienen können. Texte sollten hohen Kontrast aufweisen und gut lesbar sein. Außerdem sollte keine überflüssige Information angezeigt werden.
Fehlerbehandlung
Wurde ein ungültiger Wert oder Zeichen eingegen, so sollte das Formular einen Fehler anzeigen. Dabei sollte klar werden, welches Feld den Fehler enthält. Die Fehlermeldung sollte wirklich als Meldung angezeigt werden und für den Nutzer ersichtlich werden lassen, was der Benutzer tun muss, um den Fehler zu beheben.
Browser-Funktionalitäten
Beim Testen im Browser stehen einem zusätzliche Funktionalitäten zur Verfügung, so wie Knöpfe, um zwischen den Seiten zu navigieren (zurück, neu laden), Cookies während des Ausfüllens des Formulars löschen, den Browser schließen, Ausschneiden und Einfügen der URL bei einm Schritt inmitten des Formulars. Oder das Formular in einer anderen Reihenfolge als beabsichtigt ausfüllen.
Und jetzt die fiesen Tricks: JavaScript im Browser deaktivieren um sicher zu gehen, dass das Formular nun nicht mehr angezeigt wird (am besten wäre eine „bitte JS aktivieren“ Nachricht), oder wenn es angezeigt wird und abgeschickt werden kann, sollte jedwede Validierung von Seiten des Backends wiederholt werden. Ausprobieren wie immer mit validen und invaliden Formularen.
Auf mobilen Geräten stehen wieder andere Funktionen zur Verfügung. Der Browser kann in den Hintergrund bewegt werden, es kann ein Anruf reinkommen oder das Gerät mitten drin abgeschaltet werden. Was passiert jeweils mit dem Formular?
Ein weiterer netter Test beinhaltet die Internetverbindung. Der Browser kann die Datenrate anpassen und auf einem mobilen Gerät kann die Verbindung vollständig getrennt werden. Das Formular sollte sich entsprechend verhalten.
Mit Hilfe der definierten Browser-Matrix kann alles bisherigen in all den Browsern und auf all den Geräten getestet werden, auf welchen das Formular funktionieren soll. Auf klar ausgegrenzten Browsern sollte ggf. eine entsprechende Fehlermeldung angezeigt werden.
Hacking-Versuche
Mehr hierzu unter Pentests. Aber es ist beispielsweise einfach, falsche Symbole oder Werte zu übergeben und zu prüfen, wie das Formular reagiert.
Schnittstellen-Tests
Die echte Magie passiert im Backend. Zumindest der Teil, der Berechnungen beinhaltet, die nicht vom Browser ausgeführt werden können oder sollen. Daten beziehen, Bilder bereitstellen, Änderungen vornehmen und Formulare verarbeiten.
Das Frontend-Framework nutzt HTTP-Anfragen um mit dem Backend zu reden. Diese Anfragen haben ein spezifisches Format, Parameter und Header. Eine Änderung an einem Ende muss auch am anderen umgesetzt werden. Z.B. wenn ein Parameter umbenannt wird.
Die Funktionalitäten, die Anfragen betreffen, werden von Schnittstellen-Tests abgedeckt. Für mich ist das eine Sammlung möglicher Anfragen, die von einem Frontend gesendet werden können und dessen Workflow wiederspiegelt. Das Durchlaufen dieser Tests hilft dabei Änderungen zu entdecken, die nur an einem Ende gemacht wurden. Außerdem wird so die Verfügbarkeit von Services und Routen überprüft.
Arten von Anfragen
Die Adresse einer API-Anfrage reagiert auf GET oder POST oder auf weitere Arten von Anfragen. Es gibt z.B. noch PUT und DELETE. Unerwünschte Anfragen müssen explizit blockiert werden. Entsprechende Anfragen müssen also fehlschlagen.
Zusätzlich können sonst valide Anfragen mit dem falschen Typ geschickt werden, z.B. POST statt PUT.
Parameter
HTTP Aufrufe haben auch verschiedene Arten von Paramtern. Header sind der Anfrage hinzugefügt, URL-Parameter spezifizieren die Anfrage und als Inhalt können fast beliebige Daten mitgesendet werden.
Zusätzlich können Session-Token oder Cookies den Benutzer autorisieren. Die Autorisierung ist ein sehr sensibler Anwendungsfall, der viel Beachtung verdient. Unautorisierte Aufrufe müssen fehlschlagen, Tokens müssen erneuert werden und es sollte unmöglich sein, diese ohne valide Anmeldedaten zu erraten.
Beim Testen von Formularen sollten deren Daten in verschiedenen Variationen gesendet werden. Die vom Frontend eingesetzten Validatoren bewusst ignorieren, denn diese müssen immer im Backend wiederholt werden. Invalide Anfragen sollten abgelehnt werden und korrekte zum Erfolg führen.
Außerdem – auch wenn das Bestandteil des Pentest-Abschnitts ist – sensible Daten sollte niemals im Klartext versendet werden. Niemals. Nie.
Technologien
Hier der Beginn einer Liste von Werkzeugen, die ich schon benutzt habe und mit denen sich komfortabel API-Aufrufe durchführen lassen.
- Postman: Nutzbar als App oder Browser-Plugin um Sammlungen von Aufrufen für verschiedene Anwendungsfälle zu erstellen. So wie Login, Datenaktualisierung und so weiter.
- JMeter: Eine ältere UI, kann aber auch Lasttest durchführen und die Tests auf mehrere Geräte verteilen.
Pentests
Penetrationstests sind notwendig, wenn die Geheimhaltung, Sicherheit oder Verfügbarkeit von Daten und Webseite essentiell ist. Also eigentlich meistens. Penetrationstests emulieren Angriffe auf Seite, Service und Backend. Es gibt sie in großer Vielfalt, der Umfang sollte aber auf die Anwendung angepasst werden.
Ich deute hier einige Tests nur an und konzentriere mich auf die, die speziell zu Formularen passen.
Invalide Eingaben
Es gibt falsche Eingaben, ausgetrickste Bedingungen, fehlende Zeichen und Zahlen im Textfeld. Aber es gibt auch bösartige Eingaben. Heutzutage gibt es Frameworks, die Dependency-Injections verhindern. Trotzdem bitte nachtesten.
Dependency-Injection versucht die Eingabe zu beenden und eigenen, ausführbaren Code anzuhängen. Mit Anführungszeichen, Schrägstrichen, Semikolons ausprobieren und abwarten, wie das Formular reagiert.
Falsche Werte können zu einem validen Formular führen, wenn der Validator sie nicht abdeckt. Z.B. negative Zahlen, Sonderzeichen und die Worte „null“ oder „undefined“.
Session Management
Hierbei dreht es sich hauptsächlich um Einloggen, Ausloggen und das Bestehen der Session. Im Falle von Formularen geht es darum, wie lange die Daten der Session – der Inhalt der Felder – bestehen bleibt. Ein Benutzer möchte vielleicht später zu einem half ausgefüllten Formular zurück kehren, weil er etwas nachschlagen musste, aber gleichzeitig sollen sensible Daten nicht gefährdet werden, indem sie zu lange gespeichert werden. Außerdem sollte ein Link zur Session niemals die eingefügten Daten enthalten, diese müssen lokal und temporär gespeichert werden (und nach dem Absenden gelöscht werden).
Smoke-Test
Die sind einfach: das Kleinkind oder die Katze dürfen auf der Tastatur spielen.
Die Anwendung sollte mit unerwarteten Eingaben klarkommen – egal welche Taste, Klick oder Touch ausgeführt wird. Zumindest sollte sie nicht abstürzen oder sensible Informationen weitergeben.
(D)DoS Attacke
(Distributed) Denial of Service. Die Vielzahl an Anfragen überfordert den Server und sorgt dafür, dass er nicht mehr erreichbar ist oder sich sogar abschaltet.
Dieses Szenario ereignet sich tatsächlich häufiger. Nicht nur können Server aufgrund einer bösartigen Attacke in die Knie gehen, sondern auch damit überfordert sein, eine unerwartete Menge an Anfragen zu bearbeiten. Als Entwickler muss man sich überlegen, wieviele Benutzer ein Formular zur gleichen Zeit benutzen könnten. Kritisch wird es bei Erscheinungsterminen, Einsendeschluss oder wenn eine Seite plötzlich viral geht, dann können die Nutzeraufrufe explodieren und nicht nur dem Server zusetzen, sondern auch all die potentiellen Benutzer demotivieren.
Sonstige
Im Bereich des Pentestings gibt es noch deutlich mehr, um eine Webseite anzugreifen. Die Hälfte der Attacken zielen etwa auf den Server ab. Selbst beim Entwurf des Frontends sollte man aber vertraut sein mit Cross-Side-Scripting, Spoofing und der Kunst von Spam-Mails.
Wenn ich weitere passende Eintragungen finde, werde ich diese Liste ergänzen.