Šiame vadovėlyje paaiškinama, kas yra testavimo scenarijus, taip pat nurodoma testavimo scenarijaus svarba, įgyvendinimas, pavyzdžiai ir šablonai:
Bet koks programinės įrangos funkcionalumas ir (arba) savybė, kuriuos galima išbandyti, vadinami bandymų scenarijais. Rašant bet kokius bandymų scenarijus atsižvelgiama į galutinio vartotojo perspektyvą.
Šis vadovėlis padės jums atsakyti į klausimus: kodėl reikalingi bandymų scenarijai, kada rašomi bandymų scenarijai ir kaip rašyti bandymų scenarijus.
Kas yra testavimo scenarijus?
Apsvarstykite hipotetinę situaciją: Yra didžiulis vandenynas. Jums reikia keliauti per vandenyną nuo vieno kranto iki kito. Pavyzdžiui, iš Mumbajaus, Indijos pajūrio į Kolombą, Šrilanka pajūrį.
Galite rinktis šią kelionės rūšį:
(i) Oro transporto: Skriskite į Kolombą
(ii) Vandens keliai: pirmenybę teikiate laivui, jei norite keliauti į Kolombą
(iii) Geležinkeliais: traukiniu į Šrilanka
Dabar apie bandymų scenarijus: Kelionė iš Mumbajaus pakrantės į Kolombo pakrantę - tai funkcija, kurią reikia išbandyti.
Testavimo scenarijai apima:
- Kelionės oro linijomis,
- Kelionės vandens keliais arba
- Kelionė geležinkeliu.
Šie bandymų scenarijai turės bandymų atvejus.
Testavimo atvejai, kuriuos galima parašyti pirmiau minėtiems testavimo scenarijams, apima:
Bandymo scenarijus: Kelionės oro linijomis
Testavimo atvejai gali apimti tokius scenarijus:
- Skrydis vyksta pagal tvarkaraštį.
- Skrydis vyksta ne pagal tvarkaraštį.
- Susidarė ekstremali situacija (smarkios liūtys ir audra).
Taip pat galima parašyti atskirą testavimo atvejų rinkinį kitiems likusiems scenarijams.
Dabar pereikime prie technologinių bandymų scenarijų.
Viskas, ką galima išbandyti, yra bandymų scenarijus. Taigi galime teigti, kad bet kokią testuojamą programinės įrangos funkciją galima suskirstyti į kelias mažesnes funkcijas ir vadinti "testavimo scenarijumi".
Prieš pateikiant bet kokį produktą klientui, reikia įvertinti ir įvertinti jo kokybę. Testavimo scenarijus padeda įvertinti programinės įrangos programos funkcinę kokybę, kuri atitinka verslo reikalavimus.
Testavimo scenarijus - tai procesas, kurio metu testuotojas testuoja programinės įrangos programą iš galutinio vartotojo perspektyvos. Programinės įrangos programos veikimas ir kokybė nuodugniai įvertinami prieš ją įgyvendinant gamybinėje aplinkoje.
Testavimo scenarijaus svarba
- Vieną testavimo scenarijų gali sudaryti keli "testavimo atvejai". Jį galima įsivaizduoti kaip didelį panoraminį vaizdą, o testavimo atvejai - tai mažos dalys, kurios yra svarbios panoramai užbaigti.
- Tai vienos eilutės teiginys, o testavimo atvejai susideda iš etapinio aprašymo, kad būtų pasiektas testavimo scenarijaus teiginio tikslas.
- Pavyzdys:
Bandymo scenarijus: Atlikite mokėjimą už pasinaudotą taksi paslaugą.
Tai bus keli bandymų atvejai, kaip nurodyta toliau:
(i) Mokėjimo būdas: "PayPal", "Paytm", kredito / debeto kortelė.
(ii) Mokėjimas atliktas sėkmingai.
(iii) Mokėjimas atliktas nesėkmingai.
(iv) Mokėjimo procesas tarp jų nutrūko.
(v) Negalima naudotis mokėjimo būdais.
(vi) Paraiška sugenda tarp jų.
- Taigi bandymų scenarijai padeda įvertinti programinę įrangą pagal realias situacijas.
- Nustatyti testavimo scenarijai padeda išskaidyti testavimo apimtį.
- Šis išskaidymas vadinamas prioritetų nustatymu, kuris padeda nustatyti svarbias programinės įrangos programos funkcijas.
- Prioritetinis funkcijų testavimas labai padeda sėkmingai įgyvendinti programinę įrangą.
- Kadangi bandymų scenarijai yra prioritetiniai, galima lengvai nustatyti svarbiausias funkcijas ir jas išbandyti pagal prioritetus. Taip užtikrinama, kad dauguma svarbiausių funkcijų veiktų gerai, o su jomis susiję defektai būtų tinkamai užfiksuoti ir ištaisyti.
- Testavimo scenarijuose nustatomas programinės įrangos verslo procesų srautas, todėl galima atlikti visapusišką programos testavimą.
Testavimo scenarijaus ir testavimo atvejo skirtumas
| Bandymo scenarijus | Testavimo atvejai |
|---|---|
| Bandymų scenarijus yra sąvoka. | Testavimo atvejai - tai sprendimai, skirti šiai koncepcijai patikrinti. |
| Testavimo scenarijus yra aukšto lygio funkcija. | Testavimo atvejai - tai išsami aukšto lygio funkcionalumo testavimo procedūra. |
| Testavimo scenarijai kuriami iš Reikalavimų / Vartotojų istorijų. | Testavimo atvejai išvedami iš testavimo scenarijų. |
| Testavimo scenarijus yra "Kokią funkciją reikia išbandyti". | Testavimo atvejai yra "Kaip patikrinti funkcionalumą". |
| Testavimo scenarijai turi kelis testavimo atvejus. | Testavimo atvejis gali būti arba nebūti susijęs su keliais testavimo scenarijais. |
| Atskirų bandymų scenarijų niekada negalima pakartoti. | Vieną bandymo atvejį galima naudoti kelis kartus pagal skirtingus scenarijus. |
| Reikalingi trumpi dokumentai. | Reikia pateikti išsamius dokumentus. |
| Norint baigti kurti testavimo scenarijų, reikia surengti smegenų šturmo sesijas. | Būtinos išsamios techninės programinės įrangos žinios |
| Taupo laiką, nes nereikia pateikti smulkiausių detalių. | Tai užima daug laiko, nes reikia pasirūpinti kiekviena smulkmena. |
| Priežiūros sąnaudos yra nedidelės, nes reikia nedaug išteklių. | Priežiūros išlaidos yra didelės, nes reikia daug išteklių |
Kodėl testavimo scenarijai yra būtini?
Testavimo scenarijai išvedami iš reikalavimų arba naudotojo istorijų.
- Paimkime taksi užsakymo bandymų scenarijaus pavyzdį.
- Scenarijai gali būti tokie: taksi užsakymo parinktys, mokėjimo būdai, GPS stebėjimas, teisingai arba ne rodomas kelių žemėlapis, teisingai arba ne rodomi taksi ir vairuotojo duomenys ir t. t. Visi šie scenarijai yra išvardyti bandymo scenarijaus šablone.
- Dabar tarkime, kad bandymo scenarijus yra patikrinti, ar įjungtos vietos nustatymo paslaugos, o jei neįjungtos, rodyti pranešimą "Įjunkite vietos nustatymo paslaugas". Šis scenarijus praleistas ir neįtrauktas į bandymo scenarijų šabloną.
- Scenarijus "Vietos nustatymo paslauga" lemia kitus su juo susijusius bandymų scenarijus.
Tai gali būti:
- Vietos nustatymo paslauga pažymėta pilka spalva.
- Buvimo vietos nustatymo paslauga įjungta, bet interneto nėra.
- Apribojimai vietoje teikiamoms paslaugoms.
- Rodoma klaidinga vieta.
- Trūksta vieno scenarijaus gali reikšti, kad praleisite daug kitų svarbiausi scenarijai arba bandymų atvejai . Tai gali turėti didelį neigiamas poveikis įgyvendinant programinę įrangą. Dėl to prarandama daug išteklių (terminų).
- Bandymų scenarijai labai padeda išvengti išsamaus testavimo. Taip užtikrinama, kad būtų išbandyti visi svarbiausi ir laukiami verslo srautai, o tai dar labiau padeda atlikti galutinį programos testavimą.
- Tai taupo laiką. Be to, nereikia daug išsamesnio aprašymo pagal testavimo atvejus. Nurodomas vienos eilutės aprašymas, ką reikia testuoti.
- Testavimo scenarijai rašomi po smegenų šturmo sesijos komandos narių. Taigi tikimybė praleisti bet kurį scenarijų (esminį ar neesminį) yra minimali. Tai daroma atsižvelgiant į techninius dalykus, taip pat į programinės įrangos programos verslo srautą.
- Be to, bandymų scenarijus gali patvirtinti verslo analitikas klientas arba abu, kurie turi aiškių žinių apie testuojamą taikomąją programą.
Todėl testavimo scenarijai yra neatsiejama SDLC dalis.
Bandymų scenarijų įgyvendinimas
Pažiūrėkime, kaip įgyvendinti bandymų scenarijus arba kaip rašyti bandymų scenarijus:
- Sudaromi "Epics/Business Requirements" reikalavimai.
- "Epic" pavyzdys : Sukurkite "Gmail" paskyrą. "Epic" gali būti pagrindinė programos funkcija arba verslo reikalavimas.
- Epiniai projektai dalijami į mažesnes naudotojų istorijas per sprintus.
- Vartotojo istorijos išvedamos iš "Epics". Šios vartotojo istorijos turi būti pagrįstos ir patvirtintos suinteresuotųjų šalių.
- Testavimo scenarijai kuriami iš naudotojo istorijų arba BRS (verslo reikalavimų dokumento), SRS (sistemos reikalavimų specifikacijos dokumento) ar FRS (funkcinių reikalavimų dokumento), kurie yra užbaigti ir pagrįsti.
- Testuotojai rašo testavimo scenarijus.
- Priklausomai nuo organizacijos, šiuos bandymų scenarijus tvirtina grupės vadovas, verslo analitikas arba projekto vadovas.
- Kiekvienas testavimo scenarijus turi būti susietas su bent viena naudotojo istorija.
- Turi būti nustatyti teigiami ir neigiami bandymų scenarijai.
- Vartotojo istorijas sudaro Priėmimo kriterijai, pvz. :
- Priėmimo kriterijai - tai sąlygų arba ketinimų, susijusių su kliento reikalavimais, sąrašas. Rašant priėmimo kriterijus atsižvelgiama į kliento lūkesčius, taip pat į nesusipratimus.
- Jie yra unikalūs vienai naudotojo istorijai ir kiekviena naudotojo istorija turi turėti bent vieną priėmimo kriterijų, kuris turėtų būti nepriklausomai testuojamas.
- Priėmimo kriterijai padeda nustatyti, kurios funkcijos yra įtrauktos į projekto apimtį, o kurios - ne. Šie kriterijai turėtų apimti funkcines ir nefunkcines funkcijas.
- Verslo analitikai parašo priėmimo kriterijus, o produkto savininkas juos patvirtina.
- Kai kuriais atvejais produkto savininkas gali pats parašyti kriterijus.
- Bandymų scenarijus galima gauti iš priėmimo kriterijų.
Bandymų scenarijaus pavyzdžiai
#1) "Kindle App" testavimo scenarijai
"Kindle" - tai programa, kuria naudodamiesi e. skaitytojai gali ieškoti e. knygų internete, jas atsisiųsti ir pirkti. "Amazon Kindle" suteikia e. knygų skaitytojui realią patirtį, kaip laikyti rankose knygą ir ją skaityti. Programoje gražiai imituojamas net puslapių vertimas.
Dabar užrašykime bandymų scenarijus. ( Pastaba: Toliau išvardyti riboti scenarijai, kad būtų galima susidaryti bendrą idėją, kaip rašyti bandymo scenarijų. Iš jo gali būti išvesta keletas bandymo atvejų).
| Bandymų scenarijai # | Bandymų scenarijai |
|---|---|
| 1 | Patikrinkite, ar "Kindle App" paleidžiama tinkamai. |
| 2 | Patikrinkite, ar paleidus programą ekrano skiriamoji geba pritaikoma pagal skirtingus įrenginius. |
| 3 | Patikrinkite, ar rodomas tekstas yra įskaitomas. |
| 4 | Patikrinkite, ar veikia priartinimo ir nutolinimo parinktys. |
| 5 | Patikrinkite, ar "Kindle" programėlėje importuoti suderinami failai yra įskaitomi. |
| 6 | Patikrinkite "Kindle App" atminties talpą. |
| 7 | Patikrinkite, ar tinkamai veikia atsisiuntimo funkcija. |
| 8 | Patikrinkite, ar teisingai veikia puslapio pasukimo simuliacija |
| 9 | Patikrinkite elektroninių knygų formatų suderinamumą su "Kindle" programa. |
| 10 | Patikrinkite "Kindle" programoje palaikomus šriftus. |
| 11 | Patikrinkite "Kindle" programėlės naudojamo akumuliatoriaus veikimo laiką. |
| 12 | Patikrinkite "Kindle" veikimą priklausomai nuo tinklo ryšio (Wi-Fi, 3G arba 4G). |
Iš kiekvieno pirmiau nurodyto bandymo scenarijaus galima išvesti kelis bandymo atvejus.
#2) "Google" dokumentų priėmimo kriterijai
"Google docs" yra žiniatinklio programa, skirta kurti, redaguoti ir bendrinti teksto dokumentus, skaičiuokles, skaidres ir formas. Visus failus galima pasiekti internetu naudojant interneto naršyklę, turinčią interneto ryšį.
Sukurtus dokumentus galima bendrinti kaip tinklalapį arba spausdinti paruoštą dokumentą. Naudotojas gali nustatyti apribojimus, kas gali peržiūrėti ir redaguoti dokumentus. Vienu dokumentu gali bendrai dalytis ir dirbti su juo įvairūs asmenys iš skirtingų geografinių vietovių.
Toliau bendram supratimui paminėti riboti bandymų scenarijai. Išsamūs "Google" dokumentų bandymų scenarijai gali būti atskira tema.
| Priėmimo kriterijai # | Priėmimo kriterijai |
|---|---|
| 1 | "Word", "Sheets" arba "Forms" galima sėkmingai atidaryti be klaidų. |
| 2 | Galima naudoti dokumentų, lapų ir skaidrių šablonus. |
| 3 | Naudotojai gali naudotis turimais šablonais. |
| 4 | Naudojamą šabloną galima redaguoti (pvz.: šriftai, šrifto dydis, teksto pridėjimas, teksto ištrynimas, skaidrių įterpimas). |
| 5 | Jei interneto ryšys laikinai nepasiekiamas, failą galima saugoti vietoje ir įkelti, kai bus interneto ryšys. |
| 6 | Kelių naudotojų atlikti pakeitimai nėra perrašomi. |
| 7 | Su vienu dokumentu gali dirbti keli naudotojai. |
| 8 | Atliktas darbas išsaugomas, jei įkeliant failą nutrūksta interneto ryšys. |
| 9 | bendrinimo apribojimai taikomi teisingai. |
| 10 | Peržiūros apribojimo naudotojai negali atlikti jokių dokumentų redagavimo veiksmų. |
| 11 | Dokumentai gali būti skelbiami internete plačiajai visuomenei. |
| 12 | Dokumentų pakeitimai išsaugomi su laiko žyma ir autoriaus informacija. |
Testavimo scenarijų skaičius "Google" dokumentams bus daugialypis ir labai didelis. Tokiais atvejais paprastai nustatomi ir suinteresuotųjų šalių patvirtinami tik priėmimo kriterijai, o komandos nariai dirba su šiais priėmimo kriterijais. Testavimo atvejų ar veikiau testavimo scenarijų rašymas gali būti išsunki užduotis didžiulėms taikomosioms programoms.
Šie priėmimo kriterijai atlieka svarbų vaidmenį iteracinio proceso planavime ir jų niekada nereikėtų pamiršti. Juos apibrėžus iš anksto, išvengiama netikėtumų ar sukrėtimų sprinto ar išleidimo pabaigoje.
Atsižvelgiant į išankstinė sąlyga.
Kai atlikti veiksmą.
Tada tikimasi rezultato.
Formatai Given, When ir Then yra naudingi nurodant priėmimo kriterijus.
Testavimo scenarijaus šablono pavyzdys
| Naudokite istorijos ID # | Bandymo scenarijaus ID # | Versija # | Bandymų scenarijai | # Testavimo atvejų skaičius | Svarbumas |
|---|---|---|---|---|---|
| USID12.1 | TSID12.1.1 | Kin12.4 | Patikrinkite, ar "Kindle App" paleidžiama tinkamai. | 4 | Aukštas |
| USID12.1 | TSID12.1.2 | Kin12.4 | Patikrinkite "Kindle App" atminties talpą. | 3 | Vidutinis |
Išvada
Bet kokios programinės įrangos testavimo, gyvavimo ciklo supratimas ir testavimo scenarijų nustatymas yra labai svarbus elementas. Programinės įrangos kokybę galima pagerinti turint gerą testavimo scenarijų pagrindą. Dažnai testavimo atvejų ir testavimo scenarijų naudojimas gali būti painiojamas.
Tačiau galioja taisyklė, kad testavimo scenarijus naudojamas rašant kelis testavimo atvejus arba galima sakyti, kad testavimo atvejai išvedami iš testavimo scenarijų. Gerai apibrėžti testavimo scenarijai užtikrina gerą programinės įrangos kokybę.