Kako pisati test slučajeve: Vrhunski vodič s primjerima

how write test cases

U ovom detaljnom priručniku o tome kako pisati test slučajeve, obradio sam detalje što je test slučaj, njegovu standardnu ​​definiciju i tehnike dizajniranja test slučajeva.

Što je test slučaj?

Test slučaj ima komponente koje opisuju unos, radnju i očekivani odgovor kako bi se utvrdilo radi li značajka aplikacije ispravno.

Testni slučaj je skup uputa o „KAKO“ za provjeru valjanosti određenog testnog cilja / cilja, koji će nam nakon slijeđenja reći je li očekivano ponašanje sustava zadovoljeno ili ne.

Popis tutorijala obuhvaćenih ovom serijom pisanja testnih slučajeva:

Kako napisati:

Vodič br. 1: Što je testni slučaj i kako napisati test slučajeve (ovaj vodič)
Vodič br. 2: Uzorak predloška test primjera s primjerima (preuzmi) (mora pročitati)
Vodič br. 3: Pisanje ispitnih slučajeva iz SRS dokumenta
Vodič br. 4: Kako napisati test slučajeve za zadani scenarij
Vodič br. 5: Kako se pripremiti za pisanje test slučajeva
Vodič br. 6: Kako pisati negativne test slučajeve

Primjeri:

Vodič br. 7: 180+ uzoraka testnih slučajeva za web i stolne programe
Vodič br. 8: 100+ spremnih za izvršenje testnih scenarija (kontrolni popis)

Tehnike pisanja:

Vodič br. 9: Graf uzroka i posljedica - Tehnika pisanja dinamičkih test slučajeva
Vodič br. 10: Državna prijelazna tehnika ispitivanja
Vodič br. 11: Tehnika ispitivanja pravokutnih nizova
Vodič br. 12: Tehnika pogađanja pogrešaka
Vodič br. 13: Tehnika dizajna ispitivanja tablice provjere valjanosti polja (FVT)

Test slučajevi i scenariji ispitivanja:

Vodič br. 14: Ispitni slučajevi protiv scenarija ispitivanja
Vodič br. 15: Razlika između plana ispitivanja, strategije ispitivanja i test slučaja

Automatizacija:

Vodič br. 16: Kako odabrati ispravne ispitne slučajeve za automatizirano ispitivanje
Vodič # 17: Kako prevesti slučajeve ručnog testiranja u skripte za automatizaciju

Alati za upravljanje testovima:

Vodič br. 18: Najbolji alati za upravljanje testovima
Vodič br. 19: TestLink za upravljanje test slučajem
Vodič br. 20: Stvaranje i upravljanje test slučajevima pomoću HP centra za kvalitetu
Vodič br. 21: Izvršenje test slučajeva pomoću ALM / QC

Slučajevi specifični za domenu:

Vodič br. 22: Ispitni slučajevi za ERP aplikaciju
Vodič br. 23: JAVA Primjeri testnih slučajeva
Vodič br. 24: Analiza granične vrijednosti i podjela ekvivalencije

Nastavimo s prvim tutorijalom iz ove serije.

Preporučeni alati:

Prije nastavka postupka pisanja test slučaja, preporučujemo preuzimanje ovog alata za upravljanje test slučajem. Ovo će vam olakšati postupak pisanja test slučajeva koji se spominje u ovom vodiču:

# 1) TestRail

=> Preuzmite TestRail Tool Test Management Tool

# 2) TestMonitor

Vrhunsko internetsko upravljanje testovima. Revolucionarno lako.

TestMonitor je cjeloviti alat za upravljanje testovima za svaku organizaciju. Jednostavan, intuitivan pristup testiranju. Bilo da implementirate poslovni softver, trebate li osigurati kvalitetu, gradite kvalitetnu aplikaciju ili vam treba samo ruka pomoći u vašem testnom projektu, TestMonitor vas pokriva.

=> Posjetite web mjesto TestMonitor

Što ćete naučiti:

• Što je test slučaj i kako napisati test slučajeve?
  • Zašto pišemo testove?
  • Kako napisati test slučajeve?
  • Osnovni oblik izjave o testnom slučaju
• Savjeti za pisanje testova
  • • # 1) Neka bude jednostavno, ali ne previše jednostavno; čine ga složenim, ali ne previše složenim:
    • # 2) Nakon dokumentiranja testnih slučajeva, pregledajte jednom kao Tester:
    • # 3) Vezani i olakšajte testere:
    • # 4) Budite suradnik:
    • # 5) Nikad ne zaboravite krajnjeg korisnika:
• Kako postići izvrsnost u dokumentaciji testnog slučaja
  • Korisni savjeti i trikovi
    • # 1) Je li vaš testni dokument u dobrom obliku?
    • # 2) Ne zaboravite pokriti negativne slučajeve
    • # 3) Imajte atomske ispitne korake
    • # 4) Dajte prioritet testovima
    • # 5) Sekvenca je važna
    • # 6) U komentare dodajte vremensku oznaku i naziv testera
    • # 7) Uključite detalje o pregledniku
    • # 8) U dokumentu držite dva odvojena lista - 'Bug' i 'Summary'
• Kako NE pisati testove
  • 3 najčešća problema u test slučajevima
    • # 1) Složeni koraci
    • # 2) Ponašanje aplikacije uzima se kao očekivano ponašanje
    • # 3) Više uvjeta u jednom slučaju
• Kako poboljšati učinkovitost testnih slučajeva
  • Zbirka dokumenata za probno pisanje
  • Pravi primjer
  • Dokument o testnom slučaju
  • Probno prikupljanje podataka
• Važnost standardizacije test slučajeva
  • Razlozi ponovne upotrebe testnih slučajeva
  • Što je standardni test u web testiranju?
  • Zaključak
  • Preporučena literatura

Što je test slučaj i kako napisati test slučajeve?

Pisanje učinkovitih slučajeva je vještina. A možete to naučiti iz iskustva i znanja aplikacije koja se testira.

Osnovne upute o pisanju testova potražite u sljedećem videozapisu:

Gore navedeni resursi trebali bi nam dati osnove postupka pisanja testa.

Razine postupka pisanja testa:

• Razina 1: Na ovoj ćete razini napisati osnovni slučajevi iz dostupne specifikacije i korisničku dokumentaciju.
• Razina 2: Ovo je praktična faza u kojima slučajevi pisanja ovise o stvarnom funkcionalnom i sustavnom tijeku aplikacije.
• Razina 3: Ovo je faza u kojoj ćete grupirati neke slučajeve i napiši postupak ispitivanja . Postupak ispitivanja nije ništa drugo do skupina malih slučajeva, možda najviše 10.
• Razina 4: Automatizacija projekta. To će minimizirati ljudsku interakciju sa sustavom i stoga se QA može usredotočiti na trenutno ažurirane funkcionalnosti za testiranje, umjesto da ostane zauzet testiranjem regresije.

Zašto pišemo testove?

Osnovni cilj pisanja slučajeva je za provjeru pokrivenosti aplikacije testom.

Ako radite u bilo kojoj CMMi organizaciji, tada se strože slijede standardi ispitivanja. Pisanje slučajeva donosi neku vrstu standardizacije i minimizira ad hoc pristup u testiranju.

Kako napisati test slučajeve?

Polja:

• ID testnog slučaja
• Jedinica za testiranje: Što treba provjeriti?
• Pretpostavke
• Podaci o ispitivanju: Varijable i njihove vrijednosti
• Koraci koje treba izvršiti
• očekivani rezultat
• Stvarni rezultat
• Prođi / ne uspije
• Komentari

Osnovni oblik izjave o testnom slučaju

Potvrdite
Koristeći (naziv alata, naziv oznake, dijalog itd.)
S (Uvjeti)
Do (što se vraća, pokazuje, demonstrira)

Potvrdite: Koristi se kao prva riječ izjave o ispitivanju.
Korištenje: Da bi se identificiralo što se testira. Ovdje možete upotrijebiti 'ulazak' ili 'odabir' umjesto upotrebe, ovisno o situaciji.

Za bilo koju aplikaciju morate pokriti sve vrste testova kao što su:

• Funkcionalni slučajevi
• Negativni slučajevi
• Slučajevi granične vrijednosti

Dok pišem ove sve svoje TC-ovi bi trebali biti jednostavni i lako razumljivi .

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

Savjeti za pisanje testova

Jedna od najčešćih i glavnih aktivnosti ispitivača softvera (osoba SQA / SQC) je pisanje testnih scenarija i slučajeva.

Postoje neki važni i kritični čimbenici koji su povezani s ovom glavnom aktivnošću. Prvo nam dajte pogled iz ptičje perspektive na te čimbenike.

Važni čimbenici koji uključuju proces pisanja:

a) TC-ovi su skloni redovitoj reviziji i ažuriranju:

Živimo u svijetu koji se neprestano mijenja, a isto vrijedi i za softver. Promjene softverskih zahtjeva izravno utječu na slučajeve. Kad god se zahtjevi promijene, TC-ove treba ažurirati.

Ipak, nije samo promjena zahtjeva ta koja može prouzročiti reviziju i ažuriranje TC-a. Tijekom izvršavanja TC-a, u umu se pojavljuju mnoge ideje i mogu se identificirati mnogi poduvjeti jednog TC-a. Sve to uzrokuje ažuriranje TC-a, a ponekad dovodi i do dodavanja novih TC-a.

Štoviše, tijekom regresijskog ispitivanja, nekoliko popravaka i / ili mreškanja zahtijeva revidirane ili nove TC-e.

b) TC-i su skloni distribuciji među ispitivačima koji će izvršiti sljedeće:

Naravno, teško da postoji takva situacija u kojoj jedan ispitivač izvršava sve TC-ove. Obično postoji nekoliko testera koji testiraju različite module jedne aplikacije. Dakle, TC-i su podijeljeni između ispitivača prema njihovim područjima aplikacije koja se ispituje.

Neke TC-ove koji su povezani s integracijom aplikacije može izvršiti više testera, dok druge TC-ove može izvršiti samo jedan ispitivač.

c) TC-i skloni su grupiranju i grupiranju:

Uobičajeno je i uobičajeno da TC koji pripadaju jednom testnom scenariju obično zahtijevaju njihovo izvršavanje u nekom određenom slijedu ili u obliku grupe. Možda postoje određeni preduvjeti za TC koji zahtijevaju izvršenje ostalih TC-a prije samog pokretanja.

Slično tome, prema poslovnoj logici AUT-a, jedan TC može doprinijeti nekoliko uvjeta ispitivanja, a jedan uvjet ispitivanja može se sastojati od više TC-a.

d) TC imaju tendenciju međuovisnosti:

Ovo je također zanimljivo i važno ponašanje TC-a koji označava da mogu biti međusobno neovisni. Od srednjih do velikih aplikacija sa složenom poslovnom logikom, ova je tendencija vidljivija.

Najjasnije područje bilo koje aplikacije gdje se ovo ponašanje definitivno može uočiti jest interoperabilnost između različitih modula iste ili čak različitih aplikacija. Jednostavno rečeno, gdje god su različiti moduli pojedinačne aplikacije ili više aplikacija međusobno ovisni, isto se ponašanje odražava i na TC-ove.

e) TC-ovi su skloni distribuciji među programerima (posebno u razvojnom okruženju temeljenom na testovima):

Važna činjenica o TC-ima je da ih ispitivači ne smiju koristiti samo. U normalnom slučaju, kada su programeri pod ispravkom programske pogreške, oni neizravno koriste TC za rješavanje problema. Slično tome, ako se slijedi testni razvoj, tada programeri izravno koriste TC-ove kako bi izgradili svoju logiku i pokrili sve scenarije u svom kodu kojima se obraćaju TC-ovi.

Savjeti za pisanje učinkovitih testova:

Imajući na umu gornjih 5 čimbenika, evo nekoliko savjeta za pisanje učinkovitih TC-a.

Počnimo!!!

# 1) Neka bude jednostavno, ali ne previše jednostavno; čine ga složenim, ali ne previše složenim:

Ova se izjava čini paradoksalnom. Ali, obećavam da nije tako. Držite sve korake TC-a atomskim i preciznim. Spomenite korake s točnim redoslijedom i ispravnim mapiranjem do očekivanih rezultata. Test slučaj trebao bi biti samorazumljiv i lak za razumijevanje. To je ono što želim učiniti jednostavnim.

Sada to učiniti kompleksnim sredstvom znači integrirati ga s Planom ispitivanja i drugim TC-ima. Pogledajte ostale TC-ove, relevantne artefakte, GUI-je itd. Gdje i kada je to potrebno. Ali, učinite to uravnoteženo. Nemojte izrađivati ​​testere za pomicanje naprijed-natrag na hrpi dokumenata radi dovršavanja jednog scenarija ispitivanja.

S druge strane, nemojte dopustiti da ispitivač dokumentira ove TC-ove na vrlo kompaktan način. Dok pišete TC-ove, uvijek imajte na umu da ćete ih vi ili netko drugi morati revidirati i ažurirati.

# 2) Nakon dokumentiranja testnih slučajeva, pregledajte jednom kao Tester:

Nikad nemojte misliti da je posao završen nakon što napišete zadnji TC testnog scenarija. Idite na početak i jednom pregledajte sve TC-ove, ali ne uz razmišljanje pisca TC-a ili planera testiranja. Pregledajte sve TC-ove s pameti ispitivača. Razmislite racionalno i pokušajte pokrenuti svoje TC-ove.

Procijenite sve korake i provjerite jeste li ih jasno spomenuli na razumljiv način i jesu li očekivani rezultati u skladu s tim koracima.

Osigurajte da podaci ispitivanja navedeno u TC-ima izvedivo je ne samo za stvarne testere, već je i prema stvarnom okruženju. Osigurajte da među TC-ima ne postoji sukob ovisnosti i provjerite jesu li sve reference na druge TC-ove / artefakte / GUI-jeve točne. Inače, testeri mogu biti u velikim problemima.

# 3) Vezani i olakšajte testere:

Ne ostavljajte podatke o ispitivanju na testerima. Dajte im niz ulaza, posebno tamo gdje treba izvršiti izračune ili ponašanje aplikacije ovisi o ulazima. Možete im dopustiti da odluče o vrijednostima testnih podataka, ali nikada im ne dajte slobodu da sami odaberu testne podatke.

Budući da namjerno ili nenamjerno mogu ponovno koristiti iste testne podatke, a neki važni testni podaci mogu se zanemariti tijekom izvršavanja TC-a.

Omogućite testerima jednostavnost organiziranjem TC-a prema kategorijama testiranja i povezanim područjima aplikacije. Jasno, uputite i spomenite koji su TC-ovi međusobno ovisni i / ili skupni. Isto tako, izričito naznačite koji su TC-i neovisni i izolirani kako bi ispitivač mogao u skladu s tim upravljati svojom ukupnom aktivnošću.

U ovom trenutku možda će vas zanimati čitanje o analizi granične vrijednosti koja je strategija dizajniranja test slučajeva koja se koristi u testiranju crnih kutija. Klik ovdje znati više o tome.

# 4) Budite suradnik:

Nikad ne prihvaćajte FS ili projektni dokument takav kakav je. Vaš posao nije samo proći kroz FS i identificirati testne scenarije. Budući da ste QA resurs, nikada se nemojte ustručavati dati svoj doprinos poslu i davati prijedloge ako smatrate da se nešto može poboljšati u aplikaciji.

kako instalirati .bin datoteku

Predložite i programerima, posebno u razvojnom okruženju vođenom TC-om. Predložite padajuće popise, kontrole kalendara, popis za odabir, radio gumbe, značajnije poruke, upozorenja, upute, poboljšanja u vezi s upotrebljivošću itd.

Budući da ste QA, nemojte samo testirati, već napravite razliku!

# 5) Nikad ne zaboravite krajnjeg korisnika:

Najvažniji dionik je 'Krajnji korisnik' koji će konačno upotrijebiti aplikaciju. Zato ga nikada ne zaboravite u bilo kojoj fazi pisanja TC-a. Zapravo, krajnjeg korisnika ne treba ignorirati ni u jednoj fazi tijekom SDLC-a. Ipak, moj dosadašnji naglasak samo je povezan s mojom temom.

Stoga, tijekom identifikacije testnih scenarija, nikada ne previdite one slučajeve koje će korisnik uglavnom koristiti ili slučajeve koji su kritični za poslovanje, čak i ako se rjeđe koriste. Budite na mjestu krajnjeg korisnika, a zatim prođite kroz sve TC-ove i prosudite praktičnu vrijednost izvršavanja svih vaših dokumentiranih TC-a.

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

Kako postići izvrsnost u dokumentaciji testnog slučaja

Budući da ste ispitivač softvera, zasigurno ćete se složiti sa mnom da je stvaranje savršenog ispitnog dokumenta zaista izazovan zadatak.

Uvijek ostavljamo malo prostora za poboljšanje u našem Dokumentacija za testni slučaj . Ponekad nismo u mogućnosti pružiti 100% pokrivenost testom putem TC-a, a ponekad predložak testa nije na razini ili nam nedostaje pružanje dobre čitljivosti i jasnoće našim testovima.

Kao ispitivač, kad god se od vas zatraži da napišete testnu dokumentaciju, nemojte samo krenuti ad-hoc. Vrlo je važno dobro razumjeti svrhu pisanja testnih slučajeva prije nego što počnete raditi na procesu dokumentacije.

Testovi bi uvijek trebali biti jasni i lucidni. Trebali bi biti napisani na način koji ispititelju olakšava provođenje cjelovitog ispitivanja slijedeći korake definirane u svakom od testova.

Uz to, dokument o testnom slučaju trebao bi sadržavati onoliko slučajeva koliko je potrebno da se pruže cjeloviti podaci pokrivenost testom . Na primjer , trebali biste pokušati pokriti testiranje svih mogućih scenarija koji se mogu dogoditi unutar vaše softverske aplikacije.

Imajući na umu gornje točke, dopustite mi da vas sada vodim kroz obilazak o tome kako postići izvrsnost u testnoj dokumentaciji.

Korisni savjeti i trikovi

Evo, pružit ću vam neke korisne smjernice koje vam mogu pružiti prednost u ispitnoj dokumentaciji od ostalih.

# 1) Je li vaš testni dokument u dobrom obliku?

Najbolji i jednostavan način organizacije testnog dokumenta je razdvajanjem na mnogo korisnih odjeljaka. Podijelite cjelokupno testiranje na više scenarija ispitivanja. Zatim podijelite svaki scenarij u više testova. Na kraju, podijelite svaki slučaj u više koraka ispitivanja.

Ako koristite Excel, dokumentirajte svaki testni slučaj na zasebnom listu radne knjige u kojem svaki testni slučaj opisuje jedan cjelovit tijek ispitivanja.

# 2) Ne zaboravite pokriti negativne slučajeve

Kao ispitivač softvera, morate razmišljati izvan okvira i nacrtati sve mogućnosti s kojima se vaša aplikacija susreće. Mi kao testeri moramo provjeriti treba li zaustaviti i prijaviti bilo koji neautentičan pokušaj ulaska u softver ili bilo koji nevaljani podatak koji teče preko aplikacije.

Stoga je negativan slučaj jednako važan kao i pozitivan slučaj. Obavezno se pobrinite za svaki scenarij koji imate dva testna slučaja - jedan pozitivan i jedan negativan . Pozitivni treba pokriti namjeravani ili normalni protok, a negativni treba pokriti neželjeni ili iznimni protok.

# 3) Imajte atomske ispitne korake

Svaki testni korak trebao bi biti atomski. Ne bi trebalo biti daljnjih potkoraka. Što je testni korak jednostavniji i jasniji, to bi bilo lakše nastaviti s testiranjem.

# 4) Dajte prioritet testovima

Često imamo stroge vremenske rokove kako bismo završili testiranje aplikacije. U ovom slučaju možemo propustiti testiranje nekih važnih funkcionalnosti i aspekata softvera. Da biste to izbjegli, trebali biste označiti prioritet sa svakim testom dok ga dokumentirate.

Za definiranje prioriteta testa možete koristiti bilo koje kodiranje. Općenito je bolje koristiti bilo koju od 3 razine, visoka, srednja i niska , ili 1, 50 i 100. Dakle, kada imate strogu vremensku liniju, prvo biste trebali ispuniti sve testove visokog prioriteta, a zatim prijeći na testove srednjeg i niskog prioriteta.

Na primjer - za web mjesto za kupnju provjera odbijanja pristupa zbog nevaljanog pokušaja prijave u aplikaciju može biti slučaj visokog prioriteta, provjera prikaza relevantnih proizvoda na korisničkom zaslonu može biti slučaj srednjeg prioriteta i provjera boje teksta prikazanog na gumbi na zaslonu mogu biti test niskog prioriteta.

# 5) Sekvenca je važna

Provjerite je li slijed koraka u testu apsolutno točan. Pogrešan slijed koraka može dovesti do zabune. Po mogućnosti, koraci bi također trebali definirati čitav slijed od ulaska u aplikaciju do izlaska iz aplikacije za određeni scenarij koji se testira.

# 6) U komentare dodajte vremensku oznaku i naziv testera

Možda postoji slučaj kada testirate aplikaciju, netko vrši izmjene paralelno s istom aplikacijom ili netko može ažurirati aplikaciju nakon završetka testiranja. To dovodi do situacije u kojoj se rezultati testa mogu mijenjati s vremenom.

Dakle, uvijek je bolje dodati vremensku oznaku s imenom testera u komentare testiranja kako bi se rezultat testa (prošao ili ne uspio) mogao pripisati stanju aplikacije u to određeno vrijeme. Alternativno, možete dobiti Datum izvršenja ’, Zasebno dodan u testni slučaj koji će izričito identificirati vremensku oznaku testa.

# 7) Uključite detalje o pregledniku

Kao što znate, ako se radi o web aplikaciji, rezultati ispitivanja mogu se razlikovati ovisno o pregledniku na kojem se test provodi. Da biste olakšali ostalim testerima, programerima ili onima koji pregledavaju test dokument, dodajte slučaju i naziv preglednika u slučaj kako bi se kvar mogao lako replicirati.

# 8) U dokumentu držite dva odvojena lista - 'Bug' i 'Summary'

Ako dokumentirate u excelu, prva dva lista radne knjige trebala bi biti Sažetak i Greške. List sažetka trebao bi sažeti scenarij ispitivanja, a list Bugs trebao bi navesti sve probleme s kojima se susreće tijekom testiranja. Značaj dodavanja ova dva lista je u tome što će čitatelju / korisniku dokumenta pružiti jasno razumijevanje ispitivanja.

Dakle, kad je vrijeme ograničeno, ova se dva lista mogu pokazati vrlo korisnima u pružanju pregleda ispitivanja.

Ispitni dokument trebao bi pružiti najbolje moguće ispitivanje, izvrsnu čitljivost i trebao bi slijediti jedan standardni format.

Izvrsnost u testnoj dokumentaciji možemo postići samo imajući na umu nekoliko bitnih savjeta kao organizaciju dokumenta testnog slučaja, davanje prioriteta TC-ima, postavljanje svega u pravilnom slijedu, uključujući sve obavezne detalje za izvršenje TC-a, te pružanje jasnih i lucidnih koraka ispitivanja, itd. kao što je gore spomenuto.

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

Kako NE pisati testove

Većinu svog vremena provodimo pišući ih, pregledavajući, izvršavajući ili održavajući. Prilično je žalosno da su testovi ujedno i oni najčešće skloni pogreškama. Razlike u razumijevanju, praksi testiranja organizacije, nedostatku vremena itd., Neki su od razloga zašto često vidimo testove koji ostavljaju mnogo želja.

Na našoj web stranici ima puno članaka na ovu temu, ali ovdje ćemo vidjeti Kako NE pisati test slučajeve - nekoliko savjeta koji će vam pomoći u stvaranju prepoznatljivih, kvalitetnih i učinkovitih testova.

Čitajmo dalje i imajte na umu da su ovi savjeti i za nove i za iskusne testere.

3 najčešća problema u test slučajevima

1. Složeni koraci
2. Ponašanje aplikacije uzima se kao očekivano ponašanje
3. Više uvjeta u jednom slučaju

To troje mora biti na mom vrhu 3 liste uobičajenih problema u procesu pisanja testa.

Zanimljivo je da se to događa i s novim i s iskusnim testerima, a mi jednostavno nastavljamo slijediti iste pogrešne procese, ne shvaćajući da nekoliko jednostavnih mjera stvari može lako popraviti.

Idemo na to i detaljno razgovarajte o svakom:

# 1) Složeni koraci

Prije svega, što je složeni korak?

Na primjer, dajete upute od točke A do točke B: ako kažete da 'idite na mjesto XYZ, a zatim na ABC', ovo neće imati puno smisla, jer ovdje se nalazimo kako razmišljamo - 'Kako da doći do XYZ-a na prvom mjestu '- umjesto toga započeti s' Skrenite lijevo odavde i idite 1 milju, a zatim skrenite desno na Rd. broj 11 koji dolazi na XYZ ”mogao bi postići bolje rezultate.

Potpuno ista pravila vrijede i za testove i njihove korake.

Na primjer Pišem test za Amazon.com - naručite bilo koji proizvod.

Slijede moji koraci za testiranje (Napomena: Pišem samo korake, a ne sve ostale dijelove testa, poput očekivanog rezultata itd.)

do . Pokrenite Amazon.com
b . Potražite proizvod unosom ključne riječi / naziva proizvoda u polje 'Search' na vrhu zaslona.
c . Iz prikazanih rezultata pretraživanja odaberite prvog.
d . Na stranici s pojedinostima o proizvodu kliknite Dodaj u košaricu.
je . Plaćanje i plaćanje.
f . Provjerite stranicu za potvrdu narudžbe.

Sada, možete li prepoznati što je od toga složeni korak? Desni korak (e)

Imajte na umu da se testovi uvijek odnose na 'Kako' testirati, pa je važno da u svoj test upišete točne korake 'Kako odjaviti i platiti'.

Stoga je gornji slučaj učinkovitiji kada se napiše na sljedeći način:

do . Pokrenite Amazon.com
b . Potražite proizvod unosom ključne riječi / naziva proizvoda u polje 'Search' na vrhu zaslona.
c . Iz prikazanih rezultata pretraživanja odaberite prvog.
d . Na stranici s pojedinostima o proizvodu kliknite Dodaj u košaricu.
je . Kliknite na Checkout na stranici košarice.
f . Unesite podatke o CC-u, podatke o pošiljci i naplati.
g . Kliknite Checkout.
h . Provjerite stranicu za potvrdu narudžbe.

Stoga je složeni korak onaj koji se može rastaviti na nekoliko pojedinačnih koraka. Sljedeći put kad budemo pisali testove, pripazimo na ovaj dio i siguran sam da ćete se složiti sa mnom da to radimo češće nego što mislimo.

# 2) Ponašanje aplikacije uzima se kao očekivano ponašanje

Sve više projekata mora se nositi s ovom situacijom ovih dana.

Nedostatak dokumentacije, ekstremno programiranje, brzi razvojni ciklusi rijetki su razlozi koji nas prisiljavaju da se oslonimo na aplikaciju (starija verzija ili tako nešto) ili za pisanje testova ili za samo testiranje. Kao i uvijek, ovo je dokazana loša praksa - ne uvijek stvarno.

Bezopasno je sve dok držite otvoren um i držite se očekivanja da bi - 'AUT mogao biti manjkav'. Samo kad ne mislite da jest, stvari funkcioniraju loše. Kao i uvijek, pustit ćemo primjere da govore.

Ako je sljedeća stranica za koju pišete / dizajnirate korake ispitivanja:

Slučaj 1:

Ako su koraci za moj testni slučaj sljedeći:

1. Pokrenite web mjesto za kupnju.
2. Kliknite Dostava i povratak - Očekivani rezultat: Stranica za otpremu i povratak prikazuje se s 'Stavite svoje podatke ovdje' i gumbom 'Nastavi'.

To je onda netočno.

Slučaj 2:

1. Pokrenite web mjesto za kupnju.
2. Kliknite Dostava i povratak.
3. U tekstualni okvir 'Unesite narudžbu' koji se nalazi na ovom zaslonu unesite broj narudžbe.
4. Kliknite Nastavi - Očekivani rezultat: Prikazuju se detalji narudžbe vezane za otpremu i povrat.

Slučaj 2 je bolji test, jer iako se referentna aplikacija ponaša pogrešno, mi je uzimamo samo kao smjernicu, radimo daljnja istraživanja i zapisujemo očekivano ponašanje prema predviđenoj ispravnoj funkcionalnosti.

Poanta: Aplikacija kao referenca brzi je prečac, ali dolazi sa svojim opasnostima. Sve dok smo pažljivi i kritični, to daje nevjerojatne rezultate.

# 3) Više uvjeta u jednom slučaju

Još jednom, učimo od Primjer .

Pogledajte dolje navedene korake ispitivanja: Slijede koraci ispitivanja unutar jednog testa za funkciju prijave.

a. Unesite važeće podatke i kliknite Pošalji.
b. Ostavite polje Korisničko ime prazno. Kliknite Pošalji.
c. Ostavite polje za lozinku praznim i kliknite Pošalji.
d. Odaberite već prijavljeno korisničko ime / lozinku i kliknite Pošalji.

koji je najbolji besplatni program za preuzimanje glazbe

Ono što su morala biti 4 različita slučaja kombinira se u jedan. Možda mislite - Što nije u redu s tim? Štedi se puno dokumentacije, a ono što mogu učiniti za 4, radim za 1, nije li sjajno? Pa, ne baš. Razlozi?

Nastavi čitati:

• Što ako jedan od uvjeta ne uspije - cijeli test moramo označiti kao 'neuspjeli'. Ako cijeli slučaj označimo kao 'nije uspio', znači da sva 4 uvjeta ne rade, što zapravo nije istina.
• Testovi moraju imati protok. Od preduvjeta do koraka 1 i svih koraka. Ako slijedim ovaj slučaj, u koraku (a), ako bude uspješan, prijavit ću se na stranicu na kojoj opcija 'prijava' više nije dostupna. Dakle, kad dođem do koraka (b) - gdje će ispitivač unijeti korisničko ime? Vidite, protok je slomljen.

Stoga, napisati modularne testove . Zvuči kao puno posla, ali sve što trebate je odvojiti stvari i koristiti naše najbolje prijatelje Ctrl + C i Ctrl + V da rade za nas. :)

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

Kako poboljšati učinkovitost testnih slučajeva

Ispitivači softvera trebali bi pisati svoje testove iz ranije faze životnog ciklusa razvoja softvera, najbolje tijekom faze softverskih zahtjeva.

Voditelj ispitivanja ili QA voditelj trebali bi prikupiti i pripremiti maksimalno moguće dokumente prema donjem popisu.

Zbirka dokumenata za probno pisanje

# 1) Dokument o korisničkim zahtjevima

To je dokument koji navodi poslovni proces, korisničke profile, korisničko okruženje, interakciju s drugim sustavima, zamjenu postojećih sustava, funkcionalne zahtjeve, nefunkcionalne zahtjeve, zahtjeve za licenciranje i instalaciju, zahtjeve za izvedbu, sigurnosne zahtjeve, upotrebljivost i istodobne zahtjeve itd. .,

# 2) Dokument o poslovnoj uporabi

Ovaj dokument detaljno opisuje slučaj upotrebe scenarij funkcionalnih zahtjeva iz poslovne perspektive. Ovaj dokument pokriva poslovne aktere (ili sustav), ciljeve, preduvjete, post-uvjete, osnovni protok, zamjenski tok, opcije, iznimke svakog poslovnog toka sustava prema zahtjevima.

# 3) Dokument o funkcionalnim zahtjevima

Ovaj dokument detaljno opisuje funkcionalne zahtjeve svake značajke sustava prema zahtjevima.

Dokument o funkcionalnim zahtjevima obično služi kao zajedničko spremište kako za razvojni i ispitni tim, tako i za dionike projekta, uključujući kupce za preuzete (ponekad zamrznute) zahtjeve, što bi trebalo tretirati kao najvažniji dokument za bilo koji razvoj softvera.

# 4) Plan projektnog softvera (po izboru)

Dokument koji opisuje detalje projekta, ciljeve, prioritete, prekretnice, aktivnosti, organizacijsku strukturu, strategiju, praćenje napretka, analizu rizika, pretpostavke, ovisnosti, ograničenja, zahtjeve za obukom, odgovornosti klijenta, raspored projekata itd.,

# 5) QA / plan ispitivanja

Ovaj dokument detaljno opisuje sustav upravljanja kvalitetom, standarde dokumentacije, mehanizam kontrole promjena, kritične module i funkcionalnosti, sustav upravljanja konfiguracijom, planove ispitivanja, praćenje kvara, kriterije prihvaćanja itd.

The plan ispitivanja dokument se koristi za identifikaciju značajki koje će se testirati, značajki koje se ne testiraju, raspodjelu timskog tima i njihovo sučelje, zahtjeve za resursima, raspored testiranja, pisanje testa, pokrivenost testom, isporuke testova, preduvjet za izvršavanje testa, izvještavanje o greškama i praćenje mehanizam, mjerni podaci ispitivanja itd.,

Pravi primjer

Pogledajmo kako učinkovito napisati test slučajeve za poznati i jednostavni zaslon ‘Prijava’ prema donjoj slici. The pristup ispitivanju bit će gotovo isti čak i za složene zaslone s više informacija i kritičnim značajkama.

# 1) Prvi pristup za bilo koji postupak test slučaja bit će dobivanje prototipa zaslona (ili žičanih okvira) kao gore, ako je dostupan. To možda nije dostupno za neke od funkcionalnosti i ovisi o kritičnosti dizajniranja prototipa u ranijim fazama razvoja.

Ali, ako je SRS Dokument (Specifikacija softverskih zahtjeva) je dostupan za projekt, većinu prototipova zaslona razvio je projektni tim. Ovakav zaslon pojednostavljuje posao testera i povećava učinkovitost testova.

#dva) Dalje, specifikacije funkcionalnih zahtjeva . Ovisi o procesu organizacije, bit će dostupan u paketu više dokumenata.

Dakle, odaberite najbolji dokument za pisanje slučajeva, bilo da se radi o dokumentu korisničkog zahtjeva ili specifikaciji funkcionalnih zahtjeva (ili čak o SRS dokumentu ako testni tim to može udobno razumjeti), što će dati cjelovit funkcionalni tok odabranog značajka za testiranje.

# 3) Jednom kada prototip zaslona i funkcionalne specifikacije budu postavljeni, ispitivač bi trebao početi pisati slučajeve prema sljedećem pristupu i kriterijima.

• UI testovi :Kontrole / polja koja su vidljiva korisniku. Za značajku koja se ispituje dostupne su statičke i dinamičke kontrole. Na primjer, na gornjem zaslonu za prijavu tekstovi 'Korisničko ime i lozinka' statična su polja koja ne zahtijevaju korisničku interakciju, samo za prikaz teksta.

• Funkcionalni slučajevi :S druge strane, gumb za prijavu i hiperveze (Zaboravili ste lozinku? & Registracija) su dinamična polja koja zahtijevaju korisničku interakciju klikom na kontrole, a nakon toga će se nešto poduzeti.

• Slučajevi baze podataka :Jednom kada korisnik unese korisničko ime i lozinku, testovi se mogu napisati kako bi se provjerilo pripadajuću bazu podataka, jesu li korisničko ime i lozinka provjereni u pravoj bazi podataka i tablici, a također korisnik ima dozvolu za prijavu u testni program.
  

• Procesna ispitivanja :To je povezano s postupkom (a ne s radnjama povezanim s vidljivim kontrolama dostupnim na zaslonu) povezanim sa značajkom i funkcionalnošću. Na primjer, klik na vezu Zaboravili ste lozinku na gornjem ekranu uzorka može korisniku poslati e-poštu. Dakle, možda e-poštu treba testirati za pravilan postupak i potvrdu.

4) Napokon, zadržite ' BAOE mantra ', sredstva i) Osnovni protok ii) Alternativni tok iii) Mogućnosti i iv) Iznimke za potpuno pokrivanje funkcionalnog toka i značajke koja se ispituje. Svaki koncept treba primijeniti na pozitivne i negativne testove.

Na primjer, pogledajmo jednostavan BAOE pristup za gornji uzorak zaslona za prijavu.

• Osnovni protok: Unesite URL put prijave u bilo koji preglednik i unesite potrebne podatke i prijavite se na aplikaciju.
• Alternativni tok: Instalirajte aplikaciju na mobilni uređaj i unesite potrebne podatke i prijavite se na aplikaciju.
• Opcije: Koje su opcije dostupne za isti zaslon za prijavu? Na primjer, nakon prijave u aplikaciju, klikom na 'Odjava' može se pojaviti isti zaslon ili ako je isteklo vrijeme čekanja ili sesije, korisnik može doći na zaslon za prijavu.
• Iznimke: Koje su iznimke ako su moji testovi negativni? Na primjer, ako se na zaslon za prijavu unesu pogrešne vjerodajnice, hoće li korisnik dobiti poruku o pogrešci ili nije povezana nikakva radnja.

Sa svim ovim informacijama u rukama, započnimo s pisanjem TC-a za zaslon za prijavu, u formatu s potpunim pokrićem i sljedivošću te s detaljnim informacijama. Logični slijed i numeriranje identificiranja „ ID testnog slučaja bit će vrlo korisno za brzu identifikaciju povijesti izvršavanja test slučajeva.

Također pročitajte=> 180+ uzoraka spremnih za upotrebu testnih slučajeva za web i desktop aplikacije.

Dokument o testnom slučaju

Bilješka : Ispitni stupci nisu ograničeni na donji uzorak ispitnog dokumenta, koji se može održavati u excel listu kako bi imao onoliko stupaca koliko je potrebno za cjelovitu matricu sljedivosti, naime, prioritet, svrhu testiranja, vrstu testiranja, mjesto snimke zaslona pogreške itd.,

Također pročitajte=> Uzorak predloška test primjera s primjerima.

Radi jednostavnosti i čitljivosti ovog dokumenta, dolje ćemo detaljno napisati korake za reprodukciju, očekivano i stvarno ponašanje testova za zaslon za prijavu.

Bilješka : Dodajte stupac Stvarno ponašanje na kraju ovog predloška.

Probno prikupljanje podataka

Kada se piše testni slučaj, najvažniji zadatak bilo kojeg ispitivača je prikupljanje testnih podataka. Mnogi su ispitanici ovu aktivnost preskočili i previdjeli s pretpostavkom da se test slučajevi mogu izvršiti s nekim uzorcima podataka ili lažnim podacima te da se mogu hraniti kada su podaci zaista potrebni. Ovo je kritična zabluda da se uzorkovanje podataka ili ulaznih podataka uma pamti u vrijeme izvršavanja testnih slučajeva.

Ako se podaci ne prikupljaju i ne ažuriraju u testnom dokumentu u vrijeme pisanja testova, ispitivač bi potrošio neobično više vremena za prikupljanje podataka u vrijeme izvođenja testa. Podatke o ispitivanju treba prikupljati i za pozitivne i za negativne slučajeve iz svih perspektiva funkcionalnog toka značajke. Dokument slučaja poslovne upotrebe vrlo je koristan u ovoj situaciji.

Nađite uzorak dokumenta s podacima o ispitivanju za gore napisane testove, što će zauzvrat biti od pomoći u tome koliko učinkovito možemo prikupiti podatke koji će nam olakšati posao u vrijeme izvođenja testa.

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

Važnost standardizacije test slučajeva

U ovom užurbanom svijetu nitko ne može ponavljati stvari iz dana u dan s istom razinom interesa i energije. Pogotovo mi nije strastveno ponavljati isti posao na poslu uvijek iznova. Volim upravljati stvarima i štedjeti vrijeme. Svatko u IT-u trebao bi biti takav.

Sve IT tvrtke izvršavaju različite vrste projekata. Ti se projekti mogu temeljiti na proizvodima ili uslugama. Od ovih projekata, većina ih radi oko web stranica i testiranje web stranica . Dobra vijest o tome je da sve web stranice imaju mnogo sličnosti. A ako su web stranice za istu domenu, imaju i nekoliko zajedničkih značajki.

Pitanje koje me uvijek zbunjuje je sljedeće: „Ako je većina aplikacija slična, na primjer: kao što su maloprodajne web lokacije, koje su već tisuću puta testirane,„ Zašto trebamo pisati test slučajeve za još jedno maloprodajno mjesto od nule? ' Neće li uštedjeti tonu vremena izvlačenjem postojećih testnih skripti koje su korištene za testiranje prethodnog maloprodajnog mjesta?

Svakako, možda ćemo morati napraviti neke male dorade, ali sveukupno je to lakše, učinkovitije, štedi vrijeme i novac, a time uvijek pomaže u održavanju visoke razine interesa testera. Tko voli više puta pisati, pregledavati i održavati iste testove, zar ne? Ponovna upotreba postojećih testova može to u velikoj mjeri riješiti, a i vaši će klijenti to smatrati pametnim i logičnim.

Tako sam logično počeo izvlačiti postojeće skripte iz sličnih web-projekata, unosio izmjene i izvršio brz pregled. Također sam upotrijebio kodiranje u boji kako bih prikazao izvršene promjene, tako da se recenzent može usredotočiti samo na dio koji je promijenjen.

Razlozi ponovne upotrebe testnih slučajeva

# 1) Većina funkcionalnih područja web stranice su gotovo prijava, registracija, dodavanje u košaricu, popis želja, naplata, opcije dostave, opcije plaćanja, sadržaj stranice proizvoda, nedavno pregledani, relevantni proizvodi, promotivni kodovi itd.

#dva) Većina projekata su samo poboljšanja ili promjene postojeće funkcionalnosti.

# 3) Sustavi za upravljanje sadržajem koji definiraju mjesta za prijenos slika statičkim i dinamičkim načinima također su uobičajeni za sve web stranice.

# 4) Maloprodajne web stranice imaju DOP Sustav (korisnička služba) također.

# 5) Backend sustav i skladišna aplikacija koja koristi JDA također se koriste na svim web stranicama.

# 6) Koncept kolačića, vremenskog ograničenja i sigurnosti također su uobičajeni.

# 7) Web projekti temelje se na promjenama zahtjeva.

# 8) The vrste ispitivanja potrebni su uobičajeni poput preglednika ispitivanje kompatibilnosti , ispitivanje performansi , sigurnosno ispitivanje

Vidite, puno je zajedničkog i sličnog.

Kad smo već rekli da je ponovna upotreba put, ponekad same modifikacije mogu ili ne moraju potrajati više ili manje vremena. Ponekad se može osjećati da je bolje početi od nule nego toliko modificirati.

To se lako može riješiti stvaranjem skupa standardnih testnih slučajeva za svaku uobičajenu funkcionalnost.

Što je standardni test u web testiranju?

• Stvorite cjelovite test slučajeve - korake, podatke, varijablu itd. To će osigurati da neslične podatke / varijablu jednostavno možete zamijeniti kada je potreban sličan testni slučaj.
• Kriteriji za ulaz i izlaz trebali bi biti pravilno definirani.
• Koraci koji se mogu mijenjati ili iskaz u koracima trebaju biti označeni drugom bojom za brzo pronalaženje i zamjenu.
• Jezik koji se koristi za izradu standardnog testnog slučaja trebao bi biti generički.
• Sve značajke svake web stranice trebaju biti obuhvaćene testnim slučajevima.
• Naziv test slučajeva trebao bi biti naziv funkcionalnosti ili značajke koju test slučaj pokriva. To će znatno olakšati pronalazak testnog slučaja iz skupa.
• Ako postoji osnovni ili standardni uzorak ili GUI datoteka ili snimka zaslona značajke, tada je treba priložiti s odgovarajućim koracima.

Koristeći gornje savjete možete stvoriti skup standardnih skripti i koristiti ih s malo ili potrebnim izmjenama za različite web stranice.

I ovi standardni testni slučajevi mogu se automatizirati, ali opet je fokusiranje na ponovnu upotrebu uvijek plus. Također, ako automatizacija temelji se na GUI-ju, ponovna upotreba skripti na više URL-ova ili web lokacija nešto je što osobno nikad nisam smatrao učinkovitim.

Korištenje standardnog skupa ručnih ispitnih slučajeva za različite web stranice s manjim izmjenama najbolji je način za testiranje web stranica. Sve što trebamo je stvoriti i održavati test slučajeve s odgovarajućim standardima i upotrebom.

Zaključak

Poboljšanje učinkovitosti testnih primjera nije jednostavno definiran pojam, već je vježba i može se postići sazrelim postupkom i redovnom praksom.

Testni tim ne bi se trebao umoriti od uključivanja u poboljšanje takvih zadataka jer je to najbolji alat za veća postignuća u svijetu kvalitete, što je dokazano u mnogim testnim organizacijama širom svijeta na kritičnim projektima i složenim aplikacijama.

Nadam se da ste stekli neizmjerno znanje o konceptu test slučajeva. Pazite na našu seriju vodiča da biste saznali više o test slučajevima i slobodno izrazite svoje misli u odjeljku za komentare u nastavku!

Sljedeći vodič

Preporučena literatura

• Funkcionalno ispitivanje vs nefunkcionalno testiranje
• Vodič za ispitivanje prenosivosti s praktičnim primjerima
• Vrste testiranja softvera: različite vrste ispitivanja s pojedinostima
• Najbolji alati za testiranje softvera 2021. (Alati za automatizaciju ispitivanja kvalitete)
• Alfa testiranje i beta testiranje (cjelovit vodič)
• Što je testiranje sustava - Vodič za krajnje početnike
• Uzorci ispitnih radova s ​​odgovorima na ISTQB testiranje
• Kako napisati tjedno izvješće o testiranju softvera