Category Archive: Metodika testování

Subcategories: Druhy, typy a kategorie testů 

Fáze a úrovně provádění testů

Základní úrovně testování jsou definovány jako soubor testů, kterými je software testován na daném stupni podrobnosti. Podle toho v jaké fázi a s jakým časovým odstupem od sepsání kódu, se testování provádí, jej dělíme do pěti základních úrovní:


.advertisement

Testování programátorem

Ihned po vytvoření programového kódu, je tento kód prověřen programátorem. v praxi jsou tyto testy označovány jako „Assembly tests„. Většinou si však programátor netestuje svoji část kódu, ale realizuje se tzv. „test čtyř očí“. To znamená, že kód testuje jiný programátor, než ten který jej napsal. Program je v tomto stupni kontrolován na úrovni zdrojového kódu. V praxi je bohužel tento stupeň testování často podceňován. Přitom opravy chyby v této části testování software je nejméně nákladná. Sám jsem byl svědkem toho, jak vývojář, aniž by si po sobě jakkoliv zkontroloval kód, předal program k dalšímu testování. Tester se připravil k vlastnímu testování (nastuduje si dokumentaci, připraví testovací data apod.) a začal provádět testy. Záhy však zjistil, že program nelze spustit a nemůže tak ani začít samotné testování. Nahlásil tedy chybu tvůrci programu a ten ji posléze začal opravovat. Tester se tak zbytečně připravoval a začínal provádění testů. Kdyby si po sobě programátor zkontroloval kód dříve, zjistil by chybu mnohem rychleji než tester. Samotná oprava chyby by tak zabrala výrazně méně času. Takovéto postupy zbytečně zabírají čas i ostatním členům týmu.

Testování jednotek

Po ověření kódu programátorem přichází na řadu test jednotek. U objektově orientovaného programování se jedná o testování jednotlivých tříd a metod. Testovanou jednotkou v tomto případě rozumějme samostatně testovatelnou část aplikačního programu. Testy těchto jednotek se zapisují ve formě programového kódu. Proto jej z pravidla obsluhují vývojáři. Pro vytváření testů se využívá nástrojů na bázi frameworků.
Testy jednotek se velmi špatně aplikují na již zaběhlých projektech. U již vytvořených aplikací se většinou musí provést kompletní refaktoring kódu či dokonce mnohem hlubší úpravy. Takováto časová investice se u menších projektů většinou nevyplatí, ale ani u velkých projektů takovýto zásah není příliš šťastný a často se nesetkává s podporou u vedoucího projektu. Proto je vhodné zabývat se těmito testy již v etapě návrhu aplikace a v té době se rozhodnout, zda tyto testy budeme využívat. Jelikož obecně platí, že čím dříve (v rámci životního cyklu software) chybu nalezneme a opravíme, tím méně času nad touto opravou strávíme. Proto bych doporučoval této úrovni věnovat maximální pozornost a to již před samotným vývojem aplikace.

FAT – Funkční testy

Factory acceptance tests (FAT) je fáze během níž jsou testy prováděné na straně dodavatele. Během FAT jsou exekuovány především Funkční testy – ty jsou popsané ve zvláštním příspěvku. Aplikace nemusí být testována na plně integrovaném prostředí. Splnění akceptačních kritérií na konci FAT je nutnou podmínkou pro vstup do následující fáze SIT.

Integrační testování

V době, kdy je vývojář hotov se svými testy, přichází na řadu testovací tým. Integrační testy tedy nepřipravuje programátor, ale především testovací tým. Někdy bývají označovány jako „testy vnitřní integrace“. Musí být ověřena bezchybná komunikace mezi jednotlivými komponentami uvnitř aplikace. Integraci však lze ověřovat nejen mezi komponentami, ale také mezi komponentou a operačním systémem, hardwarem či rozhraním různých systémů. V této fázi se tak testuje integrace dosud jednotlivě ověřených částí. Postupně začínáme testovat integraci mezi dvěma komponentami a postupně přidáváme další. Integrační testy mohou být jak manuální, tak i automatizované.
Úroveň integračního testování je svým způsobem obsažena ve většině testovacích postupů softwaru. U menších projektů je však na tyto testy kladen velmi malý důraz. Má to své logické odůvodnění. Integrační testování lze v testovacím cyklu zcela vynechat. Na výslednou bezporuchovost softwaru to přitom nebude mít žádný vliv, tedy alespoň za předpokladu, že korektně provedeme následující úrovně testování. Chyba, kterou bychom odhalili během integračních testů, se zcela jistě projeví v průběhu dalších úrovní testování. Jak již bylo zmíněno dříve, během testování však platí: „čím dříve chybu objevíme, tím méně úsilí nás stojí její oprava“. Proto integrační testy mají svůj význam, nicméně nelze jejich použití nikterak přeceňovat.

Systémové testování

Spojení Integračních i Systémových testů je označována jako fáze SIT – System Integration Tests. Po ověření správné integrace nastává ten pravý čas na systémové testování. Během těchto testů je aplikace ověřována jako funkční celek. Tyto testy jsou používány v pozdějších fázích vývoje. Ověřují aplikaci z pohledu zákazníka. Podle připravených scénářů se simulují různé kroky, které v praxi mohou nastat. Obvykle probíhají v několika kolech. Nalezené chyby jsou opraveny a v dalších kolech jsou tyto opravy opět otestovány. Součástí této úrovně jsou jak funkční tak nefunkční testy. Poslední úroveň testů, které se provádějí před předáním produktu zákazníkovi, jsou tedy systémové testy. Tato úroveň testů tak většinou slouží jako výstupní kontrola softwaru. Systémové testování je obsaženo prakticky v každém procesu testování. Bez této úrovně by celé testování softwaru nemělo žádný význam. Bezporuchovost výsledného produktu by byla významně ohrožena. Proto tuto úroveň testů považuji za stěžejní v celém postupu testování software. Na realizaci těchto testů by se mělo myslet již v raném stádiu návrhu postupu testování, tak aby bylo možné obsahu testů co možná nejvíce přizpůsobit očekávanému softwaru.

UAT – Akceptační testování

User acceptance test (UAT) jsou akceptační testy na straně zákazníka. Pokud všechny předchozí etapy testů proběhly bez větších nedostatků, je možné předat aplikaci zákazníkovi. Ten si většinou se svým týmem testerů provede akceptační testy. Ty jsou často prováděny podle připravených scénářů, které společně připravil zákazník s dodavatelem. Testy probíhají na testovacím prostředí u zákazníka. Nalezené nesrovnalosti mezi aplikací a specifikací, jsou reportovány zpět vývojovému týmu. Opravené chyby jsou nasazeny na prostředí u zákazníka. V této úrovni je zřejmě nejdůležitější, definovat si předem jakou formou bude probíhat oznamování chyb od zákazníka a jak zabezpečit opravení těchto chyb v co možná nejkratší době. Z vlastních zkušeností mohu konstatovat, že zákazník zpravidla očekává určitou chybovost software a je spokojen, když jeho testovací tým nějakou chybu objeví. Velmi nespokojen je však ve chvíli, pokud je takovýchto chyb mnoho nebo jsou to chyby, jež mají zásadní dopad na funkčnost celé aplikace. Pokud jsou již nějaké chyby v úrovni akceptačních testů objeveny, je nutné v co nejkratším čase tyto chyby opravit a předat zákazníkovi k dalším testům. Velké prodlevy v nalezení a opravení chyby (v akceptační úrovni testování) mohou vést ke zpoždění termínu nasazení softwaru do provozu. Taková situace může mít fatální dopad na úspěch celého projektu.


.advertisement

Share on TwitterShare via email
Tagged , , , , , , , , , , , , , , , ,

Testy splněním a selháním

Někdy se uvádí také pojmy pozitivní a negativní testy. U testů splněním jako vstupní hodnoty v aplikaci využíváme jen množinu dat, kterou musí aplikace vždy akceptovat. Kontrolujeme, zda získaný výstup je shodný s výstupem očekávaným v požadavcích od zákazníka.

Při testech selháním do aplikace zadáváme pouze nestandardní data. Naší snahou je aplikaci tzv. „shodit“ (způsobit nečekané ukončení běhu programu). Během testů ověřujeme, že výstupní data neobsahují nežádoucí hodnoty, tj. data, která neobsahuje množina očekávaných dat. Obě tyto kategorie se lze využívat v jedné sadě testů. Testy splnění a selhání se mohou prolínat.

Testy splněním a selháním se využívají velmi často. Mnohdy zejména v kombinaci s použitím testů černé skříňky. V praxi se většinou nejprve spustí testy splněním. Pakliže jimi testovaný software projde, lze spustit testy selháním. Nic nám však nebrání v použití obou kategorií najednou, samozřejmě pokud je na to projekt dostatečně připraven (tzn., neobsahuje velké množství chyb, které by odhalily testy splněním). Při testech selháním se doporučují postupy jako např. dělení nulou, vkládání extrémních hodnot apod. Pozor si musíme dávat nejen na bezporuchové chování programu, ale i na správnost chybových hlášení. Oznámení typu: „chyba!“ nebo „operace se nezdařila“ nedávají uživateli moc šancí na zjištění, jaký krok dělá nesprávně. Tato kategorie testů se spouští zejména v systémové úrovni testování. Zde má na celkovou bezporuchovost produktu velký význam. Osobně v praxi kladu velký důraz na testy selháním, protože tyto testy v konečném důsledku velmi zvyšují bezporuchovost software.

Share on TwitterShare via email
Tagged , , ,

Progresní a regresní testy

Progresní testy využíváme při kontrole nových funkcí nebo vlastností aplikace. K jejich správnému provedení je nutná dokumentace, která přesně popisuje nově implementované oblasti. Používáme je ve všech etapách testování.

Regresní testy se využívají při opětovném testování funkcí a vlastností aplikace. Jejich smyslem je ověření, že provedené změny či implementace nových vlastností v aplikaci nemělo žádný vliv na stávající funkce a vlastnosti. Tedy především na oblasti, které zůstaly v programovém kódu nezměněny. Oblasti, které byly předmětem úprav, by správně již měly být otestovány funkčními testy. Takovéto situace z pravidla nastávají po opravení chyb či po novém release. Regresní testy je velmi vhodné automatizovat.

V praxi jsou regresní testy velmi rozšířené. V různých formách se používají prakticky u většiny projektů. Využívají se hlavně při retestech opravených chyb. Oproti tomu progresní testy nejsou příliš rozšířeny a často je tato kategorie testů rozložena do jiných kategorií.

Share on TwitterShare via email
Tagged ,

Smoke testy

Občas se do češtiny nesprávně překládá jako „zahořovací test“. Kategorie Smoke testů se využívá v okamžiku, kdy je dokončen vývoj aplikace a lze ji spustit. Tedy na konci úrovně integračního testování. Jedná se o krátký test, který slouží jako rychlé ověření, zda je vyvíjená aplikace připravena pro další fázi testování. Obvykle se provede jen jednoduché ověření, že všechny části aplikace jsou implementovány, nainstalovány a spuštěny. Smoke testy se zaměřují pouze na hlavní funkce programu, které nebývají příliš často upravovány. Často se také kombinují s kategorií testů splněním. Jelikož je rozsah smoke testů menší než tomu bývá u ostatních kategorií a pokrývají pouze hlavní funkce, jsou velmi často automatizovány. Pokud nejsou automatizovány v plném rozsahu, zbytek testů je prováděn manuálně. Úspěšné provedení smoke testů je podmínkou pro vstup do systémové úrovně testování. Proto jsou velmi důležité. U menších projektů, kde je testování software opomíjeno nebo není příliš organizováno, se provádí pouze smoke testy.

Share on TwitterShare via email
Tagged

Funkční a nefunkční testy

Testy, které ověřují, že aplikace správně plní všechny úkoly pro které je určena, nazýváme funkční testy. Testují se obecně všechny funkce, které jsou v aplikaci implementovány, a ověřuje se, že fungují správně a že odpovídají požadavkům zákazníka [1]. Ověřuje, zda daný software disponuje funkcemi, které jsou uvedeny v požadavcích zákazníka.

Nefunkční testy spočívají v testování všech vlastností aplikace, které přímo nesouvisí s jejími funkcemi, ale zároveň jsou podstatné pro její správné fungování. Řadí se sem především výkonové testování (Performance testing), které má ověřit například, že aplikace i pod zátěží (větší počet současně pracujících uživatelů, větší objem dat, atd.) bude pracovat dostatečně „svižně“. Testuje se také připravenost aplikace pro budoucí nárůst zátěže. A testování neujde ani chování aplikace k počítači, na kterém běží. Tedy třeba to, zda zbytečně nezatěžuje paměť a procesor.

Z výše uvedeného je zřejmé, že funkční testy mají na výslednou bezporuchovost softwaru významný vliv. Proto je na tuto kategorii kladen veliký důraz během celého testovacího cyklu software. Nezáleží přitom na rozsahu testovaného produktu. Nejčastěji se tato kategorie využívá v integrační, systémové a akceptační úrovni testování. Využití této kategorie přináší velké množství odhalených chyb, tedy alespoň ve srovnání s ostatními kategoriemi. Nefunkční testování má také nepochybný vliv na výslednou bezporuchovost software. Bohužel v praxi na něj většinou není příliš pamatováno nebo se této kategorii testů nedostává dostatečná doba na provedení všech potřebných testů.

[1] JORGENSEN, Paul. Software testing. Boca Raton: Auerbach. 2008. 416 s. ISBN 0-8493-7475-8

Share on TwitterShare via email
Tagged ,

Testování bílé a černé skříňky (white box, black box, grey box)

Při použití testů černé skříňky není k dispozici přístup k programovému kódu. Software si lze v tomto případě představit jako černou skříňku, jejíž obsah (zdrojový kód) není zvenčí viditelný. Neznáme tedy, jak přesně systém pracuje s daty. Můžeme pouze sledovat, jaký výsledek získáme po vložení vstupních dat. Naopak u testů bílé skříňky máme zdrojový kód k dispozici. Známe tak vnitřní strukturu software. Lépe pak můžeme otestovat pokud možno všechny průchody zdrojovým kódem, zadání neočekávaných vstupních hodnot a další testy, které vycházejí z kontroly zdrojového kódu. Občas se setkáváme s kombinací obou kategorií, ta bývá nazývána jako testy šedé skříňky. V praxi se může jednat např. o situaci, kdy software testujeme přes jeho uživatelské rozhraní. Výsledky operací pak ověřujeme pomocí dotazů do databáze.

Share on TwitterShare via email
Tagged , , , , ,

Statické a dynamické testy

Podle toho, zda je k testování nutné spuštění software(aplikace), rozlišujeme statické a dynamické testy.

Statické testy nevyžadují běh software. Využívají se tedy zejména v raných fázích životního cyklu software, kdy ještě není vytvořen funkční prototyp aplikace. Lze je použít ještě před začátkem psaní kódu na kontrolu specifikace požadavků a analýzu zdrojového kódu.

Dynamické testy vyžadují spuštění aplikace. Potřebují proto alespoň spustitelný prototyp software. Používají se v pozdějších fázích vývoje a jsou zaměřeny na provoz software.

Share on TwitterShare via email
Tagged ,