Druhý z minisérie článků popisujících zkušenosti získané při testování webové aplikace pomocí automatických funkcionálních testů. Seznámíte se s charakterem testované aplikace a s hlavními výsledky testování.
Druhý z minisérie článků popisujících zkušenosti získané při testování webové aplikace pomocí automatických funkcionálních testů. Seznámíte se s charakterem testované aplikace a s hlavními výsledky testování.
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é.
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:
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.
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.
celkově řádek | řádek kódu | ||
---|---|---|---|
Aplikace UIS | Java | 6 652 | 3 109 |
JSP | 1 536 | 1 536 | |
dohromady | 8 188 | 4 645 | |
Testy | Jednotkové | 6 400 | 3 998 |
Functionální | 16 116 | 10 441 | |
dohromady | 22 516 | 14 439 | |
poměr testy / UIS | 2,75 | 3,11 |
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.
Pracuje na Katedře informatiky a výpočetní techniky Fakulty aplikovaných věd na Západočeské univerzitě v Plzni, zabývá se programovacími jazyky, softwarovými technologiemi a testováním.
Internet Info Root.cz (www.root.cz)
Informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2019 Internet Info, s.r.o. Všechna práva vyhrazena.