Lekce 2 - Testovací případy
V minulé lekci, Úvod do automatizovaného testování softwaru, jsme si ukázali přínosy automatizace a představili si projekt, se kterým budeme pracovat.
V tomto tutoriálu kurzu praktického testování projektů si připomeneme, jak pracovat s nástrojem Jira a seznámíme se s konkrétními testovacími případy, na které se v průběhu kurzu zaměříme.
Testovací případy v Jiře
Základy práce s nástrojem Jira jsme si popsali v lekci Plánování testů v Jiře - Tvorba testovacích scénářů, kde jsme také vytvořili první testovací případ (test case) k manuálnímu testování, TC1 – Přidání osoby.
Následně jsme v lekcích Plánování testů v Jira - Testovací případy pro front-end a Plánování testů v Jira - Testovací případy pro back-end a UX doplnili další TC a vše rozdělili do tří sprintů:

TC pro automatizované testování
V následujících tutoriálech se zaměříme na automatizaci testovacích případů. Ukážeme si, jak testovat obě vrstvy naší aplikace pomocí běžně používaných nástrojů v Pythonu. K tomu si vytvoříme další testovací případy v Jira, které zařadíme do nového - čtvrtého sprintu, abychom tak měli automatizované testování oddělené.
Pokud jste neabsolvovali kurz manuálního testování, vytvořte si v Jira nový projekt s názvem "Fakturační systém". V tomto projektu si následně vytvoříme nový sprint a testovací případy pro automatizované testování.
Očekáváme, že účastníci už mají zkušenosti s návrhem testovacích případů, orientují se v Jiře a rozumí základům testovacího procesu, na které v tomto kurzu přímo navazujeme a dále je rozvíjíme směrem k automatizaci. Pokud tyto znalosti nemáte, doporučujeme nejdříve absolvovat kurz Praktické testování projektů - Manuální testování.
Vytvoření nového sprintu
V sekci Backlog si vytvoříme nový sprint. Klikneme na tlačítko Create sprint:

Sprint přejmenujeme. Klikneme na ... a zvolíme Edit sprint:

Jako nový název zadáme Sprint 4 - Automatizace
. Můžeme zde
také nastavit dobu trvání sprintu, obvykle to bývá 1–2
týdny. Alternativně můžeme nastavit počáteční a konečné
datum sprintu. Nás bude nyní nejvíce zajímat poslední pole, v
němž definujeme cíl sprintu (Sprint goal). Zde tedy
vyplníme krátký popis našeho testovacího úkolu - "Otestovat základní
funkcionalitu aplikace, včetně CRUD operací (vytváření, čtení,
aktualizace, mazání), s důrazem na validaci vstupů a zobrazení v
uživatelském rozhraní." a potvrdíme tlačítkem Update:

Výsledek bude vypadat takto:

Testování front-endu pomocí Selenia
Pro automatizované testování webového rozhraní využijeme nástroj Selenium, který umožňuje programově ovládat webový prohlížeč (např. Chrome nebo Firefox), jako by s ním pracoval běžný uživatel. Během tohoto testování Selenium kliká na prvky stránky, vyplňuje formuláře nebo ověřuje přítomnost konkrétních dat.
Pro testování front-endu si vytvoříme tyto testovací případy:
- TC11 – Přidání faktury - Ověříme, že po vyplnění formuláře a jeho odeslání se nová faktura správně uloží a zobrazí v seznamu.
- TC12 – Smazání faktury - Otestujeme, že po kliknutí na tlačítko Smazat u konkrétní faktury dojde k jejímu odstranění z databáze a že ji uživatel již neuvidí v seznamu. Díky tomuto testu bude odstraněna faktura, kterou jsme vytvořili v předchozím automatickém testu (TC11 – Přidání faktury).
Oba testy tak tvoří uzavřený celek, který ověřuje správnou funkčnost systému při práci se záznamy od jejich vytvoření až po jejich odstranění. Tyto scénáře zároveň pokrývají základní funkce, s nimiž se uživatel nejčastěji setkává (vytváření a mazání záznamů).
TC11 – Přidání faktury
Jako první si připravíme a otestujeme TC11 - Přidání faktury - Selenium. V backlogu zvolíme u čtvrtého sprintu + Create:

Dále vybereme typ Task (obrázek fajfky v modrém čtverečku), je možné, že tento typ zde bude automaticky přednastavený, pokud ne, rozklikneme si ikonku a vybereme správný typ:

Pojmenujeme jej TC11 - Přidání faktury - Selenium
a stiskneme
Enter
:

Kliknutím na název případu se nám v pravé části stránky otevře možnost editace:

Kliknutím na ID testovacího případu v hlavičce, jej můžeme otevřít v samostatném okně:

Připravená pole vyplníme dle tabulky:
Název pole | Text, který budeme vkládat |
---|---|
Description | Testovací případ ověřuje, zda uživatel může úspěšně přidat novou fakturu v aplikaci a zda se správně zobrazí v seznamu. |
Preconditions | • Uživatel se nachází na obrazovce "Faktury". |
• Aplikace je spuštěna na adrese http://localhost:3000. | |
Test Steps | 1. Uživatel klikne v horním menu na záložku "Faktury". |
2. Klikne na tlačítko "Nová faktura". | |
3. Počká, než se zobrazí formulář. | |
4. Do pole "Číslo faktury" vyplní hodnotu (např. 12345). | |
5. Vybere první položku v selectu "Dodavatel". | |
6. Vybere druhou položku v selectu "Odběratel". | |
7. Vyplní datum vystavení, datum splatnosti, produkt, cenu, DPH a poznámku. | |
8. Klikne na tlačítko "Uložit". | |
9. Po odeslání ověří, že se nová faktura zobrazí v seznamu faktur. | |
10. Ověří, že cena faktury odpovídá očekávané hodnotě. | |
Expected Results | • Nová faktura se po kliknutí na tlačítko "Uložit" uloží. |
• Faktura se ihned zobrazí v seznamu faktur s vyplněnými údaji včetně správné ceny. | |
Acceptance Criteria | • Uživatel musí být schopen přidat fakturu při vyplnění všech povinných polí. |
• Po úspěšném uložení se nová faktura zobrazí v seznamu faktur se správnými daty. |
V testovacím případu jsme nejdříve vyplnili popis, aby tester věděl, kterou část kódu testuje a co přesně má být ověřeno. Pomocí Preconditions zajistíme, že test začíná ve správném kontextu a není třeba provádět zbytečné přechody v aplikaci. Testovacími kroky ověřujeme, že aplikace funguje podle očekávání, když uživatel zadá platné údaje. Tento scénář simuluje běžné použití aplikace.
Body uvedené v části Expected Results slouží k vymezení správného fungování systému a zajištění předvídatelného chování při různých scénářích. V posledním poli máme stanovené jasné podmínky, které musí být splněny, aby byl testovací případ úspěšně dokončen. Tím zajišťujeme, že vývojový tým i tester mají jednotné porozumění tomu, co se testuje a jaké jsou požadavky na funkčnost.
Negativní scénáře jsme si již vyzkoušeli v manuálním testování. Zde se v rámci automatizace zaměříme pouze na ověření pozitivního scénáře.
Výsledek bude vypadat takto:

TC12 – Smazání faktury
V dalším testovacím případu budeme kontrolovat funkčnost smazání
faktury. Vytvoříme si nový testovací případ a pojmenujeme jej
TC12 - Smazání faktury - Selenium
.
Než se podíváte na řešení, zkuste si testovací případ nejprve navrhnout sami. Řešení testovacího případu najdete skryté pod šipkou, kterou si můžete rozkliknout v případě, že si nebudete vědět rady. Slouží pouze jako nápověda, nikoli k přímému opisování.
Název pole | Text, který budeme vkládat |
---|---|
Description | Testovací případ ověřuje, zda uživatel může úspěšně odstranit existující fakturu v aplikaci a zda se odstranění projeví v seznamu faktur. |
Preconditions | • Uživatel se nachází na obrazovce "Faktury". |
• V systému existuje alespoň jedna faktura, která je připravena k odstranění. | |
Test Steps | 1. Uživatel klikne v horním menu na "Faktury". |
2. Vyhledá fakturu podle čísla (např. 12345). | |
3. Klikne na tlačítko "Odstranit" u příslušné faktury. | |
4. Potvrdí případné potvrzovací dialogové okno (pokud se zobrazuje). | |
5. Ověří, že faktura byla ze seznamu odstraněna. | |
Expected Results | • Faktura je po kliknutí na "Odstranit" úspěšně smazána. |
• Faktura se nadále nezobrazuje v seznamu faktur. | |
Acceptance Criteria | • Uživatel musí být schopen odstranit existující fakturu. |
• Po odstranění faktura zmizí ze seznamu a není dále dostupná pro zobrazení nebo úpravu. |
Výsledek bude vypadat takto:

Testování back-endu pomocí pytestu
Serverovou část aplikace budeme testovat pomocí frameworku pytest, který je široce používaný pro automatizované testování v Pythonu. Umožňuje přehledně organizovat testy, hromadně je spouštět a vyhodnocovat jejich výsledky.
Na rozdíl od testování front-endu se zde zaměříme na ověření logiky a funkčnosti API, tedy na to, zda server správně reaguje na požadavky typu editace, mazání, získání dat apod. Místo simulace uživatele pracujeme přímo s požadavky HTTP.
Vybrané testovací scénáře:
- TC13 – Editace osoby - Ověříme, zda server umožní upravit údaje u existující osoby a zda se změny správně uloží.
- TC14 – Smazání osoby - Otestujeme, že po odeslání požadavku na smazání určité osoby server záznam skutečně odstraní a nebude jej vracet v seznamu.
Smazání osoby je v naší aplikaci odlišné od smazání faktury. Ve skutečnosti se "smazaná" osoba, která může figurovat v již vystavených fakturách, v databázi pouze skryje. Díky použití frameworku pytest se po provedení těchto testovacích případů data v databázi automaticky vrátí do původního stavu, takže testování nijak neovlivní reálný obsah aplikace.
Oba případy pokrývají důležité akce nad entitou osoby a zároveň
ověřují různé HTTP metody (v našem případě PUT
a
DELETE
), čímž si procvičíme práci s REST API a testování
různých typů požadavků.
Zvolená čtveřice testovacích případů dobře reprezentuje základní funkce obou částí systému a umožní nám vytvořit smysluplný základ pro budoucí rozšíření automatizace. Zaměřujeme se na CRUD operace (Create, Read, Update, Delete), které jsou jádrem většiny moderních aplikací.
Výsledkem bude nejen provedení konkrétních testů, ale i vytvoření základního testovacího rámce, na který bude možné dále navázat.
TC13 – Editace osoby
V další testovacím případu budeme kontrolovat funkčnost editace osoby.
Vytvoříme si nový testovací případ a pojmenujeme jej
TC13 – Editace osoby - pytest
.
Pro testování back-endu budeme potřebovat URL adresu (endpoint) a JSON kód, který můžeme zjistit v API dokumentaci k našemu projektu. V API dokumentaci si najdeme endpoint na editaci osoby a pomocí těchto údajů vyplníme v Jira příslušná pole:
Název pole | Text, který budeme vkládat |
---|---|
Description | Testovací případ ověřuje, zda API umožňuje upravit existující záznam osoby a zda při této operaci proběhne správná logika skrytí původního záznamu a vytvoření nového záznamu. |
Preconditions | • V databázi existuje alespoň jedna osoba se všemi vyplněnými povinnými údaji. |
• API je dostupné na adrese http://localhost:8000/api/persons/{id}/. | |
Test Steps | 1. Odeslat PUT požadavek na endpoint /api/persons/{id}/ s novým identifikačním číslem, ostatní data zůstanou stejná. |
2. Ověřit, že API vrátí status kód 200 OK. | |
3. Ověřit, že původní záznam osoby má nastaven atribut hidden na true. | |
4. Ověřit, že nový záznam osoby existuje a má změněné identifikační číslo. | |
Expected Results | • API vrátí stavovou odpověď 200 OK. |
• Původní záznam je označen jako skrytý (hidden = true). | |
• Nový záznam osoby existuje a má nové identifikační číslo. | |
Acceptance Criteria | • Editace osoby přes API proběhne úspěšně a zachová pravidla aplikace: původní záznam je skryt, nový záznam je vytvořen a data odpovídají požadavku. |
Výsledek bude vypadat takto:

TC14 – Smazání osoby
V další testovacím případu budeme kontrolovat funkčnost smazání
osoby. Vytvoříme si nový testovací případ a pojmenujeme jej
TC14 – Smazání osoby - pytest
.
Než se podíváte na řešení, zkuste si testovací případ nejprve navrhnout sami. Řešení testovacího případu najdete skryté pod šipkou, kterou si můžete rozkliknout v případě, že si nebudete vědět rady. Slouží pouze jako nápověda, nikoli k přímému opisování.
Název pole | Text, který budeme vkládat |
---|---|
Description | Testovací případ ověřuje, zda API umožňuje "smazání" osoby a zda při této operaci dojde ke správné změně stavu osoby na "skrytá" (hidden = true) namísto fyzického smazání z databáze. |
Preconditions | • V databázi existuje alespoň jedna osoba se všemi vyplněnými povinnými údaji. |
• API je dostupné na adrese http://localhost:8000/api/persons/{id}/. | |
Test Steps | 1. Odeslat DELETE požadavek na endpoint /api/persons/{id}/. |
2. Ověřit, že API vrátí status kód 204 No Content. | |
3. Ověřit, že záznam osoby má atribut hidden nastaven na true. | |
Expected Results | • API vrátí stavovou odpověď 204 No Content. |
• Původní záznam osoby není fyzicky odstraněn, ale je označen jako skrytý (hidden = true). | |
Acceptance Criteria | • API musí umožnit "logické smazání" osoby. |
• Po úspěšném smazání se osoba nesmí nadále zobrazovat v seznamu aktivních osob. | |
• Atribut hidden musí být správně nastaven. |
Výsledek bude vypadat takto:

V příští lekci, Automatizované testování front-endu - Příprava prostředí, přejdeme k automatickému testování projektu a připravíme si prostředí pro automatizované testy front-endu.