The wiki page is under active construction, expect bugs.

Differences

This shows you the differences between two versions of the page.

--- statnice:bakalar:b6b36ts1 [2025/05/28 13:21] – [Vytváření testovacích scénářů: Testy konzistence dat] prokop
+++ statnice:bakalar:b6b36ts1 [2025/05/28 15:42] (current) – [Testovací strategie: princip metody Business Driven Test Management] prokop
@@ Line 188: / Line 188: @@
   * **příklad testovaného výrazu:**
+{{statnice:bakalar:ts1komblog.png?600}}
   - **Condition coverage (CC)**
@@ Line 290: / Line 291: @@
     * Mají všechny entity všechny potřebné CRUD operace?
     * Pokud ne, proč?
   - **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.
   - **Prioritizuj testy:**
     * Pokud nemůžeš pokrýt všechny kombinace, testuj prioritně nejdůležitější funkce a cesty.
+**Příklad:**
+{{statnice:bakalar:ts1crud.png?700}}
+=== BONUS: CRUD - vázané podmínky ===
+  * 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:**
+  - Entitu zákazník lze smazat, pokud má zaplacené všechny objednávky.
+  - 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!
 ===== Způsoby vytváření testovacích dat. =====
-===== Jednotkové testy: princip testu, vlastnosti, které má mít jednotkový test, odlišnosti proti integračním testům. =====
+==== Proč jsou testovací data důležitá ====
-===== 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. =====
+  * Nastavují stav aplikace před začátkem testu.
-===== Testovací strategie: princip metody Business Driven Test Management, její základní části a jejich souvislosti. =====
+  * Š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í.
+==== Způsoby přípravy testovacích dat ====
+  - **Ruční příprava dat**
+    * Vytvoření dat ručně přes funkce aplikace (CRUD → Create, Update).
+  - **Automatické skripty**
+    * Automatizace ruční přípravy pomocí testovacích skriptů.
+  - **Hromadné generování umělých dat**
+    * Automatizované generování dat podle struktury systému.
+  - **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.
+==== Porovnání způsobů přípravy dat ====
+| Způsob | Vstupní investice | Provozní náklady | Rizika |
+|-|-|-|-|
+| Ruční příprava | Nízká | Nízké | Nízká |
+| Automatické skripty | Střední | Střední | Nízká |
+| Hromadné generování dat | Střední–velká (dle systému) | Střední | Nízká |
+| Kopie produkčních dat bez úpravy | Nízká | Nízké | Vysoká (právní a regulační) |
+| Kopie produkčních dat s anonymizací | Střední–velká | Střední | Nízká |
+==== Způsoby sdílení dat ====
+  * Neří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.
+=== Další možnosti ===
+  * 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í.
+===== Jednotkové testy=====
+==== Princip ====
+  * 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.
+==== Vlastnosti ====
+  * 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.
+==== Unit test X Integration test ====
+| Aspekt | Jednotkové testy | Integrační testy |
+|-|-|-|
+| Úroveň | Testují jednotlivé bloky kódu (např. metody, třídy) izolovaně. | Testují spolupráci více komponent (modulů, služeb, systémů). |
+| Zaměření | Ověření správnosti malých jednotek logiky. | Ověření správnosti propojení mezi jednotkami a jejich interakce. |
+| Nástroje | Unit test frameworky (JUnit, TestNG). | Automatizační frameworky, integrační nástroje, end-to-end testy. |
+| Komplexita | Nízká (zaměřeno na detaily). | Vyšší (zaměřeno na celý proces, komunikaci, integrace). |
+| Účel | Rychlé odhalení chyb v kódu, prevence regrese. | Ověření, že jednotlivé části systému fungují dohromady správně. |
+| Příklad | Test metody pro výpočet ceny. | Test propojení mezi platebním modulem a bankovní API. |
+===== Automatizované testy založené na simulaci akcí uživatele v uživatelském rozhraní systému=====
+==== Princip testu ====
+  * **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.
+==== Příklad technologie ====
+  * **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).
+==== Rozdíl oproti jednotkovým testům ====
+| Aspekt | E2E testy (testy UI) | Jednotkové testy |
+|-|-|-|
+| Úroveň | Testují celý systém (od uživatelského vstupu po backend a zpět). | Testují izolované části kódu (metody, funkce). |
+| Zaměření | Uživatelská zkušenost, integrační funkce, procesy napříč systémem. | Logika a správnost jednotlivých bloků kódu. |
+| Rychlost | Pomalejší, protože zahrnují více vrstev systému. | Velmi rychlé, běží přímo nad kódem. |
+| Stabilita | Náchylné k chybám způsobeným změnami UI nebo závislostí. | Stabilní, méně závislé na okolí. |
+| Nástroje | Selenium, Cypress, Playwright, TestCafe, Puppeteer. | JUnit, TestNG, NUnit, xUnit. |
+| Účel | Ověření, že celý systém funguje pro uživatele. | Ověření, že logika kódu funguje podle očekávání. |
+===== Testovací strategie: princip metody Business Driven Test Management =====
+=== Testovací Strategie Obecně ===
+  * 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.
+==== Princip metody Business Driven Test Management ====
+  * 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.
+=== Základní části metody ===
+  * **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žší.
+=== Souvislosti mezi částmi ===
+  * 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.

Trace: • a_legacy_of_excellence_and_innovation

Differences

Search

Navigation

Print/export

Tools

QR Code