Menu

Zápis testovacích prípadov z dokumentu SRS (STIAHNUŤ ukážky testovacích prípadov projektu Live)

writing test cases from srs document

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Písanie testovacích prípadov z dokumentu SRS (Stiahnite si ukážkové testovacie prípady živého projektu) - Výcvikový deň QA pre testovanie softvéru

Len aby sme znova premiešali to, čo sme doteraz robili - prepracovávame sa Výcvik testovania softvéru minikurz na živom projekte OrangeHRM.

V tejto zatiaľ bezplatnej online sérii školení QA sme hotoví s:

  1. Preskúmanie SRS,
  2. Scenár testu / identifikácia rozsahu testu a
  3. Zdokumentovaný plán testov .

Písanie testovacích prípadov z dokumentu SRS

Teraz sme sa dostali k časti, ktorá je skutočnou dohodou,testovacie prípady.

Ako je uvedené v článku pred týmto: Testovacie prípady dokumentuje tím QA, zatiaľ čo prebieha fáza kódu SDLC. Inými slovami, zatiaľ čo tím vývojárov zostavuje softvérový systém, testovací tím sa pripravuje na testovacie prípady, ktoré by nám pomohli testovať systém, akonáhle je pripravený, t. J. Na konci fázy kódu.

V dnešnom článku teda budeme pracovať na porozumení toho, čo sú testovacie prípady, ako ich vytvoriť a napísať niekoľko vzorových testovacích prípadov pre náš živý projekt.

Poďme na to hneď.

Čo sa dozviete:

Základy písania testovacích prípadov

# 1) Ak išlo o testovacie scenáre, „Čo budeme testovať“ na AUT - o testovacích prípadoch ide „Ako budeme testovať požiadavku“.

Napríklad , ak je testovacím scenárom „Overiť funkčnosť prihlásenia správcu“ - To by prinieslo 3 testovacie prípady (alebo podmienky) - Prihlásenie (úspešné), Prihlásenie neúspešné pri zadaní nesprávneho používateľského mena, Prihlásenie neúspešné pri zadaní nesprávneho hesla . Každý testovací prípad by zase mal kroky na riešenie toho, ako môžeme skontrolovať, či je konkrétny testovací stav splnený alebo nie.

#dva) Vstupom pre vytvorenie dokumentu testovacieho prípadu je FRD, Testovacie scenáre vytvorené v predchádzajúcom kroku a všetky ďalšie referenčné dokumenty, ak existujú.

# 3) Dokumentácia testovacích prípadov je dôležitým výstupom tímu QA a je zdieľaná s BA, PM a ďalšími tímami, keď sú hotové pre ich spätnú väzbu.

# 4) Práca je rozdelená medzi členov tímu a každý člen bude zodpovedný za vytvorenie testovacích prípadov pre určitý modul alebo časť určitého modulu.

# 5) Rovnako ako v prípade testovacích scenárov, aj predtým, ako začneme s dokumentáciou testovacích prípadov, je potrebné dohodnúť spoločnú šablónu. Na vytvorenie testovacích prípadov sa dá použiť prakticky čokoľvek. 2 najčastejšie používané možnosti sú MS Excel a MS word.

# 6) The MS word šablóna vyzerá asi takto:

Testovacie prípady MS word template

# 7) The Šablóna programu Excel môže vyzerať takto:

qa tréningové testovacie prípady vzorky xls

# 8) Z vyššie uvedených dvoch šablón je možné pozorovať, že polia (alebo komponenty), ktoré tvoria testovací prípad, sú rovnaké, rozdiel je iba v spôsobe ich usporiadania.

Pokiaľ teda existuje pole pre každý z typov informácií, ktoré sa majú zahrnúť do testu, na formáte šablóny nezáleží. Mojím osobným favoritom je však hárok programu Excel, pretože je ľahké ho rozbaliť, zbaliť, triediť atď. Vyberte si však opäť akýkoľvek formát, ktorý vám najlepšie vyhovuje.

Polia v testovacích prípadoch

Venujme chvíľu pozorovaniu polí, ktoré sú súčasťou testovacieho prípadu.

Id testovacieho prípadu a popis testovacieho prípadu sú všeobecné.

Ostatné polia možno vysvetliť nasledovne:

  • Predpoklad: Stav AUT (stav, v ktorom musí byť AUT, aby sme mohli začať).
  • Vstup: Kroky zadávania údajov. Pri týchto krokoch je dôležité uvedomiť si, aký druh vstupných informácií sa vyžaduje - Testovacie údaje.
  • Validačný bod / spúšťač / akcia : Čo spôsobuje validáciu? (Kliknutie na tlačidlo alebo prepínač alebo prístup na odkaz. Uistite sa, že v testovacom prípade je aspoň jeden validačný bod - inak to bude všetko, čo bude zadávanie údajov a nebude treba čo hľadať. Tiež zaistíme dostatočnú modularitu, Snažte sa nekombinovať príliš veľa overovacích bodov do jedného testovacieho prípadu. Optimálny je 1 testovací prípad.)
  • Výkon: Ocakavane vysledky.
  • Dodatočná podmienka: Toto sú ďalšie informácie, ktoré sú poskytované v prospech testera, len aby bol testovací prípad prehľadnejší a informatívnejší. Zahŕňa to vysvetlenie toho, čo sa stane alebo čo možno očakávať od AUT po vykonaní všetkých krokov v testovacom prípade.

Pozri tiež => Ukážka šablóny testovacieho prípadu

Príklady testovacích prípadov živého projektu (na stiahnutie)

Teraz, keď máme dostatok základných informácií, aby sme mohli začať s procesom vytvárania testovacích prípadov, poďme začať a vytvorme niekoľko testovacích prípadov pre náš projekt Live.

Na základe vyššie uvedeného procesu sme vytvorili niekoľko vzorových testovacích prípadov pre modul účtu OrangeHRM. Mali by vám poskytnúť presný formát testovacieho prípadu a predstavu, ako postupovať pri písaní testovacích prípadov.

=> Stiahnite si vzorový dokument testovacích prípadov pre náš živý projekt tu .

Poznámka: Existuje niekoľko obrázkov odkazujúcich na vzorové testovacie prípady XLS dokumentu. Ak si toto prezeráte v staršej verzii MS Office, môžu sa vyskytnúť problémy s kompatibilitou.

Nižšie uvádzame tieto obrázky podľa ich mien v súboroch XLS:

Zobraziť obrázok 1
Zobraziť obrázok 2
Zobraziť obrázok 3

Tam je všetko hotové a všetko dobré.

Metódy zapisovania / optimalizácie testovacích prípadov

Teraz si predstavte situáciu, keď určitá stránka obsahuje niekoľko desiatok polí alebo má komplexnú obchodnú logiku, ktorá je tam implementovaná. Aby sme sa uistili, že v takýchto situáciách optimalizujeme proces vytvárania testovacích prípadov, máme testeri určité metódy optimalizácie testovacích prípadov.

Nižšie sú uvedené odkazy, ktoré poskytujú ďalšie informácie o týchto metódach.

životný cyklus chyby v testovaní softvéru

Pomocou vyššie uvedených techník a nasledovania všeobecného procesu vytvárania testovacích prípadov vytvoríme množinu testovacích prípadov, ktoré by efektívne testovali aplikáciu po ruke.

Je potrebné si všimnúť niekoľko dôležitých bodov

  • Testovacie prípady, ktoré vytvárame, sú nielen referenčným bodom pre fázu QA, ale aj pre UAT.
  • Interne testovacie prípady sú Recenzované v rámci tímu .
  • Ak určitú situáciu nerieši testovací prípad - platí pravidlo, že sa nebude testovať. Toto je dobré miesto na kontrolu, či testovací balík, ktorý sme vytvorili, dosahuje cieľ 100% pokrytia testom alebo nie. Na tento účel je možné vytvoriť maticu vysledovateľnosti. Pozrite sa na všetko, čo treba vedieť o Matica sledovateľnosti tu .
  • Nástroje - nástroje na správu testov ako QC , qTest pomôžte nám s tvorbou testovacích prípadov. Príklad, ako je možné vyriešiť testovacie prípady pomocou Centra kvality, si pozrite tu Výukový program pre Centrum kvality .
  • Na vytvorenie testovacích prípadov je možné použiť automatizačné nástroje - v takom prípade sa označujú ako Testovacie skripty.
Pro Tip :Vykonajte kontrolu pravopisu a gramatiky každého dokumentu, ktorý vytvoríme. Sme zástupcami kvality pre IT projekty - a to sa na nás pozitívne neodzrkadľuje, ak samotné naše produkty majú horšiu kvalitu.

Tým sa dostávame k cieľu ďalšieho zaujímavého segmentu.

Záver

Na konci fázy vytvárania testu / fázy návrhu testu (STLC) a na konci fázy kódu (SDLC) sa spravidla označuje koniec fázy prípravy testu a začiatok fázy vykonania testu.

Ďalšia príručka v tomto kurze testovania softvéru - V nasledujúcom článku si povieme, čo je Test Execution, čo obsahuje a aké sú očakávania od tímu QA počas tejto fázy.

=> QA Training Day 5: Vykonanie testu

Dúfame, že všetci pracujete spolu s touto sériou. Pre jednoduchosť bolo vytvorených iba niekoľko testovacích prípadov. Najlepšie výsledky však uvidíte, keď pracujete na rozsiahlom testovaní, čo znamená písanie ďalších a ďalších testovacích prípadov. Neobmedzujte preto svoju prácu a robte toľko, koľko môžete.

Dajte nám prosím vedieť svoje otázky a komentáre nižšie. Príjemné testovanie!

Výukový program PREV | NEXT Tutorial

Odporúčané čítanie

^