Jaký formát je nejlepší pro šablonu testovacího případu - Excel nebo Word?

Excel je vhodný pro strukturované provedení trackrál se stavovými sloupci a filtry. Word se hodí pro narativní testovací scénáře. Mnoho týmů přesouvá oba formáty do nástrojů pro správu testů, jako je HP ALM nebo JIRA, pro tracsnadnost.

Stáhnout šablonu testovacího případu v Excelu

⚡ Chytré shrnutí

Šablona testovacího případu poskytuje standardizovanou strukturu pro dokumentaci testovacích případů pro jakýkoli softwarový projekt. Tento tutoriál vysvětluje všechna základní pole, nabízí ukázky v Excelu a Wordu ke stažení a uvádí osvědčené postupy, které zajišťují konzistenci testovacích artefaktů v celém týmu QA.

???? Konzistence na prvním místě: Standardní šablona sladí tým QA a zkrátí nástupní proces pro nové testery.
🧾 Klíčové obory: ID testovacího případu, Priorita, Kroky, Testovací data, Očekávaný výsledek a Stav jsou neobchodovatelné položky.
📊 Excel vs. Word: Excel je ideální pro tabulkové zpracování trackrál; Word se hodí k narativním testovacím scénářům.
🔗 Volitelné obohacení: ID defektu, odkaz na požadavky, reference a příznak automatizace zvyšují připravenost na audit.
🤖 Aktivace umělé inteligence: Nástroje umělé inteligence automaticky generují, seskupují a prioritizují testovací případy z požadavků.

Přečíst více

Co je šablona testovacího případu?

A Šablona testovacího případu je dobře navržený dokument, který pomáhá testerům vyvíjet a konzistentně chápat data pro konkrétní scénář testovacího případu. Dobrý Testovací případ Šablona udržuje konzistenci testovacích artefaktů pro tým a usnadňuje všem zúčastněným stranám sledování testovacích případů. Psaní testovacích případů ve standardním formátu snižuje náročnost testování a snižuje chybovost. Standardizovaný formát je obzvláště žádoucí, když testovací případy kontrolují externí odborníci.

Šablona, kterou si pro svůj projekt vyberete, závisí na vašich zásadách testování. Mnoho organizací vytváří testovací případy v Microsoft Excel, ostatní v Microsoft Worda některé používají nástroje pro správu testů, jako je HP ALM.

Důležitá pole v šabloně testovacího případu

Bez ohledu na zvolenou metodu dokumentace musí každá dobrá šablona testovacího případu obsahovat následující pole.

Pole testovacího případu	Description
ID testovacího případu	Každý testovací případ by měl být reprezentován jedinečným ID. Pro označení typu testu použijte konvenci jako „TC_UI_1“ – například „Testovací případ uživatelského rozhraní č. 1“.
Priorita testu	Užitečné během provádění. Běžné hodnoty jsou Nízká, Střední a Vysoká.
Název modulu	Hlavní modul nebo submodul, který je testován.
Test Designed by	Jméno testera.
Datum navržení testu	Datum, kdy byl test navržen.
Test Provedl	Tester, který test provedl.
Datum provedení testu	Datum, kdy je třeba test provést.
Jméno nebo Název testu	Název testovacího případu.
Description / Shrnutí	Stručné shrnutí účelu testu.
Předběžná podmínka	Veškeré předpoklady, které musí být splněny před spuštěním tohoto testovacího případu. Uveďte všechny předpoklady.
Závislosti	Jakékoli závislosti na požadavcích na testování nebo jiných testovacích případech.
Testovací kroky	Podrobné kroky v pořadí, v jakém musí být provedeny. Buďte co nejkonkrétnější.
Testovací data	Testovací data použito jako vstup. Poskytněte různé datové sady s přesnými hodnotami.
Očekávaný výsledek	Očekávaný výsledek, včetně případných chyb nebo zpráv, které by se měly zobrazit na obrazovce.
Post-Condition	Stav systému po spuštění testovacího případu.
Skutečný výsledek	Skutečný výsledek zachycený po provedení.
Stav (Vyhovuje/Nevyhovuje)	Označte jako Neúspěšné, pokud skutečný výsledek neodpovídá očekávanému výsledku.
Poznámky	Zvláštní podmínky, které jinde nejsou zachyceny.

Volitelná pole lze přidat v závislosti na požadavcích projektu.

ID odkazu / vady: Odkaz vada nebo číslo závady, pokud test selhal.
Klíčová slova / Typ testu: Používá se ke kategorizaci testů podle typu, například použitelnosti, funkčnosti nebo obchodních pravidel.
Požadavky: Požadavek(y), pro který(é) je testovací případ napsán.
Odkazy / Přílohy: Cesta k podpůrnému dokumentu nebo diagramu pro složité scénáře.
Automatizace (Ano/Ne): TracStav automatizace k pro automatizované testovací případy.
Vlastní pole: Pole specifická pro potřeby klienta nebo procesu vašeho projektu.

Stáhnout šablonu testovacího případu (Excel a Word)

Obě šablony obsahují výše popsaná pole. Vyberte formát, který odpovídá stylu dokumentace vašeho týmu.

Nejlepší postupy pro psaní testovacích případů

Šablona je jen tak cenná, jako je disciplína použitá při jejím vyplňování. Níže uvedené postupy umožňují opakovaně použitelné testovací případy, tracsnadno a jasně.

Každý krok popište jasně: Každý tester by měl být schopen provést kroky bez nutnosti požadovat vysvětlení.
Začněte z pohledu uživatele: popisovat, co dělá uživatel, ne co dělá kód.
Znovupoužijte místo duplikace: odkazovat na existující testovací případ podle ID namísto opakování jeho kroků.
Zajistěte plné pokrytí: mapovat testovací případy na požadavky pomocí požadavku TracMatice proveditelnosti.
Použijte nástroj pro správu: platformy jako PROHLÍDKA nebo HP ALM uchovávají historii verzí, přílohy a protokoly spuštění na jednom místě.

Nejčastější dotazy

Excel je vhodný pro strukturované provedení trackrál se stavovými sloupci a filtry. Word se hodí pro scénáře narativního testování. Mnoho týmů přesouvá oba formáty do nástrojů pro správu testů, jako je HP ALM nebo PROHLÍDKA for tracsnadnost.

Testovací scénář je obecné prohlášení o tom, co se má testovat. Testovací případ je podrobný postup krok za krokem, který prokazuje, zda scénář splňuje nebo nesplňuje očekávání. Jeden scénář se obvykle mapuje na několik testovacích případů.

Používejte jasnou konvenci pojmenování, která označuje typ modulu a testu. Například TC_UI_LOGIN_001 znamená Uživatelské rozhraní, Přihlašovací modul, První testovací případ. Tento vzorec zajišťuje předvídatelnost ID v celém projektu.

Očekávaný výsledek je definován při návrhu testovacího případu a představuje správné chování. Skutečný výsledek je zaznamenán po provedení a ukazuje, co systém skutečně udělal. Neshoda označí test jako neúspěšný.

Ne. Předpoklady popisují stav systému, který je vyžadován před zahájením kroků. Uchovávejteping Jejich oddělení zkracuje testovací kroky a umožňuje jejich opakované použití napříč více testovacími případy, které sdílejí stejné nastavení.

Použijte požadavek TracMatice proveditelnosti (RTM), která mapuje každé ID požadavku na testovací případy, které ho ověřují. To zaručuje plné pokrytí a usnadňuje analýzu dopadu při změně požadavků.

Ano. Nástroje umělé inteligence čtou uživatelské příběhy nebo specifikace a navrhují pozitivní, negativní a hraniční testovací případy. Testeři stále kontrolují výstup, aby se ujistili, že obchodní záměr a hraniční případy jsou správně zachyceny.

Umělá inteligence řadí testovací případy podle nedávných změn kódu, historické míry selhání a obchodního rizika. Vysoce rizikové případy se spouštějí jako první, takže regresní cykly odhalují kritické vady brzy, místo aby čekaly na úplné schválení.