NOVINKA - Online rekvalifikační kurz Python programátor. Oblíbená a studenty ověřená rekvalifikace - nyní i online.
Hledáme nové posily do ITnetwork týmu. Podívej se na volné pozice a přidej se do nejagilnější firmy na trhu - Více informací.

Lekce 8 - Testovací analýza a návrh testů

V předchozí lekci, Proces zpětné vazby a revize, jsme probrali proces zpětné vazby a revize u statického testování. Zaměřili jsme se na role a odpovědnosti při revizích a typy revizí.

V dnešní lekci test analysis a test designu si ukážeme přehled testovacích technik, poté se zaměříme na techniky black-box testing, rozdělení tříd ekvivalence, analýzu hraničních hodnot, testování dle rozhodovací tabulky a nevynecháme ani testování přechodů stavů.

Přehled technik testování

Techniky testování pomáhají testerům jak při test analysis a při test designu, tak při systematickém definování test casů, podmínek, položek pokrytí a testovacích dat:

Techniky testování - Testování softwaru dle ISTQB

Techniky black-box testingu jsou založené na analýze chování testovaného objektu bez ohledu na jeho vnitřní strukturu. Test casy jsou nezávislé na implementaci a mohou se použít i po změně kódu, pokud chování zůstává stejné.

Techniky white-box testingu jsou založené na analýze vnitřní struktury softwaru. Tyto testy jsou závislé na test designu a mohou být vytvořeny až po dokončení implementace.

Techniky experience-based testingu (techniky testování založeného na zkušenostech) využívají znalosti a zkušenosti testerů, což umožňuje odhalit defekty, které jiné techniky nemusí zachytit. Efektivita závisí na schopnostech testerů.

Techniky black-box testingu

Techniky black-box testingu zahrnují equivalence partitioning (rozdělení tříd ekvivalence), boundary value analysis (analýzu hraničních hodnot), decision table testing (testování dle rozhodovací tabulky) a state transition testing (testování přechodů stavů).

Equivalence partitioning

Equivalence partitioning (EP) je testovací technika, která rozděluje data na skupiny neboli třídy, kde všechny hodnoty v jedné třídě mají být zpracovány stejným způsobem. Pokud test najde chybu pro jednu hodnotu v konkrétní třídě, je pravděpodobné, že stejná chyba by se objevila i u jiných hodnot v této třídě.

Equivalence classes

Equivalence classes (třídy ekvivalence) lze vytvořit pro různé typy dat, jako jsou vstupy (co uživatel zadá), výstupy (co systém vrátí), konfigurace (nastavení systému), interní hodnoty, časové údaje nebo rozhraní mezi systémy. Tyto třídy mohou být různého typu – například spojité nebo diskrétní, uspořádané (seřazené), neuspořádané, konečné (s omezeným počtem hodnot) nebo nekonečné.

Kritéria pokrytí

V EP se za kritéria pokrytí považují samotné equivalence classes. Aby bylo pokrytí úplné, musí testovací scénáře zahrnovat alespoň jednu hodnotu z každé identifikované třídy. Pokrytí se vyjadřuje jako procento tříd, které byly otestovány alespoň jedním testovacím scénářem, vůči celkovému počtu identifikovaných tříd. Mnoho testovaných systémů má více sad equivalence classes, což umožňuje, aby jeden test pokryl třídy z různých sad.

Každá třída musí být jedinečná (bez překryvů) a obsahovat alespoň jednu hodnotu. U jednoduchých vstupů je dělení na třídy obvykle snadné, ale pro složitější data může být toto rozdělení náročnější a vyžaduje pečlivý přístup. Třídy s platnými hodnotami se nazývají valid equivalence classes (platné třídy ekvivalence), zatímco třídy s neplatnými hodnotami jsou invalid equivalence classes (neplatné třídy ekvivalence). Rozlišení mezi platnými a neplatnými hodnotami se často liší podle potřeb a pravidel jednotlivých týmů nebo organizací.

Praktický příklad

Představme si aplikaci pro registraci uživatelů, která vyžaduje, aby uživatelé zadali věk v rozmezí 18–56 let:

Equivalence partitioning - Testování softwaru dle ISTQB

Valid equivalence class zahrnuje hodnoty jako 18, 25, 50. Test case ověří, že pokud uživatel zadá věk v tomto rozmezí, systém jej úspěšně zaregistruje. Invalid equivalence class zahrnuje věk menší než 18 let, například hodnoty 10 a 15. Test case ověří, že pokud uživatel zadá věk pod 18 let, systém zobrazí chybovou zprávu. Invalid equivalence class zahrnuje také věk větší než 56 let. Například hodnoty 58, 76. Dalším případem mohou být nečíselné hodnoty, například text nebo speciální znaky.

Boundary value analysis

Boundary value analysis (BVA) je technika, která se zaměřuje na hraniční hodnoty equivalence classes. Lze ji použít pouze v případě uspořádaných tříd, kde minimální a maximální hodnoty každé třídy jsou její hraniční hodnoty. Pokud dva prvky patří do stejné třídy, všechny prvky mezi nimi musí být také součástí této třídy.

BVA se soustředí na hraniční hodnoty, protože právě na těchto hranicích jsou chyby nejpravděpodob­nější. Typické defekty jsou často výsledkem nesprávného umístění hranic – buď nad, nebo pod specifikovanou hodnotou, případně jejich vynechání.

Varianty BVA

Existují dvě varianty BVA: dvouhodnotová a trojhodnotová. Tyto varianty se liší v počtu položek pokrytí potřebných k dosažení 100% pokrytí hraničních hodnot:

Dvouhodnotová BVA

  • Zahrnuje dvě položky pro každou hranici – hraniční hodnotu a jejího souseda ze sousední třídy.
  • Pro dosažení 100% pokrytí musí být test casy vykonány pro všechny identifikované hraniční hodnoty a jejich sousedy.
  • Pokrytí se měří jako poměr pokrytých hraničních hodnot k celkovému počtu identifikovaných hraničních hodnot.

Trojhodnotová BVA

  • Zahrnuje tři položky pro každou hranici – hraniční hodnotu a oba její sousedy.
  • Některé z těchto sousedů nemusí být hraničními hodnotami žádné třídy, ale jejich zahrnutí je nezbytné pro dosažení 100% pokrytí.
  • Měření pokrytí zahrnuje hraniční hodnoty i jejich sousedy.

Trojhodnotová BVA je přísnější než dvouhodnotová a může odhalit defekty, které by s dvouhodnotovou variantou zůstaly neodhalené.

Kancelář programátorů. - Testování softwaru dle ISTQB

Praktický příklad

Máme podmínku, která stanoví, že určitá akce by se měla provést, je-li hodnota proměnné x menší nebo rovna 10. Správná podmínka by tedy v kódu měla vypadat takto:

IF (x ≤ 10) …

Chybou při implementaci se však může stát, že programátor zapíše podmínku takto:

IF (x = 10) …

V této chybné podmínce se akce provede pouze tehdy, když se hodnota x přesně rovná 10, a ne tehdy, když je menší než 10. To je samozřejmě špatně, protože omezuje podmínku pouze na hodnotu x = 10 místo hodnot x ≤ 10.

Dvouhodnotová BVA

Dvouhodnotová BVA testuje pouze dvě hodnoty:

  • hraniční hodnotu (v našem případě 10),
  • hodnotu těsně za hranicí (v našem případě 11).

Testovali bychom tedy x = 10, x = 11. Pro hodnotu x = 10 se podmínka vyhodnotí jako pravda a test by prošel, zatímco pro hodnotu x = 11 se podmínka vyhodnotí jako nepravda, což také odpovídá očekávanému výsledku. Dvouhodnotová BVA tím pádem tento defekt nezachytí.

Trojhodnotová BVA

Trojhodnotová BVA jde o krok dále a testuje tři hodnoty:

  • hodnotu těsně pod hranicí (9),
  • hraniční hodnotu (10),
  • hodnotu těsně nad hranicí (11).

V našem příkladu by tedy testovací hodnoty byly x = 9, x = 10 a x = 11. Když dojde na testování hodnoty x = 9, chybně implementovaná podmínka if (x = 10) se vyhodnotí jako nepravda (protože 9 není rovno 10), a test by tedy neprošel. Tím by se ukázalo, že podmínka nefunguje správně pro hodnoty menší než 10, což je v rozporu s očekáváním.

Decision table testing

Decision tables (rozhodovací tabulky) jsou efektivní nástroj pro zaznamenávání složité logiky, jako jsou byznysová pravidla, a jsou vhodné pro testování systémových požadavků, kde různé kombinace podmínek vedou k různým výsledkům. Tabulka se skládá ze dvou hlavních částí: podmínky a výsledné akce systému. Každý sloupec reprezentuje jedno pravidlo rozhodování, což je kombinace podmínek, která určuje, které akce se mají vykonat.

Symboly používané v tabulkách

V tabulkách s omezeným počtem vstupů jsou podmínky a akce zobrazeny jako logické hodnoty – pravda/true, nebo nepravda/false. V tabulkách s rozšířeným počtem vstupů mohou podmínky a akce zpracovávat více hodnot.

Symboly používané v tabulkách:

  • "T" (true) – podmínka je splněna.
  • "F" (false) – podmínka není splněna.
  • "-" znamená, že hodnota podmínky je pro výsledek akce irelevantní.
  • "N/A" – podmínka je pro dané pravidlo neproveditelná.

Zápis akcí:

  • "X" – akce by měla nastat.
  • "" (prázdná hodnota) – akce by neměla nastat.

Tabulky lze zjednodušit odstraněním neproveditelných kombinací nebo sloučením sloupců, kde podmínky nemají vliv na výsledek. Položky pokrytí jsou sloupce obsahující proveditelné kombinace podmínek. Pro dosažení 100% pokrytí musí testy pokrýt všechny proveditelné kombinace podmínek.

Decision table testing poskytuje systematický přístup k identifikaci všech kombinací podmínek, čímž snižuje riziko přehlédnutí některých variant. Tabulky pomáhají také při odhalování nedostatků v požadavcích. Při velkém počtu podmínek může být zpracování všech kombinací časově náročné, proto lze použít zjednodušené tabulky nebo metody založené na rizicích ke snížení počtu testů.

Praktický příklad

Představme si e-shop, který nabízí různé slevy na základě kombinace podmínek. Zda je zákazník nový, má věrnostní kartu nebo zda nákup překročil částku 1000 Kč. Decision table určuje, kdy se poskytne sleva:

Rozhodovací tabulka - Testování softwaru dle ISTQB

V tomto případě testovací tým provede testy pro všechny kombinace podmínek, aby ověřil, že sleva je poskytována správně dle pravidel, například když je zákazník nový a nákup překročí 1000 Kč. Sleva však naopak poskytována není, pokud zákazník nenakoupí nad 1000 Kč.

State transition testing

State transition diagram je nástroj, který ukazuje, jak se systém může chovat. Zobrazuje všechny možné stavy, které může systém mít, a přechody mezi nimi, tedy situace, kdy se systém změní z jednoho stavu do druhého. Ke změně stavu dochází na základě určité události, například po kliknutí nebo zadání hesla. Přechod může mít také guard condition (podmínku přechodu), která musí být splněna, aby přechod mohl nastat. Někdy může být s podmínkou spojená i akce, kterou systém při přechodu provede. Obvyklá syntaxe přechodů je:

událost [podmínka přechodu] / akce

Nejsou-li podmínka nebo akce potřeba, mohou být vynechány.

Ke state transition diagramu existuje ekvivalent – state transition table (tabulka přechodů stavů). V této tabulce jsou stavy uspořádány do řádků a události s případnými podmínkami do sloupců. V každé buňce je zapsán cílový stav systému, pokud daná událost a podmínka nastanou, případně jaká akce se při tom provede. Tabulka také ukazuje neplatné přechody – buňky jsou prázdné tam, kde přechod není povolený.

Z takového diagramu nebo tabulky se pak tvoří testovací scénáře. Test case pak sleduje sérii událostí, které vedou k určité posloupnosti změn stavů, a může pokrýt více přechodů v rámci jednoho scénáře.

Kritéria pokrytí

Pro state transition testing existuje mnoho kritérií pokrytí:

Kritéria pokrytí - Testování softwaru dle ISTQB
Pokrytí všech stavů

Položkami pokrytí jsou jednotlivé stavy. Pro dosažení 100% pokrytí musí test casy pokrýt všechny stavy. Pokrytí se měří jako poměr pokrytých stavů k celkovému počtu stavů.

Pokrytí platných přechodů

Položkami pokrytí jsou platné přechody. Pro dosažení 100% pokrytí musí test casy pokrýt všechny platné přechody. Pokrytí se měří jako poměr pokrytých platných přechodů k celkovému počtu platných přechodů.

Pokrytí všech přechodů

Položkami pokrytí jsou všechny přechody (platné i neplatné). Test casy musí pokrýt všechny platné přechody a prověřit neplatné přechody. Je vhodné testovat jeden neplatný přechod na test case, aby se snížilo riziko maskování defektů (situace, kdy jeden defekt skryje druhý). Pokrytí se měří jako poměr přechodů, které byly pokryty, k celkovému počtu všech přechodů.

Praktický příklad

Představme si výtahový systém se čtyřmi stavy: v klidu, jízda nahoru, jízda dolů a dveře otevřené:

Tabulka přechodů stavů - Testování softwaru dle ISTQB

Systém přechází mezi těmito stavy na základě událostí, jako je stisknutí tlačítka nebo příjezd do patra. Například po stisknutí tlačítka pro jízdu nahoru výtah přejde ze stavu "v klidu" do stavu "jízda nahoru". Po příjezdu do cílového patra přejde výtah do stavu "dveře otevřené" a po zavření dveří se vrátí zpět do stavu "v klidu". Neplatným přechodem by bylo stisknutí tlačítka pro jízdu nahoru, když výtah již jede nahoru, což by měl systém ignorovat.

Výtah - Testování softwaru dle ISTQB

Pokrytí všech stavů je slabší kritérium než pokrytí platných přechodů, protože ho lze dosáhnout bez pokrytí všech přechodů. Nejpoužívanější je pokrytí platných přechodů, které by mělo být minimálním požadavkem pro bezpečnostně kritický software. Plné pokrytí platných přechodů zaručuje také plné pokrytí stavů, zatímco plné pokrytí všech přechodů garantuje jak pokrytí všech stavů, tak pokrytí všech platných přechodů.

Zdrojem této lekce jsou Učební osnovy – Certifikovaný tester základní úrovně ver. 4.0. Copyright © 2023 autoři verze 4.0: Renzo Cerquozzi, Wim Decoutere, Klaudia Dussa-Zieger, Jean-François Riverin, Arnika Hryszko, Martin Klonk, Michaël Pilaeten, Meile Posthuma, Stuart Reid, Eric Riou du Cosquer (předseda), Adam Roman, Lucjan Stapp, Stephanie Ulrich (místopředseda), Eshraka Zakaria

V příští lekci, Techniky testování bílé skříňky, si ukážeme techniky testování bílé skříňky a techniky testování založené na zkušenostech.


 

Předchozí článek
Proces zpětné vazby a revize
Všechny články v sekci
Testování softwaru dle ISTQB
Přeskočit článek
(nedoporučujeme)
Techniky testování bílé skříňky
Článek pro vás napsala Jana Zimčíková
Avatar
Uživatelské hodnocení:
22 hlasů
Autorka se věnuje IT a technologiím. Ovládá Javu, Spring Boot, SQL i frontend a chce pomáhat lidem objevit svůj potenciál v IT světě.
Aktivity