Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| statnice:bakalar:b6b36ts1 [2025/05/28 15:11] – [Automatizované testy založené na simulaci akcí uživatele v uživatelském rozhraní systému] prokop | statnice:bakalar:b6b36ts1 [2025/05/28 15:42] (current) – [Testovací strategie: princip metody Business Driven Test Management] prokop | ||
|---|---|---|---|
| Line 378: | Line 378: | ||
| | Příklad | Test metody pro výpočet ceny. | Test propojení mezi platebním modulem a bankovní API. | | | 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===== | ===== Automatizované testy založené na simulaci akcí uživatele v uživatelském rozhraní systému===== | ||
| - | === Princip testu === | + | ==== Princip testu ==== |
| * **End-to-end (E2E)** testování simuluje chování reálného uživatele v aplikaci. | * **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. | * Ověřuje správnou funkčnost aplikace z pohledu uživatele – od začátku do konce. | ||
| Line 388: | Line 388: | ||
| * ověření správného dokončení procesu. | * ověření správného dokončení procesu. | ||
| - | === Příklad technologie === | + | ==== Příklad technologie |
| * **Selenium** – nástroj pro automatizaci webových prohlížečů. | * **Selenium** – nástroj pro automatizaci webových prohlížečů. | ||
| * Další příklady (BONUS): | * Další příklady (BONUS): | ||
| Line 401: | Line 401: | ||
| * ověřovat výsledky akcí (např. přidání položky, dokončení platby). | * ověřovat výsledky akcí (např. přidání položky, dokončení platby). | ||
| - | === Rozdíl oproti jednotkovým testům === | + | ==== Rozdíl oproti jednotkovým testům |
| | Aspekt | E2E testy (testy UI) | Jednotkové testy | | | Aspekt | E2E testy (testy UI) | Jednotkové testy | | ||
| |-|-|-| | |-|-|-| | ||
| Line 410: | Line 410: | ||
| | Nástroje | Selenium, Cypress, Playwright, TestCafe, Puppeteer. | JUnit, TestNG, NUnit, xUnit. | | | 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í. | | | Úč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: 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, | ||
| + | * Pomáhá sladit očekávání mezi zadavatelem, | ||
| + | * Zajišťuje, | ||
| + | |||
| + | ==== 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 | ||
| + | * analýzu rizik, | ||
| + | * test levels, | ||
| + | * druhy testů | ||
| + | * 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, | ||
| + | * **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, | ||
