Automatické testování webových aplikací: souhrnný přehled výsledků

Poznámka k předchozímu dílu

Překvapila mne bohatá diskuze k prvnímu článku, která podle mého ukazuje zejména na důležitost problematiky testování obecně. Bohužel jsem se v předchozím článku dopustil malé nepřesnosti, kterou mi pozorní čtenáři právem vytkli. Když to zjednoduším, příčinou byla věta: Čili negativních testů je pro současné aplikace zapotřebí jen velmi málo.

V žádném případě si nemyslím, že by se neměly negativní testy provádět. V kontextu mého testování jsem jich (viz třetí díl minisérie) napsal tolik, kolik jsem jich považoval za smysluplné. Ale protože v celé aplikaci je pouze šest vstupních elementů typu input , bylo těchto testů relativně málo. 

Mým opomenutím v článku ale bylo, že jsem dostatečně nezdůraznil, že tento malý počet negativních testů je dostatečný z pohledu funkcionálního testování černé skříňky.
Z tohoto pohledu je tedy třeba pro správné chápání zbylých dvou dílů minisérie jasně zdůraznit, že z dimenze kvality FURPS+ (Functionality, Usability, Reliability, Performance, Supportability) jsem se zabýval jen tou první částí, tj. funkcionalitou. Další dimenze jsem netestoval, ovšem částečně to provedl můj kolega, který testovanou aplikaci vytvářel.
Pro jistotu zdůrazním, že stav, kdy jsem neprováděl testy podle ostatních dimenzí kvality, neznamená, že takovéto testy považuji obecně za zbytečné.

Testovaná aplikace

Aplikace, na které bylo prováděno masivní testování, se nabízela sama. Totiž v souvislosti s vývojem nových testovacích metod na spřáteleném pracovišti (Software Testing IntelLigent Lab) vznikla potřeba mít netriviální semirealistickou aplikaci. Do ní by mělo být možné následně injektovat různé softwarové chyby a ty pak nově vyvíjenými metodami testování hledat. Tento projekt má název TbUIS (Testbed UIS). Pro splnění tohoto cíle je ale samozřejmě nutné mít na počátku aplikaci „bezchybnou“ a do ní pak poruchy injektovat. Bezchybná aplikace pak může sloužit i jako etalon pro nejrůznější srovnávání. Další podrobnosti zde nejsou důležité.

Pokud jste jako já z akademického prostředí, pak netriviální semirealistická aplikace, které bude „každý na první pohled rozumět“, bude s velkou pravděpodobností něco zpracovávající entity učitelé–studenti–předměty. A tak vznikl UIS neboli University Information System.

Jaké jsou vlastnosti UIS:

• Semirealistická, netriviální (má celkem 17 hlavních případů užití) a snadná pro pochopení. Případy užití mají dva aktory – učitele, který vyučuje a zkouší několik předmětů, a studenta, který si předměty zapisuje, skládá z nich zkoušky a dostává za to známky a kredity.
• Komplexní třívrstvá webová aplikace s vrstvou objektově relačního mapování. Je napsána v Javě s využitím JSP, Bootstrap, Hibernate a Springu (to také kvůli pozdějšímu snadnému injektování chyb). Pro funkcionální testování takovýchto typů aplikací existuje dostatečná podpora.
• Pro ukládání dat využívá relační databázi.
• Přednastavená realistickými testovacími daty, tj. v dostatečném množství a kvalitě. Data jsou v nejrůznějších kombinacích tak, aby pokrývaly co nejširší spektrum nastavení a bylo tak možné okamžitě testovat. Přednastaveno je celkem 6 učitelů, 12 studentů a 14 předmětů.
  Celé přednastavení je přehledně zobrazeno v nápovědách samotné aplikace.
• Využívající jasně stanovená realistická omezení, např. student může studovat najednou max. 7 předmětů. Všechna omezení jsou přehledně zobrazena v nápovědách samotné aplikace.
• S možností importu vlastního nastavení (XML, JSON) testovacích dat a exportu výsledů.
• Používající co nejvíce běžných webových elementů, jako jsou menu, tlačítka, check-boxy, modální okna, výběrové seznamy, Javascript apod.
• Připravená pro automatické funkcionální testování, např.:
  • Každý web element má svoje ID (včetně každé řádky v tabulkách).
  • Každá operace zobrazí hlášení o svém výsledku.
  • Má z pohledu praktického používání „nesmyslné“ možnosti, např. volbu „Restore DB“, pomocí níž může kdokoliv kdykoliv vrátit databázi do původního nastavení. To není chyba, ale důležitá vlastnost.
• Dobře dokumentovaná.
• V ideálním případě bez defektů. Absence defektů by měla být zajištěna díky masivnímu testování, které je popsáno dále.
• Protože se uvažuje o využití UIS v rámci mezinárodního vědeckého týmu, je připravena kompletně v angličtině.

Poznámka o složitosti aplikace

Přesto, že celá aplikace vypadá relativně jednoduše, při nakreslení diagramu přechodů a stavů jsme zjistili, že se může vyskytovat ve 117 různých stavech, mezi nimiž je 159 „hlavních“ přechodů. („Hlavních“ proto, že není možné zakreslit všechny opakující se přechody do menu apod.) Pod pojmem stav si můžeme představit jakýkoliv nastavitelný element nebo webovou stránku a přechody jsou návaznosti mezi nimi. Například jednoduchá přihlašovací stránka má stav vstupní pole Login (vyplněné či nevyplněné), ze kterého se přechází do stavu vstupní pole Heslo (opět vyplněné či nevyplněné), pak se přechází do stavu tlačítko Přihlásit (stisknuto či nestisknuto) a po jeho stisku a úspěšném přihlášení do stavu Hlavní menu.

Testování UIS – souhrnný pohled

Od samého počátku vývoje byla testování věnována zvýšená pozornost. Vývojář vytvářel současně s aplikací i jednotkové testy – jejich stručný přehled bude uveden v následující tabulce. Já jsem pak psal funkcionální testy nezávislé na vývojáři, které budou dále popisovány ve třetím dílu této minisérie. Význam sloupce „celkově řádek“ je počet všech řádek kódu včetně prázdných řádek, komentářů apod., zatímco „řádek kódu“ jsou řádky „skutečného“ kódu.

Budeme-li tedy považovat za nejpřesnější metriku počet řádků kódu (LOC – Lines of Code), pak oba dva typy testů mají dohromady více než trojnásobný rozsah oproti velikosti kódu aplikace.

Poznámka: Je jasné, že není úplně v pořádku porovnávat obtížnost psaní aplikace a kódu testů. Ovšem na druhou stranu, pokud je kvalitně připravený balík support (viz dále), pak je kód vlastních testů velmi úsporný. Typicky je to vždy jen jedna metoda z balíku support s příslušnými skutečnými parametry volání.

Trojnásobný rozsah testů vůči kódu aplikace mne dosti překvapil. Čekal jsem, že rozsah testů bude přibližně stejně velký, jako rozsah aplikace. Ve skutečnosti se ale ukazuje, že „stejný rozsah“ téměř platí už jen pro jednotkové testy. Pokrytí kódu jednotkovými testy bylo 86,8 %.

V příští závěrečné části minisérie si ukážeme, jakým způsobem byla aplikace testována. Čtenáři dávám možnost si aplikaci samostatně před třetím článkem série vyzkoušet. Aplikace je dostupná na oks.kiv.zcu.cz:10008.
Způsob přihlášení do aplikace je popsán na její hlavní stránce v odkazu: „Database content is here“.

Poznámka: Pokud by se nějaký z čtenářů rozhodl aplikaci skutečně důkladně vyzkoušet, pak by bylo zřejmě na závadu, že současně s ním ji může libovolně ovlivňovat kdokoliv další. V případě vážnějšího zájmu mne prosím kontaktujte na herout@kiv.zcu.cz a já bych vám nasdílel WAR pro lokální experimenty.