Základní otestování webového formuláře

Prakticky každý vývojář se alespoň jednou sektal s nutností vytvořit nějaký ten webový formulář. Taková úloha se většinou skládá ze zobrazení formuláře, po jeho odeslání validací odeslaných dat na straně serveru a jejich dalším zpracování. Často je též navíc dostupná validace na straně klienta (nejčastěji formou JavaScriptu), čímž se zajistí rychlejší a příjemnější zobrazování chybových zpráv uživateli.

Abychom se při testování tzv. neuklikali, můžeme použít nástroje jako například Selenium IDE, které nám pomohou nudnou práci zautomatizovat. Pokud však tvoříme webový formulář, je dobré se nad jeho funkčností zamyslet už při vývoji a nespoléhat jen na to, že za nás všechny chyby odhalí automatizované testy. Scénářů a možných chyb je totiž tolik, že v to ani doufat nemůžeme. Pro jednoduché otestování webového formuláře se mi osvědčilo několik základních testů:

• Nevyplňuji do formuláře žádné údaje a pokouším se formulář ihned odeslat. Po získání chybového výstupu vyplňuji jen to, co mi říká chybové hlášení. Pokud mám i validaci na straně klienta formou JavaScriptu, provedu stejný test s vypnutím JavaScriptu. Výstupem tohoto testu mohou být různé chybové stavy, nekonzistentní chybová hlášení či rozdíly ve validaci na straně klienta a serveru.
• Zkouším zadat tzv. bíle znaky. Mam editační pole, které vyžaduje vyplnění alespoň x znaků. Jednoduše tedy zkusím místo reálných znaků zadat např. mezery, tabulátory apod. Validátor by na to měl umět reagovat a výstupem by mělo být hlášení uživateli, že je potřeba zadat platný obsah.
• Zadávám nesmyslné číselné hodnoty. U editačních polí vyžadujících číselné hodnoty v určitém rozsahu zkouším zadat neplatné hodnoty. Pokud pole vyžaduje zadání kladné hodnoty, zkouším zadat zápornou hodnotu včetně nuly. Zkouším do pole vyžadující číselnou hodnotu zadat prostý text.
• Pokouším se o vložení většího množství textu do editačního pole. Pokud je délka vstupu u editačního pole shora omezena, neměl bych mít jako uživatel možnost zadat delší vstup.
• Pokud o přidání duplicitní unikátní hodnoty. Pole, jehož hodnota musí být v rámci tabulky unikátní, je dobré otestovat pokusem o zadání duplicitní hodnoty. Je dobré si dát pozor na možnost pouhé rozdílnosti velikosti písmen či hodnoty doplněné o bílé znaky.
• Zadání neplatného kalendářového data. Občas se vyskytne situace, kdy je do editačního pole nutné zadávat kalendářové datum v určitém formátu. V takovém případě je potřeba ověřit, že zadání neplatné hodnoty je správně ošetřeno. V případě dvou editačních polí udávajících hodnoty „od“ a „do“ je dobré ověřit, zda hodnota „do“ nemůže předcházet hodnotě „od“, případně nemohou být hodnoty stejné (pokud se nejedná o platný vstup).
• Otestování problematických znaků uvozovek, & apod. Otestováním uvedených znaků ověříte, zda jsou hodnoty správně owrapované či ne.
• Ověření všech akcí na správu dat. Pokud se jedná o formulář (kolekci formulářů), které spravují data (akce Přidat, Upravit, Smazat), vyzkoušet všechny akce.

Uvedené body jdou dle mého názoru takovým základem pro otestování funkčnosti formuláře. Je mi jasné, že popisují pouze základní otestování a neřeší otázky bezpečnostního či výkonnostního testování.