V tem učbeniku je razloženo, kaj je testni scenarij in kakšen je njegov pomen, izvajanje, primeri in predloge:
Vsaka funkcionalnost/lastnost programske opreme, ki jo je mogoče preizkusiti, je testni scenarij. Pri pisanju testnih scenarijev se upošteva vidik končnega uporabnika.
Ta vadnica vam bo pomagala odgovoriti na vprašanja: zakaj so testni scenariji potrebni, kdaj se testni scenariji pišejo in kako napisati testne scenarije.
Kaj je testni scenarij?
Razmislite o hipotetični situaciji: Obstaja ogromen ocean. Potovati moraš čez ocean od ene morske obale do druge. Na primer, iz Mumbaja na indijski obali do Kolomba na šrilanški obali.
Način potovanja, ki ga lahko izberete, je:
(i) letalski prevozniki: Poletite v Kolombo
(ii) Vodne poti: za potovanje v Kolombo raje uporabite ladjo
(iii) železnice: z vlakom na Šrilanko
Zdaj pa testni scenariji: Potovanje od obale Mumbaja do obale Kolomba je funkcionalnost, ki jo je treba preizkusiti.
Testni scenariji vključujejo:
- Potovanje z letalsko družbo,
- Potovanje po vodnih poteh ali
- Potovanje z železnico.
Ti testni scenariji bodo imeli testne primere.
Testni primeri, ki jih je mogoče napisati za zgornje testne scenarije, vključujejo:
Preskusni scenarij: Potovanje z letalskimi prevozniki
Testni primeri lahko vključujejo scenarije, kot so:
- Let poteka po voznem redu.
- Polet ni v skladu z načrtovanim časom.
- Nastale so izredne razmere (močno deževje in neurje).
Na enak način je mogoče za druge preostale scenarije napisati ločen sklop testnih primerov.
Zdaj pa se lotimo tehnoloških testnih scenarijev.
Vse, kar je mogoče testirati, je testni scenarij. Tako lahko rečemo, da lahko vsako funkcionalnost programske opreme, ki se testira, razdelimo na več manjših funkcionalnosti in jo poimenujemo "testni scenarij".
Pred izročitvijo izdelka stranki je treba oceniti in ovrednotiti njegovo kakovost. Testni scenarij pomaga pri ocenjevanju funkcionalne kakovosti programske aplikacije, ki je skladna s poslovnimi zahtevami.
Testni scenarij je postopek, pri katerem tester testira programsko aplikacijo z vidika končnega uporabnika. Izvedba in kakovost programske aplikacije se temeljito ocenita pred implementacijo v produkcijsko okolje.
Pomen testnega scenarija
- En testni scenarij ima lahko več "testnih primerov". Lahko si ga predstavljamo kot veliko panoramsko sliko, testni primeri pa so majhni deli, ki so pomembni za dokončanje panorame.
- Gre za enovrstično izjavo, testni primeri pa obsegajo opis po korakih, da se izpolni namen izjave testnega scenarija.
- Primer:
Preskusni scenarij: Izvedite plačilo za uporabljeno storitev taksija.
To bo imelo več testnih primerov, kot je navedeno spodaj:
(i) Način plačila: PayPal, Paytm, kreditna/debetna kartica.
(ii) Opravljeno plačilo je uspešno.
(iii) Opravljeno plačilo je neuspešno.
(iv) Postopek plačila se je vmes prekinil.
(v) Ne morete dostopati do načinov plačila.
(vi) Vmes se aplikacija pokvari.
- Testni scenariji tako pomagajo pri ocenjevanju programske aplikacije glede na dejanske razmere.
- Ko so testni scenariji določeni, pomagajo razdvojiti obseg testiranja.
- Ta razdvojitev se imenuje prioritizacija, ki pomaga pri določanju pomembnih funkcionalnosti programske aplikacije.
- Prednostno testiranje funkcionalnosti v veliki meri pripomore k uspešnemu izvajanju programske aplikacije.
- Ker so testni scenariji razvrščeni po pomembnosti, je mogoče zlahka prepoznati najpomembnejše funkcionalnosti in jih prednostno testirati. To zagotavlja, da večina ključnih funkcionalnosti deluje brezhibno in da so napake, povezane z njimi, ustrezno zajete in odpravljene.
- Testni scenariji določajo potek poslovnega procesa programske opreme, zato je mogoče testiranje aplikacije od začetka do konca.
Razlika med testnim scenarijem in testno zadevo
| Preskusni scenarij | Testni primeri |
|---|---|
| Testni scenarij je koncept. | Testni primeri so rešitve za preverjanje tega koncepta. |
| Testni scenarij je funkcionalnost na visoki ravni. | Testni primeri so podroben postopek za testiranje funkcionalnosti na visoki ravni. |
| Testni scenariji izhajajo iz zahtev/uporabniških zgodb. | Testni primeri so izpeljani iz testnih scenarijev . |
| Testni scenarij je "Katero funkcionalnost je treba testirati". | Testni primeri so "Kako preizkusiti funkcionalnost". |
| Testni scenariji imajo več testnih primerov. | Testni primer je lahko povezan z več testnimi scenariji ali ne. |
| Posameznih testnih scenarijev ni mogoče nikoli ponoviti. | En testni primer se lahko uporabi večkrat v različnih scenarijih. |
| Potrebna je kratka dokumentacija. | Potrebna je podrobna dokumentacija. |
| Za dokončno oblikovanje scenarija testiranja so potrebne možganske nevihte. | Potrebno je podrobno tehnično znanje o programski aplikaciji. |
| Varčuje s časom, saj ni treba upoštevati podrobnosti o minutah. | Zahteva veliko časa, saj je treba poskrbeti za vsako najmanjšo podrobnost. |
| Stroški vzdrževanja so nizki, saj je potrebnih malo virov. | Stroški vzdrževanja so visoki, saj je potrebnih veliko virov. |
Zakaj so testni scenariji nepogrešljivi?
Testni scenariji izhajajo iz zahtev ali uporabniških zgodb.
- Vzemimo primer testnega scenarija za rezervacijo taksijev.
- Scenariji so lahko možnosti rezervacije taksija, načini plačila, sledenje GPS, pravilno ali nepravilno prikazan zemljevid ceste, pravilno ali nepravilno prikazani podatki o taksiju in vozniku itd., ki so navedeni v predlogi scenarija preskusa.
- Zdaj predpostavimo, da je scenarij preskusa preverjanje, ali so lokacijske storitve vklopljene, in če niso vklopljene, se prikaže sporočilo "Vklopite lokacijske storitve". Ta scenarij je izpuščen in ni naveden v predlogi scenarijev preskusa.
- Scenarij "Lokacijska storitev" je podlaga za druge testne scenarije, povezane z njim.
To so lahko:
- Lokacijska storitev je siva.
- Lokacijska storitev je vklopljena, vendar ni interneta.
- Omejitve storitev na lokaciji.
- Prikazana je napačna lokacija.
- Manjka en sam scenarij lahko pomeni, da boste zamudili številne druge ključni scenariji ali testni primeri . To ima lahko velik vpliv na negativni učinek To povzroči veliko izgubo sredstev (rokov).
- Testni scenariji v veliki meri pomagajo pri izogibanje izčrpnemu testiranju Zagotavlja, da se preizkusijo vsi ključni in pričakovani poslovni tokovi, kar dodatno pomaga pri celovitem testiranju aplikacije.
- To je prihranek časa. Prav tako ni potreben veliko podrobnejši opis v skladu s testnimi primeri. Določen je enovrstični opis o tem, kaj je treba testirati.
- Testni scenariji so napisani po možganske nevihte Zato je verjetnost, da bi zamudili kakršen koli scenarij (ključen ali manj pomemben), minimalna. Pri tem se upoštevajo tehnične podrobnosti in tudi poslovni tok programske aplikacije.
- Poleg tega lahko testne scenarije odobri poslovni analitik ali oba, ki izrecno poznata testirano aplikacijo.
Testni scenariji so tako nepogrešljiv del SDLC.
Izvajanje testnih scenarijev
Oglejmo si izvajanje testnih scenarijev ali kako napisati testne scenarije:
- Oblikovane so epske/poslovne zahteve.
- Primer Epic : Ustvarite račun Gmail. Epizoda je lahko glavna značilnost aplikacije ali poslovne zahteve.
- Epske zgodbe so razdeljene na manjše uporabniške zgodbe v sprintih.
- Uporabniške zgodbe so izpeljane iz Epics-a. Te uporabniške zgodbe morajo biti osnovane in odobrene s strani zainteresiranih strani.
- Testni scenariji izhajajo iz uporabniških zgodb ali dokumentov BRS (Business Requirement Document), SRS (System Requirement Specification Document) ali FRS (Functional Requirement Document), ki so dokončani in osnovno določeni.
- Testerji napišejo testne scenarije.
- Te testne scenarije odobrijo vodja skupine, poslovni analitik ali vodja projekta, odvisno od organizacije.
- Vsak testni scenarij mora biti povezan z vsaj eno uporabniško zgodbo.
- Opredeliti je treba pozitivne in negativne testne scenarije.
- Uporabniške zgodbe so sestavljene iz Merila sprejemljivosti, kot so :
- Merila sprejemljivosti so seznam pogojev ali stanje namere za zahteve naročnika. Pri pisanju meril sprejemljivosti se upoštevajo naročnikova pričakovanja in tudi nesporazumi.
- Ti so edinstveni za eno uporabniško zgodbo, vsaka uporabniška zgodba pa mora imeti vsaj eno merilo sprejemljivosti, ki ga je treba neodvisno testirati.
- Merila sprejemljivosti pomagajo pri določanju, katere funkcije so v obsegu projekta in katere so zunaj obsega. Ta merila morajo vključevati funkcionalne in nefunkcionalne funkcije.
- Poslovni analitiki napišejo merila sprejemljivosti, lastnik izdelka pa jih potrdi.
- V nekaterih primerih lahko lastnik izdelka sam napiše merila.
- Testne scenarije je mogoče pridobiti iz meril sprejemljivosti.
Primeri testnih scenarijev
#1) Testni scenariji za aplikacijo Kindle App
Kindle je aplikacija, ki bralnikom e-knjig omogoča iskanje e-knjig na spletu, njihov prenos in nakup. Amazon Kindle bralcu e-knjige omogoča resnično izkušnjo, kot da bi v rokah držal knjigo in jo bral. Aplikacija lepo simulira celo obračanje strani.
Zdaj zapišimo testne scenarije. ( Opomba: V nadaljevanju so navedeni omejeni scenariji, da dobite splošno predstavo o pisanju testnega scenarija. Iz njega je lahko izpeljanih več testnih primerov).
| Testni scenariji # | Preskusni scenariji |
|---|---|
| 1 | Preverite, ali se aplikacija Kindle zažene pravilno. |
| 2 | Po zagonu aplikacije preverite, ali se ločljivost zaslona prilagodi različnim napravam. |
| 3 | Preverite, ali je prikazano besedilo berljivo. |
| 4 | Preverite, ali delujeta možnosti povečave in pomanjšave. |
| 5 | Preverite, ali so združljive datoteke, uvožene v aplikacijo Kindle, berljive. |
| 6 | Preverite zmogljivost shranjevanja aplikacije Kindle. |
| 7 | Preverite, ali funkcija prenosa deluje pravilno. |
| 8 | Preverite, ali simulacija obračanja strani deluje pravilno |
| 9 | Preverite združljivost formatov e-knjig z aplikacijo Kindle. |
| 10 | Preverite pisave, ki jih podpira aplikacija Kindle. |
| 11 | Preverite trajanje baterije, ki ga uporablja aplikacija Kindle. |
| 12 | Preverite delovanje naprave Kindle glede na omrežno povezljivost (Wi-Fi, 3G ali 4G). |
Iz vsakega zgoraj navedenega preskusnega scenarija je mogoče izpeljati več preskusnih primerov.
#2) Merila sprejemljivosti za dokumente Google
Google docs je spletna aplikacija za ustvarjanje, urejanje in skupno rabo besedilnih dokumentov, preglednic, diapozitivov in obrazcev. Do vseh datotek lahko dostopate prek spleta s spletnim brskalnikom, ki ima internetno povezavo.
Ustvarjene dokumente je mogoče deliti kot spletno stran ali dokument, pripravljen za tiskanje. Uporabnik lahko določi omejitve glede tega, kdo lahko pregleduje in ureja dokumente. Posamezen dokument lahko v sodelovanju delijo in delajo na njem različni posamezniki z različnih geografskih lokacij.
Za splošno razumevanje so spodaj navedeni omejeni testni scenariji. Poglobljeni testni scenariji za Googlove dokumente so lahko povsem ločena tema.
| Merila sprejemljivosti # | Merila sprejemljivosti |
|---|---|
| 1 | Word, liste ali obrazce lahko uspešno odprete brez napak. |
| 2 | Na voljo so predloge za dokumente, liste in diapozitive. |
| 3 | Uporabnikom so na voljo razpoložljive predloge. |
| 4 | Uporabljeno predlogo je mogoče urejati (npr.: pisave, velikost pisave, dodajanje besedila, brisanje besedila, vstavljanje diapozitivov). |
| 5 | Če internetna povezava začasno ni na voljo, lahko datoteko shranite lokalno in jo naložite, ko bo na voljo internetna povezava. |
| 6 | Spremembe, ki jih opravi več uporabnikov, niso prepisane. |
| 7 | Na enem dokumentu lahko dela več uporabnikov. |
| 8 | Opravljeno delo se shrani, če se med nalaganjem datoteke izgubi internetna povezava. |
| 9 | Omejitve souporabe se uporabljajo pravilno. |
| 10 | Uporabniki z omejitvijo pogleda ne morejo urejati dokumentov. |
| 11 | Dokumenti se lahko objavijo na internetu za širšo javnost. |
| 12 | Spremembe dokumentov so shranjene s časovnim žigom &; podatki o avtorju. |
Število testnih scenarijev bo za Google Docs veliko in zelo veliko. V takšnih primerih zainteresirane strani običajno določijo in odobrijo samo merila za sprejem, člani ekipe pa delajo na teh merilih za sprejem. Pisanje testnih primerov ali bolje testnih scenarijev je lahko za velike aplikacije izčrpna naloga.
Ta merila sprejemljivosti imajo pomembno vlogo pri načrtovanju iterativnega procesa in jih nikoli ne smete spregledati. Z njihovo vnaprejšnjo opredelitvijo se izognete presenečenjem ali šokom ob koncu sprintov ali izdaj.
Glede na predpogoj.
Ko za izvedbo dejanja.
Nato rezultat je pričakovan.
Oblike Given, When in Then so koristne za določanje meril sprejemljivosti.
Primer predloge za testni scenarij
| Uporabite ID zgodbe # | ID preskusnega scenarija # | Različica # | Preskusni scenariji | # Število testnih primerov | Pomembnost |
|---|---|---|---|---|---|
| USID12.1 | TSID12.1.1 | Kin12.4 | Preverite, ali se aplikacija Kindle zažene pravilno. | 4 | Visoka |
| USID12.1 | TSID12.1.2 | Kin12.4 | Preverite zmogljivost shranjevanja aplikacije Kindle. | 3 | Srednja |
Zaključek
Pri vsakem testiranju programske opreme je razumevanje življenjskega cikla in določitev testnih scenarijev zelo pomemben element. Kakovost programske opreme je mogoče izboljšati z dobro podlago za testne scenarije. Pogosto se lahko uporaba testnih primerov in testnih scenarijev zamenja.
Vendar pa velja pravilo, da se testni scenarij uporablja za pisanje več testnih primerov ali pa lahko rečemo, da testni primeri izhajajo iz testnih scenarijev. Dobro opredeljeni testni scenariji zagotavljajo kakovostno programsko opremo.