Ako písať testovacie prípady: Najdôležitejší sprievodca s príkladmi

how write test cases

V tomto podrobnom praktickom výučbe Ako písať testovacie prípady som sa zaoberal podrobnosťami o testovacom prípade, jeho štandardnej definícii a technikách návrhu testovacích prípadov.

Čo je testovací prípad?

Testovací prípad obsahuje komponenty, ktoré popisujú vstup, činnosť a očakávanú reakciu, aby bolo možné zistiť, či funkcia aplikácie funguje správne.

Testovací prípad je súbor pokynov na tému „AKO“ na validáciu konkrétneho cieľu / cieľov testu, ktoré nám pri dodržaní povedia, či je očakávané správanie systému splnené alebo nie.

Zoznam výukových programov zahrnutých v tejto sérii písania testovacích prípadov:

Ako napísať:

Výukový program č. 1: Čo je testovací prípad a ako písať testovacie prípady (tento návod)
Výukový program č. 2: Ukážka šablóny testovacieho prípadu s príkladmi (Stiahnuť) (musíš si prečítať)
Výukový program č. 3: Písanie testovacích prípadov z dokumentu SRS
Výukový program č. 4: Ako písať testovacie prípady pre daný scenár
Výukový program č. 5: Ako sa pripraviť na písanie testovacích prípadov
Výukový program č. 6: Ako písať negatívne testovacie prípady

Príklady:

Výukový program č. 7: 180+ vzorových testovacích prípadov pre webové a desktopové aplikácie
Výukový program č. 8: 100+ testovacích scenárov pripravených na vykonanie (kontrolný zoznam)

Techniky písania:

Výukový program č. 9: Graf príčin a následkov - technika písania dynamického testovacieho prípadu
Výukový program č. 10: Technika testovania prechodného stavu
Výukový program č. 11: Technika testovania ortogonálneho poľa
Výukový program č. 12: Technika odhadovania chýb
Výukový program č. 13: Technika návrhu testu pri overovaní tabuľky v teréne (FVT)

Scenáre testovacieho prípadu vs

Výukový program č. 14: Testovacie prípady vs. Testovacie scenáre
Výukový program č. 15: Rozdiel medzi testovacím plánom, stratégiou testu a testovacím prípadom

Automatizácia:

Výukový program č. 16: Ako vyberať správne testovacie prípady pre testovanie automatizácie
Výukový program č. 17: Ako previesť manuálne testovacie prípady do automatizačných skriptov

Nástroje na správu testov:

Výukový program č. 18: Najlepšie nástroje na správu testov
Výukový program č. 19: TestLink pre správu testovacích prípadov
Výukový program č. 20: Vytváranie a správa testovacích prípadov pomocou HP Quality Center
Výukový program č. 21: Vykonávanie testovacích prípadov pomocou ALM / QC

Prípady špecifické pre doménu:

Výukový program č. 22: Testovacie prípady pre aplikáciu ERP
Výukový program č. 23: Testovacie prípady aplikácie JAVA
Výukový program č. 24: Analýza hraničných hodnôt a rozdelenie ekvivalencie

Pokračujme prvým tutoriálom v tejto sérii.

Odporúčané nástroje:

Pred pokračovaním v procese písania testovacích prípadov vám odporúčame stiahnuť si tento nástroj na správu testovacích prípadov. Uľahčíte tým proces písania testovacích prípadov spomenutý v tejto príručke:

# 1) TestRail

=> Stiahnite si nástroj na správu testovacích prípadov TestRail

# 2) TestMonitor

Najvyššia úroveň online správy testov. Revolučný ľahký.

TestMonitor je komplexný nástroj na správu testov pre každú organizáciu. Jednoduchý, intuitívny prístup k testovaniu. Či už implementujete podnikový softvér, potrebujete kontrolu kvality, budujete kvalitnú aplikáciu alebo potrebujete len pomocnú ruku vo svojom testovacom projekte, TestMonitor vás pokryje.

=> Navštívte web TestMonitor

Čo sa dozviete:

• Čo je testovací prípad a ako písať testovacie prípady?
  • Prečo píšeme testy?
  • Ako písať testovacie prípady?
  • Základný formát vyhlásenia o testovacom prípade
• Tipy na písanie testov
  • • # 1) Snažte sa, aby to bolo jednoduché, ale nie príliš jednoduché; urobte to zložitým, ale nie príliš zložitým:
    • # 2) Po zdokumentovaní testovacích prípadov skontrolujte raz ako tester:
    • # 3) Pripútajte a uľahčite testerov:
    • # 4) Staňte sa prispievateľom:
    • # 5) Nikdy nezabudnite na koncového používateľa:
• Ako dosiahnuť dokonalosť v dokumentácii k testovacím prípadom
  • Užitočné tipy a triky
    • # 1) Je váš testovací dokument v dobrom tvare?
    • # 2) Nezabudnite pokryť negatívne prípady
    • # 3) Vykonajte kroky atómového testu
    • # 4) Stanovte priority testov
    • # 5) Na veciach sekvencií
    • # 6) Pridajte do poznámok časovú pečiatku a názov testera
    • # 7) Zahrňte podrobnosti prehliadača
    • # 8) V dokumente si nechajte dva samostatné listy - „Chyby“ a „Zhrnutie“
• Ako NEPÍSAŤ testy
  • 3 Najčastejšie problémy v testovacích prípadoch
    • # 1) Zložené kroky
    • # 2) Správanie aplikácie sa považuje za očakávané správanie
    • # 3) Viac podmienok v jednom prípade
• Ako zvýšiť efektívnosť testovacích prípadov
  • Zbierka dokumentov na písanie testu
  • Skutočný príklad
  • Dokument o testovacom prípade
  • Testovanie zhromažďovania údajov
• Dôležitosť štandardizácie testovacích prípadov
  • Dôvody na opakované použitie testovacích prípadov
  • Čo je štandardný test pri webovom testovaní?
  • Záver
  • Odporúčané čítanie

Čo je testovací prípad a ako písať testovacie prípady?

Písanie efektívnych prípadov je zručnosť. A môžete sa to naučiť zo skúseností a znalostí testovanej aplikácie.

Základné pokyny na písanie testov nájdete v nasledujúcom videu:

Vyššie uvedené zdroje by nám mali poskytnúť základy procesu písania testu.

Úrovne procesu písania testu:

• Úroveň 1: Na tejto úrovni napíšete základné prípady z dostupnej špecifikácie a užívateľská dokumentácia.
• Úroveň 2: To je praktická etapa v ktorých prípady písania závisia od skutočného funkčného a systémového toku aplikácie.
• Úroveň 3: Toto je fáza, v ktorej zoskupíte niektoré prípady a napíš skúšobný postup . Postup testu nie je nič iné ako skupina malých prípadov, možno maximálne 10.
• Úroveň 4: Automatizácia projektu. Tým sa minimalizuje ľudská interakcia so systémom, a preto sa QA môže zamerať na aktuálne aktualizované funkcionality na testovanie, a nie zostať zaneprázdnená regresným testovaním.

Prečo píšeme testy?

Základným cieľom písania prípadov je na overenie pokrytia testu aplikáciou.

Ak pracujete v akejkoľvek organizácii CMMi, potom sú testovacie štandardy dôslednejšie dodržiavané. Písanie prípadov prináša určitú štandardizáciu a minimalizuje ad hoc prístup pri testovaní.

Ako písať testovacie prípady?

Polia:

• ID testovacieho prípadu
• Jednotka na testovanie: Čo treba overiť?
• Domnienky
• Údaje o teste: Premenné a ich hodnoty
• Kroky, ktoré sa majú vykonať
• ocakavane vysledky
• Skutočný výsledok
• Vyhovel / nevyhovel
• Pripomienky

Základný formát vyhlásenia o testovacom prípade

Overiť
Použitím (názov nástroja, názov značky, dialógové okno atď.)
S (podmienky)
To (čo je vrátené, zobrazené, preukázané)

Overiť: Používa sa ako prvé slovo testovacieho vyhlásenia.
Použitím: Identifikovať, čo sa testuje. Tu môžete namiesto použitia použiť „zadanie“ alebo „výber“ v závislosti od situácie.

Pre každú aplikáciu musíte pokryť všetky typy testov ako:

• Funkčné prípady
• Negatívne prípady
• Prípady hraničnej hodnoty

Pri písaní všetkých týchto TC by mali byť jednoduché a ľahko pochopiteľné .

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

Tipy na písanie testov

Jednou z najčastejších a najdôležitejších činností softvérového testera (osoba SQA / SQC) je písanie testovacích scenárov a prípadov.

S touto hlavnou činnosťou súvisia niektoré dôležité a kritické faktory. Najprv sa pozrime na tieto faktory z vtáčej perspektívy.

Dôležitý faktor zapojený do procesu písania:

a) TC sú náchylní na pravidelné revízie a aktualizácie:

Žijeme v neustále sa meniacom svete a to isté platí aj pre softvér. Softvérové ​​požiadavky sa na prípady priamo vzťahujú. Vždy, keď sa zmenia požiadavky, je potrebné TC aktualizovať.

Nie je to však len zmena požiadavky, ktorá môže spôsobiť revíziu a aktualizáciu TC. Počas vykonávania TC prichádza do úvahy veľa nápadov a je možné identifikovať mnoho čiastkových podmienok jedného TC. To všetko spôsobuje aktualizáciu TC a niekedy dokonca vedie k pridaniu nových TC.

Okrem toho počas regresného testovania vyžaduje niekoľko opráv alebo zvlnení revidované alebo nové TC.

b) TC sú náchylní na distribúciu medzi testermi, ktorí ich vykonajú:

Samozrejme, ťažko existuje situácia, že jediný tester vykoná všetky TC. Normálne existuje niekoľko testerov, ktorí testujú rôzne moduly jednej aplikácie. TC sú teda rozdelené medzi testerov podľa oblastí ich vlastnenia testovanej aplikácie.

Niektoré TC, ktoré súvisia s integráciou aplikácie, môže vykonať viac testerov, zatiaľ čo iné TC môže vykonať iba jeden tester.

c) TC sú náchylní na zhlukovanie a dávkovanie:

Je bežné a bežné, že TC patriaci k jednému testovaciemu scenáru zvyčajne požadujú ich vykonanie v nejakej konkrétnej sekvencii alebo vo forme skupiny. Môžu existovať určité predpoklady TC, ktoré požadujú vykonanie ďalších TC pred samotným spustením.

Podobne podľa obchodnej logiky AUT môže jeden TC prispieť k niekoľkým testovacím podmienkam a jeden testovací stav môže pozostávať z viacerých TC.

d) TC majú tendenciu vzájomnej závislosti:

Toto je tiež zaujímavé a dôležité správanie TC, ktoré naznačuje, že môžu byť navzájom závislí. Od stredných po veľké aplikácie so zložitou obchodnou logikou je táto tendencia viditeľnejšia.

Najjasnejšou oblasťou každej aplikácie, kde je možné toto správanie určite pozorovať, je interoperabilita medzi rôznymi modulmi rovnakých alebo dokonca rôznych aplikácií. Jednoducho povedané, všade tam, kde sú rôzne moduly, ktoré majú jednu alebo viac aplikácií, navzájom závislé, rovnaké správanie sa odráža aj v TC.

e) TC sú náchylné na distribúciu medzi vývojármi (najmä v testovacom vývojovom prostredí):

Dôležitým faktom o TC je, že ich majú využívať nielen testéri. V normálnom prípade, keď vývojári opravujú chybu, nepriamo používajú TC na odstránenie problému. Podobne, ak sa sleduje vývoj založený na testoch, vývojári priamo používajú TC, aby vytvorili svoju logiku a pokryli všetky scenáre v ich kóde, ktoré TC riešia.

Tipy na písanie efektívnych testov:

Nezabudnite na týchto 5 faktorov. Tu je niekoľko rád, ako napísať efektívne TC.

Začnime!!!

# 1) Snažte sa, aby to bolo jednoduché, ale nie príliš jednoduché; urobte to zložitým, ale nie príliš zložitým:

Toto tvrdenie sa javí ako paradox. Sľubujem však, že to tak nie je. Všetky kroky TC musia byť atómové a presné. Uveďte kroky so správnou postupnosťou a správnym mapovaním k očakávaným výsledkom. Testovací prípad by mal byť samozrejmý a ľahko pochopiteľný. To je to, čo chcem povedať, aby som to zjednodušil.

Teraz to urobiť komplexným znamená urobiť to integrovaným s Testovacím plánom a inými TC. Ak je to potrebné, pozrite si ďalšie TC, príslušné artefakty, GUI atď. Robte to však vyváženým spôsobom. Nerobte testera tak, aby sa pohyboval sem a tam v hromade dokumentov na dokončenie jedného testovacieho scenára.

Na druhú stranu, nenechajte ani testera dokumentovať tieto TC veľmi kompaktným spôsobom. Pri písaní TC vždy pamätajte na to, že vy alebo niekto iný ich bude musieť revidovať a aktualizovať.

# 2) Po zdokumentovaní testovacích prípadov skontrolujte raz ako tester:

Nikdy si nemyslite, že práca je splnená, až keď napíšete posledný TC testovacieho scenára. Choďte na začiatok a skontrolujte všetky TC raz, ale nie s myslením autora TC alebo plánovača testovania. Skontrolujte všetky TC s mysľou testera. Myslite racionálne a pokúste sa TC spustiť nasucho.

Posúďte všetky kroky a zistite, či ste ich jasne a zreteľne spomenuli a očakávané výsledky sú v súlade s týmito krokmi.

Zaistite, aby údaje z testu uvedené v TC je uskutočniteľné nielen pre skutočných testerov, ale je tiež v súlade s prostredím reálneho času. Zaistite, aby medzi TC neexistoval konflikt závislostí a overte, či sú všetky odkazy na iné TC / artefakty / GUI presné. V opačnom prípade môžu mať testéri veľké problémy.

# 3) Pripútajte a uľahčite testerov:

Nenechávajte testovacie údaje na testeroch. Poskytnite im celý rad vstupov, najmä tam, kde sa majú vykonať výpočty alebo správanie aplikácie závisí od vstupov. Môžete im nechať rozhodnúť sa o hodnotách dátových položiek testu, ale nikdy im nedáte slobodu zvoliť si samotné testovacie dátové položky.

Pretože môžu úmyselne alebo neúmyselne použiť rovnaké testovacie údaje znova a znova a niektoré dôležité testovacie údaje môžu byť počas vykonávania TC ignorované.

Usporiadajte testerov v pohode organizovaním TC podľa testovacích kategórií a súvisiacich oblastí aplikácie. Je zrejmé, že poučte a uveďte, ktoré TC sú vzájomne závislé a / alebo dávkované. Rovnako výslovne uveďte, ktoré TC sú nezávislé a izolované, aby tester mohol zodpovedajúcim spôsobom riadiť svoju celkovú aktivitu.

V tomto okamihu by vás mohlo zaujímať čítanie o analýze hraničných hodnôt, čo je stratégia návrhu testovacieho prípadu, ktorá sa používa pri testovaní čiernej skrinky. Kliknite tu vedieť o tom viac.

# 4) Staňte sa prispievateľom:

Nikdy neprijímajte dokument FS alebo dizajnový dokument taký, aký je. Vašou úlohou nie je iba prejsť FS a identifikovať testovacie scenáre. Keďže ste zdrojom QA, nikdy neváhajte prispieť do podnikania a dať návrhy, ak máte pocit, že je možné v aplikácii niečo vylepšiť.

Navrhnite tiež vývojárom, najmä vo vývojovom prostredí riadenom TC. Navrhnite rozbaľovacie zoznamy, ovládacie prvky kalendára, výberový zoznam, skupinové prepínače, zmysluplnejšie správy, varovania, výzvy, vylepšenia týkajúce sa použiteľnosti atď.

Ak chcete byť QA, nielen testujte, ale urobte rozdiel!

# 5) Nikdy nezabudnite na koncového používateľa:

Najdôležitejšou zainteresovanou stranou je ‚Koncový používateľ‘, ktorý aplikáciu nakoniec použije. Takže na neho nikdy nezabudnite v ktorejkoľvek fáze písania TC. V skutočnosti by koncový používateľ nemal byť ignorovaný v žiadnej fáze procesu SDLC. Môj doterajší dôraz sa však zatiaľ týka iba mojej témy.

Počas identifikácie testovacích scenárov teda nikdy neprehliadnite tie prípady, ktoré budú väčšinou používané používateľom, alebo prípady, ktoré sú z obchodného hľadiska dôležité, aj keď sú používané menej často. Držte sa v koži koncového používateľa a potom si prečítajte všetky TC a posúďte praktickú hodnotu vykonania všetkých svojich zdokumentovaných TC.

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

Ako dosiahnuť dokonalosť v dokumentácii k testovacím prípadom

Keďže ste softvérovým testerom, určite mi dáte za pravdu, že prísť s dokonalým dokumentom o teste je skutočne náročná úloha.

V našom vždy ponechávame určitý priestor na zlepšenie Dokumentácia k testovacím prípadom . Niekedy nie sme schopní poskytnúť stopercentné pokrytie testom prostredníctvom TC a niekedy testovacia šablóna nie je na úrovni alebo nám chýba dobrá čitateľnosť a jasnosť našich testov.

Ako tester, kedykoľvek sa od vás žiada, aby ste napísali dokumentáciu k testu, nezačínajte iba ad-hoc spôsobom. Pred prácou na dokumentačnom procese je veľmi dôležité pochopiť účel písania testovacích prípadov.

Testy by mali byť vždy jasné a prehľadné. Mali by byť napísané spôsobom, ktorý testerovi uľahčí vykonanie úplného testovania podľa krokov definovaných v každom z testov.

Dokument o testovacom prípade by mal navyše obsahovať toľko prípadov, koľko je potrebných na zabezpečenie úplnosti pokrytie testom . Napríklad , mali by ste sa pokúsiť pokryť testovanie všetkých možných scenárov, ktoré sa môžu vo vašej softvérovej aplikácii vyskytnúť.

Pamätajúc na vyššie uvedené body, dovoľte mi, aby som vás teraz previedol prehliadkou Ako dosiahnuť excelenciu v dokumentácii k testom.

Užitočné tipy a triky

Tu vám poskytnem niekoľko užitočných pokynov, ktoré vám môžu poskytnúť prehľad v dokumentácii k testom od ostatných.

# 1) Je váš testovací dokument v dobrom tvare?

Najlepším a jednoduchým spôsobom, ako usporiadať testovací dokument, je rozdeliť ho do mnohých samostatných užitočných častí. Celé testovanie rozdelte do viacerých testovacích scenárov. Potom rozdeľte každý scenár do viacerých testov. Nakoniec každý prípad rozdeľte do niekoľkých testovacích krokov.

Ak používate program Excel, zdokumentujte každý testovací prípad na samostatnom hárku zošita, kde každý testovací prípad popisuje jeden kompletný testovací tok.

# 2) Nezabudnite pokryť negatívne prípady

Ako tester softvéru musíte myslieť mimo krabicu a využiť všetky možnosti, s ktorými sa vaša aplikácia stretáva. Ako testeri musíme overiť, či je potrebné zastaviť a nahlásiť akýkoľvek neautentický pokus o vstup do softvéru alebo akékoľvek neplatné údaje, ktoré prúdia cez aplikáciu.

Negatívny prípad je teda rovnako dôležitý ako pozitívny prípad. Uistite sa, že pre každý scenár, ktorý máte dva testovacie prípady - jeden pozitívny a jeden negatívny . Pozitívny prietok by mal pokrývať zamýšľaný alebo normálny prietok a záporný prúd by mal pokrývať nechcený alebo výnimočný prietok.

# 3) Vykonajte kroky atómového testu

Každý testovací krok by mal byť atómový. Nemali by sa robiť žiadne ďalšie podkroky. Čím je testovací krok jednoduchší a prehľadnejší, tým ľahšie by bolo s testovaním pokračovať.

# 4) Stanovte priority testov

Na dokončenie testovania aplikácie máme často prísne časové osy. V takom prípade nám môže chýbať testovanie niektorých dôležitých funkcií a aspektov softvéru. Aby ste tomu zabránili, mali by ste pri dokumentovaní označiť prioritu pri každom dokumentovaní.

Na definovanie priority testu môžete použiť akékoľvek kódovanie. Všeobecne je lepšie použiť ktorúkoľvek z 3 úrovní, vysoká, stredná a nízka alebo 1, 50 a 100. Takže, ak máte prísny časový rozvrh, mali by ste najskôr dokončiť všetky testy s vysokou prioritou a potom prejsť na testy so strednou a nízkou prioritou.

Napríklad - v prípade webových stránok zameraných na nakupovanie môže byť overenie odmietnutia prístupu pre neplatný pokus o prihlásenie do aplikácie prípadom s vysokou prioritou, overenie zobrazenia relevantných produktov na obrazovke používateľa môže byť prípadom so strednou prioritou a overenie farby textu zobrazeného na tlačidlá na obrazovke môžu byť testom s nízkou prioritou.

# 5) Na veciach sekvencií

Potvrďte, či je postupnosť krokov v teste úplne správna. Nesprávna postupnosť krokov môže viesť k zámene. Kroky by mali prednostne definovať aj celú postupnosť od vstupu do aplikácie až po ukončenie aplikácie pre konkrétny testovaný scenár.

# 6) Pridajte do poznámok časovú pečiatku a názov testera

Môže sa vyskytnúť prípad, že testujete aplikáciu, niekto robí úpravy paralelne s rovnakou aplikáciou alebo niekto môže aplikáciu aktualizovať po vykonaní testovania. To vedie k situácii, keď sa výsledky vášho testu môžu časom meniť.

Vždy je lepšie pridať do komentárov k testu časovú pečiatku s menom testera, aby bolo možné výsledok testu (vyhovieť alebo zlyhať) pripísať stavu aplikácie v konkrétnom čase. Prípadne môžete mať ‘ Dátum vykonania “Stĺpec pridaný osobitne k testovaciemu prípadu, ktorý výslovne identifikuje časovú pečiatku testu.

# 7) Zahrňte podrobnosti prehliadača

Ako viete, ak sa jedná o webovú aplikáciu, výsledky testu sa môžu líšiť v závislosti od prehliadača, v ktorom sa test vykonáva. Pre uľahčenie práce ostatných testerov, vývojárov alebo kohokoľvek, kto kontroluje dokument o teste, by ste mali do prípadu pridať názov a verziu prehliadača, aby bolo možné chybu ľahko replikovať.

# 8) V dokumente si nechajte dva samostatné listy - „Chyby“ a „Zhrnutie“

Ak dokumentujete v programe Excel, potom by prvé dva listy zošita mali byť Súhrn a Chyby. V súhrnnom hárku by mal byť zhrnutý scenár testu a v hárku Bugs by mali byť uvedené všetky problémy, ktoré sa vyskytli počas testovania. Dôležitosť pridania týchto dvoch listov je v tom, že čitateľovi / používateľovi dokumentu poskytne jasné pochopenie testovania.

Pokiaľ je teda čas obmedzený, tieto dva listy sa môžu ukázať ako veľmi užitočné pri poskytovaní prehľadu o testovaní.

Dokument o teste by mal poskytovať čo najlepšie pokrytie testom, vynikajúcu čitateľnosť a mal by mať po celom jednom štandardnom formáte.

Môžeme dosiahnuť excelentnosť v dokumentácii testov tak, že budeme mať na pamäti niekoľko základných tipov, ako je organizácia dokumentu testovacieho prípadu, stanovenie priorít TC, všetko v správnom poradí, vrátane všetkých povinných podrobností na vykonanie TC, a poskytnutie jasných a prehľadných krokov testu, atď., ako je uvedené vyššie.

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

Ako NEPÍSAŤ testy

Trávime väčšinu času ich písaním, kontrolou, vykonávaním alebo údržbou. Je dosť poľutovaniahodné, že testy sú tiež najviac náchylné na chyby. Rozdiely v porozumení, postupoch testovania v organizácii, nedostatku času atď. Sú niektoré z dôvodov, prečo často vidíme testy, ktoré nechávajú veľa požadovaných vecí.

Na našom webe je veľa článkov o tejto téme, ale uvidíme tu Ako NEPISOVAŤ testovacie prípady - niekoľko tipov, ktoré pomôžu pri vytváraní charakteristických, kvalitných a efektívnych testov.

Čítajme ďalej a tieto tipy sú určené pre nových aj skúsených testerov.

3 Najčastejšie problémy v testovacích prípadoch

1. Zložené kroky
2. Správanie aplikácie sa považuje za očakávané správanie
3. Viaceré podmienky v jednom prípade

Títo traja musia byť na mojom prvom 3 zozname bežných problémov v procese písania testu.

Zaujímavé je, že k tomu dochádza u nových aj skúsených testerov. Stále sledujeme rovnaké chybné procesy a nikdy si neuvedomujeme, že niekoľko jednoduchých opatrení môže veci ľahko napraviť.

Poďme na to a podrobne si o každej z nich povieme:

# 1) Zložené kroky

V prvom rade, čo je zložený krok?

Napríklad dávate pokyny z bodu A do bodu B: ak hovoríte, že „choďte na miesto XYZ a potom do ABC“, nebude to mať veľký zmysel, pretože tu sa ocitneme v myšlienkach - „Ako môžem dostať sa na prvom mieste k XYZ “- namiesto toho začnite slovami„ Odbočte odtiaľto doľava a choďte 1 míľu, potom odbočte doprava na Rd. číslo 11, ktoré má doraziť na XYZ “, môže dosiahnuť lepšie výsledky.

Rovnaké pravidlá platia aj pre testy a ich kroky.

Napríklad Píšem test pre Amazon.com - urobte objednávku na akýkoľvek produkt.

Nasledujú moje testovacie kroky (Poznámka: Píšem iba kroky a nie všetky ďalšie časti testu, ako je očakávaný výsledok atď.)

do . Spustite stránku Amazon.com
b . Vyhľadajte produkt zadaním kľúčového slova / názvu produktu do poľa „Hľadať“ v hornej časti obrazovky.
c . Zo zobrazených výsledkov vyhľadávania vyberte prvý.
d . Kliknite na položku Pridať do košíka na stránke s podrobnosťami o produkte.
je . Pokladňa a platba.
f . Skontrolujte stránku s potvrdením objednávky.

Teraz, viete určiť, ktorý z nich je zloženým krokom? Pravý krok (e)

Pamätajte, že pri testoch ide vždy o to, ako testovať, takže je dôležité do testu zapísať presný postup z časti „Ako sa odhlásiť a zaplatiť“.

Vyššie uvedený prípad je preto účinnejší, ak je napísaný nižšie:

do . Spustite stránku Amazon.com
b . Vyhľadajte produkt zadaním kľúčového slova / názvu produktu do poľa „Hľadať“ v hornej časti obrazovky.
c . Zo zobrazených výsledkov vyhľadávania vyberte prvý.
d . Kliknite na položku Pridať do košíka na stránke s podrobnosťami o produkte.
je . Kliknite na stránku Pokladňa na stránke nákupného košíka.
f . Zadajte informácie o CC, poštovné a fakturačné údaje.
g . Kliknite na položku Pokladňa.
h . Skontrolujte stránku s potvrdením objednávky.

Zložený krok je preto ten, ktorý je možné rozdeliť do niekoľkých jednotlivých krokov. Keď nabudúce píšeme testy, venujme tejto časti pozornosť všetci a som si istý, že so mnou budete súhlasiť, že to robíme častejšie, ako si uvedomujeme.

# 2) Správanie aplikácie sa považuje za očakávané správanie

Túto situáciu musí v dnešnej dobe riešiť čoraz viac projektov.

Nedostatok dokumentácie, extrémne programovanie, rýchle vývojové cykly sú niekoľkými dôvodmi, ktoré nás nútia spoliehať sa na to, že aplikácia (staršia verzia alebo iná) bude písať testy alebo na nich bude založené samotné testovanie. Ako vždy, ide o osvedčený zlý postup - nie vždy.

Je to neškodné, pokiaľ máte otvorenú myseľ a očakávate, že - „AUT by mohlo mať chybu“. Iba vtedy, keď si nemyslíte, že to tak je, veci fungujú zle. Ako vždy necháme hovoriť príklady.

Ak píšete / navrhujete testovacie kroky pre túto stránku, postupujte takto:

Prípad 1:

Ak sú kroky môjho testovacieho prípadu uvedené nižšie:

1. Spustite stránku s nákupmi.
2. Kliknite na Preprava a vrátenie - Očakávaný výsledok: Stránka prepravy a vrátenia sa zobrazí s tlačidlami „Sem vložte svoje informácie“ a tlačidlom „Pokračovať“.

Potom je to nesprávne.

Prípad 2:

1. Spustite stránku s nákupmi.
2. Kliknite na Preprava a vrátenie.
3. Do textového poľa „Zadať číslo objednávky“ na tejto obrazovke zadajte číslo objednávky.
4. Kliknite na Pokračovať - ​​Očakávaný výsledok: Zobrazia sa podrobnosti objednávky súvisiace s dopravou a vrátením.

Prípad 2 je lepším testovacím prípadom, pretože aj keď sa referenčná aplikácia chová nesprávne, berieme ju iba ako vodítko, robíme ďalší prieskum a očakávané správanie zapisujeme podľa predpokladanej správnej funkčnosti.

Spodná čiara: Aplikácia ako referencia je rýchla skratka, ale má svoje vlastné riziká. Pokiaľ sme opatrní a kritickí, prináša úžasné výsledky.

# 3) Viac podmienok v jednom prípade

Opäť sa poučme Príklad .

Prezrite si nasledujúce kroky testu: Nasledujú kroky testu v rámci jedného testu funkcie prihlásenia.

a. Zadajte platné podrobnosti a kliknite na tlačidlo Odoslať.
b. Pole pre meno používateľa nechajte prázdne. Kliknite na tlačidlo Odoslať.
c. Nechajte pole pre heslo prázdne a kliknite na Submit.
d. Vyberte už prihlásené používateľské meno / heslo a kliknite na tlačidlo Odoslať.

Čo museli byť 4 rôzne prípady, je spojené do jedného. Možno si myslíte - Čo je na tom zlé? Ušetrí to veľa dokumentácie a to, čo môžem urobiť v 4, to robím v 1, nie je to skvelé? No nie celkom. Dôvody?

Pokračuj v čítaní:

• Čo ak niektorá z podmienok zlyhá - musíme celý test označiť ako „nevyhovel“. Ak označíme celý prípad ako „zlyhaný“, znamená to, že všetky 4 podmienky nefungujú, čo nie je pravda.
• Testy musia mať prietok. Od predbežného predpokladu po krok 1 a všetky kroky. Ak budem postupovať podľa tohto prípadu, v kroku (a), ak bude úspešný, budem prihlásený na stránku, kde už nie je k dispozícii možnosť „prihlásiť sa“. Takže keď sa dostanem ku kroku (b) - kde tester zadá používateľské meno? Uvidíte, tok je prerušený.

Teda písať modulárne testy . Znie to ako veľa práce, ale všetko, čo potrebujete, je oddeliť veci a použiť našich najlepších priateľov Ctrl + C a Ctrl + V na prácu pre nás. :)

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

Ako zvýšiť efektívnosť testovacích prípadov

Testéri softvéru by mali svoje testy písať od skoršej fázy životného cyklu vývoja softvéru, najlepšie počas fázy požiadaviek na softvér.

Manažér testov alebo manažér QA by mal zhromaždiť a pripraviť maximálny možný počet dokumentov podľa nižšie uvedeného zoznamu.

Zbierka dokumentov na písanie testu

# 1) Dokument o požiadavkách na používateľa

Je to dokument, ktorý uvádza obchodný proces, profily používateľov, užívateľské prostredie, interakciu s inými systémami, výmenu existujúcich systémov, funkčné požiadavky, nefunkčné požiadavky, licenčné a inštalačné požiadavky, výkonové požiadavky, bezpečnostné požiadavky, použiteľnosť a súbežné požiadavky atď. .,

# 2) Dokument prípadu obchodného použitia

Tento dokument podrobne popisuje prípad použitia scenár funkčných požiadaviek z obchodného hľadiska. Tento dokument obsahuje podnikateľov (alebo systém), ciele, predbežné podmienky, následné podmienky, základný tok, alternatívny tok, možnosti, výnimky každého obchodného toku systému podľa požiadaviek.

# 3) Dokument o funkčných požiadavkách

Tento dokument podrobne uvádza funkčné požiadavky jednotlivých funkcií systému podľa požiadaviek.

Dokument o funkčných požiadavkách zvyčajne slúži ako spoločné úložisko pre vývojový a testovací tím, ako aj pre zainteresované subjekty v projekte vrátane zákazníkov, pokiaľ ide o splnené (niekedy zmrazené) požiadavky, ktoré by sa mali považovať za najdôležitejší dokument pre akýkoľvek vývoj softvéru.

# 4) Plán softvérového projektu (voliteľný)

Dokument, ktorý popisuje podrobnosti projektu, ciele, priority, míľniky, činnosti, organizačnú štruktúru, stratégiu, monitorovanie pokroku, analýzu rizík, predpoklady, závislosti, obmedzenia, požiadavky na školenie, zodpovednosti klienta, harmonogram projektu atď.,

# 5) Plán kvality / test

Tento dokument podrobne popisuje systém riadenia kvality, normy dokumentácie, mechanizmus kontroly zmien, kritické moduly a funkcie, systém riadenia konfigurácie, plány testovania, sledovanie chýb, kritériá prijatia atď.

The plán skúšok dokument sa používa na identifikáciu funkcií, ktoré sa majú testovať, funkcií, ktoré sa nemajú testovať, pridelenia testovacieho tímu a ich rozhrania, požiadavky na zdroje, plán testovania, písanie testu, pokrytie testu, výstupy testu, predpoklad vykonania testu, hlásenie chyby a sledovanie mechanizmus, testovacie metriky atď.,

Skutočný príklad

Pozrime sa, ako efektívne napísať testovacie prípady pre známu a jednoduchú obrazovku „Prihlásenie“ podľa nasledujúceho obrázka. The prístup testovania bude takmer rovnaké aj pri zložitých obrazovkách s väčším počtom informácií a kritických funkcií.

# 1) Prvým prístupom v každom procese testovacieho prípadu bude získanie prototypu obrazovky (alebo drôtených rámov), ako je uvedené vyššie, ak je k dispozícii. To nemusí byť k dispozícii pre niektoré funkcie a závisí to od kritickosti návrhu prototypu v skorších fázach vývoja.

Ale ak SRS Dokument (Špecifikácia softvérových požiadaviek) je k dispozícii pre projekt, väčšinu prototypov obrazoviek vyvinul projektový tím. Tento druh obrazovky zjednodušuje prácu testera a zvyšuje efektivitu testov.

#dva) Ďalej špecifikácie funkčných požiadaviek . Závisí to od organizačného procesu, bude k dispozícii v balíku viacerých dokumentov.

Takže rozhodnite sa pre najlepší dokument na písanie prípadov, môže to byť buď dokument požiadaviek používateľa, alebo špecifikácia funkčných požiadaviek (alebo dokonca dokument SRS, ak to testovací tím pochopí pohodlne), ktorý poskytne kompletný funkčný tok vybraného funkcia, ktorá sa má testovať.

# 3) Po zavedení prototypu obrazovky a funkčných špecifikácií by mal tester začať písať prípady podľa nasledujúceho prístupu a kritérií.

• Testy používateľského rozhrania :Ovládacie prvky / polia, ktoré sú viditeľné pre používateľa. Pre testovanú funkciu sú k dispozícii statické a dynamické ovládacie prvky. Napríklad, na prihlasovacej obrazovke vyššie sú texty „Používateľské meno a heslo“ statické polia, ktoré nevyžadujú žiadnu interakciu používateľa, iba na zobrazenie iba textu.

• Funkčné prípady :Na druhej strane, tlačidlo Prihlásiť sa a Hypertextové odkazy (Zabudli ste heslo? & Registrácia) sú dynamické polia, ktoré si vyžadujú interakciu používateľa kliknutím na ovládacie prvky, ktoré potom urobí nejakú akciu.

• Databázové prípady :Akonáhle užívateľ zadá užívateľské meno a heslo, môžu byť testy napísané tak, aby skontrolovali súvisiacu databázu, či je užívateľské meno a heslo skontrolované v správnej databáze a tabuľke a tiež má užívateľ povolenie na prihlásenie do testovanej aplikácie.
  

• Procesné skúšky :Súvisí to s procesom (nie s akciami spojenými s viditeľnými ovládacími prvkami dostupnými na obrazovke) spojenými s danou funkciou a funkčnosťou. Napríklad, kliknutím na odkaz Zabudnuté heslo na vyššie uvedenej ukážkovej obrazovke môžete používateľovi poslať e-mail. Je možné, že e-mail musí byť otestovaný na správny proces a potvrdenie.

4) Nakoniec si ponechajte BAOE mantra ”, Znamená i) Základný tok ii) Alternatívny tok iii) Možnosti a iv) Výnimky pre úplné pokrytie funkčného toku a vlastnosti, ktorá sa má testovať. Každý koncept by sa mal uplatniť pri pozitívnych a negatívnych testoch.

Napríklad, pozrime sa na jednoduchý prístup BAOE pre vzorovú prihlasovaciu obrazovku vyššie.

• Základný tok: Zadajte cestu URL prihlásenia v ľubovoľnom prehliadači a zadajte požadované informácie a prihláste sa do aplikácie.
• Alternatívny prietok: Nainštalujte si aplikáciu na mobilné zariadenie, zadajte požadované informácie a prihláste sa do aplikácie.
• Možnosti: Aké sú možnosti dostupné na rovnakú prihlasovaciu obrazovku? Napríklad, po prihlásení do aplikácie sa kliknutím na „Odhlásiť“ môže zobraziť rovnaká obrazovka alebo ak vypršal časový limit relácie alebo relácia vyprší, môže sa používateľ dostať na prihlasovaciu obrazovku.
• Výnimky: Aké sú výnimky, ak sú moje testy negatívne? Napríklad, ak sú na prihlasovacej obrazovke zadané nesprávne poverenia, či sa používateľovi zobrazí chybová správa alebo nebude spojená žiadna akcia.

So všetkými týmito informáciami v ruke začnime písať TC pre prihlasovaciu obrazovku vo formáte s úplným pokrytím a sledovateľnosťou a s podrobnými informáciami. Logická postupnosť a číslovanie identifikácie „ ID testovacieho prípadu “ bude veľmi užitočné pre rýchlu históriu vykonania identifikácie testovacích prípadov.

Prečítajte si tiež=> Viac ako 180 vzoriek pripravených na použitie pre webové a desktopové aplikácie.

Dokument o testovacom prípade

Poznámka : Testovacie stĺpce sa neobmedzujú iba na nasledujúci vzorový testovací dokument, ktorý je možné uchovať v excelovom hárku, aby mal toľko stĺpcov, koľko je potrebných pre kompletnú maticu vysledovateľnosti, tj. Priorita, účel testovania, typ testovania, umiestnenie chybovej snímky obrazovky atď.,

Prečítajte si tiež=> Ukážka šablóny testovacieho prípadu s príkladmi.

Pre ľahkosť jednoduchosti a čitateľnosti tohto dokumentu si nižšie podrobne napíšeme kroky na reprodukciu očakávaného a skutočného priebehu testov pre prihlasovaciu obrazovku.

Poznámka : Pridajte stĺpec Skutočné správanie na koniec tejto šablóny.

Testovanie zhromažďovania údajov

Pri písaní testovacieho prípadu je najdôležitejšou úlohou každého testera zozbierať údaje o teste. Mnoho testerov túto aktivitu preskakuje a prehliada s predpokladom, že testovacie prípady je možné vykonať s niektorými vzorovými údajmi alebo fiktívnymi údajmi a je možné ich načítať, keď sú údaje skutočne potrebné. Toto je kritická mylná predstava, že kŕmenie vzorových údajov alebo vstupných údajov z pamäte mysle v čase vykonania testovacích prípadov.

Ak sa v dokumente o teste v čase písania testov údaje nezhromažďujú a neaktualizujú, tester by v čase vykonania testu venoval abnormálne viac času zhromažďovaniu údajov. Údaje o teste by sa mali zhromažďovať pre pozitívne aj negatívne prípady z celej perspektívy funkčného toku prvku. V tejto situácii je veľmi užitočný dokument prípadu obchodného použitia.

Vyhľadajte vzorový dokument s údajmi o teste pre testy napísané vyššie, čo zase pomôže, ako efektívne dokážeme zhromaždiť údaje, ktoré nám uľahčia prácu v čase vykonania testu.

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

Dôležitosť štandardizácie testovacích prípadov

V tomto rušnom svete nikto nemôže robiť opakujúce sa veci každý deň s rovnakou úrovňou záujmu a energie. Najmä nie som nadšený z toho, že v práci robím stále tie isté úlohy. Rád spravujem veci a šetrím čas. Každý v IT by to tak mal byť.

najlepší softvér na skrytie adresy IP

Všetky IT spoločnosti realizujú rôzne typy projektov. Tieto projekty môžu byť založené na produktoch alebo službách. Z týchto projektov väčšina z nich pracuje na webových stránkach a testovanie webových stránok . Dobrá správa je, že všetky webové stránky majú veľa podobností. A ak sú webové stránky pre rovnakú doménu, majú tiež niekoľko spoločných funkcií.

Otázka, ktorá ma vždy trápi, je: „Ak je väčšina aplikácií podobná, napríklad: napríklad maloobchodné weby, ktoré už boli tisíckrát testované,„ Prečo musíme písať testovacie prípady pre ďalší maloobchodný web úplne od začiatku? “ Nešetrí to kopu času vytiahnutím existujúcich testovacích skriptov, ktoré sa použili na testovanie predchádzajúcej maloobchodnej stránky?

Iste, môžu existovať nejaké drobné vylepšenia, ktoré možno budeme musieť urobiť, ale celkovo je to jednoduchšie, efektívne, tiež šetrí čas a peniaze, a tým vždy pomôže udržať vysokú úroveň záujmu testerov. Kto rád píše, kontroluje a udržiava rovnaké testovacie prípady opakovane, že? Opätovné použitie existujúcich testov to môže do značnej miery vyriešiť a vašim klientom to bude pripadať tiež inteligentné a logické.

Logicky som teda začal sťahovať existujúce skripty z podobných webových projektov, urobil som zmeny a rýchlo som ich prebral. Farebné kódovanie som použil aj na zobrazenie vykonaných zmien, aby sa recenzent mohol sústrediť iba na tú časť, ktorá bola zmenená.

Dôvody na opakované použitie testovacích prípadov

# 1) Najfunkčnejšie oblasti webu sú takmer - prihlásenie, registrácia, pridanie do košíka, zoznam želaní, kontrola, možnosti dopravy, možnosti platby, obsah stránky produktu, naposledy zobrazené, relevantné produkty, možnosti promo kódu atď.

#dva) Väčšina projektov sú iba vylepšenia alebo zmeny existujúcej funkčnosti.

# 3) Systémy na správu obsahu, ktoré definujú sloty na nahrávanie obrázkov statickými a dynamickými spôsobmi, sú tiež bežné pre všetky webové stránky.

# 4) Maloobchodné weby majú CSR (Zákaznícky servis).

# 5) Backendový systém a skladová aplikácia využívajúca JDA používajú aj všetky webové stránky.

# 6) Spoločný je tiež koncept súborov cookie, časového limitu a bezpečnosti.

# 7) Webové projekty sú často náchylné na zmeny požiadaviek.

# 8) The typy testovania potrebné sú bežné ako prehliadač testovanie kompatibility , testovanie výkonu , testovanie bezpečnosti

Uvidíte, je veľa toho spoločného a podobného.

Vzhľadom na to, že opätovná použiteľnosť je správna cesta, niekedy samotné úpravy môžu alebo nemusia trvať viac alebo menej času. Niekedy môže mať človek pocit, že je lepšie začať od nuly ako toľko upravovať.

To sa dá ľahko vyriešiť vytvorením sady štandardných testovacích prípadov pre každú z bežných funkcií.

Čo je štandardný test pri webovom testovaní?

• Vytvorte úplné testovacie prípady - kroky, údaje, premenné atď. Takto sa zabezpečí, že nepodobné údaje / premenné sa dajú jednoducho vymeniť, keď sa vyžaduje podobný testovací prípad.
• Mali by byť správne definované vstupné a výstupné kritériá.
• Upraviteľné kroky alebo výrok v krokoch by mali byť zvýraznené inou farbou, aby ste ich mohli rýchlo nájsť a nahradiť.
• Jazyk použitý na vytvorenie štandardného testovacieho prípadu by mal byť všeobecný.
• V testovacích prípadoch by mali byť zahrnuté všetky funkcie každej webovej stránky.
• Názov testovacích prípadov by mal byť názvom funkčnosti alebo vlastnosti, ktorú testovací prípad pokrýva. Toto výrazne uľahčí nájdenie testovacieho prípadu zo súpravy.
• Ak existuje nejaký základný alebo štandardný vzorový súbor alebo súbor grafického používateľského rozhrania alebo snímka obrazovky funkcie, mal by byť pripojený s príslušnými krokmi.

Pomocou vyššie uvedených tipov môžete vytvoriť skupinu štandardných skriptov a použiť ich s malými alebo požadovanými úpravami pre rôzne webové stránky.

Aj tieto štandardné testovacie prípady je možné automatizovať, ale zameranie sa na opätovné použitie je vždy plusom. Tiež ak automatizácia je založené na grafickom používateľskom rozhraní, opakované použitie skriptov na viacerých adresách URL alebo na iných stránkach je niečo, čo som osobne nikdy nenašiel efektívne.

Najlepším spôsobom, ako vykonať testovanie webových stránok, je použitie štandardnej sady manuálnych testovacích prípadov pre rôzne webové stránky s malými úpravami. Všetko, čo potrebujeme, je vytvoriť a udržiavať testovacie prípady s náležitými štandardmi a použitím.

Záver

Zlepšenie efektívnosti testovacích prípadov nie je jednoducho definovaný pojem, ale je to cvičenie a je možné ho dosiahnuť vyzretým procesom a pravidelným cvičením.

Testovací tím by nemal byť unavený z účasti na zlepšovaní týchto úloh, pretože je najlepším nástrojom na dosiahnutie väčších úspechov vo svete kvality, čo sa osvedčilo v mnohých testovacích organizáciách na celom svete v oblasti najdôležitejších projektov a zložitých aplikácií.

Dúfam, že by ste získali obrovské vedomosti o koncepcii testovacích prípadov. Pozrite si našu sériu návodov, kde sa dozviete viac o testovacích prípadoch, a vyjadrite svoje myšlienky v sekcii komentárov nižšie!

Ďalšia príručka

Odporúčané čítanie

• Funkčné testovanie vs. Nefunkčné testovanie
• Príručka na testovanie prenosnosti s praktickými príkladmi
• Typy testovania softvéru: Rôzne typy testovania s podrobnosťami
• Najlepšie nástroje na testovanie softvéru 2021 (QA Test Automation Tools)
• Alfa testovanie a beta testovanie (kompletný sprievodca)
• Čo je Testovanie systému - Sprievodca pre úplných začiatočníkov
• Vzorové dotazníky s odpoveďami na testovanie certifikácie ISTQB
• Ako písať týždenné správy o testovaní softvéru