Jak psát testovací případy: Ultimate Guide s příklady

how write test cases

V tomto podrobném praktickém výukovém programu Jak psát testovací případy jsem se zabýval podrobnostmi o tom, co je testovací případ, jeho standardní definice a techniky testování testovacích případů.

Co je testovací případ?

Testovací případ obsahuje komponenty, které popisují vstup, akci a očekávanou odezvu, aby bylo možné zjistit, zda funkce aplikace funguje správně.

Testovací případ je sada pokynů k „JAK“ k ověření konkrétního testovacího cíle / cílů, které nám při následném zjištění sdělí, zda je očekávané chování systému splněno nebo ne.

Seznam výukových programů zahrnutých v této sérii psaní testovacích případů:

Jak psát:

Výukový program č. 1: Co je testovací případ a jak psát testovací případy (tento návod)
Výukový program č. 2: Ukázková šablona testovacího případu s příklady (Stáhnout) (musíš číst)
Výukový program č. 3: Psaní testovacích případů z dokumentu SRS
Výukový program č. 4: Jak psát testovací případy pro daný scénář
Výukový program č. 5: Jak se připravit na psaní testovacích případů
Výukový program č. 6: Jak psát případy negativního testu

Příklady:

Výukový program č. 7: 180+ ukázkových testovacích případů pro webové a desktopové aplikace
Výukový program č. 8: 100+ testovacích scénářů připravených k provedení (kontrolní seznam)

Techniky psaní:

Výukový program č. 9: Graf příčin a následků - technika psaní dynamických testovacích případů
Výukový program č. 10: Technika testování přechodového stavu
Výukový program č. 11: Technika testování ortogonálního pole
Výukový program č. 12: Technika hádání chyb
Výukový program č. 13: Technika návrhu zkoušky pole ověřovací tabulky (FVT)

Scénáře testovacího případu Vs:

Výukový program č. 14: Testovací případy vs. testovací scénáře
Výukový program č. 15: Rozdíl mezi testovacím plánem, strategií testu a testovacím případem

Automatizace:

Výukový program č. 16: Jak vybrat správné testovací případy pro testování automatizace
Výukový program č. 17: Jak převést ruční testovací případy do automatizačních skriptů

Nástroje pro správu testů:

Výukový program č. 18: Nejlepší nástroje pro správu testů
Výukový program č. 19: TestLink pro správu testovacích případů
Výukový program č. 20: Vytváření a správa testovacích případů pomocí HP Quality Center
Výukový program č. 21: Provádění testovacích případů pomocí ALM / QC

Případy specifické pro doménu:

Výukový program č. 22: Testovací případy pro aplikaci ERP
Výukový program č. 23: Testovací případy aplikace JAVA
Výukový program č. 24: Analýza hraničních hodnot a rozdělení ekvivalence

Pokračujme prvním tutoriálem v této sérii.

Doporučené nástroje:

Než budete pokračovat v procesu psaní testovacích případů, doporučujeme si stáhnout tento nástroj pro správu testovacích případů. To usnadní váš proces psaní testovacích případů uvedený v tomto kurzu:

# 1) TestRail

=> Stáhněte si nástroj pro správu testovacích případů TestRail

# 2) TestMonitor

Špičková online správa testů. Revoluční snadné.

TestMonitor je komplexní nástroj pro správu testů pro každou organizaci. Jednoduchý, intuitivní přístup k testování. Ať už implementujete podnikový software, potřebujete QA, vytváříte kvalitní aplikaci nebo potřebujete pomocnou ruku ve svém testovacím projektu, TestMonitor vás pokryje.

=> Navštivte web TestMonitor

Co se naučíte:

• Co je testovací případ a jak psát testovací případy?
  • Proč píšeme testy?
  • Jak psát testovací případy?
  • Základní formát prohlášení o případu
• Tipy pro psaní testů
  • • # 1) Udržujte to jednoduché, ale ne příliš jednoduché; aby to bylo složité, ale ne příliš složité:
    • # 2) Po zdokumentování testovacích případů zkontrolujte jednou jako tester:
    • # 3) Vázejte a usnadňujte testery:
    • # 4) Buďte přispěvatelem:
    • # 5) Nikdy nezapomeňte na koncového uživatele:
• Jak dosáhnout dokonalosti v dokumentaci testovacích případů
  • Užitečné tipy a triky
    • # 1) Je váš testovací dokument v dobrém stavu?
    • # 2) Nezapomeňte pokrýt negativní případy
    • # 3) Proveďte kroky atomového testu
    • # 4) Stanovte priority testů
    • # 5) Na pořadí záleží
    • # 6) Přidejte do komentářů časové razítko a název testeru
    • # 7) Uveďte podrobnosti o prohlížeči
    • # 8) V dokumentu si ponechejte dva samostatné listy - „Chyby“ a „Souhrn“
• Jak NE psát testy
  • 3 Nejběžnější problémy v testovacích případech
    • # 1) Složené kroky
    • # 2) Chování aplikace se považuje za očekávané chování
    • # 3) Více podmínek v jednom případě
• Jak zlepšit účinnost testovacích případů
  • Sbírka dokumentů pro psaní testů
  • Skutečný příklad
  • Dokument testovacího případu
  • Testování sběru dat
• Důležitost standardizace testovacích případů
  • Důvody pro opakované použití testovacích případů
  • Co je standardní test při testování webu?
  • Závěr
  • Doporučené čtení

Co je testovací případ a jak psát testovací případy?

Psát efektivní případy je dovednost. A můžete se to naučit ze zkušeností a znalostí testované aplikace.

Základní pokyny, jak psát testy, najdete v následujícím videu:

Výše uvedené zdroje by nám měly poskytnout základy procesu psaní testu.

Úrovně procesu psaní testu:

• Úroveň 1: Na této úrovni napíšete základní případy z dostupné specifikace a uživatelská dokumentace.
• Úroveň 2: To je praktická fáze ve kterých případech psaní závisí na skutečném funkčním a systémovém toku aplikace.
• Úroveň 3: Toto je fáze, ve které seskupíte některé případy a napsat zkušební postup . Zkušební postup není nic jiného než skupina malých případů, možná maximálně 10.
• Úroveň 4: Automatizace projektu. Tím se minimalizuje interakce člověka se systémem, a proto se QA může zaměřit na aktuálně aktualizované funkce k testování, spíše než zůstat zaneprázdněn regresním testováním.

Proč píšeme testy?

Základním cílem psaní případů je k ověření pokrytí testu aplikací.

Pokud pracujete v jakékoli organizaci CMMi, pak jsou testovací standardy důsledněji dodržovány. Psaní případů přináší určitý druh standardizace a minimalizuje ad hoc přístup při testování.

Jak psát testovací případy?

Pole:

• ID testovacího případu
• Jednotka k testování: Co je třeba ověřit?
• Předpoklady
• Testovací data: Proměnné a jejich hodnoty
• Kroky, které mají být provedeny
• Očekávaný výsledek
• Skutečný výsledek
• Úspěšné / neúspěšné
• Komentáře

Základní formát prohlášení o případu

Ověřit
Použitím (název nástroje, název značky, dialog atd.)
S (podmínky)
Na (co je vráceno, ukázáno, předvedeno)

Ověřit: Používá se jako první slovo testovacího prohlášení.
Použitím: Identifikovat, co se testuje. Zde můžete použít „zadání“ nebo „výběr“ místo použití v závislosti na situaci.

U jakékoli aplikace musíte pokrýt všechny typy testů jako:

• Funkční případy
• Negativní případy
• Případy mezní hodnoty

Při psaní všech těchto TC by měly být jednoduché a snadno pochopitelné .

***********************************

Tipy pro psaní testů

Jednou z nejčastějších a hlavních činností softwarového testeru (osoba SQA / SQC) je psaní testovacích scénářů a případů.

S touto hlavní činností souvisí několik důležitých a kritických faktorů. Nejprve se podívejme na tyto faktory z ptačí perspektivy.

Důležité faktory zapojené do procesu psaní:

a) TC jsou náchylní k pravidelné revizi a aktualizaci:

Žijeme v neustále se měnícím světě a totéž platí i pro software. Softwarové požadavky se přímo týkají případů. Kdykoli se změní požadavky, TC je třeba aktualizovat.

Revizi a aktualizaci TC však může způsobit nejen změna požadavku. Během provádění TC vychází v mysli mnoho nápadů a lze identifikovat mnoho dílčích podmínek jednoho TC. To vše způsobuje aktualizaci TC a někdy dokonce vede k přidání nových TC.

jak otevřít soubory dat v systému Windows

Během regresního testování navíc několik oprav a / nebo zvlnění vyžaduje revidované nebo nové TC.

b) TC jsou náchylní k distribuci mezi testery, kteří je provedou:

Samozřejmě, že jen stěží existuje situace, kdy jeden tester provede všechny TC. Normálně existuje několik testerů, kteří testují různé moduly jedné aplikace. TC jsou tedy rozděleni mezi testery podle jejich vlastněných oblastí testované aplikace.

Některé TC, které souvisejí s integrací aplikace, mohou být prováděny více testery, zatímco jiné TC mohou být prováděny pouze jedním testerem.

c) TC jsou náchylní ke shlukování a dávkování:

Je normální a běžné, že TC náležející k jednomu testovacímu scénáři obvykle vyžadují jejich provedení v určité konkrétní sekvenci nebo ve formě skupiny. Mohou existovat určité předpoklady TC, které vyžadují spuštění dalších TC před vlastním spuštěním.

Podobně podle obchodní logiky AUT může jeden TC přispívat k několika testovacím podmínkám a jedna testovací podmínka může sestávat z více TC.

d) TC mají tendenci vzájemné závislosti:

Toto je také zajímavé a důležité chování TC, které naznačuje, že mohou být na sobě navzájem závislí. Od středních po velké aplikace se složitou obchodní logikou je tato tendence viditelnější.

Nejjasnější oblastí každé aplikace, kde lze toto chování rozhodně pozorovat, je interoperabilita mezi různými moduly stejných nebo dokonce různých aplikací. Jednoduše řečeno, všude tam, kde jsou různé moduly jedna aplikace nebo více aplikací vzájemně závislé, stejné chování se odráží také v TC.

e) TC jsou náchylné k distribuci mezi vývojáři (zejména v testovacím vývojovém prostředí):

Důležitým faktem o TC je, že tyto mají být použity nejen testery. V normálním případě, když vývojáři opravují chybu, nepřímo používají TC k vyřešení problému. Podobně, pokud je sledován vývoj řízený testem, pak vývojáři přímo používají TC, aby vytvořili svou logiku a pokryli všechny scénáře v jejich kódu, které jsou adresovány TC.

Tipy pro psaní efektivních testů:

Mějte na paměti výše uvedených 5 faktorů. Zde je několik tipů, jak napsat efektivní TC.

Začněme!!!

# 1) Udržujte to jednoduché, ale ne příliš jednoduché; aby to bylo složité, ale ne příliš složité:

Toto tvrzení se jeví jako paradox. Ale slibuji, že to tak není. Udržujte všechny kroky TCs atomové a přesné. Uveďte kroky se správnou posloupností a správným mapováním k očekávaným výsledkům. Testovací případ by měl být samozřejmý a snadno pochopitelný. To je to, co tím chci zjednodušit.

Nyní je to složité znamená integrovat jej do plánu zkoušek a dalších TC. Kde a kdy je to nutné, nahlédněte do ostatních TC, příslušných artefaktů, GUI atd. Ale udělejte to vyváženým způsobem. Nedělejte testera, aby se pohyboval sem a tam v hromadě dokumentů pro dokončení jediného testovacího scénáře.

Na druhou stranu nedovolte, aby tester dokumentoval tyto TC velmi kompaktním způsobem. Při psaní TC vždy pamatujte, že vy nebo někdo jiný je budete muset revidovat a aktualizovat.

# 2) Po zdokumentování testovacích případů zkontrolujte jednou jako tester:

Nikdy si nemyslete, že práce je hotová, jakmile napíšete poslední TC testovacího scénáře. Přejít na začátek a zkontrolovat všechny TC jednou, ale ne s myšlenkou spisovatele TC nebo plánovače testování. Zkontrolujte všechny TC s myslí testera. Myslete racionálně a zkuste své TC spustit nasucho.

Vyhodnoťte všechny kroky a zjistěte, zda jste je jasně a srozumitelně zmínili a očekávané výsledky jsou v souladu s těmito kroky.

Zajistěte, aby testovací data specifikované v TC je proveditelné nejen pro skutečné testery, ale také podle prostředí v reálném čase. Zajistěte, aby mezi TC nedošlo ke konfliktu závislostí, a ověřte, zda jsou všechny odkazy na jiné TC / artefakty / GUI přesné. Jinak by se testeři mohli dostat do velkých potíží.

# 3) Vázejte a usnadňujte testery:

Nenechávejte testovací data na testerech. Dejte jim řadu vstupů, zejména tam, kde je třeba provádět výpočty nebo chování aplikace závisí na vstupech. Můžete je nechat rozhodnout o hodnotách datových položek testu, ale nikdy jim nedovolte, aby si sami vybrali datové položky testu.

Protože úmyslně nebo neúmyslně mohou znovu a znovu používat stejná testovací data a některá důležitá testovací data mohou být během provádění TC ignorována.

Udržujte testery v pohodě uspořádáním TC podle testovacích kategorií a souvisejících oblastí aplikace. Je zřejmé, že poučte a uveďte, které TC jsou vzájemně závislé a / nebo dávkované. Stejně tak výslovně uveďte, které TC jsou nezávislé a izolované, aby tester mohl odpovídajícím způsobem řídit svou celkovou aktivitu.

V tomto okamžiku by vás mohlo zajímat, abyste si přečetli analýzu hraničních hodnot, což je strategie návrhu testovacího případu, která se používá při testování černé skříňky. Klepněte na tady vědět o tom víc.

# 4) Buďte přispěvatelem:

Nikdy nepřijímejte dokument FS nebo návrhový dokument tak, jak je. Vaším úkolem není jen projít FS a identifikovat testovací scénáře. Být zdrojem QA, nikdy neváhejte přispět k podnikání a podat návrhy, pokud máte pocit, že v aplikaci lze něco vylepšit.

Navrhněte také vývojářům, zejména ve vývojovém prostředí založeném na TC. Navrhněte rozevírací seznamy, ovládací prvky kalendáře, seznam výběru, skupinové přepínače, smysluplnější zprávy, upozornění, výzvy, vylepšení týkající se použitelnosti atd.

Být QA, nejen testovat, ale změnit!

# 5) Nikdy nezapomeňte na koncového uživatele:

Nejdůležitějším zúčastněným subjektem je „koncový uživatel“, který aplikaci nakonec použije. Takže na něj nikdy nezapomeňte v žádné fázi psaní TC. Ve skutečnosti by koncový uživatel neměl být ignorován v žádné fázi celého SDLC. Přesto se můj důraz zatím týká pouze mého tématu.

Během identifikace testovacích scénářů tedy nikdy nepřehlédněte ty případy, které budou většinou používány uživatelem, nebo případy, které jsou obchodně kritické, i když jsou používány méně často. Udržujte se v kůži koncového uživatele a poté projděte všechny TC a posuďte praktickou hodnotu provedení všech vašich dokumentovaných TC.

***********************************

Jak dosáhnout dokonalosti v dokumentaci testovacích případů

Jako tester softwaru jistě se mnou budete souhlasit, že vymyslet perfektní testovací dokument je opravdu náročný úkol.

V naší oblasti vždy ponecháváme určitý prostor pro zlepšení Dokumentace testovacího případu . Někdy nejsme schopni poskytnout 100% pokrytí testů prostřednictvím TC a někdy testovací šablona není na stejné úrovni, nebo nám chybí zajištění dobré čitelnosti a jasnosti našich testů.

Jako tester, kdykoli budete požádáni o napsání dokumentace k testu, nezačínejte jen ad-hoc způsobem. Než začnete pracovat na procesu dokumentace, je velmi důležité porozumět účelu psaní testovacích případů.

Testy by měly být vždy jasné a přehledné. Měly by být napsány způsobem, který testerovi usnadní provedení kompletního testování podle kroků definovaných v každém z testů.

Dokument o testovacím případu by navíc měl obsahovat tolik případů, kolik je požadováno k poskytnutí úplnosti testovací pokrytí . Například , měli byste se pokusit pokrýt testování všech možných scénářů, které mohou nastat ve vaší softwarové aplikaci.

S ohledem na výše uvedené vám dovolím, abych vás provedl prohlídkou Jak dosáhnout excelence v testovací dokumentaci.

Užitečné tipy a triky

Zde vám poskytnu několik užitečných pokynů, které vám mohou pomoci ve vaší testovací dokumentaci od ostatních.

# 1) Je váš testovací dokument v dobrém stavu?

Nejlepší a jednoduchý způsob, jak uspořádat testovací dokument, je rozdělit jej do mnoha jednotlivých užitečných sekcí. Rozdělte celé testování na několik testovacích scénářů. Poté rozdělte každý scénář do více testů. Nakonec rozdělte každý případ do několika testovacích kroků.

Pokud používáte Excel, dokumentujte každý testovací případ na samostatném listu sešitu, kde každý testovací případ popisuje jeden kompletní testovací tok.

# 2) Nezapomeňte pokrýt negativní případy

Jako tester softwaru musíte myslet mimo krabici a vypracovat všechny možnosti, na které vaše aplikace naráží. My jako testeři musíme ověřit, že pokud by měl být zastaven a nahlášen jakýkoli neautentický pokus o vstup do softwaru nebo jakákoli neplatná data, která by procházela aplikací.

Negativní případ je tedy stejně důležitý jako pozitivní případ. Ujistěte se, že pro každý scénář, který máte dva testovací případy - jeden pozitivní a jeden negativní . Kladný by měl pokrývat zamýšlený nebo normální průtok a záporný by měl pokrývat nezamýšlený nebo výjimečný průtok.

# 3) Proveďte kroky atomového testu

Každý testovací krok by měl být atomový. Neměly by být žádné další dílčí kroky. Čím jednodušší a jasnější je testovací krok, tím snazší by bylo s testováním pokračovat.

# 4) Stanovte priority testů

Často máme přísné časové osy pro dokončení testování aplikace. V tomto případě nám může chybět testování některých důležitých funkcí a aspektů softwaru. Abyste tomu zabránili, měli byste při dokumentaci označit prioritu u každého testu.

K definování priority testu můžete použít jakékoli kódování. Obecně je lepší použít kteroukoli ze 3 úrovní, vysoká, střední a nízká nebo 1, 50 a 100. Pokud tedy máte přísnou časovou osu, měli byste nejprve dokončit všechny testy s vysokou prioritou a poté přejít na testy se střední a nízkou prioritou.

Například - pro nákupní web může být ověření odmítnutí přístupu pro neplatný pokus o přihlášení do aplikace případ s vysokou prioritou, ověření zobrazení příslušných produktů na obrazovce uživatele může být případ se střední prioritou a ověření barvy textu zobrazeného na tlačítka na obrazovce mohou mít nízkou prioritu.

# 5) Na pořadí záleží

Potvrďte, zda je pořadí kroků v testu naprosto správné. Chybná posloupnost kroků může vést ke zmatku. Kroky by měly přednostně také definovat celou sekvenci od vstupu do aplikace až po ukončení aplikace pro konkrétní scénář, který se testuje.

php rozhovor otázky a odpovědi na 5 let zkušeností

# 6) Přidejte do komentářů časové razítko a název testeru

Může nastat případ, že testujete aplikaci, někdo provádí úpravy paralelně se stejnou aplikací nebo někdo může aplikaci po dokončení testování aktualizovat. To vede k situaci, kdy se výsledky vašeho testu mohou časem měnit.

Vždy je tedy lepší přidat do komentářů k testování časové razítko se jménem testera, aby bylo možné výsledek testu (vyhovět nebo selhat) připsat stavu aplikace v daném čase. Alternativně můžete mít Datum provedení “Sloupec přidaný samostatně do testovacího případu, který výslovně identifikuje časové razítko testu.

# 7) Uveďte podrobnosti o prohlížeči

Jak víte, pokud se jedná o webovou aplikaci, výsledky testu se mohou lišit podle prohlížeče, ve kterém je test spuštěn. Pro usnadnění dalších testerů, vývojářů nebo kohokoli, kdo kontroluje dokument o testu, byste měli přidat název a verzi prohlížeče do případu, aby bylo možné vadu snadno replikovat.

# 8) V dokumentu si ponechejte dva samostatné listy - „Chyby“ a „Souhrn“

Pokud dokumentujete v aplikaci Excel, první dva listy sešitu by měly být Shrnutí a Chyby. Souhrnný list by měl shrnout scénář testu a list Chyby by měl obsahovat seznam všech problémů, které se vyskytly během testování. Význam přidání těchto dvou listů spočívá v tom, že čtenáři / uživateli dokumentu poskytne jasné pochopení testování.

Když je tedy čas omezen, tyto dva listy se mohou ukázat jako velmi užitečné při poskytování přehledu o testování.

Zkušební dokument by měl poskytovat co nejlepší pokrytí testem, vynikající čitelnost a měl by se řídit jedním standardním formátem.

Můžeme dosáhnout excelence v testovací dokumentaci pouhým zapamatováním několika základních tipů, jako je organizace dokumentu testovacích případů, upřednostnění TC, vše ve správném pořadí, včetně všech povinných podrobností k provedení TC, a poskytnutí jasných a jasných testovacích kroků, atd., jak je uvedeno výše.

***********************************

Jak NE psát testy

Většinu času věnujeme jejich psaní, kontrole, provádění nebo údržbě. Je docela škoda, že testy jsou také nejvíce náchylné k chybám. Rozdíly v porozumění, postupy testování organizace, nedostatek času atd., To jsou některé z důvodů, proč často vidíme testy, které nechávají mnoho na přání.

Na našem webu je o tomto tématu spousta článků, ale uvidíme zde Jak NE psát testovací případy - několik tipů, které vám pomohou při vytváření charakteristických, kvalitních a efektivních testů.

Čtěte dále a tyto tipy jsou určeny jak pro nové, tak pro zkušené testery.

3 Nejběžnější problémy v testovacích případech

1. Složené kroky
2. Chování aplikace se považuje za očekávané chování
3. Více podmínek v jednom případě

Tito tři musí být na mém vrcholu 3 seznamu běžných problémů v procesu psaní testu.

Zajímavé je, že k tomu dochází u nových i zkušených testerů a my stále sledujeme stejné chybné procesy, aniž bychom si uvědomili, že několik jednoduchých opatření může věci snadno napravit.

Pojďme na to a podrobně si o každé promluvte:

# 1) Složené kroky

Za prvé, co je složený krok?

Například dáváte pokyny z bodu A do bodu B: pokud řeknete, že „Jděte na místo XYZ a pak do ABC“, nebude to mít smysl, protože zde si myslíme - „Jak dostat se na XYZ na prvním místě “- místo toho počínaje„ Odtud odbočte doleva a jděte 1 míli, pak zahněte doprava na Rd. č. 11 na XYZ “může dosáhnout lepších výsledků.

Stejná pravidla platí i pro testy a jejich kroky.

Například Píšu test pro Amazon.com - objednejte si jakýkoli produkt.

Níže jsou uvedeny moje testovací kroky (Poznámka: Píši pouze kroky a ne všechny ostatní části testu, jako je očekávaný výsledek atd.)

na . Spusťte Amazon.com
b . Vyhledejte produkt zadáním klíčového slova / názvu produktu do pole „Hledat“ v horní části obrazovky.
C . Ze zobrazených výsledků hledání vyberte první.
d . Klikněte na Přidat do košíku na stránce s podrobnostmi o produktu.
je . Pokladna a platba.
F . Zkontrolujte stránku s potvrzením objednávky.

Nyní, můžete určit, který z nich je složený krok? Pravý krok (e)

Pamatujte, že testy jsou vždy o tom, „Jak“ testovat, takže je důležité do testu napsat přesné kroky „Jak se odhlásit a zaplatit“.

Výše uvedený případ je proto efektivnější, když je napsán níže:

na . Spusťte Amazon.com
b . Vyhledejte produkt zadáním klíčového slova / názvu produktu do pole „Hledat“ v horní části obrazovky.
C . Ze zobrazených výsledků hledání vyberte první.
d . Klikněte na Přidat do košíku na stránce s podrobnostmi o produktu.
je . Na stránce nákupního košíku klikněte na Pokladna.
F . Zadejte informace o CC, přepravní a fakturační údaje.
G . Klikněte na Pokladna.
h . Zkontrolujte stránku s potvrzením objednávky.

Složený krok je tedy krok, který lze rozdělit do několika jednotlivých kroků. Až příště píšeme testy, věnujme této části pozornost všichni a jsem si jistý, že se mnou budete souhlasit, že to děláme častěji, než si uvědomujeme.

# 2) Chování aplikace se považuje za očekávané chování

Tuto situaci dnes musí řešit stále více projektů.

Nedostatek dokumentace, extrémní programování, rychlé vývojové cykly jsou několika důvody, které nás nutí spoléhat se na to, že aplikace (starší verze nebo tak) buď bude psát testy, nebo na nich bude založeno samotné testování. Jako vždy se jedná o osvědčený špatný postup - ne vždy.

Je to neškodné, pokud si zachováte otevřenou mysl a očekáváte, že - „AUT může být vadný“. Teprve když si myslíte, že to tak není, věci fungují špatně. Jako vždy necháme mluvit příklady.

Pokud na této stránce píšete / navrhujete testovací kroky, postupujte takto:

Případ 1:

Pokud jsou kroky mého testovacího případu uvedeny níže:

1. Spusťte nákupní web.
2. Klikněte na Odeslání a vrácení - Očekávaný výsledek: Stránka odeslání a vrácení se zobrazí s tlačítkem „Sem vložte informace“ a tlačítkem „Pokračovat“.

Pak je to nesprávné.

Případ 2:

1. Spusťte nákupní web.
2. Klikněte na Odeslání a vrácení.
3. Do textového pole „Zadejte číslo objednávky“ na této obrazovce zadejte číslo objednávky.
4. Klikněte na Pokračovat - Očekávaný výsledek: Zobrazí se podrobnosti objednávky související s dopravou a vrácením.

Případ 2 je lepší testovací případ, protože i když se referenční aplikace chová nesprávně, bereme ji pouze jako vodítko, provedeme další průzkum a zapíšeme očekávané chování podle očekávané správné funkce.

Sečteno a podtrženo: Aplikace jako reference je rychlá zkratka, ale přichází s vlastními nebezpečími. Pokud jsme opatrní a kritičtí, přináší úžasné výsledky.

# 3) Více podmínek v jednom případě

Opět se učme Příklad .

Podívejte se na níže uvedené kroky testu: Níže jsou uvedeny kroky testu v rámci jednoho testu funkce přihlášení.

A. Zadejte platné podrobnosti a klikněte na Odeslat.
b. Pole pro uživatelské jméno nechte prázdné. Klikněte na Odeslat.
C. Pole pro heslo nechte prázdné a klikněte na Odeslat.
d. Vyberte již přihlášené uživatelské jméno / heslo a klikněte na Odeslat.

To, co musely být 4 různé případy, je spojeno do jednoho. Možná si myslíte - Co je na tom špatného? Šetří to spoustu dokumentace a co můžu dělat ve 4, dělám to v 1, není to skvělé? No, ne tak docela. Důvody?

Číst dál:

• Co když některá z podmínek selže - musíme celý test označit jako „nevyhověl“. Pokud označíme celý případ jako „selhal“, znamená to, že nefungují všechny 4 podmínky, což není pravda.
• Testy musí mít průtok. Od předběžného stavu po krok 1 a všechny kroky. Pokud budu postupovat podle tohoto případu, v kroku (a), pokud bude úspěšný, budu přihlášen na stránku, kde již není k dispozici možnost „přihlášení“. Takže když se dostanu ke kroku (b) - kde tester zadá uživatelské jméno? Vidíte, tok je přerušený.

Proto, psát modulární testy . Zní to jako spousta práce, ale vše, co potřebujete, je oddělit věci a použít naše nejlepší přátele Ctrl + C a Ctrl + V, aby pro nás pracovali. :)

***********************************

Jak zlepšit účinnost testovacích případů

Testeři softwaru by měli psát své testy z dřívější fáze životního cyklu vývoje softwaru, nejlépe během fáze požadavků na software.

Manažer testu nebo manažer QA by měl shromáždit a připravit maximální možné dokumenty podle níže uvedeného seznamu.

nejlepší zdarma DVD Ripper Windows 10

Sbírka dokumentů pro psaní testů

# 1) Dokument o požadavcích uživatele

Jedná se o dokument, který uvádí obchodní proces, uživatelské profily, uživatelské prostředí, interakci s jinými systémy, výměnu stávajících systémů, funkční požadavky, nefunkční požadavky, licenční a instalační požadavky, výkonnostní požadavky, bezpečnostní požadavky, použitelnost a souběžné požadavky atd. .,

# 2) Dokument případu obchodního použití

Tento dokument podrobně popisuje případ použití scénář funkčních požadavků z obchodního hlediska. Tento dokument zahrnuje obchodní subjekty (nebo systém), cíle, předběžné podmínky, následné podmínky, základní tok, alternativní tok, možnosti, výjimky každého obchodního toku systému podle požadavků.

# 3) Dokument o funkčních požadavcích

Tento dokument podrobně popisuje funkční požadavky jednotlivých funkcí systému podle požadavků.

Normálně dokument funkčních požadavků slouží jako společné úložiště pro vývojový a testovací tým i pro zúčastněné strany projektu včetně zákazníků pro závazky (někdy zmrazené) požadavky, které by měly být považovány za nejdůležitější dokument pro jakýkoli vývoj softwaru.

# 4) Plán softwarového projektu (volitelný)

Dokument, který popisuje podrobnosti projektu, cíle, priority, milníky, činnosti, organizační strukturu, strategii, monitorování pokroku, analýzu rizik, předpoklady, závislosti, omezení, požadavky na školení, odpovědnost klienta, harmonogram projektu atd.,

# 5) QA / testovací plán

Tento dokument podrobně popisuje systém řízení kvality, standardy dokumentace, mechanismus kontroly změn, kritické moduly a funkce, systém správy konfigurace, plány testování, sledování chyb, kritéria přijetí atd.

The testovací plán dokument slouží k identifikaci funkcí, které se mají testovat, funkcí, které se nemají testovat, přidělení testovacího týmu a jejich rozhraní, požadavky na zdroje, plán testování, psaní testů, pokrytí testů, výstupy testu, předpoklad pro provedení testu, hlášení chyb a sledování mechanismus, testovací metriky atd.,

Skutečný příklad

Podívejme se, jak efektivně psát testovací případy pro známou a jednoduchou obrazovku „Přihlášení“ podle obrázku níže. The přístup testování bude téměř stejný i pro složité obrazovky s více informacemi a kritickými funkcemi.

# 1) Prvním přístupem pro jakýkoli proces testovacího případu bude získání prototypu obrazovky (nebo drátových rámů), jak je uvedeno výše, pokud je k dispozici. To nemusí být u některých funkcí k dispozici a záleží to na kritičnosti návrhu prototypu v dřívějších fázích vývoje.

Ale pokud SRS Dokument (Specifikace softwarových požadavků) je k dispozici pro projekt, většina prototypů obrazovek byla vyvinuta projektovým týmem. Tento druh obrazovky zjednodušuje práci testeru a zvyšuje efektivitu testů.

#dva) Dále specifikace funkčních požadavků . Záleží na organizačním procesu, bude k dispozici v sadě více dokumentů.

Rozhodněte se tedy pro nejlepší dokument pro psaní případů, ať už se jedná o dokument s požadavkem uživatele nebo specifikace funkčních požadavků (nebo dokonce dokument SRS, pokud je testovacímu týmu pohodlně srozumitelný), který poskytne kompletní funkční tok vybraného funkce, která má být testována.

# 3) Jakmile je prototyp obrazovky a funkční specifikace k dispozici, měl by tester začít psát případy s následujícím přístupem a kritérii.

• Testy uživatelského rozhraní :Ovládací prvky / pole, která jsou viditelná pro uživatele. Pro testovanou funkci jsou k dispozici statické a dynamické ovládací prvky. Například, na přihlašovací obrazovce výše jsou texty „Uživatelské jméno a heslo“ statická pole, která nevyžadují žádnou interakci uživatele, pouze pro zobrazení pouze textu.

• Funkční případy :Na druhou stranu, tlačítko Přihlásit se a Hypertextové odkazy (Zapomněli jste heslo? & Registrace) jsou dynamická pole, která vyžadují interakci uživatele kliknutím na ovládací prvky, které provedou nějakou akci později.

• Databázové případy :Jakmile uživatel zadá uživatelské jméno a heslo, mohou být napsány testy ke kontrole související databáze, zda je uživatelské jméno a heslo zkontrolováno ve správné databázi a tabulce a také má uživatel oprávnění k přihlášení k testované aplikaci.
  

• Procesní testy :To souvisí s procesem (nikoli s akcemi spojenými s viditelnými ovládacími prvky dostupnými na obrazovce) asociovanými s funkcí a funkcí. Například, kliknutím na odkaz Zapomenout heslo na výše uvedené ukázkové obrazovce můžete uživateli odeslat e-mail. Možná tedy musí být e-mail otestován na správný proces a potvrzení.

4) Nakonec ponechte „ BAOE mantra ”, Znamená i) Základní tok ii) Alternativní tok iii) Možnosti a iv) Výjimky pro úplné pokrytí funkčního toku a funkce, která má být testována. Každý koncept by měl být aplikován na pozitivní a negativní testy.

Například, uvidíme jednoduchý přístup BAOE pro ukázkovou přihlašovací obrazovku výše.

• Základní tok: Zadejte cestu URL přihlášení v libovolném prohlížeči a zadejte požadované informace a přihlaste se do aplikace.
• Alternativní tok: Nainstalujte aplikaci do mobilního zařízení, zadejte požadované informace a přihlaste se k aplikaci.
• Možnosti: Jaké jsou možnosti dostupné na stejnou přihlašovací obrazovku? Například, po přihlášení do aplikace se kliknutím na „Odhlásit“ může zobrazit stejná obrazovka nebo pokud vypršel časový limit relace nebo relace vypršela, může uživatel přejít na přihlašovací obrazovku.
• Výjimky: Jaké jsou výjimky, pokud jsou mé testy negativní? Například, pokud jsou na přihlašovací obrazovce zadána nesprávná pověření, zda se uživateli zobrazí chybová zpráva nebo nebude přidružena žádná akce.

Se všemi těmito informacemi v ruce začněme psát TC pro přihlašovací obrazovku ve formátu s úplným pokrytím a sledovatelností as podrobnými informacemi. Logická posloupnost a číslování identifikace ‚ ID testovacího případu “ bude velmi užitečné pro rychlou historii provádění identifikace testovacích případů.

Přečtěte si také=> 180+ ukázkových testovacích případů připravených k použití pro webové a desktopové aplikace.

Dokument testovacího případu

Poznámka : Testovací sloupce se neomezují na níže uvedený testovací dokument, který lze udržovat v listu aplikace Excel, aby měl tolik sloupců, kolik je požadováno pro úplnou matici sledovatelnosti, viz. Priorita, účel testování, typ testování, umístění chybového snímku obrazovky atd.,

Přečtěte si také=> Ukázková šablona testovacího případu s příklady.

Pro snazší jednoduchost a čitelnost tohoto dokumentu si níže podrobně napíšeme kroky pro reprodukci, očekávané a skutečné chování testů pro přihlašovací obrazovku.

Poznámka : Přidejte sloupec Skutečné chování na konec této šablony.

Testování sběru dat

Při psaní testovacího případu je nejdůležitějším úkolem každého testera shromáždit testovací data. Tuto aktivitu mnoho testerů přeskakuje a přehlíží s předpokladem, že testovací případy lze provést s některými ukázkovými daty nebo fiktivními daty a lze je přenést, když jsou data skutečně požadována. Toto je kritická mylná představa, že v době provádění testovacích případů se krmí vzorová data nebo vstupní data z paměti mysli.

Pokud data nejsou shromažďována a aktualizována v testovacím dokumentu v době psaní testů, tester by strávil neobvykle více času shromažďováním dat v době provádění testu. Údaje o zkoušce by se měly shromažďovat pro pozitivní i negativní případy z celé perspektivy funkčního toku funkce. V této situaci je velmi užitečný dokument případu obchodního použití.

Najděte ukázkový dokument s údaji o zkoušce pro testy napsané výše, což zase pomůže v tom, jak efektivně můžeme shromažďovat data, což nám usnadní práci v době provedení testu.

***********************************

Důležitost standardizace testovacích případů

V tomto rušném světě nikdo nemůže dělat opakující se věci každý den se stejnou úrovní zájmu a energie. Hlavně nemám vášeň pro opakování stejného úkolu v práci. Rád spravuji věci a šetřím čas. Každý v IT by tomu tak měl být.

Všechny IT společnosti provádějí různé typy projektů. Tyto projekty mohou být buď produktové, nebo servisní. Z těchto projektů většina z nich pracuje kolem webů a testování webových stránek . Dobrá zpráva o tom je, že všechny webové stránky mají mnoho podobností. A pokud jsou webové stránky pro stejnou doménu, mají také několik společných funkcí.

Otázka, která mě vždy trápí, je, že: „Pokud je většina aplikací podobná, například: například maloobchodní weby, které byly již tisíckrát testovány,„ Proč musíme psát testovací případy pro další maloobchodní web od nuly? “ Nešetří tunu času vytažením stávajících testovacích skriptů, které byly použity k testování předchozího maloobchodního webu?

Jistě, možná budeme muset udělat nějaké drobné vylepšení, ale celkově je to jednodušší, efektivnější, také časově a finančně úspornější, a tím vždy pomůže udržet vysokou úroveň zájmu testerů. Kdo rád píše, kontroluje a udržuje stejné testovací případy opakovaně, že? Opětovné použití existujících testů to může do značné míry vyřešit a vaši klienti to také najdou chytře a logicky.

Logicky jsem tedy začal stahovat existující skripty z podobných webových projektů, provedl jsem změny a rychle je zkontroloval. Také jsem použil barevné kódování k zobrazení provedených změn, aby se recenzent mohl soustředit pouze na část, která byla změněna.

Důvody pro opakované použití testovacích případů

# 1) Většina funkčních oblastí webu je téměř - přihlášení, registrace, přidání do košíku, seznam přání, pokladna, možnosti dopravy, možnosti platby, obsah stránky produktu, naposledy zobrazené, relevantní produkty, možnosti promo kódu atd.

#dva) Většina projektů je pouze vylepšení nebo změny stávající funkce.

# 3) Systémy pro správu obsahu, které definují sloty pro nahrávání obrázků statickými a dynamickými způsoby, jsou také společné pro všechny weby.

# 4) Maloobchodní weby mají CSR Systém (Zákaznický servis) také.

# 5) Backendový systém a skladová aplikace využívající JDA používají také všechny weby.

# 6) Koncept cookies, časový limit a bezpečnost jsou také běžné.

# 7) Webové projekty jsou často náchylné ke změnám požadavků.

# 8) The typy testování potřebné jsou běžné jako prohlížeč testování kompatibility , testování výkonu , testování bezpečnosti

Víte, je spousta běžných a podobných věcí.

Jak již bylo řečeno, opakovaná použitelnost je správná cesta, někdy samotné úpravy mohou nebo nemusí zabrat více či méně času. Někdy může mít člověk pocit, že je lepší začít od nuly, než tolik upravovat.

To lze snadno zvládnout vytvořením sady standardních testovacích případů pro každou z běžných funkcí.

Co je standardní test při testování webu?

• Vytvořte úplné testovací případy - kroky, data, proměnnou atd. Tím zajistíte, že nepodobná data / proměnné lze jednoduše nahradit, když je vyžadován podobný testovací případ.
• Kritéria pro vstup a výstup by měla být správně definována.
• Upravitelné kroky nebo příkaz v krocích by měly být zvýrazněny jinou barvou pro rychlé vyhledání a nahrazení.
• Jazyk použitý pro vytvoření standardního testovacího případu by měl být obecný.
• V testovacích případech by měly být zahrnuty všechny funkce každého webu.
• Název testovacích případů by měl být názvem funkce nebo funkce, kterou testovací případ pokrývá. Díky tomu bude hledání testovacího případu ze sady mnohem snazší.
• Pokud existuje nějaký základní nebo standardní ukázkový soubor nebo soubor GUI nebo snímek obrazovky funkce, měl by být připojen s příslušnými kroky.

Pomocí výše uvedených tipů lze vytvořit sadu standardních skriptů a použít je s malými nebo požadovanými úpravami pro různé webové stránky.

I tyto standardní testovací případy lze automatizovat, ale opětovné zaměření na opětovné použití je vždy výhodou. Také pokud automatizace je založeno na grafickém uživatelském rozhraní, opětovné použití skriptů na více adresách URL nebo webech je něco, co mě osobně nikdy nepovažovalo za účinné.

Nejlepší možností provedení testování webu je použití standardní sady manuálních testovacích případů pro různé webové stránky s malými úpravami. Vše, co potřebujeme, je vytvořit a udržovat testovací případy se správnými standardy a použitím.

Závěr

Zlepšení účinnosti testovacích případů není jednoduše definovaný pojem, ale je to cvičení a lze ho dosáhnout vyzrálým procesem a pravidelným cvičením.

Testovací tým by neměl být unavený z účasti na zlepšování takových úkolů, protože je to nejlepší nástroj pro větší úspěchy ve světě kvality, což se osvědčuje v mnoha testovacích organizacích po celém světě na projektech kritických pro misi a komplexních aplikacích.

Doufám, že byste získali obrovské znalosti o konceptu testovacích případů. Podívejte se na naši sérii tutoriálů, abyste věděli více o testovacích případech a neváhejte vyjádřit své myšlenky v sekci komentáře níže!

Další výuka

Doporučené čtení

• Funkční testování vs. nefunkční testování
• Příručka pro testování přenositelnosti s praktickými příklady
• Typy testování softwaru: Různé typy testování s podrobnostmi
• Nejlepší nástroje pro testování softwaru 2021 (QA Test Automation Tools)
• Alfa testování a beta testování (kompletní průvodce)
• Co je Testování systému - Průvodce pro začátečníky
• ISTQB Testování Certifikace Ukázkové dotazníky s odpověďmi
• Jak psát týdenní zprávu o stavu testování softwaru