Techniky návrhu testovacích scénářů, jednotkové testy, automatické funkční testy, testovací strategie, testovací data

B6B36TS1

1. Organizace testování, typy testů, V-model a W-model.
2. Určení vstupních dat do testů: Mezní podmínky, třídy ekvivalence.
3. Určení vstupních dat do testů: Párové testování, kombinatorické testování.
4. Vytváření testovacích scénářů: Procesní testy - model problému, jak vypadá testovací scénář, kritérium pokrytí Test Depth Level, vytváření testů.
5. Vytváření testovacích scénářů: Testy konzistence dat - model problému, jak vypadá testovací scénář, vytváření testů.
6. Způsoby vytváření testovacích dat.
7. Jednotkové testy: princip testu, vlastnosti, které má mít jednotkový test, odlišnosti proti integračním testům.
8. Automatizované testy založené na simulaci akcí uživatele v uživatelském rozhraní systému: princip testu, příklad technologie, rozdíl oproti jednotkovým testům.
9. Testovací strategie: princip metody Business Driven Test Management, její základní části a jejich souvislosti.

Organizace testování, typy testů, V-model a W-model.

Proč testovat software - člověk zanese chybu, která způsobí selhání systému ⇒ Defekty je potřeba najít, než se systém začne používat. Terminologie - obecně nejednotná - v předmětu dle ISTQB foundation level sylabu a TMAP Next , tak aby nepřekrývala ISTQB standard

Verifikace - Proces vyhodnocování, jestli produkt konkrétní vývojové fáze odpovídá požadavkům na tento produkt definovaným na začátku této fáze.

Validace - Vyhodnocování software v průběhu nebo na konci jeho vývoje, jestli software odpovídá zadaným požadavků.

1. Testování ukazuje přítomnost defektů - Testování může ukázat, že jsou defekty přítomny, ale nemůže dokázat, že v softwaru nejsou žádné defekty.
2. Vyčerpávající testování je nemožné - Testování všeho (všech kombinací vstupů a vstupních podmínek) není realizovatelné s výjimkou triviálních případů ⇒ musí se stanovit priority
3. Včasné testování - Testovací aktivity by měly v rámci životního cyklu vývoje softwaru nebo systému začít tak brzy, jak je to jen možné, a měly by být zaměřeny na definované cíle.
4. Shlukování defektů - Malé množství modulů obsahuje většinu defektů zjištěných v průběhu testování před uvolněním, nebo je zodpovědné za nejvíc provozních selhání.
5. Pesticidní paradox - Jsou-li stále opakovány tytéž testy, časem stejný soubor testovacích případů nenalezne žádné nové defekty ⇒ Je potřeba existující testovací případy pravidelně revidovat a upravovat a je potřeba napsat nové, odlišné testy
6. Testování je závislé na kontextu - Testování je vykonáváno odlišně v různých kontextech (Bezpečnost, Acessibility,..)
7. Falešná představa o neexistenci omylů - Nalezení a opravení defektů nepomůže, pokud je vytvořený systém nepoužitelný a nesplňuje potřeby a očekávaní uživatelů.

Typy testů se dají kategorizovat podle několika různých pohledů:

1. Podle test levels:
   • Vývojářské testy
   • Integrační testy
   • Systémové testy
   • Uživatelské akceptační testy
2. Podle technického postupu testu nebo charakteristiky kvality systému:
   • Unit testy kódu
   • Funkční testy
   • E2E (end-to-end) testy
   • Zátěžové testy
   • Penetrační testy
   • Testy provozuschpnosti na platformě
   • Crash testy a testy zotavení systému
3. Podle znalosti vnitřní struktury:
   • Black-box testing
   • White-box testing
   • Grey-box testing
4. Podle toho, kdo a kde testuje:
   • Alfa testy
   • Beta testy

Test Basis - Definice dle ISTQB: Dokumentace, na jejíž základě jsou vytvářené testovací scénáře. Zde je to část V směřující dolů ('\')

Test Level - Skupina testovacích aktivit, které jsou organizované a řízené jako jeden blok. Má svůj samostatný cíl. Zde část V směřující vzhůru ('/')

Bohémův zákon - Chyby jsou nejčastější ve fázích požadavků a návrhu a čím později odhalíme chybu v průběhu vývoje systému, tím je dražší

Přesně to se děje u V modelu, resp. drahé chyby způsobené špatnými požadavky odhalujeme až ke konci testování.

• Každé fázi přípravy systému odpovídá kontrolní fáze
• V praxi levnější než předělávání a opravy na poslední chvíli, ale vyžaduje počáteční investici, proto není příliš rozšířený

• Jak vhodně nakombinovat hodnoty (data) ve vstupech pro rozhodovací bod?

⇒ Můžeme vytvořit klasifikační strom pro každý rozhodovací bod v aplikaci

• Uzly = classification ~ jednotlivé vstupy pro rozhodovací bod (příklad: políčka z webového formuláře, část podmínky v procesu rozhodování, …)
• Listy = třídy ekvivalence pro danou classification

„Do vstupu můžu zadat velké množství hodnot. Jak vybrat vhodnou množinu pro test?“ → Konkrétní množinu hodnot, které jsou zadat do vstupu, rozdělíme na podmnožiny - třídy ekvivalence:

• Systém se má podle specifikace (na základě které testujeme) pro všechny hodnoty z konkrétní třídy ekvivalence chovat stejným způsobem

Konkrétní hodnoty (data) pro test pak vybereme z vytvořených tříd ekvivalence. Kolik jich vybrat? Záleží, jaké chceme mít *testovací pokrytí*

1. Dle typu vstupu:
   • Interval - Například pro: částka, věk, číslo účtu
     • Hranice intervalu = mezní podmínky (viz dále)
   • Diskrétní hodnoty - Například pro: typ prohlížeče, metoda platby, položka v menu, výběr z položek v číselníku
     • Nejsou mezní podmínky
2. Dle validity dat:

• Třída ekvivalence nesmí být prázdná (tj. určíme nějakou podmínku, která bude vymezovat data v ní, ale žádná data nebo případy jí nebudou odpovídat)
• Žádné dvě třídy ekvivalence nesmí mít neprázdný průnik
• Sjednocení všech tříd ekvivalence musí být původní
  • interval (pro typ interval)
  • množina (pro typ diskrétní hodnoty)

Jak určit třídy ekvivalence?

• U diskrétních hodnot: Analýza požadavků a specifikace
• U intervalu: Analýza požadavků a specifikace pomocí techniky mezních podmínek

• ISTQB definice: Hodnota, která tvoří hranici mezi třídami ekvivalence, nebo je o malý inkrement posunutá na jednu ze stran této hranice

• Přesnost dané hodnoty
  • Přesnost daná datovým typem (Příklad: SQL typ DECIMAL(10,4) se 4 desetinnými místy)
  • Přesnost daná specifikací (Příklad: Částku transakce účtujeme se 2 desetinnými místy. Zaokrouhlovací rozdíly se řeší opravnými položkami.)

• Iterace kolem hranice třídy ekvivalence:
  • M – mezní hodnota, tvořící hranici třídy ekvivalence
  • I – nenulová nejmenší hodnota, kterou jde uložit
  • Testujeme M, M + I, M - I

• Vazba mezních podmínek na typy tříd ekvivalence:

Jak nyní určíme vhodné kombinace dat v jednotlivých vstupech rozhodovacího bodu, aby naše testy našly co nejvíce chyb (v limitech toho, jakou kapacitu na ty testy máme)?

• Statistika: Pokud je někde v software defekt, aktivuje se nejčastěji buď
  1. hodnotou jednoho konkrétního vstupu
  2. kombinací hodnot ve dvou vstupech

• Princip: Místo testování všech možných kombinací vstupních hodnot (což by mohlo být obrovské množství) testujeme všechny dvojice (páry) vstupních hodnot.

• Proč to funguje:Statisticky většina chyb vzniká buď na základě jedné konkrétní vstupní hodnoty, nebo na základě kombinace dvou vstupů. Situace, kdy chyba vznikne až kombinací tří a více vstupů, jsou vzácné.

• klasifikační strom pro vstupy:

• Počet kombinací = (počet EC v prvním vstupu) * (počet EC v druhém vstupu) * (počet EC v třetím vstupu) = 3 * 2 * 2 = 12
• Kompletní pokrytí všemi možnými kombinacemi – 12 variant k otestování:

• Párové testování: V každém páru vstupů jsou pokryty všechny kombinace – 6 variant k otestování:

• Existují různé metody, jak vybrat z možných kombinací vhodné hodnoty pro výsledné testovací scénáře tak, aby pokrytí systému bylo co největší

• příklad testovaného výrazu:

1. Condition coverage (CC)
   • Výstup každé podmínky (TRUE / FALSE) je vyhodnocen alespoň jednou
2. Decision coverage (DC)
   • Alespoň jednou jsou vyhodnoceny všechny možné výstupy nějakého vyhodnocení ((A AND B) OR C)
3. Condition / Decision coverage (C/DC)
   • Spojení CC a DC

• MCC (Multiple Condition Coverage)
  • Všechny možné kombinace výsledků podmínek v logickém výrazu jsou testovány alespoň jednou.
  • Nejvyšší úroveň pokrytí.
  • Počet kombinací: pro obecný klasifikační strom: (počet EC ve vstupu1) * (počet EC ve vstupu2) * (počet EC ve vstupu3) …
  • Příklad:

• MC/DC (Modified Condition/Decision Coverage):
  • Každý z výsledků všech podmínek v logickém výrazu je otestován alespoň jednou a zároveň každá z podmínek nezávisle ovlivnila výsledek logického výrazu(tím, že měníme pouze vstupní hodnoty pro tuto podmínku, zatímco vstupní hodnoty pro ostatní podmínky držíme zafixované)
  • Pracuje s termínem neutrální hodnota
  • Příklad: na slidech 24 - 33

• Testovaná aplikace se modeluje jako orientovaný graf nebo zjednodušený UML activity diagram.
• Uzly grafu = větvící body (rozhodovací body).
• Hrany grafu = přechody (akce) mezi uzly.
• Testovací scénář je sled (sekvence) akcí, kterými aplikace prochází z počátečního do koncového stavu.

• Je to konkrétní průchod grafem od startu do konce.
• Obsahuje:
  • sekvenci vstupních a výstupních akcí pro jednotlivé uzly,
  • všechny potřebné kombinace podle požadované úrovně pokrytí.

(viz vytváření testů)

1. Modelujeme aplikaci jako orientovaný graf.
2. Identifikujeme vstupní a výstupní akce v každém rozhodovacím bodě.
3. Určíme potřebnou úroveň pokrytí (TDL).
4. Generujeme sekvence testů:
   • Kombinujeme akce tak, aby pokryly všechny požadované cesty.
   • Minimalizujeme opakování, pokud už je kombinace pokrytá.
   • Při omezených zdrojích preferujeme:
     • prioritní akce (z pohledu businessu nebo rizika),
     • nejdůležitější průchody.

Příklady:

• Data v systému mají životní cyklus: C (create) → R (read) → U (update) → D (delete)
• Různé funkce aplikace provádějí různé operace na datových entitách.
• Konzistence znamená, že:
  1. Data, která uložíme, poté správně přečteme.
  2. Aktualizace nezpůsobí nečekanou chybu.
  3. Smazání (nebo archivace) odpovídá očekávání systému.
• Mezi funkcemi a datovými entitami je obecně M:N vztah (více funkcí pracuje s více entitami).

Jaké jsou možné chyby?

• Některá z operací C, R, U, D není vůbec implementovaná
• Některá z operací C, R, U, D neprobíhá správně
• Pokud se operace C, R, U, D vykonají mimo očekávaný průběh, naruší se konzistence dat
• Operace D není ve sktečnosti delete, ale jen archivace. Ale některé z funkcí tesotvaného systému pracují s archivovanou entitou stále jako s aktivní…

Skládá se z posloupnosti operací:

• začíná Create,
• následují různé kombinace Read a Update,
• končí Delete.

Po každé operaci C, U, D se doporučuje spustit Read, abychom ověřili aktuální stav dat.

• Jednou R pro nejdůležitější funkci, která zobrazuje datovou entitu
  1. základní pokrytí
• Vícekrát pro různé funkce, které zobrazují datovou entitu
  1. kompletní pokrytí R

Kompletní pokrytí znamená testovat různé funkce, které čtou nebo mění entitu, nejen jednu hlavní.

1. Sestav CRUD matici:
   • řádky = funkce aplikace,
   • sloupce = datové entity,
   • v buňkách = které CRUD operace daná funkce nad entitou vykonává.
2. Udělej statickou kontrolu:
   • Mají všechny entity všechny potřebné CRUD operace?
   • Pokud ne, proč?
3. Udělej dynamické testy konzistence:
   • Ověř, že kombinace operací nevede k poškození dat.
   • Sleduj, zda některá funkce nezpůsobí chybu, která se projeví až v jiné funkci.
4. Prioritizuj testy:
   • Pokud nemůžeš pokrýt všechny kombinace, testuj prioritně nejdůležitější funkce a cesty.

Příklad:

• S konkrétní datovou entitou A jde provést některou z operací C, R, U, D, pouze pokud je splněná daná podmínka.

Příklady:

1. Entitu zákazník lze smazat, pokud má zaplacené všechny objednávky.
2. Provozovnu lze smazat, pokud do ní nejsou přiřazení žádní zaměstnanci.

Pozor: Taková podmínka nemusí být jen na úrovni integrity v DB schématu!

• Nastavují stav aplikace před začátkem testu.
• Šetří čas na přípravu scénářů.
• Umožňují opakovat testy se stejnými podmínkami (retest).
• Pomáhají minimalizovat interference mezi týmy při sdílení prostředí.

1. Ruční příprava dat
   • Vytvoření dat ručně přes funkce aplikace (CRUD → Create, Update).
2. Automatické skripty
   • Automatizace ruční přípravy pomocí testovacích skriptů.
3. Hromadné generování umělých dat
   • Automatizované generování dat podle struktury systému.
4. Kopie produkčních dat
   • Použití reálných dat bez úprav.
   • Varianta s opatřeními: omezení přístupu, odstranění osobních/citlivých údajů.
   • Varianta se zmenšeným vzorkem dat.

• Neřízený přístup
  • Riziko kolizí mezi testery (přepisování dat, chyby vzniklé sdílením).
• Řízený přístup
  • Rozdělení datových entit mezi týmy (např. podle ID, prefixů, vlastností).
  • Použití skriptů pro výběr nebo evidenci používaných entit.

• Virtualizace komponent
  • Nahrazení systému simulací (stub), pokud reálný systém není dostupný nebo je příliš drahý.
  • Simulace odpovědí, zálohování stavu, přepínání konfigurací.

• Odhalují chyby na úrovni kódu.
• Porovnávají výsledek volání metody/procedury s očekávaným výsledkem.
• Jsou napsané jako speciální část kódu, která kontroluje funkční část programu.
• Programátor je může psát sám přímo ke svému kódu.
• Unit testovací frameworky (např. JUnit, TestNG) poskytují podporu a zrychlují přípravu testů.
• Testy je možné opakovaně spouštět, často se integrují do build procedury.
• Klíčová součást Test Driven Development (TDD), kde slouží i jako specifikace výsledku.

• Nezávislost na jiných testech (test nesmí být prerekvizitou pro jiný test).
• Minimální množství vstupních podmínek (preconditions), kde je to možné.
• Jedna funkcionalita → Jeden unit test
• Přiměřený počet assertů, aby test zůstal přehledný a údržba nebyla zbytečně náročná.
• Srozumitelný a jasný název metody testu, který popisuje, co test kontroluje.
• Používání jednotného zdroje testovacích dat a konzistentní jmenné konvence.
• Struktura testů by měla odpovídat objektové struktuře kódu (např. třídě odpovídá testovací třída).
• Unit testy jsou určeny pouze pro kontrolu kódu, nikoliv konfigurace.