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.

• End-to-end (E2E) testování simuluje chování reálného uživatele v aplikaci.
• Ověřuje správnou funkčnost aplikace z pohledu uživatele – od začátku do konce.
• Kontroluje nejen jednotlivé komponenty, ale i jejich propojení, integraci a datovou konzistenci.
• Typické scénáře:
  • otevření aplikace (např. v prohlížeči),
  • zadání vstupů (kliknutí, psaní, potvrzování),
  • sledování odpovědí systému (zobrazení dat, reakce UI),
  • ověření správného dokončení procesu.

• Selenium – nástroj pro automatizaci webových prohlížečů.
• Další příklady (BONUS):
  • Cypress.IO
  • Playwright
  • Robot Framework
  • TestCafe
  • Puppeteer
• Tyto nástroje umožňují:
  • simulovat klikání, psaní, posouvání,
  • kontrolovat obsah stránek,
  • ověřovat výsledky akcí (např. přidání položky, dokončení platby).

• Testovací strategie je plán na vyšší úrovni, který definuje:
  • co budeme testovat,
  • jak budeme testovat,
  • s jakými prioritami,
  • s jakou intenzitou,
  • jakými metodami a nástroji.
• Slouží jako vodítko pro celý testovací tým, aby všichni pracovali podle stejného rámce a cílů.
• Obsahuje nejen technické aspekty, ale i organizační a byznysové pohledy – stejná terminologie, procesy, metriky
• Pomáhá sladit očekávání mezi zadavatelem, managementem a testovacím týmem.
• Zajišťuje, že se testování soustředí na oblasti s největším rizikem nebo nejvyšší byznys hodnotou.

• Metoda BDTM (Business Driven Test Management) pochází z rámce TMAP Next.
• Je určená hlavně pro větší testovací projekty, ale lze ji škálovat i na menší.
• Jejím cílem je přímo propojit cíle byznysu s přípravou a prováděním testů.
• Výstupem je velká tabulka, která propojuje:
  • testovací cíle (test goals),
  • požadavky a specifikace,
  • části testovaného systému,
  • analýzu rizik,
  • test levels,
  • druhy testů a jejich intenzitu,
  • zvolené test design techniky.

• Test goals (testovací cíle)
  • Overall test goals (např. od investora, senior managementu).
  • Departmental test goals (např. od budoucích koncových uživatelů).
  • Pomáhají sjednotit očekávání kvality a odhalit rozpory mezi investorem a uživateli.
• Popis testovaného systému
  • Přehled funkcí systému a jejich vazba na požadavky, procesy a kvalitativní aspekty (funkčnost, výkon, bezpečnost).
• Analýza rizik
  • Hodnocení pravděpodobnosti selhání a možného dopadu.
  • Určení tříd rizika podle kombinace těchto faktorů.
• Určení priorit
  • Podle tříd rizika určujeme, co testovat intenzivněji.
  • Priorita je odvozena z byznysového dopadu selhání, nikoliv jen z technického pohledu.
• Test levels
  • Definujeme úrovně testování (např. vývojářské testy, systémové testy, UAT, testy v produkci).
  • Určujeme, jakou intenzitou se bude testovat na které úrovni.
• Intenzita testování
  • Přizpůsobujeme intenzitu podle rizik a dostupných zdrojů.
  • Např. pro vysokorizikové oblasti vyšší pokrytí a intenzita, pro nízkorizikové nižší.

• Test goals určují, co je potřeba ověřit → vazba na funkce systému a požadavky.
• Analýza rizik určuje priority a intenzitu testování pro jednotlivé oblasti.
• Test levels rozdělují testy podle fází a týmů.
• Intenzita testování se přizpůsobuje prioritám, rozpočtu a časovým omezením.
• Celý proces je propojený v hlavní řídicí tabulce, která zajišťuje přehlednost, konzistenci a trasovatelnost.