Jede Nutzer-Interaktion stellt ein potentielles Risiko f\u00fcr die Webanwendung dar. Bei der Handhabe von Formularen gibt es entsprechend viele zu testende Punkte, um reibungsloses Funktionieren zu gew\u00e4hrleisten. Die Sicherheit des Servers, unver\u00e4nderbarkeit 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\u00fcllen eines Formulars auch nicht demotiviert werden. Entsprechend sollte man im Auge behalten, wie ein Formular von einem Menschen bearbeitet wird.<\/p>\n\n\n\n
Dies hier wird ein allgemeiner Beitrag, um die Testarten aufzulisten, die f\u00fcr Web-Formulare in Betracht gezogen werden sollten. Wenn m\u00f6glich versuche ich Beitr\u00e4ge mit spezifischen Anwendungen in Frameworks nachzuziehen.<\/p>\n\n\n\n
Der Artikel “A Checklist for Web Form Testing von Pooja Potghan)<\/a> betrachtet das Testing per Browser, von Hand und mit Hilfe einfacher, bereits vorhandener Werkzeuge. There will be resources for whichever specific framework you use, so watch out for them. Ja, das verdient eine eigene \u00dcberschrift. Bei der Konstruktion von Anwendung und Web-Formular sollten auch Ressourcen in die Planung des Testings flie\u00dfen. TDD <\/strong>(Test Driven Development – Test getriebene Entwicklung) und Richtlinien f\u00fcr Unit-Tests und PR (Pull Requests) etablieren, sowie Ressourcen f\u00fcr manuelles Testen frei stellen und Testger\u00e4te <\/strong>anschaffen.<\/p>\n\n\n\n Weiterhin zu Bedenken: Web-Formulare m\u00fcssen in verschiedenen Browsern auf verschiedenen Plattformen laufen. Da es nahezu unm\u00f6glich ist f\u00fcr ALLE Browser zu programmieren, sollte eine Browser- und Ger\u00e4te-Matrix<\/strong> f\u00fcrs Testen erstellt werden. Besonders wenn f\u00fcr einen Steakholder gearbeitet wird. So spezifisch wie m\u00f6glich sollten die Ger\u00e4te mit OS-Version und Browsern mit spezifischer oder “aktueller” Version vermerkt werden.<\/p>\n\n\n\n Jede Funktionalit\u00e4t 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\u00e4nkungen. Es gibt auch Tests die immer noch sinnvoll sind, selbst wenn ein stabiles Framework genutzt wird, um die korrekte Handhabung der Eingabe abzuarbeiten.<\/p>\n\n\n\n Im Beitrag \u00fcber das Design von Web-Formularen<\/a> wurden Validatoren bereits erw\u00e4hnt. Ob sie funktionieren kann \u00fcberpr\u00fcft werden, indem leere, unerwartete oder merkw\u00fcrdig formatierte Eingaben erfolgen, sowie \u00fcber Grenzf\u00e4lle. Je nach Art des Feldes und der Information, die es sammeln soll, sind weitere Tests sinnvoll.<\/p>\n\n\n\n F\u00fcr Namen <\/strong>von Leuten und Orten, wurden ben\u00f6tigte Sonderzeichen erlaubt? (\u00e1, \u00f6, …) Wurde die L\u00e4nge beschr\u00e4nkt und dadurch der Nutzer davon abgehalten, seinen sehr langen Namen einzugeben? Wurde der Text mit trim von Leerzeichen befreit?<\/p>\n\n\n\n Bei Auswahlm\u00f6glichkeiten<\/strong>, gibt es einen Default-Wert? Ist dieser Default auch valide und wird durch das Formular \u00fcbergeben?<\/p>\n\n\n\n Datum<\/strong>s-Eingaben sind f\u00fcr 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?<\/p>\n\n\n\n Nur valide Formulare sollten abgesendet werden. Deswegen…<\/p>\n\n\n\n Denk daran, dass es mehr als eine Art gibt, ein Formular auszuf\u00fcllen – valide oder invalide;<\/p>\n\n\n\n Wenn das verwendete Framework MVC als Pattern nutzt, dann kann MVP (Model View Presenter)<\/a> eingesetzt werden. Das lohnt sich ggf. nur f\u00fcr gro\u00dfe Projekte, macht dann das Testen aber deutlich einfacher.<\/p>\n\n\n\n In der Designphase kann das Formular dahingehend kompliziert gemacht werden, dass es optional sichtbare Elemente, Abh\u00e4ngigkeiten zwischen Feldern und dynamische Validatoren gibt. In den zugeh\u00f6rigen Tests sollten positive und negative Testf\u00e4lle enthalten sein um sicher zu stellen, dass diese korrekt funktionieren.<\/p>\n\n\n\n Dies beinhaltet Tester, die sich von den Entwicklern unterscheiden. Das Problem ist n\u00e4mlich, dass sich Entwickler darauf konzentrieren, wie der Weg durch das Formular zu einem Erfolg f\u00fchrt, sodass es manchmal einen frischen Blickwinkel braucht.<\/p>\n\n\n\n Das Formular sollte einfach zu bedienen sein. Pflichtfelder und optionale sollten leicht zu unterscheiden sein. Ein Nutzer sollte das Formular ausschlie\u00dflich per Tastatur bedienen k\u00f6nnen. Texte sollten hohen Kontrast aufweisen und gut lesbar sein. Au\u00dferdem sollte keine \u00fcberfl\u00fcssige Information angezeigt werden.<\/p>\n\n\n\n Wurde ein ung\u00fcltiger Wert oder Zeichen eingegen, so sollte das Formular einen Fehler anzeigen. Dabei sollte klar werden, welches Feld den Fehler enth\u00e4lt. Die Fehlermeldung sollte wirklich als Meldung angezeigt werden und f\u00fcr den Nutzer ersichtlich werden lassen, was der Benutzer tun muss, um den Fehler zu beheben.<\/p>\n\n\n\n Beim Testen im Browser stehen einem zus\u00e4tzliche Funktionalit\u00e4ten zur Verf\u00fcgung, so wie Kn\u00f6pfe, um zwischen den Seiten zu navigieren<\/strong> (zur\u00fcck, neu laden), Cookies <\/strong>w\u00e4hrend des Ausf\u00fcllens des Formulars l\u00f6schen, den Browser schlie\u00dfen, Ausschneiden und Einf\u00fcgen der URL bei einm Schritt inmitten des Formulars. Oder das Formular in einer anderen Reihenfolge als beabsichtigt ausf\u00fcllen.<\/p>\n\n\n\n Und jetzt die fiesen Tricks: JavaScript <\/strong>im Browser deaktivieren <\/strong>um sicher zu gehen, dass das Formular nun nicht mehr angezeigt wird (am besten w\u00e4re 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.<\/p>\n\n\n\n Auf mobilen Ger\u00e4ten<\/strong> stehen wieder andere Funktionen zur Verf\u00fcgung. Der Browser kann in den Hintergrund bewegt werden, es kann ein Anruf reinkommen oder das Ger\u00e4t mitten drin abgeschaltet werden. Was passiert jeweils mit dem Formular?<\/p>\n\n\n\n Ein weiterer netter Test beinhaltet die Internetverbindung<\/strong>. Der Browser kann die Datenrate anpassen und auf einem mobilen Ger\u00e4t kann die Verbindung vollst\u00e4ndig getrennt werden. Das Formular sollte sich entsprechend verhalten.<\/p>\n\n\n\n Mit Hilfe der definierten Browser-Matrix<\/strong> kann alles bisherigen in all den Browsern und auf all den Ger\u00e4ten getestet werden, auf welchen das Formular funktionieren soll. Auf klar ausgegrenzten Browsern sollte ggf. eine entsprechende Fehlermeldung angezeigt werden.<\/p>\n\n\n\n Mehr hierzu unter Pentests. Aber es ist beispielsweise einfach, falsche Symbole oder Werte zu \u00fcbergeben und zu pr\u00fcfen, wie das Formular reagiert.<\/p>\n\n\n\n Die echte Magie passiert im Backend. Zumindest der Teil, der Berechnungen beinhaltet, die nicht vom Browser ausgef\u00fchrt werden k\u00f6nnen oder sollen. Daten beziehen, Bilder bereitstellen, \u00c4nderungen vornehmen und Formulare verarbeiten. Die Funktionalit\u00e4ten, die Anfragen betreffen, werden von Schnittstellen-Tests abgedeckt. F\u00fcr mich ist das eine Sammlung m\u00f6glicher Anfragen, die von einem Frontend gesendet werden k\u00f6nnen und dessen Workflow wiederspiegelt. Das Durchlaufen dieser Tests hilft dabei \u00c4nderungen zu entdecken, die nur an einem Ende gemacht wurden. Au\u00dferdem wird so die Verf\u00fcgbarkeit von Services und Routen \u00fcberpr\u00fcft.<\/p>\n\n\n\n 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\u00fcnschte Anfragen m\u00fcssen explizit blockiert <\/strong>werden. Entsprechende Anfragen m\u00fcssen also fehlschlagen.<\/p>\n\n\n\n Zus\u00e4tzlich k\u00f6nnen sonst valide Anfragen mit dem falschen Typ geschickt werden, z.B. POST statt PUT.<\/p>\n\n\n\n HTTP Aufrufe haben auch verschiedene Arten von Paramtern. Header <\/strong>sind der Anfrage hinzugef\u00fcgt, URL-Parameter<\/strong> spezifizieren die Anfrage und als Inhalt <\/strong>k\u00f6nnen fast beliebige Daten mitgesendet werden. Beim Testen von Formularen sollten deren Daten in verschiedenen Variationen gesendet werden. Die vom Frontend eingesetzten Validatoren <\/strong>bewusst ignorieren, denn diese m\u00fcssen immer im Backend <\/strong>wiederholt werden. Invalide Anfragen sollten abgelehnt werden und korrekte zum Erfolg f\u00fchren.<\/p>\n\n\n\n Au\u00dferdem – auch wenn das Bestandteil des Pentest-Abschnitts ist – sensible Daten sollte niemals im Klartext versendet werden. Niemals. Nie.<\/p>\n\n\n\n Hier der Beginn einer Liste von Werkzeugen, die ich schon benutzt habe und mit denen sich komfortabel API-Aufrufe durchf\u00fchren lassen.<\/p>\n\n\n\n Penetrationstests sind notwendig, wenn die Geheimhaltung, Sicherheit oder Verf\u00fcgbarkeit von Daten und Webseite essentiell ist. Also eigentlich meistens. Penetrationstests emulieren Angriffe auf Seite, Service und Backend. Es gibt sie in gro\u00dfer Vielfalt, der Umfang sollte aber auf die Anwendung angepasst werden. Es gibt falsche Eingaben, ausgetrickste Bedingungen, fehlende Zeichen und Zahlen im Textfeld. Aber es gibt auch b\u00f6sartige Eingaben. Heutzutage gibt es Frameworks, die Dependency-Injections verhindern. Trotzdem bitte nachtesten.<\/p>\n\n\n\n Dependency-Injection versucht die Eingabe zu beenden und eigenen, ausf\u00fchrbaren Code anzuh\u00e4ngen. Mit Anf\u00fchrungszeichen, Schr\u00e4gstrichen, Semikolons ausprobieren und abwarten, wie das Formular reagiert.<\/p>\n\n\n\n Falsche Werte k\u00f6nnen zu einem validen Formular f\u00fchren, wenn der Validator sie nicht abdeckt. Z.B. negative Zahlen, Sonderzeichen und die Worte “null” oder “undefined”.<\/p>\n\n\n\n Hierbei dreht es sich haupts\u00e4chlich 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\u00f6chte vielleicht sp\u00e4ter zu einem half ausgef\u00fcllten Formular zur\u00fcck kehren, weil er etwas nachschlagen musste, aber gleichzeitig sollen sensible Daten nicht gef\u00e4hrdet werden, indem sie zu lange gespeichert werden. Au\u00dferdem sollte ein Link zur Session niemals die eingef\u00fcgten Daten enthalten, diese m\u00fcssen lokal und tempor\u00e4r gespeichert werden (und nach dem Absenden gel\u00f6scht werden).<\/p>\n\n\n\n Die sind einfach: das Kleinkind oder die Katze d\u00fcrfen auf der Tastatur spielen. (Distributed) Denial of Service. Die Vielzahl an Anfragen \u00fcberfordert den Server und sorgt daf\u00fcr, dass er nicht mehr erreichbar ist oder sich sogar abschaltet. Im Bereich des Pentestings gibt es noch deutlich mehr, um eine Webseite anzugreifen. Die H\u00e4lfte 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.<\/p>\n\n\n\n Wenn ich weitere passende Eintragungen finde, werde ich diese Liste erg\u00e4nzen.<\/p>\n","protected":false},"excerpt":{"rendered":" Web-Formulare m\u00fcssen getestet werden. Anhand eines Plan kann manuell, automatisiert und technisch versiert gepr\u00fcft werden, ob das Formular Angriffen und Tippfehlern stand h\u00e4lt.<\/p>\n","protected":false},"author":1,"featured_media":384,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12,36],"tags":[39,24,38],"class_list":["post-346","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-programming","category-web-programming","tag-forms","tag-testing","tag-web"],"translation":{"provider":"WPGlobus","version":"3.0.0","language":"de","enabled_languages":["en","de"],"languages":{"en":{"title":true,"content":true,"excerpt":true},"de":{"title":true,"content":true,"excerpt":true}}},"_links":{"self":[{"href":"https:\/\/erdbeerbeet.com\/de\/wp-json\/wp\/v2\/posts\/346","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/erdbeerbeet.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/erdbeerbeet.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/erdbeerbeet.com\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/erdbeerbeet.com\/de\/wp-json\/wp\/v2\/comments?post=346"}],"version-history":[{"count":8,"href":"https:\/\/erdbeerbeet.com\/de\/wp-json\/wp\/v2\/posts\/346\/revisions"}],"predecessor-version":[{"id":381,"href":"https:\/\/erdbeerbeet.com\/de\/wp-json\/wp\/v2\/posts\/346\/revisions\/381"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/erdbeerbeet.com\/de\/wp-json\/wp\/v2\/media\/384"}],"wp:attachment":[{"href":"https:\/\/erdbeerbeet.com\/de\/wp-json\/wp\/v2\/media?parent=346"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/erdbeerbeet.com\/de\/wp-json\/wp\/v2\/categories?post=346"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/erdbeerbeet.com\/de\/wp-json\/wp\/v2\/tags?post=346"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Dann gibt es die “Form Submission Test Checklist”<\/a> mit abstrakten, aber sehr guten Punkten die es beim Testen von Web-Formularen zu beachten gilt.
Au\u00dferdem gibt es “Checklist for Better Web Forms” (von Mert TOL)<\/a>, das sich die besonderen Arten von Eingabefeldern besieht und wie diese korrekt implementiert werden.<\/p>\n\n\n\n
And as always, I will happily expand this list.<\/p>\n\n\n\nTest-Plan<\/h2>\n\n\n\n
Unit-Tests<\/h2>\n\n\n\n
Validatoren<\/h3>\n\n\n\n
Absenden<\/h3>\n\n\n\n
MVP<\/h3>\n\n\n\n
Bedingungen<\/h3>\n\n\n\n
Manuelle Tests<\/h2>\n\n\n\n
UI\/UX Tests<\/h3>\n\n\n\n
Fehlerbehandlung<\/h3>\n\n\n\n
Browser-Funktionalit\u00e4ten<\/h3>\n\n\n\n
Hacking-Versuche<\/h3>\n\n\n\n
Schnittstellen-Tests<\/h2>\n\n\n\n
Das Frontend-Framework nutzt HTTP-Anfragen um mit dem Backend zu reden. Diese Anfragen haben ein spezifisches Format, Parameter und Header. Eine \u00c4nderung an einem Ende muss auch am anderen umgesetzt werden. Z.B. wenn ein Parameter umbenannt wird.<\/p>\n\n\n\nArten von Anfragen<\/h3>\n\n\n\n
Parameter<\/h3>\n\n\n\n
Zus\u00e4tzlich k\u00f6nnen Session-Token oder Cookies den Benutzer autorisieren. Die Autorisierung ist ein sehr sensibler Anwendungsfall, der viel Beachtung verdient. Unautorisierte Aufrufe m\u00fcssen fehlschlagen, Tokens m\u00fcssen erneuert werden und es sollte unm\u00f6glich sein, diese ohne valide Anmeldedaten zu erraten.<\/p>\n\n\n\nTechnologien<\/h3>\n\n\n\n
Pentests<\/h2>\n\n\n\n
Ich deute hier einige Tests nur an und konzentriere mich auf die, die speziell zu Formularen passen.<\/p>\n\n\n\nInvalide Eingaben<\/h3>\n\n\n\n
Session Management<\/h3>\n\n\n\n
Smoke-Test<\/h3>\n\n\n\n
Die Anwendung sollte mit unerwarteten Eingaben klarkommen – egal welche Taste, Klick oder Touch ausgef\u00fchrt wird. Zumindest sollte sie nicht abst\u00fcrzen oder sensible Informationen weitergeben.<\/p>\n\n\n\n(D)DoS Attacke<\/h3>\n\n\n\n
Dieses Szenario ereignet sich tats\u00e4chlich h\u00e4ufiger. Nicht nur k\u00f6nnen Server aufgrund einer b\u00f6sartigen Attacke<\/strong> in die Knie gehen, sondern auch damit \u00fcberfordert sein, eine unerwartete Menge an Anfragen zu bearbeiten. Als Entwickler muss man sich \u00fcberlegen, wieviele Benutzer ein Formular zur gleichen Zeit benutzen k\u00f6nnten. Kritisch wird es bei Erscheinungsterminen, Einsendeschluss oder wenn eine Seite pl\u00f6tzlich viral geht, dann k\u00f6nnen die Nutzeraufrufe explodieren und nicht nur dem Server zusetzen, sondern auch all die potentiellen Benutzer <\/strong>demotivieren.<\/p>\n\n\n\nSonstige<\/h3>\n\n\n\n