what is test scenario
Ovaj vodič objašnjava što je testni scenarij, zajedno s važnošću, provedbom, primjerima i predlošcima testnog scenarija:
Bilo koja softverska funkcionalnost / značajka koja se može testirati kaže se kao testni scenarij. Perspektiva krajnjeg korisnika uzima se u obzir tijekom pisanja bilo kojeg scenarija testa.
Ovaj vodič će vam pomoći u odgovoru na pitanja: zašto su potrebni test scenariji, kada su napisani test testovi i kako napisati test scenarije.
Što ćete naučiti:
Što je testni scenarij?
Razmotrimo hipotetičku situaciju: Postoji ogroman ocean. Morate putovati preko oceana s jedne na drugu obalu mora. Na primjer, od Mumbaija, morska obala Indije do Kolomba, obala Srilanke.
Način putovanja koji možete odabrati su:
(i) Zračni put: Letite za Colombo
(ii) Plovni putovi:Preferirajte brod koji putuje do Colomba
(iii) Željeznice:Vozite se vlakom do Srilanke
Sada za testne scenarije: Putovanje od obale Mumbaija do obale Colomba funkcionalnost je koja se treba testirati.
Testni scenariji uključuju:
- Putovanje zračnim putem,
- Putovanje plovnim putovima ili
- Putovanje željeznicom.
Ovi scenariji testiranja imat će test slučajeve.
Test slučajevi koji se mogu napisati za gornje scenarije testiranja uključuju:
Testni scenarij: Putovanje zračnim putem
Test slučajevi mogu uključivati scenarije poput:
- Let je prema zakazanom vremenu.
- Let nije prema zakazanom vremenu.
- Uslijedila je izvanredna situacija (obilne kiše i oluja).
Na isti se način za ostale preostale scenarije može napisati zaseban skup testnih slučajeva.
Sada ćemo prijeći na scenarije tehnoloških ispitivanja.
Sve što se može testirati je testni scenarij. Stoga možemo ustvrditi da bilo koja softverska funkcionalnost koja je na testiranju i koja se može podijeliti u više manjih funkcionalnosti može se nazvati ‘Test Scenarij’.
Prije isporuke bilo kojeg proizvoda klijentu, treba procijeniti i procijeniti kvalitetu proizvoda. Testni scenarij pomaže u procjeni funkcionalne kvalitete softverske aplikacije koja je u skladu sa svojim poslovnim zahtjevima.
Scenarij ispitivača postupak je u kojem ispitivač testira softversku aplikaciju iz perspektive krajnjeg korisnika. Učinak i kvaliteta softverske aplikacije temeljito se procjenjuju prije implementacije u proizvodno okruženje.
Važnost testnog scenarija
- Jedan testni scenarij može imati više „testnih slučajeva“. Može se zamisliti kao velika panoramska slika, a test slučajevi su mali dijelovi koji su važni za dovršavanje panorame.
- Izjava je u jednom retku i slučajevi ispitivanja sastoje se od detaljnog opisa za dovršavanje svrhe izjave o scenariju ispitivanja.
- Primjer:
Testni scenarij: Isplatite uslugu taksija.
Ovo će imati više testnih slučajeva kako je navedeno u nastavku:
(i) Način plaćanja: PayPal, Paytm, kreditna / debitna kartica.
(ii) Isplatagotovo je uspješno.
(iii) Uplata je neuspješna.
(iv) Isplatapostupak prekinut između.
(v) Ne mogu pristupiti načinima plaćanja.
(mi) Aplikacijaizmeđu se kvari.
- Test scenariji tako pomažu u procjeni softverske aplikacije prema stvarnim situacijama.
- Scenariji ispitivanja kada se utvrde, pomažu u razdvajanju opsega testiranja.
- Ova bifurkacija naziva se prioritetom koji pomaže u određivanju važnih funkcionalnosti softverske aplikacije.
- Prioritetno testiranje funkcionalnosti u velikoj mjeri pomaže u uspješnoj implementaciji softverske aplikacije.
- Kako se scenariji ispitivanja daju prioritet, najvažnije funkcije mogu se lako prepoznati i testirati na prioritetu. To osigurava da većina ključnih funkcija radi u redu i da se s njom povezane pogreške uredno uhvate i otklone.
- Scenariji ispitivanja određuju tijek poslovnog procesa softvera i stoga je moguće cjelovito testiranje aplikacije.
Razlika između scenarija ispitivanja i test slučaja
Testni scenarij | Ispitni slučajevi |
---|---|
Potrebna kratka dokumentacija. | Potrebna je detaljna dokumentacija. |
Testni scenarij je koncept. | Test slučajevi su rješenja za provjeru tog koncepta. |
Testni scenarij je funkcionalnost visoke razine. | Test slučajevi su detaljan postupak za testiranje funkcionalnosti visoke razine. |
Testni scenariji izvedeni su iz Zahtjeva / Priče korisnika. | Ispitni slučajevi izvedeni su iz scenarija ispitivanja. |
Scenarij testa je 'Koju funkcionalnost treba testirati' | Ispitni slučajevi su 'Kako testirati funkcionalnost'. |
Testni scenariji imaju više testnih slučajeva. | Testni slučaj može ili ne mora biti povezan s više testnih scenarija. |
Scenariji pojedinačnog ispitivanja nikada se ne mogu ponoviti. | Jedan testni slučaj može se koristiti više puta u različitim scenarijima. |
Za finaliziranje testnog scenarija potrebne su sesije mozga. | Potrebno je detaljno tehničko znanje softverske aplikacije |
Ušteda vremena kao detalji minute nisu potrebne. | Potrebno je vremena jer treba paziti na svaki minutni detalj. |
Troškovi održavanja su niski jer su potrebni resursi niski. | Troškovi održavanja visoki su jer su potrebni resursi visoki |
Zašto su scenariji testa neophodni?
Scenariji ispitivanja izvedeni su iz zahtjeva ili korisničkih priča.
- Uzmimo primjer testnog scenarija za rezervaciju kabine.
- Scenariji bi mogli biti poput mogućnosti rezervacije kabine, načini plaćanja, GPS praćenje, karta puta prikazana ispravno ili ne, detalji kabine i vozača prikazani ispravno ili ne, itd. Svi su navedeni u predlošku testnog scenarija.
- Sada pretpostavimo da je testni scenarij provjeriti jesu li lokacijske usluge uključene, ako nisu uključene, prikazati poruku 'Uključi lokacijske usluge'. Ovaj je scenarij propušten i nije naveden u predlošku testnih scenarija.
- Scenarij 'Lokacijske usluge' dovodi do drugih testnih scenarija povezanih s njim. To mogu biti:
- Lokacijska usluga je zasivljena.
- Usluga lokacije uključena je, ali nema interneta.
- Ograničenja za usluge lokacije.
- Prikazuje se pogrešno mjesto.
- Nedostaje jedan scenarij može značiti propuštanje mnogih drugih presudni scenariji ili test slučajevi . Ovo može imati sjajno negativan utjecaj tijekom implementacije softverske aplikacije. To rezultira velikim gubitkom sredstava (rokovi).
- Test scenariji u velikoj mjeri pomažu u izbjegavajući iscrpno testiranje . Osigurava testiranje svih ključnih i očekivanih poslovnih tokova, što dodatno pomaže na kraju do kraja testiranja aplikacije.
- To su uštede vremena. Također, nije potreban puno detaljan opis prema testnim slučajevima. Navodi se jednoslojni opis o tome što testirati.
- Scenariji ispitivanja napisani su nakon seanse mozga članova tima. Stoga je vjerojatnost propuštanja bilo kojeg scenarija (ključnog ili manjeg) minimalna. To se radi imajući na umu tehničke značajke i poslovni tok softverske aplikacije.
- Štoviše, scenarije testiranja može odobriti ili poslovni analitičar ili klijent ili obojica koji imaju izričito znanje o aplikaciji koja se testira.
Stoga su test scenariji neizostavni dio SDLC-a.
gdje mogu pronaći sigurnosni ključ
Provedba testnih scenarija
Pogledajmo implementaciju test scenarija ili kako napisati test scenarije-
- Formiraju se epski / poslovni zahtjevi.
- Primjer epike : Stvorite Gmail račun. Epsko može biti glavno obilježje aplikacije ili poslovnog zahtjeva.
- Epovi su podijeljeni u manje korisničke priče u sprintima.
- Priče korisnika izvedene su iz Epics-a. Ove korisničke priče moraju biti temeljne i odobrene od strane dionika.
- Scenariji ispitivanja izvedeni su iz korisničkih priča ili BRS-a (dokument poslovnog zahtjeva), SRS-a (dokument specifikacija zahtjeva sustava) ili FRS-a (dokument funkcionalnog zahtjeva) koji je finaliziran i pripremljen.
- Ispitivači pišu scenarije ispitivanja.
- Ove scenarije ispitivanja odobrava vođa tima, poslovni analitičar ili voditelj projekta, ovisno o organizaciji.
- Svaki testni scenarij mora biti vezan za barem jednu korisničku priču.
- Moraju se identificirati pozitivni i negativni scenariji ispitivanja.
- Priče korisnika sastoje se od Kriteriji prihvaćanja poput :
- Kriteriji prihvaćanja su popis uvjeta ili stanje namjere za zahtjevima kupca. Očekivanja kupca i nesporazumi uzimaju se u obzir prilikom pisanja kriterija prihvaćanja.
- Oni su jedinstveni za jednu korisničku priču i svaka korisnička priča mora imati barem jedan kriterij prihvaćanja koji bi trebao biti neovisno provjerljiv.
- Kriteriji prihvaćanja pomažu u određivanju koje su značajke obuhvaćene, a koje izvan dometa projekta. Ti bi kriteriji trebali uključivati funkcionalne, ali i nefunkcionalne značajke.
- Poslovni analitičari pišu kriterije prihvaćanja, a vlasnik proizvoda ih odobrava.
- Ili u nekim slučajevima vlasnik proizvoda može sam napisati kriterije.
- Scenariji ispitivanja mogu se dobiti iz kriterija prihvaćanja.
Primjeri scenarija ispitivanja
# 1) Testni scenariji za aplikaciju Kindle
Kindle je aplikacija koja svojim e-čitačima omogućuje pretraživanje e-knjiga na mreži, preuzimanje i kupnju. Amazon Kindle pruža čitaču e-knjiga stvarno iskustvo držanja knjige u ruci i čitanja. Čak je i okretanje stranica lijepo simulirano u aplikaciji.
Sada zabilježimo testne scenarije. ( Bilješka: Ograničeni scenariji navedeni su u nastavku kako biste dobili opću ideju za pisanje testnog scenarija. Iz njega može biti izvedeno više testnih slučajeva).
Testni scenariji # | Testni scenariji |
---|---|
7 | Provjerite radi li funkcija preuzimanja ispravno. |
1 | Provjerite pokreće li se aplikacija Kindle pravilno. |
dva | Provjerite je li razlučivost zaslona prilagođena različitim uređajima nakon pokretanja aplikacije. |
3 | Provjerite je li prikazani tekst čitljiv. |
4 | Provjerite rade li opcije zumiranja i smanjivanja. |
5 | Provjerite jesu li kompatibilne datoteke uvezene u aplikaciju Kindle čitljive. |
6 | Provjerite kapacitet pohrane aplikacije Kindle. |
8 | Provjerite radi li simulacija okretanja stranica ispravno |
9 | Provjerite kompatibilnost formata e-knjiga s aplikacijom Kindle. |
10 | Provjerite fontove koje podržava aplikacija Kindle. |
jedanaest | Provjerite trajanje baterije koju koristi aplikacija Kindle. |
12 | Provjerite izvedbu Kindle-a ovisno o mrežnoj povezanosti (Wi-Fi, 3G ili 4G). |
Iz svakog gore navedenog scenarija može se izvesti više testnih slučajeva.
# 2) Kriteriji prihvaćanja za Google dokumente
'Google dokumenti' internetska je aplikacija za stvaranje, uređivanje i dijeljenje word dokumenata, proračunskih tablica, dijapozitiva i obrazaca. Svim datotekama može se pristupiti putem interneta putem web preglednika koji ima internetsku vezu.
Stvoreni dokumenti mogu se dijeliti kao web stranica ili kao dokument spreman za ispis. Korisnik može postaviti ograničenja na to tko može pregledavati i uređivati dokumente. Različiti pojedinci s različitih zemljopisnih mjesta mogu zajednički dijeliti jedan dokument i raditi na njemu.
Ograničeni scenariji ispitivanja navedeni su u nastavku za opće razumijevanje. Scenariji detaljnog testiranja za Google dokumente mogu biti zasebna tema.
Kriteriji prihvatljivosti # | Kriteriji prihvatljivosti |
---|---|
7 | Više korisnika može raditi na jednom dokumentu. |
1 | Word, Tablice ili Obrasci mogu se uspješno otvoriti bez pogreške. |
dva | Predlošci su dostupni za dokumente, listove i dijapozitive. |
3 | Dostupni predlošci dostupni su korisnicima. |
4 | Predložak koji se koristi može se uređivati (npr. Fontovi, veličina fonta, dodavanje teksta, brisanje teksta, umetanje slajda). |
5 | Ako internetska veza privremeno nije dostupna, datoteka se može lokalno pohraniti i učitati prema dostupnosti internetske veze. |
6 | Promjene koje je napravilo više korisnika ne prepisuju se. |
8 | Završeni posao pohranjuje se ako se prilikom prijenosa datoteke izgubi internetska veza. |
9 | Ograničenja dijeljenja primjenjuju se ispravno. |
10 | Korisnici s ograničenjem prikaza ne mogu uređivati dokumente. |
jedanaest | Dokumenti se mogu objaviti na internetu za širu javnost. |
12 | Promjene na dokumentima spremaju se s vremenskim žigom i pojedinostima o autoru. |
Broj scenarija ispitivanja bit će višestruk i vrlo velik za Google dokumente. U takvim slučajevima općenito, dionici postavljaju i odobravaju samo kriterije prihvaćanja, a članovi tima rade na tim kriterijima prihvaćanja. Pisanje testnih slučajeva za test scenarije može biti iscrpan zadatak ogromnih aplikacija.
Ovi kriteriji prihvaćanja igraju glavnu ulogu u iterativnom planiranju procesa i nikada ih se ne smije previdjeti. Njihovim unaprijed definiranim i unaprijed izbjegava iznenađenja ili šokove na kraju sprinta ili izdanja
S obzirom preduvjet.
Kada učiniti akciju.
Zatim očekivani rezultat.
Formati Dani, Kada i Tada korisni su za određivanje kriterija prihvaćanja.
Primjer predloška scenarija testa
Upotrijebi ID priče # | ID scenarija testa # | Verzija # | Testni scenariji | Broj testnih slučajeva | Važnost |
---|---|---|---|---|---|
USID12.1 | TSID12.1.1 | Kin12.4 | Provjerite pokreće li se aplikacija Kindle pravilno. | 4 | Visoko |
USID12.1 | TSID12.1.2 | Kin12.4 | Provjerite kapacitet pohrane aplikacije Kindle. | 3 | Srednji |
Zaključak
U bilo kojem testiranju softvera razumijevanje i postavljanje scenarija ispitivanja vrlo je važan element. Kvaliteta softvera može se poboljšati postojanjem dobrih temelja za testne scenarije. Upotreba test slučajeva i scenarija testiranja često se mogu međusobno zamijeniti.
Međutim, pravilo palca glasi da se testni scenarij koristi za pisanje više testnih slučajeva ili možemo reći da su testni slučajevi izvedeni iz testnih scenarija. Dobro definirani scenariji ispitivanja osiguravaju kvalitetan softver.
Preporučena literatura
- Uzorak predloška plana testiranja softvera s formatom i sadržajem
- Uzorak predloška test primjera s primjerima test primjera (preuzmi)
- Uzorak predloška za izvješće o ispitivanju prihvaćanja s primjerima
- Predlošci na C ++ s primjerima
- Python DateTime Vodič s primjerima
- Izreži naredbu u Unixu s primjerima
- Testni scenarij i testni slučaj: Koja je razlika između njih?
- Blazemeter dodatak i Jmeter predložak