what is test scenario
Tento výukový program vysvětluje, co je testovací scénář, spolu s významem, implementací, příklady a šablonami testovacího scénáře:
O jakékoli softwarové funkčnosti / funkci, kterou lze testovat, se říká, že jde o testovací scénář. Při psaní testovacích scénářů se zohledňuje perspektiva koncového uživatele.
Tento kurz vám pomůže při odpovídání na otázky: proč jsou vyžadovány testovací scénáře, když jsou psané testovací scénáře a jak psát testovací scénáře.
Co se naučíte:
Co je testovací scénář?
Zvažte hypotetickou situaci: Je tu obrovský oceán. Musíte cestovat přes oceán z jednoho pobřeží na druhé. Například, z Bombaje, indického pobřeží do Colomba na pobřeží Srílanky.
Způsob cestování, který si můžete zvolit, je:
i) Airways: Lette do Colomba
ii) Vodní cesty:Chcete-li cestovat do Colomba, dejte přednost lodi
iii) Železnice:Jeďte vlakem na Srílanku
Nyní pro testovací scénáře: Cestování z mořského pobřeží Bombaj do mořského pobřeží Colombo je funkčnost, kterou je třeba otestovat.
Testovací scénáře zahrnují:
- Cestování Airways,
- Cestování po vodních cestách nebo
- Cestování po železnici.
Tyto testovací scénáře budou obsahovat testovací případy.
Testovací případy, které lze zapsat pro výše uvedené testovací scénáře, zahrnují:
Scénář testu: Cestování letadly
Testovací případy mohou zahrnovat scénáře jako:
- Let je podle plánovaného času.
- Let není podle plánovaného času.
- Nastala mimořádná situace (silné srážky a bouře).
Stejným způsobem lze zapsat samostatnou sadu testovacích případů pro další zbývající scénáře.
Nyní se podívejme na scénáře technologických testů.
Testovacím scénářem je cokoli, co lze otestovat. Můžeme tedy konstatovat, že jakákoli softwarová funkce, která je testována a lze ji rozdělit na několik menších funkcí a lze ji označit jako „Testovací scénář“.
Před dodáním jakéhokoli produktu klientovi je třeba posoudit a vyhodnotit kvalitu produktu. Testovací scénář pomáhá při hodnocení funkční kvality softwarové aplikace, která je v souladu s jejími obchodními požadavky.
Scénář testeru je proces, při kterém tester testuje softwarovou aplikaci z pohledu koncového uživatele. Před implementací do produkčního prostředí je důkladně posouzen výkon a kvalita softwarové aplikace.
Důležitost testovacího scénáře
- Jeden testovací scénář může mít několik „testovacích případů“. Lze to považovat za velký panoramatický snímek a testovací případy jsou malé části, které jsou důležité pro dokončení panoramatu.
- Jedná se o jednorázový příkaz a testovací případy obsahují postupný popis k dokončení účelu příkazu testovacího scénáře.
- Příklad:
Scénář testu: Proveďte platbu za taxislužbu využívanou.
Bude to mít několik testovacích případů, jak je uvedeno níže:
jaká je nejlepší e-mailová služba k použití
(i) Použitý způsob platby: PayPal, Paytm, kreditní / debetní karta.
ii) PlatbaHotovo je úspěšné.
(iii) Platba byla neúspěšná.
(iv) Platbaproces přerušen mezi.
(proti) Nelze získat přístup k platebním metodám.
(my) Aplikacerozpadá se mezi tím.
- Testovací scénáře tak pomáhají při hodnocení softwarové aplikace podle skutečných situací.
- Testovací scénáře, pokud jsou určeny, pomáhají při rozšiřování rozsahu testování.
- Toto rozdvojení se nazývá prioritizace, která pomáhá při určování důležitých funkcí softwarové aplikace.
- Prioritní testování funkcí pomáhá do značné míry při úspěšné implementaci softwarové aplikace.
- Jakmile budou mít testovací scénáře prioritu, nejdůležitější funkce lze snadno identifikovat a otestovat na prioritě. Tím je zajištěno, že většina rozhodujících funkcí funguje dobře a vady s tím související jsou řádně zachyceny a odstraněny.
- Scénáře testování určují tok obchodního procesu softwaru, a proto je možné komplexní testování aplikace.
Rozdíl mezi testovacím scénářem a testovacím případem
Scénář testu | Testovací případy |
---|---|
Je vyžadována krátká dokumentace. | Je vyžadována podrobná dokumentace. |
Scénář testu je koncept. | Testovací případy jsou řešení k ověření tohoto konceptu. |
Testovací scénář je funkčnost na vysoké úrovni. | Testovací případy jsou podrobný postup testování funkce na vysoké úrovni. |
Testovací scénáře jsou odvozeny z požadavků / uživatelských příběhů. | Testovací případy jsou odvozeny z testovacích scénářů. |
Scénář testu je „Jaká funkce má být testována“ | Testovací případy jsou „Jak otestovat funkčnost“. |
Testovací scénáře mají několik testovacích případů. | Testovací případ může, ale nemusí být přidružen k několika testovacím scénářům. |
Jednotlivé testovací scénáře nelze nikdy opakovat. | Jeden testovací případ lze použít několikrát v různých scénářích. |
K dokončení testovacího scénáře jsou nutné brainstormingové relace. | Vyžadují se podrobné technické znalosti softwarové aplikace |
Šetřič času jako minutové podrobnosti není vyžadován. | Časově náročné, protože je třeba se starat o každou minutu. |
Náklady na údržbu jsou nízké, protože jsou potřebné nízké zdroje. | Náklady na údržbu jsou vysoké, protože jsou potřebné vysoké zdroje |
Proč jsou testovací scénáře nepostradatelné?
Scénáře testování jsou odvozeny z požadavků nebo uživatelských příběhů.
- Vezměte si příklad testovacího scénáře pro rezervaci taxíkem.
- Scénáře mohou být jako možnosti rezervace kabiny, platební metody, sledování GPS, správně zobrazená nebo nezobrazená cestovní mapa, správně zobrazené nebo nezobrazené podrobnosti o kabině a řidiči atd. Všechny jsou uvedeny v šabloně testovacího scénáře.
- Nyní předpokládejme, že testovacím scénářem je zkontrolovat, zda jsou zapnuty služby určování polohy, pokud nejsou zapnuty, zobrazit zprávu „Zapnout služby určování polohy“. Tento scénář chybí a není uveden v šabloně testovacích scénářů.
- Ze scénáře „Služba určování polohy“ vznikají další související scénáře testování. Může to být:
- Polohová služba se zobrazila šedě.
- Služba určování polohy je zapnutá, ale žádný internet.
- Omezení pro služby určování polohy.
- Je zobrazeno nesprávné umístění.
- Chybí jediný scénář může znamenat, že přijdete o mnoho dalších zásadní scénáře nebo testovací případy . To může mít skvělý negativní vliv při implementaci softwarové aplikace. To má za následek velkou ztrátu rekurzů (lhůt).
- Testovací scénáře pomáhají do značné míry v vyhýbání se vyčerpávajícím zkouškám . Zajišťuje testování všech rozhodujících a očekávaných obchodních toků, které dále pomáhají při komplexním testování aplikace.
- To jsou spořiče času. Rovněž není vyžadován podrobný popis podle testovacích případů. Je specifikován jednorázový popis toho, co se má testovat.
- Scénáře testu jsou zapsány později brainstorming členů týmu. Pravděpodobnost, že některý scénář (rozhodující nebo vedlejší) zmeškáte, je proto minimální. To se děje s ohledem na technické aspekty a také obchodní tok softwarové aplikace.
- Scénáře testu mohou navíc schválit buď obchodní analytik, klient nebo oba, kteří mají výslovnou znalost testované aplikace.
Testovací scénáře jsou tedy nepostradatelnou součástí SDLC.
Implementace testovacích scénářů
Podívejme se na implementaci testovacích scénářů nebo na to, jak psát testovací scénáře -
- Jsou vytvořeny požadavky na epos / podnikání.
- Příklad eposu : Vytvořte si účet Gmail. Epic může být hlavní funkcí aplikace nebo obchodního požadavku.
- Eposy jsou rozděleny do menších uživatelských příběhů napříč sprinty.
- Uživatelské příběhy jsou odvozeny od společnosti Epics. Tyto uživatelské příběhy musí být základem a schváleny zúčastněnými stranami.
- Scénáře testu jsou odvozeny z příběhů uživatelů nebo BRS (Business Requirement Document), SRS (System Requirement Specification Document) nebo FRS (Functional Requirement Document), které jsou finalizovány a zohledněny.
- Testeři píší testovací scénáře.
- Tyto testovací scénáře schvaluje vedoucí týmu, obchodní analytik nebo projektový manažer v závislosti na organizaci.
- Každý testovací scénář musí být svázán s alespoň jedním příběhem uživatele.
- Musí být identifikovány scénáře pozitivního i negativního testu.
- Uživatelské příběhy zahrnují Kritéria přijetí jako :
- Kritéria přijetí jsou seznam podmínek nebo stav záměru pro požadavky zákazníka. Při psaní akceptačních kritérií se berou v úvahu očekávání zákazníka a také nedorozumění.
- Jsou jedinečné pro jeden příběh uživatele a každý příběh uživatele musí mít alespoň jedno akceptační kritérium, které by mělo být nezávisle testovatelné.
- Kritéria přijetí pomáhají určit, které funkce jsou v rozsahu a které jsou mimo rozsah projektu. Tato kritéria by měla zahrnovat funkční i nefunkční prvky.
- Obchodní analytici píší kritéria přijetí a vlastník produktu je schvaluje.
- Nebo v některých případech může vlastník produktu sám napsat kritéria.
- Scénáře testu lze získat z kritérií přijetí.
Příklady testovacích scénářů
# 1) Testovací scénáře pro aplikaci Kindle
Kindle je aplikace, která umožňuje svým elektronickým čtenářům vyhledávat e-knihy online, stahovat je a nakupovat. Amazon Kindle dává čtečce elektronických knih skutečný zážitek z držení knihy v ruce a jejího čtení. Dokonce i otáčení stránek je do aplikace pěkně simulováno.
Nyní si poznamenejme testovací scénáře. ( Poznámka: Níže jsou uvedeny omezené scénáře, abyste získali obecnou představu o psaní testovacího scénáře. Z toho může být odvozeno několik testovacích případů).
Testovací scénáře # | Testovací scénáře |
---|---|
7 | Ověřte, zda funkce stahování funguje správně. |
jeden | Ověřte, zda se aplikace Kindle spouští správně. |
dva | Po spuštění aplikace ověřte, zda se rozlišení obrazovky upraví podle různých zařízení. |
3 | Ověřte, zda je zobrazený text čitelný. |
4 | Ověřte, zda možnosti přiblížení a oddálení fungují. |
5 | Ověřte, zda jsou kompatibilní soubory importované do aplikace Kindle čitelné. |
6 | Ověřte kapacitu úložiště aplikace Kindle. |
8 | Ověřte, zda simulace otáčení stránek funguje správně |
9 | Ověřte kompatibilitu formátů elektronických knih s aplikací Kindle. |
10 | Ověřte písma podporovaná aplikací Kindle. |
jedenáct | Ověřte výdrž baterie využívanou aplikací Kindle. |
12 | Ověřte výkon Kindle v závislosti na síťovém připojení (Wi-Fi, 3G nebo 4G). |
Z jednotlivých testovacích scénářů uvedených výše lze odvodit více testovacích případů.
# 2) Kritéria přijetí pro dokumenty Google
„Dokumenty Google“ je webová aplikace pro vytváření, úpravy a sdílení textových dokumentů, tabulek, snímků a formulářů. Ke všem souborům lze přistupovat online pomocí webového prohlížeče s připojením k internetu.
Vytvořené dokumenty lze sdílet jako webovou stránku nebo dokument připravený k tisku. Uživatel může nastavit omezení toho, kdo může dokumenty prohlížet a upravovat. Jeden dokument mohou společně sdílet a zpracovat různí jednotlivci z různých geografických umístění.
Omezené testovací scénáře jsou uvedeny níže pro obecné pochopení. Scénáře hloubkových testů pro dokumenty Google mohou být celkem samostatným tématem.
Kritéria přijatelnosti # | Kritéria přijatelnosti |
---|---|
7 | Na jednom dokumentu může pracovat více uživatelů. |
jeden | Word, Tabulky nebo Formuláře lze úspěšně otevřít bez chyb. |
dva | Šablony jsou k dispozici pro dokumenty, listy a snímky. |
3 | Dostupné šablony jsou přístupné uživatelům. |
4 | Použitou šablonu lze upravovat (např. Písma, velikost písma, přidávání textu, mazání textu, vkládání snímků). |
5 | Pokud není připojení k internetu dočasně k dispozici, lze soubor uložit lokálně a nahrát jej podle dostupnosti připojení k internetu. |
6 | Změny provedené více uživateli nejsou přepsány. |
8 | Hotová práce se uloží, pokud dojde ke ztrátě připojení k internetu během nahrávání souboru. |
9 | Omezení sdílení jsou použita správně. |
10 | Omezení zobrazení uživatelé nemohou v dokumentech provádět žádné úpravy. |
jedenáct | Dokumenty lze publikovat na internetu pro širokou veřejnost. |
12 | Změny provedené v dokumentech se ukládají s časovým razítkem a podrobnostmi o autorovi. |
Počet testovacích scénářů bude pro Dokumenty Google několikanásobný a velmi obrovský. V takových případech jsou zúčastněnými stranami stanovena a schválena pouze akceptační kritéria a členové týmu na těchto akceptačních kritériích pracují. Psaní testovacích případů pro nebo spíše testovací scénáře může být vyčerpávajícím úkolem pro obrovské aplikace.
Tato kritéria přijetí hrají hlavní roli při iteračním plánování procesu a nikdy by neměla být přehlížena. Jejich definování předem a předem se vyhne překvapením nebo šokům na konci sprintů nebo uvolnění
Dáno podmínka.
Když udělat akci.
Pak očekávaný výsledek.
Formáty Zadané, Kdy a Pak jsou užitečné pro určení kritérií přijetí.
Příklad šablony testovacího scénáře
Použít ID příběhu # | ID testovacího scénáře # | Verze # | Testovací scénáře | # Počet testovacích případů | Důležitost |
---|---|---|---|---|---|
USID12.1 | TSID12.1.1 | Kin12.4 | Ověřte, zda se aplikace Kindle spouští správně. | 4 | Vysoký |
USID12.1 | TSID12.1.2 | Kin12.4 | Ověřte kapacitu úložiště aplikace Kindle. | 3 | Střední |
Závěr
V každém testování životního cyklu softwaru je velmi důležitým prvkem porozumění a stanovení testovacích scénářů. Kvalitu softwaru lze zlepšit dobrým základem pro testovací scénáře. Často se může použití testovacích případů a testovacích scénářů zaměnit.
Pravidlo palce však je, že testovací scénář se používá k zápisu více testovacích případů, nebo můžeme říci, že testovací případy jsou odvozeny od testovacích scénářů. Dobře definované testovací scénáře zajišťují kvalitní software.
Doporučené čtení
- Ukázková šablona plánu testování softwaru s formátem a obsahem
- Ukázková šablona testovacího případu s příklady testovacích případů (Stáhnout)
- Ukázková šablona pro protokol o přejímce s příklady
- Šablony v C ++ s příklady
- Výukový program Python DateTime s příklady
- Vyjmout příkaz v Unixu s příklady
- Testovací scénář vs Testovací případ: Jaký je rozdíl mezi nimi?
- Blazemeter Plugin and Jmeter Template