Testovací případ

V tomto příspěvku se dozvíte, co je to testovací případ, jaké typy testovacích případů máme a jaké informace by měl testovací případ obsahovat.

Testovací případ (test case) definuje postup, jak otestovat daný požadavek. Pokud hovoříme o požadavcích, máme na mysli funkční a nefunkční požadavky uváděné většinou v SRS (Software Requirements Specification) dokumentu. Testovací případ popisuje, jak otestovat požadovanou funkčnost, to znamená, co má být zadáno na vstupu a co lze očekávat na výstupu. Testovací případy si můžeme rozdělit na logické a fyzické.

• Logický testovací případ (logical test case) je abstraktní popis toho, co se má otestovat, definuje obor a množinu hodnot.
• Fyzický testovací případ (physical test case) je konkrétní popis toho, co se má otestovat, definuje jaké hodnoty se mají zadat.

Doporučuji vždy začít návrhem logického testovacího případu a poté k němu vytvořit odpovídající fyzické testovací případy (obvykle k jednomu logickému případu existuje několik fyzických). Každý testovací případ by měl:

• mít přidělen jednoznačný identifikátor,
• mít stanovenu prioritu,
• obsahovat stručný popis předmětu testu,
• uvádět, jaké hodnoty se mají zadat na vstupu,
• uvádět, jaká je očekávaná doba zpracování,
• uvádět, jaké hodnoty je možno očekávat na výstupu,
• mít předepsáno na jaké HW a SW konfiguraci se má test provést,
• uvádět, jaký test má tomuto testu předcházet.

Nyní si výše uvedené požadavky na ideální testovací případ stručně popišme.

Jednoznačná Identifikace testovacího případu
Aby bylo možné jednotlivé testovací případy vyhodnotit a případně zopakovat, musí mít každý testovací případ přidělen jednoznačný identifikátor. Nezapomínejte na to, že stejný test může být prováděn více testery. To je další důvod, proč je jednoznačná identifikace nutná.

Priorita testovacího případu
Pokud nebyla ve fázi requirements development podceněna prioritizace požadavků, stačí již jen přihlédnout k tomu, jaký dopad by měla chyba na business zákazníka a podle toho výslednou prioritu testovacího případu stanovit.

Popis testovacího případu
Doporučuji u každého testovacího případu uvádět kromě stručného popisu i odkaz na dokumentaci, kde je uveden detailní popis vlastnosti, která má být testována. Jedině tak lze zajistit, že předmětné vlastnosti budou pokryty odpovídajícími testovacími případy. Další důvod je ten, že lidé obvykle dosahují lepších výsledků, pokud rozumí tomu, co vlastně dělají.

Vstup
Vstupem je obvykle hodnota zadaná z klávesnice, vybrána myší nebo načtená ze souboru. Doporučuji věnovat zvýšenou pozornost datovému typu, jeho syntaxi, délce a hraničním hodnotám. Testujte také, jak se aplikace zachová a jaký je výsledek operace pokud zadáte číslo mimo rozsah, desetinnou čárku místo tečky a naopak, číslo se zápornou hodnotou, matematický výraz nebo textový řetězec tam, kde aplikace očekávala číslo.

Zpracování
Mezi vstupem a výstupem obvykle dochází k nějakému zpracování. U některých typů testů nás zajímá i doba zpracování, v takovém případě by měla být uvedena konkrétní hodnota, které se má dosáhnout. Pokud je v SRS dokumentu požadována okamžitá odezva, jedná se sice o nefunkční požadavek, ale špatně definovaný, protože každý z nás může mít o okamžité odezvě zcela jinou představu. Takový požadavek by měl být vrácen a upřesněn.

Výstup
Výstup je obvykle zobrazen na obrazovce nebo zapsán do souboru. Pokud máme výstup porovnávat s očekávanou hodnotou, musí být očekávaná hodnota nebo alespoň její rozsah uveden.

HW a SW konfigurace
Pokud má mít testování nějakou vypovídající hodnotu, musí být definováno na jaké HW a SW konfiguraci se mají jednotlivé testovací případy provádět. Prostředí, kde je daná aplikace hostována, je většinou dostatečně popsáno, problém však často bývá s popisem prostředí, ze kterého se testy spouští. Pokud budeme uvažovat webovou aplikaci, ke které se přistupuje prostřednictvím tenkého klienta (browseru), měli bychom popsat nejen typ a verzi OS, ale i typ prohlížeče a na jakých verzích se má testování provádět. Pokud hovořím o SW konfiguraci, mám na mysli například i to, že výsledky testování a tedy i vlastní funkčnost daného SW mohou ovlivnit i zdánlivě takové maličkosti, jako je zapnutí nebo vypnutí java skriptu, ActiveX komponenty či cachování. I tuto skutečnost je nutné vzít při návrhu testů v potaz. Největším problémem samotného testování tak může být rozhodnutí o tom, na jakých HW a SW konfiguracích by se mělo testování provádět. Ale i odpověď na tuto otázku bychom měli nalézt v SRS dokumentu. Je zřejmé, že není možné aplikaci otestovat na všech možných konfiguracích a je nutné se smířit s tím, že na některých konfiguracích daná aplikace prostě fungovat nebude. Z tohoto důvodu by vždy mělo být uvedeno, na jakých HW a SW konfiguracích bylo testování provedeno.

Předcházející test
V některých případech nemůže test začít dříve, než jiný test skončí. Tato informace nabývá na významu obzvlášť v případech, kdy se testování účastní více testerů.

A jak stanovujete prioritu testovacího případu vy?

Štítky: Testování SW

Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.