Testování softwaru

Základní pojmy

Ke správnému pochopení problematiky testování softwaru je nezbytné nejprve vyložit několik základních pojmů, na kterých testování softwaru postaveno.

Softwarová chyba

Softwarová chyba (angl. Software bug) je chyba, vada, omyl nebo selhání v počítačovém programu které brání vykonávání původně zamýšlené činnosti (tj. produkování správného výsledku) [WIKI3]. Jedná se o běžný, jev který se nevyhne žádnému složitějšímu softwarovému projektu. Jeden z axiomů testování tvrdí, že čím více chyb najdete, tím více jich v testovaném softwaru ještě je [PAT02] a námi nalezené chyby tvoří pouze špičku pomyslného ledovce. Další z axiomů testování říká, že testování nám nikdy nezaručí, že v aplikaci žádné chyby nejsou [PAT02]. Můžeme se tedy alespoň pokusit vyčistit testovanou aplikaci od těch nejzávažnějších.

Kvalita

Kvalita představuje dle [VEE07] míru, jakou testovaný software splňuje specifikované požadavky, uživatelské potřeby a očekávání. Vyčerpávající definici kvality nám poskytne mezinárodní standard pro hodnocení kvality softwaru ISO 9126, který definuje kvalitu na základě šesti hlavních charakteristik (funkcionalita, spolehlivost, použitelnost, efektivnost, udržovatelnost a přenositelnost) rozdělených dále do celkem 21 vedlejších charakteristik. Každá vedlejší charakteristika obsahuje soubor atributů, které můžou být měřeny a ověřovány na konkrétním softwarovém produktu [WIKI7].

Testování softwaru

Testování software je termín, který můžeme definovat několika způsoby podle pohledu na danou problematiku. Pokud se na testování softwaru díváme jako na činnost, můžeme se spokojit s nejčastěji se vyskytující a všeobecně přijímanou definicí tj. testování softwaru je hledání chyb v softwaru. Toto tvrzení je pravdivé, i když nepokrývá všechny aspekty testování softwaru. I když je provádění testů a hledání chyb hlavní náplní testování softwaru mezi další aktivity patří také činnosti s plánováním, přípravou a vyhodnocením testů. Pokud bychom tedy chtěli testování softwaru definovat na základě prováděných činností, mohli bychom ho popsat jako plánování, přípravu, provedení a vyhodnocení testů za účelem odhalení chyb v softwaru. Dle [VEE07] je testování softwaru proces sestávající ze statických a dynamických aktivit napříč všemi životními cykly softwarového produktu, který má odhalit chyby, určit že produkt splňuje specifikované požadavky a  splňuje svůj účel.

Při pohledu na testování softwaru jako na samostatný obor v rámci vývoje softwaru narazíme na odlišné definice, např. dle [WIKI1] je testování softwaru proces užívaný k měření správnosti, úplnosti, bezpečnosti a kvality vyvinutého softwaru.

Pozice testování ve vývoji softwaru

Testování softwaru má své pevné místo prakticky ve všech metodikách vývoje softwaru. Ať již prováděno zkušeným testovacím týmem v případě velkých projektů nebo samotnými programátory v případě projektů menších.

Vodopádový model

Vodopádový model představuje klasický způsob vývoje softwaru. Fázi testování v tomto modelu nacházíme po fázi implementace, kdy je vše naprogramováno a aplikace je připravena k otestování a případnou opravu chyb. Tento přístup je vhodný pro malé projekty, u kterých je možné nalezené chyby v rámci časového úseku naplánovaného pro testování opravit. Růst velikosti a náročnosti projektu je přímo úměrný času a prostředkům nutným na nalezení a opravu chyb.

Obrázek : Pozice testování softwaru vodopádovém modelu vývoje

Iterativní model

Iterativní model rozděluje proces vývoje do několika iterací. Výsledkem každé iterace je spustitelná verze softwaru. Testování je zařazeno, podobně jako u vodopádového modelu, po implementační fázi. Díky opakujícím se iteracím a menším celkům, které se testují, je proces testování efektivnější a flexibilnější než u vodopádového modelu.

U některých metodik, používajících iterativní model vývoje softwaru, byly hranice mezi jednotlivými fázemi odstraněny a každá z nich, včetně testování, probíhá s různou intenzitou souběžně s ostatními. Díky tomuto přístupu můžeme při pokrytí postupného vývoje aplikace vhodnými druhy testů zvýšit šance na nalezení a odstranění chyb v ranném stádiu, kdy je jejich odstranění nejjednodušší a nejlevnější.

Způsob testování softwaru

Manuální testování

Základním principem manuálního testovaní je procházení testovanou aplikaci, hledání a záznam chyb. Postup testera testovanou aplikací je dle zvolené metody testování zcela náhodný nebo se drží předem připraveného scénáře s přesně definovaným průchodem testovanou aplikací a akcemi, které se mají provést. Manuální testování je pracný proces a od testera vyžaduje značnou dávku trpělivosti, všímavosti, kreativity a důmyslnosti [WIKI3].

Výhodou manuálního testování je jednoduchost. Jeho provádění může při dobré organizaci a vedení probíhat bez nákladných softwarových nástrojů. Při jednoduchých manuálních testech také nejsou potřeba příliš zkušení a proškolení testeři. Díky lidskému důvtipu a nepředvídatelnosti lze v testované aplikaci docílit mnoha zajímavých stavů, které by se jinak obtížně navozovali a otestovat tak chování aplikace v extrémních podmínkách.

Mezi nevýhody manuálního testování patří časová náročnost a s ní souvisejí náklady na lidské a finanční zdroje. S růstem projektu dochází k odpovídajícímu, téměř lineárnímu růstu času a nákladů nutných k dostatečnému otestování vyvíjené aplikace.

Dalším problémem manuálního testování je volba rozsahu testů. Při obrovském množství kombinací vstupů, podmínek a postupů, které můžeme při testování použít, je úplné manuálního otestování libovolné aplikace prakticky nemožné. Náklady na testování stoupají úměrně s požadovanou kvalitou a rozsahem testů, a proto musí být zvolen kompromis mezi rozsahem testů a náklady.

Automatické testování

Princip automatického testování spočívá v zaznamenání nebo vyvolání požadované činnosti v testované aplikaci pomocí určitého nástroje pro automatické testování softwaru a následné přehrání a vyhodnocení této činnosti. Lidský zásah je nutný pouze v počáteční fázi záznamu a tvorby automatického testu a případně při jeho vyhodnocení. Samotný test probíhá zcela automaticky.

Mezi výhody patří nízké náklady na samotný provoz, protože veškerou činnost obstarává samotný nástroj bez nutnosti lidského zásahu. Absence lidského faktoru v procesu testování také eliminuje případné chyby a omyly, které vznikají díky lidské nepozornosti. 

I přes zjevné výhody se automatické testování potýká s mnoha překážkami. Největší z nich jsou vysoké počáteční náklady, časová a organizační náročnost celého řešení a potřeba kvalifikovaných lidských zdrojů.

Problematice automatického testování softwaru se budu dále podrobněji věnovat ve 3. kapitole mé bakalářské práce.

Tabulka : Výhody a nevýhody automatického a manuálního testování

Přístup k testování softwaru

Testování černé skříňky

Při testování černé skříňky přistupujeme k testované aplikaci jako k automatu, do kterého vložíme vstupní hodnoty a očekáváme výsledek, který by měl podle specifikace z automatu vypadnout. Nevidíme vnitřní strukturu testované aplikace, tj. její zdrojový kód, funkce, které se odehrávají uvnitř ani způsob jakým bylo z námi zadaných vstupů dosaženo výsledku. Zajímá nás pouze správnost dosažených výsledků.

Testování bílé skříňky

Pokud jsme při testování černé skříňky zkoumali výsledky bez znalosti vnitřních pochodů, pak je testování bílé skříňky jejím pravým opakem. Známe zdrojový kód a vnitřní strukturu testované aplikace a na základě těchto znalostí můžeme co nejefektivněji určit vstupní data pro otestování dané aplikace. Testování bílé skříňky klade zvláštní nároky na testera, který se mimo znalostí z oblasti testování softwaru neobejde bez znalosti programování a dokonalé orientace ve zdrojovém kódu testované aplikace.

Testování šedé skříňky

Testování šedé skříňky je kombinací předchozích typů. Testovanou aplikaci testujeme jako černou skříňku, ale zároveň jako doplnění testů nahlížíme do její činnosti [PAT07].

Testování dle typu testů

Vzhledem k náročnosti a variabilitě testovacího procesu v různých prostředích, je důležitou otázkou volba typů testů, které budou navrženy, implementovány a provedeny. V testovacím procesu by měl být vždy kladen důraz na to, aby testy pokryly všechny rozměry kvality softwaru. Pro tento účel můžeme použít model FURPS sloužící ke specifikaci požadavků a sledování jejich naplnění. Jednotlivé rozměry kvality v tomto modelu (funkčnost, použitelnost, spolehlivost, výkon a podpora) lze pokrýt určitými typy testů.

Funkční testování

Účelem funkčního testování je ověřit zda testovaná aplikace splňuje svými funkcemi business požadavky dané specifikací [WIKI1].

Testování použitelnosti

Testování použitelnosti zahrnuje testování všech částí aplikace, které se dostanou do přímého kontaktu s uživatelem. Jedná se o uživatelské rozhraní, dokumentaci, nápovědu nebo školící materiály. Účelem je ověřit, zda je daná část aplikace použitelná a srozumitelná pro běžného uživatele.

Testování spolehlivosti

Cílem testování spolehlivosti je ověřit stabilitu systému a jeho chování v nestandardních a krizových situacích.

Testování výkonu

Testování výkonu se zaměřuje na testování práce systému pod vysokou zátěží, rychlostí odezvy systému za určitých podmínek a schopnosti zvládat přístupy více uživatelů najednou.

Testování podpory

Testováním podpory se rozumí ověření práce systému na různých konfiguracích, jeho udržovatelnost a adaptabilita.

Testování dle počtu opakování testů

Progresní testování

Progresní testování probíhá při prvním spuštění testu který testuje novou funkcionalitu.

Re-testy

Účelem re-testů je otestování určité oblasti funkcionality poté, co byla v této oblasti opravena chyba a ověření skutečného odstranění této chyby.

Regresní testování

Regresní testování je opakované provádění stejné sady testů, které je v ideálním případě prováděno vždy se změnou aplikace nebo testovacího prostředí. Jeho účelem je ověřit stávající funkce nové verze testované aplikace a zjistit, zda změny a opravy nepřinesly žádné další chyby v dosud fungujících částech aplikace.

Testování softwaru dle fází vývoje

Unit testy

Testování jednotlivých částí zdrojového kódu, konkrétně nejmenších testovatelných částí (funkcí a procedur u procedurálního nebo metod u objektového programování). Účelem je ověřit že tyto individuální části zdrojového kódu pracují správně [WIKI4]. Takto otestované moduly slouží jako vstupy pro integrační testy.

Integrační testy

Účelem integračních testů je odhalit chyby v rozhraních a interakcemi mezi jednotlivými komponentami [VEE07]. Jako vstupy pro integrační testování slouží moduly, které byly otestovány pomocí Unit testů.

Systémový test

Systémové testování je testování provedené na kompletním, integrovaném systému, které má ohodnotit jeho shodu se specifikovanými požadavky [WIKI5]. Jako vstupy slouží softwarové komponenty, které prošly integračními testy.

Uživatelský akceptační test

Formální testování s důrazem na uživatelské požadavky a business procesy sloužící k ověření zda systém splňuje nebo nesplňuje akceptační kritéria, a které umožňuje zadavateli, uživatelům nebo jiným pověřeným osobám vyslovit svůj souhlas nebo nesouhlas s předkládaným systémem [VEE07]. Uživatelský akceptační test se provádí před samotným dodáním hotového systému a jsou do něj zapojeni koncoví uživatelé a ostatní zainteresované osoby. Pokud proběhnou úspěšně, testovaná aplikace je přijata a připravena k implementaci u zadavatele. V opačném případě nastává další kolo testování a opravy chyb, které je u chyb nalezených v takto pokročilé fázi vývoje aplikace značně nákladné a nepříznivě ovlivňuje náklady na celý projekt.

Obecný postup testování softwaru

Cíl testování

Z obecné definice testování softwaru vyplývá, že jeho cílem je ověření shody testované aplikace a její specifikace. Pokud bychom zvolili konkrétnější definici cíle testování můžeme říci, že cílem testování je objevit co možná nejvyšší počet softwarových chyb [WIKI1]. Tento jednoduše definovaný cíl doplňuje definice cíle testování z [PAT02], který tvrdí že cílem softwarového testera je vyhledávat chyby, vyhledávat je co nejdříve a zajistit jejich nápravu.

Role v testovacím týmu

Vhodné rozdělení rolí a odpovědnosti v testovacím týmu je důležité k hladkému průběhu a efektivitě celého testování. Hlavou testovacího týmu je vedoucí testů. Jeho úkolem je příprava plánu testů, rozděluje práci mezi jednotlivé členy týmu a dohlíží a zodpovídá za celý testovací proces. Na přípravě plánu testů spolupracuje s analytikem testů, k jehož dalším úkolům patří vyhodnocení provedených testů a vhodné nastavení testovacího procesu. Příprava samotných testových procedur spadá do kompetence designéra testů. Samotní testeři vykonávají jednotlivé testy a zaznamenávají nalezené chyby.

Definování požadavků

Před začátkem testování je nutné shromáždit kvalitativní a kvantitativní požadavky na testovanou aplikaci. Tyto požadavky se nejčastěji získávají z jejího návrhu a specifikace. Takto sebrané požadavky slouží jako podklad pro vytvoření testovacího plánu.

Plánování a tvorba testů

Základ pro plánování a tvorbu testů tvoří plán testů. Jedná se o dokument obsahující zaměření, přístup, zdroje a časový harmonogram zamýšlených testovacích aktivit. Jsou v něm identifikovány a popsány testovací objekty, vlastnosti, které mají být otestovány, rozdělení testů mezi jednotlivé členy testovacího týmu, testovací prostředí, techniky návrhu testů, vstupní a výstupní kritéria s důvodem jejich volby [VEE07].

Na základě plánu testů jsou vytvořeny příslušné testy, resp. testové procedury. Jedná se o záznam specifikující postup akcí nutných pro vykonání testu [VEE07]. K nim se váže příprava příslušných testovacích dat.

Poslední akcí předcházející samotnému spuštění testů je tvorba testovacího prostředí. Jedná se o   prostředí obsahující hardware, software, simulátory, softwarové nástroje a další prvky potřebné pro provedení testů [VEE07]. Jeho hlavním účelem je oddělení testování od procesu vývoje, popřípadě opravy chyb, které by se mohly vzájemně ovlivňovat a narušit přesnost a správnost testovacího procesu.

Spuštění a vyhodnocení testů

Podle plánu testů je spuštěno samotné testování. Výsledky provedených testů se zaznamenávají a slouží k pozdější dokumentaci. Nalezené chyby a problémy jsou předány vývojovému týmu, který má na starosti jejich řešení. Po jejich opravě se znovu otestují nebo jsou otestovány v rámci dalšího kola testování, které probíhá až do dosažení požadovaných akceptačních kritérií ze strany zadavatele.

Nutno podotknout že ne všechny chyby musí být odstraněny okamžitě po jejich nalezení. V závislosti na čase a prostředcích vyčleněných na jejich opravu může být oprava některých chyb odsunuta, nemusí být z časových a technických důvodů vůbec opravena,   popřípadě může být šalamounsky vyřešena prohlášením za dodatečnou vlastnost systému.

Ukončení testování

Testování je ukončeno, pokud aplikace projde závěrečnými akceptačními testy a je připravená k implementaci.