Testování programových systémů
Metody testování, typy testování. Validace, verifikace, akceptace.

Metody testování

Testování obecně:

• proces spouštění programu (IS?) za účelem nalezení chyby
• úspěšný test je takový, který objevil dosud neobjevené chyby
• může ukázat, že pro určitá data program vyhovuje požadovaným specifikacím. Je to indikací spolehlivosti a kvality softwaru.
• testování má zvýšit pravděpodobnost, že v programu nejsou chyby
• měly by vztahovat k požadavkům zákazníka
• měly být plánovány v předstihu (plánovat je jakmile jsou specifikovány požadavky, navrhnout data, jakmile je proveden návrh programu.)
• úplné otestování není možné (nelze otestovat počet všech kombinací cest programem)

Principy testování:

Testy by se měly vztahovat k požadavkům zákazníka (většina defektů z pohledu zákazníka se projeví neshodou s požadavky). Testy by měly být plánovány v předstihu (plánovat je jakmile jsou specifikovány požadavky, navrhnout data, jakmile je proveden návrh programu.) Princi Pareto: většina všech neobjevených chyb má původ v několika málo modulech. Problémem je ty moduly nalézt.

Testování by mělo začít testováním “v malém” a pokračovat testování “ve velkém”. (Začít testováním modulů, pak integrovaných skupin (clusterů) modulů a nakonec celého systému). Úplné otestování není možné (nelze otestovat počet všech kombinací cest programem). Testování by mělo být vedeno nezávislou třetí stranou (jiný úhel pohledu, snaha nalézt chybu, ne dokázat, že tam není)

Testovatelnost:

Výčet vlastností vedoucích k dobré testovatelnosti:

operability - spustitelnost (čím lépe pracuje, tím účinněji může být otestován), chyby nebrání běhu programu, může být testován a vyvíjen současně

observability - přehlednost (testuješ, co vidíš) - různé výstupy pro různé vstupy, stavy systému a proměnné jsou viditelné během chodu, faktory ovlivňující výstup jsou viditelné, nesprávné výstupy jsou lehce identifikovatelné, vnitřní chyby jsou automaticky detekovány a zaznamenávány, je dostupný zdrojový kód

controllability - (čím lépe lze software kontrolovat/řídit, tím spíše lze testování automatizovat a optimalizovat) - všechny možné výstupy jsou generovány nějakou kombinací vstupů, veškerý kód je spustitelný nějakou kombinací vstupů, vstupní a výstupní formát je konsistentní a strukturovaný, testy mohou být specifikovány, automatizovány a reprodukovány

dekomponovatelnost - (kontrolováním rozsahu testování můžeme rychleji oddělit problémy a provést následné testy)

jednoduchost - (čím méně máme testovat, tím rychleji to můžeme provést) - jednoduchost funkce, struktury, kódu

stabilita - (čím méně změn softwaru, tím lépe) - nejsou časté, jsou řízené, neovlivní provedené testy

srozumitelnost - (čím víc máme informací, tím budou testy chytřejší) - srozumitelný návrh, srozumitelné závislosti mezi vnitřními, vnějšími a sdílenými komponentami, dostupnost a srozumitelnost technické dokumentace

White-box testing (strukturální testování)

• vychází ze znalosti programové řídicí struktury. Testy by měly vyzkoušet alespoň jeden průchod všemi příkazy a vyzkoušet všechny logické podmínky.
• je to testování v malém, pro malé programy a moduly
• testování toho, zda všechny vnitřní komponenty správně fungují (ale nemusí postihnout chybějící alternativy)
• všechny samostatné cesty uvnitř modulu budou provedeny alespoň jednou
• všechny podmínky se projdou podél větve s hodnotou ANO (true) i podél větve s hodnotou NE (false)
• projde všechny cykly
• prověří vnitřní datové struktury

Black-box testing (funkcionální testování)

• hledá chyby ve funkčním chování, bez ohledu na jejich implementaci. Je zaměřeno na informační doménu, odvozuje testovací data ze vstupních a výstupních podmínek.
• testování správného provádění všech navržených funkcí produktu (ale nemusí postihnout všechny podrobnosti implementace)
• je založeno na funkčních požadavcích.
• vzhledem k white-box testing jde o doplňkovou nikoli alternativní metodu
• aplikuje se až po white-box testing.

Hledá:

• nesprávné nebo chybějící funkce
• chyby rozhraní
• chyby datových struktur nebo přístupu k externím databázím
• chybné chování (performance)
• chyby
• inicializace nebo skončení

Speciální metody testování jsou pro různé typy programů a aplikačních oblastí - GUI, klient/server, real time, dokumentace a help.

Typy testů

1.) Unitní testy

Každý vývojář by si měl svou práci vždy sám otestovat. V rámci testování by se měl zaměřit i na to, jestli používá vhodné algoritmy, návrhové vzory, datové typy atd.

2.) Integrační testy

Cílem těchto testů je zjistit, zda spolu jednotlivé moduly spolupracují tak, jak mají.

Regression test
Ověření, zda se v důsledku změny neobjevila chyba tam, kde to předtím již bylo v pořádku.

Incremental Integration Test
Provádí se v okamžiku, kdy je ke stávajícím již otestovaným modulům přidán další.

Smoke test
Test, zda je systém připraven na hloubkový systémový test, aniž by spadnul. To je důležité, protože kdybychom tento test přeskočili, mohlo by se stát, že by v hloubkovém systémovém testu došlo k pádu a v testování by se nemohlo pokračovat.

3.) Systémové testy

Cílem těchto testů je ověřit, že produkt splňuje všechny požadavky.

Recovery test
Účelem je otestovat, jak rychle a zda vůbec se produkt vzpamatuje po pádu systému, HW chybě, výpadku proudu atd. Tento požadavek by měl být uveden v SRS dokumentu v sekci nefunkčních požadavků.

Security test
Odhalují, jak a zda vůbec se systém chrání před neautorizovaným přístupem, jak jsou ukládána hesla, jak je řízen přístup, jak je implementována integritní ochrana. Slouží k nalezení nežádoucího kódu, bezpečnostních chyb, zranitelností.

Stress test
Cílem je ověřit, zda při velké zátěži, která může být vygenerována automaticky např. provedením velkého počtu složitých dotazů, a nedostatku zdrojů, nedojde k chybě, která by se za normálního provozu neobjevila.

Performance test
Při tomto testu systém odolává velkému počtu různých požadavků a sleduje se, jaká je jeho odezva, resp. jak je ovlivněn výkon aplikace, např. jak rychle je aplikace schopna na jednotlivé typy požadavků odpovídat. Tím lze vysledovat, které části systému je třeba věnovat větší pozornost a provést v ní příslušné optimalizace (Může to být refaktorizace kódu, ale stejně tak i prosté vytvoření indexů nad tabulkou databáze.)

Installation test
Testuje se, jak probíhá instalace a odinstalce produktu na dané platformě.

4.) Akceptační testy

Alpha test
Tyto testy ve vývojovém prostředí provádí někdo jiný než vývojový tým, ten to jen sleduje a poskytuje podporu.

Beta test
Tyto testy probíhají v prostředí zákazníka a chyby jsou reportovány vývojářům dohodnutou cestou pomocí připravených formulářů.

Acceptance test
Provádí zákazník ve svém testovacím prostředí a ověřuje, zda produkt je v souladu s požadavky ve specifikaci a zda se v jeho prostředí chová tak, jak má.

Long Term Test
Tyto testy slouží k odhalení chyb, které se zpravidla vyskytnou až po delší době používání aplikace.

Další možné rozdělení

Ruční testování

• tester testuje aplikaci a její funkce - většinou se to týká uživatelského rozhraní na klientské vrstvě (př. přihlášení do aplikace, proklikání menu aplikace, vyplnění formuláře a uloženi apod.) nebo něčeho co nelze dobře otestovat automatizovaně

Automatizované testování

• používá se k tomu nějakého nástroje pro ten účel
• nejprve se napíše scénář pro testování (může to byt i rozsáhlý program v nějakém programovacím jazyce nebo jen vstupní data)
• scénář může pokrývat opakovaně testovaní určité funkce nebo části aplikace nebo informačního systému, může se jednat o simulace i několika tisíc uživatelů paralelně tedy ve stejný okamžik pro stejnou funkčnost ale rozdílná data
• součástí bývá přehled statistik a reportu pro porovnávání výsledků apod.

Validace, verifikace, akceptace

·     verifikace – ověření, pravda, to co je specifikované zda bylo realizováno (implementováno)

o  zda je systém udělaný dobře a nemá chyby

o  potvrzení správnosti, pravosti, ověřování

·     validace – to co zadal klient je to co jsme udělali

o  systém dělá co zákazník chtěl

o  ověření, prověření

·     akceptace– je součástí smlouvy, píše se před formální specifikací, klient mu musí rozumět

o  klient podle něj testuje sw posloupností operací a musí se stát to co chtěl

o  posloupnost operací která se provádí a dojde se podle ní k výsledku

Akceptační test  (Akceptace)

·     podklad pro ověření funkčnosti řešení

·     typický podklad smlouvy, obvykle ho sepisuje třetí strana

·     vše co musím udělat např.: od přihlášení až po vytištění faktury

·     důležitý pro validaci softwaru – ověření, zda navržené specifikace splňují požadavky zákazníka, tzn. testy jsou navrhované na základě analýzy požadavků zákazníka.

·     cílem a základním kritériem testů je prokázat, že aplikace splňuje všechny požadavky specifikované zákazníkem, zejména funkčnost softwaru, popřípadě i další vlastní specifikace zákazníka, například tvaru a funkčnosti vnějších rozhraní.

·     neměly by být navrhovány příliš obecně, ani příliš do hloubky, mělo by být nalezeno optimum, aby akceptačnímu testu zákazník rozuměl a aby byla dostatečně a jasně specifikována definice testu.

·     provádí se v testovací fázi životního cyklu softwaru. Zákazník podepisuje akceptační test současně se smlouvou a přijímá tím podmínky a definici akceptačního testu.

·     klient podle něj testuje sw posloupností operací a musí se stát to co chtěl

·     posloupnost operací která se provádí a dojde se podle ní k výsledku

Definice akceptačního testu, který se přikládá ke smlouvě musí obsahovat následující náležitosti: 

1. podmínky pro akceptační test – za kterých bude splněn

·     popis prostředí, ve kterém bude akceptační test probíhat. Není-li v akceptačním testu prostředí explicitně stanoveno, musí být možno akceptační test vykonat v rámci standardního prostředí

·     popis všech vstupních dat, která budou v akceptačním testu využívána. Patří sem popis všech databází, konfiguračních souborů a jiných testovacích dat, která budou v akceptačním testu využívána.

2. dokumentaci pro akceptační test – jak se to má dokumentovat

·     dokumentace potřebná pro vytvoření a instalaci produktu

·     uživatelská příručka

·     definice akceptačního testu

·     protokol o provedení akceptačního testu – zda byl proveden, jestli s asistencí nebo bez nebo zda bylo vše automatizované

3. definici akcí pro akceptační test – postup aby naplnil scénář

·     popis všech scénářů, které budou tvořit akceptační test. Sada scénářů musí zaručit dostatečné ověření funkčnosti řešení

·     pro scénáře, pro které je možno stanovit požadovanou reakci systému, je součástí akceptačního testu i popis odpovídajících reakcí

·     scénáře akceptačního testu musí zahrnovat i základní chybové situace (např. zadání špatného hesla) a jejich řešení

·     vychází se z životního cyklu systému

·     mělo by jich být dostatečně tolik aby to ověřilo systém

·           je na uživatelské úrovni

·           nedělá programátor!!!