Testování je důležitou rolí, která probíhá ve všech fázích životního cyklu každého projektu.
Je to kontrola správnosti programu, ve kterém nesmí být jediná chyba. Chybou programu se v testování rozumí např. to, že jeho chování neodpovídá zadání, při zadání vstupů z určené množiny hodnot neodpovídá požadovaným výsledkům, neodpovídá dokumentaci a uživateli požadovaným informacím nebo nepracuje tak, jak od něj uživatel rozumně očekává.
Testovat není jednoduchá věc, bez patřičných znalostí bychom ji asi neuměli vůbec provést. Provádí ji určitá skupina lidí neboli testerů.
Kontrola správnosti programu se dělí na tři části:
Metodika označuje nějaký pracovní postup, provádění nějaké činnosti. Cílem je vytvořit rámec, ve kterém jsou definovány jednotlivé činnosti, jejich návaznosti a přesahy. Může obsahovat také šablony dokumentů, popisující jednotlivé fáze účastníkovi procesu vývoje, co musí být splněno, aby mohl zahájit svojí činnost, jaký je očekávaný výstup a komu má být předán.
Je to metodika, ve které se postupně navazují jednotlivé fáze vývoje. Jakmile skončí jedna, začíná druhá. Nejobvyklejší fázemi jsou sběr dat, analýza, vývoj, testování. Tento přístup má značné nevýhody, např. pokud je jedna fáze již hotová a začneme druhou, která na předchozí navazuje, už se k ní nemůžeme vrátit.
Aplikace je rozdělena na několik menších částí. Každá fáze se vyvíjí samostatně. Výhodou tohoto přístupu je, že je celý proces rychlejší. Snadněji se zde hledají chyby a rychleji se na ně reaguje.
Je to metodika, která se snaží minimalizovat formálnost ve vývoji softwaru a tím tento vývoj zjistit. Probíhá zde vysoká komunikativnost se zákazníkem a zapojení zákazníka do procesu vývoje. Používá se hlavně v malých týmech kvůli přímé komunikace bez formalit. Cílem v rámci agilních metodik je spokojenost zákazníka.
Testování se dělí na šest stupňů:
Jakmile dojde k vytvoření programového kódu, programátor ho musí prověřit. Tomuto testování se v praxi říká Assembly tests. Je zde použitý tzv. „test čtyř očí“. Znamená to, že kód má za úkol otestovat jiný programátor, než ten, který ho napsal. Pracuje se zdrojovým kódem programu. Pokud program obsahuje chyby, nahlásí je tvůrci a ten je pak musí opravit. Tato část je také na opravování nejméně nákladná. Tester si před tímto testováním musí nastudovat dokumentaci a připravit testovací data.
Pokud program úspěšně projde testováním programátorem, následuje test jednotek. Pokud se jedná o objektově orientované programování, provádí se na úrovni jednotlivých tříd a metod. Jednotka je samostatně testovatelná část programu. Tyto testy zpravidla obsluhují vývojáři, protože se zapisují pomocí programových kódů. Využívá se zde nástrojů softwaru.
Testování jednotek se na probíhajících projektech špatně aplikuje, což vyžaduje kompletní refaktoring, který nemá vliv na vnější chování kódu, nebo i hlubší úpravy. Z tohoto důvodu se před vytvářením programu musíme rozhodnout, zda tohoto stupně testování budeme využívat. Testeři by měli věnovat této fázi testování co nejvíce pozornosti, protože čím dříve chybu opravíme, tím strávíme testováním méně času a celý projekt bude nakonec méně nákladný.
Je to fáze, kde jsou testy prováděny na straně dodavatele. Ověřují, že aplikace plní správně všechny úkoly. Zjišťuje se, zda všechny funkce fungují správně a zda odpovídají požadavkům zákazníka.
Když je vývojář se svými testy hotový, jeho práci přebírá testovací tým. V tomto stupni testování se ověřuje bezchybná komunikace mezi jednotlivými komponentami v aplikaci. Nejdříve se provádí testování mezi dvěma komponentami a pak se postupně přidávají další. Integrační testování nemusí probíhat jen mezi komponentami. Může probíhat i mezi komponentou a operačním systémem, hardwarem nebo i rozhraním různých systémů. Tyto testy jsou jak manuální, tak i automatizované. V malých projektech se dají vynechat, ale pak musíme správně provést další stupně testování.
Regression test - Ověření, zda se v důsledku změny neobjevila chyba někde, kde předtím nebyla.
Incremental Integration test - Provádí se, když je ke stávajícím, již otestovaným modulům, přidán další.
Smoke test - Testuje jestli je systém připraven na hloubkový systémový test, aniž by spadl
Zde je aplikace ověřována jako funkční celek, která je ověřována z pohledu zákazníka. Simulují se různé kroky, které mohou nastat. Má několik částí. V první části jsou opraveny nalezené chyby a v dalších částích jsou tyto opravy znovu testovány.
Je to poslední a nejdůležitější etapa před předáním aplikace zákazníkovy. Bez tohoto stupně by celé testování nemělo žádný význam. Zákazník by tedy mohl dostat software, který by nebyl správně otestován a mohl by fungovat špatně.
Recovery test - Účelem tohoto testu je otestovat, jak rychle a zda vůbec produkt obnoví svou činnost po pádu systému, hardwarové chybě, výpadku proudu atd.
Security test - Odhalují, jak a zda vůbec je systém chráněn před neautorizovaným přístupem, jak se ukládají hesla, jak je řízen přístup nebo jak je implementována integritní ochrana. Slouží k nalezení nežádoucího kódu, bezpečnostních chyb či zranitelností.
Stress test - Ověřuje, zda při velké zátěži, která může být vygenerována automaticky například provedením velkého počtu složitější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 je sledována jeho odezva, respektive ovlivnění výkonu aplikace, například 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, jak probíhá instalace a odinstalace systému na dané platformě.
Jsou to testy na straně zákazníka. Když je bezchybná a je předána zákazníkovi, tak si ji chce většinou otestovat se svým týmem testerů. Provedou tzv. akceptační testy. Jsou provedeny podle připravených scénářů, které společně připravil zákazník s dodavatelem. Probíhají u zákazníka v testovacím prostředí. Pokud tým nalezne chybu, vrátí aplikaci zpět dodavateli. V tomto stupni testování se musí dohodnout, jak bude oznamování chyb od zákazníka probíhat a jak opravit chyby v co nejkratší době.
Alpha test - Tyto testy ve vývojovém prostředí provádí někdo jiný než vývojový tým, ten pouze sleduje a poskytuje podporu.
Beta test - Probíhají v prostředí zákazníka a případné chyby jsou reportovány vývojářům dohodnutou cestou pomocí připravených formulářů.
Acceptance test - Provádí ho zákazník ve svém vlastním testovacím prostředí a ověřuje, zda je produkt v souladu s požadavky ve specifikaci a zda se v jeho prostředí chová tak, jak má.
Long term test - Cílem těchto testů je odhalení chyb, které se zpravidla vyskytnou až po delší době používání aplikace.
Spočívá v hledání chyb bez provádění testovaného objektu. Pomocí syntaktické, strukturální a sémantické analýzy má za cíl odhalit místa, která jsou náchylné k chybám.
Testovací aktivity:
V případě složitých systémů vyžadují analýzy složitosti, struktury a toku dat nástroje pro podporu těchto analýz.
Při tomto testování jsou objekty přímo prováděny nebo simulovány. Obsahuje tyto činnosti:
Objekty musí absolvovat dynamické testování i v případě, že úspěšně prošly statickým testováním.
Každý objekt se dá testovat dvěma způsoby. Kontrolou vztahu mezi vstupem a výstupem bez (black box) nebo s (white box) ohledem na jeho vnitřní strukturu.
Black box - Je testováno chování rozhraní objektu při jeho provádění. Testovací běhy jsou vybírány pouze na základě specifikace objektu bez ohledu na jeho vnitřní strukturu. Kontrolují se též reakce na mezní nebo chybná vstupní data. Nezabývá se funkcemi neovlivňující vstup a výstup. Metoda je vhodná pro integrační testy.
White box - Má za cíl prověřit všechny průchody testovaným programem. Testovací běhy se vybírají s ohledem na vnitřní strukturu objektu.
Testování podle dat předpokládá, že data můžeme rozdělit do několika tříd a pro každou třídu lze provést jeden test (ostatní data skupiny by dávala stejný výsledek).
Testování podle struktury programu vychází z grafu řídící struktury programům, kde uzly jsou rozhodovací prvky a hrany přechody mezi nimi. Je třeba vybrat takové testy, které projdou všechny větve programu alespoň jednou. Testy se provádí tak aby každý modul a funkce byly provedeny alespoň jednou, každá větev byla provedena alespoň jednou, se provedlo tolik řídících cest kolik je možné. Je nutné projít skutečně každou větev programu, ne pouze provést každý příkaz.
Testování patří k největším problémům programování a tvoří někdy i třicet procent rozsahu výsledného produktu. I přesto však ve výsledku v programu zůstává takové množství chyb, že údržba systému spolkne až šedesát procent celkových nákladů a odstranit chyby za provozu je padesátkrát dražší než při návrhu programu. Proto by se testování mělo provádět důkladně a v žádném případě by se nemělo podceňovat.
26. květen 2018
1 797×
1455 slov
