Šajā pamācībā ir izskaidrots, kas ir testa scenārijs, kā arī testa scenārija nozīme, īstenošana, piemēri un veidnes:
Jebkuru programmatūras funkcionalitāti/funkciju, ko var testēt, sauc par testa scenāriju. Rakstot testēšanas scenārijus, tiek ņemta vērā gala lietotāja perspektīva.
Šī pamācība palīdzēs jums atbildēt uz jautājumiem: kāpēc ir nepieciešami testa scenāriji, kad tiek rakstīti testa scenāriji un kā rakstīt testa scenārijus.
Kas ir testa scenārijs?
Apskatiet hipotētisku situāciju: Ir milzīgs okeāns. Tev jāceļo pāri okeānam no vienas jūras krasta malas uz otru. Piemēram, no Mumbajas, Indijas piekrastē uz Kolombo, Šrilankas piekrastē.
Jūs varat izvēlēties šādus ceļošanas veidus:
(i) aviosabiedrības: Lidojums uz Kolombo
(ii) Ūdensceļi: dodiet priekšroku kuģim, lai dotos uz Kolombo.
(iii) Dzelzceļš: braukt ar vilcienu uz Šrilanku.
Tagad par testa scenārijiem: Ceļošana no Mumbajas jūras krasta uz Kolombo jūras krastu ir funkcionalitāte, kas ir jāpārbauda.
Testa scenārijos ir iekļauti šādi testēšanas scenāriji:
- Ceļošana ar aviokompāniju,
- Ceļošana pa ūdensceļiem vai
- Ceļošana pa dzelzceļu.
Šiem testa scenārijiem būs testa gadījumi.
Testa gadījumi, ko var rakstīt iepriekš minētajiem testa scenārijiem, ietver:
Testa scenārijs: Ceļošana ar aviokompāniju
Testēšanas gadījumi var ietvert šādus scenārijus:
- Lidojums notiek atbilstoši paredzētajam laikam.
- Lidojums nenotiek plānotajā laikā.
- Ir izveidojusies ārkārtas situācija (spēcīgas lietusgāzes un vētra).
Tādā pašā veidā var uzrakstīt atsevišķu testa gadījumu kopumu pārējiem atlikušajiem scenārijiem.
Tagad pievērsīsimies tehnoloģisko testu scenārijiem.
Viss, ko var pārbaudīt, ir testa scenārijs. Tādējādi mēs varam apgalvot, ka jebkuru testējamo programmatūras funkcionalitāti var sadalīt vairākās mazākās funkcionalitātēs, un to var saukt par "testa scenāriju".
Pirms jebkura produkta nodošanas klientam ir jāizvērtē un jānovērtē produkta kvalitāte. Testēšanas scenārijs palīdz novērtēt programmatūras lietojumprogrammas funkcionālo kvalitāti, kas atbilst tās biznesa prasībām.
Testētāja scenārijs ir process, kurā testētājs testē programmatūras lietojumprogrammu no galalietotāja viedokļa. Programmatūras lietojumprogrammas veiktspēja un kvalitāte tiek rūpīgi novērtēta pirms ieviešanas ražošanas vidē.
Testa scenārija nozīme
- Vienam testa scenārijam var būt vairāki "testa gadījumi". To var iztēloties kā lielu panorāmas attēlu, un testa gadījumi ir mazas daļas, kas ir svarīgas panorāmas pabeigšanai.
- Tas ir vienas rindas paziņojums, un testa gadījumi ietver pakāpenisku aprakstu, lai pabeigtu testa scenārija paziņojuma mērķi.
- Piemērs:
Testa scenārijs: Veiciet maksājumu par izmantoto taksometra pakalpojumu.
Tam būs vairāki testa gadījumi, kā norādīts tālāk:
(i) Izmantojamā maksājuma metode: PayPal, Paytm, kredītkarte/debetkarte.
(ii) Maksājums ir veikts veiksmīgi.
(iii) Maksājums ir veikts neveiksmīgi.
(iv) Maksājuma process pa vidu tika pārtraukts.
(v) Nav iespējams piekļūt maksājumu metodēm.
(vi) Pieteikums starp tām sabojājas.
- Tādējādi testa scenāriji palīdz novērtēt programmatūras lietojumprogrammu atbilstoši reālās pasaules situācijām.
- Testēšanas scenāriji, kad tie ir noteikti, palīdz sadalīt testēšanas jomu.
- Šo sadalīšanu sauc par prioritāšu noteikšanu, kas palīdz noteikt svarīgākās programmatūras lietojumprogrammas funkcijas.
- Funkcionalitāšu testēšana pēc prioritātēm lielā mērā palīdz sekmīgi īstenot programmatūras lietojumprogrammu.
- Tā kā testa scenāriji tiek sakārtoti pēc prioritātes, var viegli identificēt un prioritārā kārtā testēt svarīgākās funkcionalitātes. Tas nodrošina, ka lielākā daļa svarīgāko funkcionalitāšu darbojas pareizi un ar tām saistītie defekti tiek pienācīgi fiksēti un novērsti.
- Testēšanas scenāriji nosaka programmatūras biznesa procesu plūsmu, un tādējādi ir iespējama lietojumprogrammas testēšana no gala līdz galam.
Atšķirība starp testa scenāriju un testa gadījumu
| Testa scenārijs | Testēšanas gadījumi |
|---|---|
| Testa scenārijs ir jēdziens. | Testēšanas gadījumi ir risinājumi, lai pārbaudītu šo koncepciju. |
| Testa scenārijs ir augsta līmeņa funkcionalitāte. | Testēšanas gadījumi ir detalizētas procedūras augsta līmeņa funkcionalitātes testēšanai. |
| Testēšanas scenāriji tiek atvasināti no prasībām/lietotāja stāstiem. | Testa gadījumi tiek atvasināti no testa scenārijiem . |
| Testa scenārijs ir "Kāda funkcionalitāte ir jātestē". | Testēšanas gadījumi ir ' Kā pārbaudīt funkcionalitāti'. |
| Testa scenārijos ir vairāki testa gadījumi. | Testa gadījumu var saistīt vai nesaistīt ar vairākiem testa scenārijiem. |
| Atsevišķus testa scenārijus nekad nevar atkārtot. | Vienu testa gadījumu var izmantot vairākas reizes dažādos scenārijos. |
| Nepieciešama īsa dokumentācija. | Ir nepieciešama detalizēta dokumentācija. |
| Lai pabeigtu testēšanas scenārija izstrādi, ir nepieciešamas smadzeņu vētras sesijas. | Nepieciešamas detalizētas tehniskās zināšanas par programmatūras lietojumprogrammu. |
| Laika taupīšana, jo nav nepieciešama sīkāka informācija. | Tas prasa daudz laika, jo ir jārūpējas par katru sīkumu. |
| Uzturēšanas izmaksas ir zemas, jo nepieciešamie resursi ir nelieli. | Uzturēšanas izmaksas ir augstas, jo nepieciešami lieli resursi. |
Kāpēc testa scenāriji ir nepieciešami?
Testēšanas scenāriji tiek atvasināti no prasībām vai lietotāja stāstiem.
- Piemēram, taksometra rezervācijas testa scenārijs.
- Scenāriji var būt taksometra rezervēšanas iespējas, maksāšanas metodes, GPS izsekošana, pareizi vai nepareizi parādīta ceļa karte, pareizi vai nepareizi parādīta informācija par taksometru un vadītāju u. c. - visi šie scenāriji ir uzskaitīti testa scenāriju veidnē.
- Pieņemsim, ka testa scenārijs ir pārbaudīt, vai ir ieslēgti atrašanās vietas pakalpojumi, un, ja tie nav ieslēgti, parādīt ziņojumu "Ieslēdziet atrašanās vietas pakalpojumus. Šis scenārijs ir izlaists un nav iekļauts testa scenāriju veidnē.
- Scenārijs "Atrašanās vietas pakalpojums" rada citus ar to saistītus testa scenārijus.
Tie var būt:
- Atrašanās vietas pakalpojums ir pelēks.
- Ieslēgts atrašanās vietas pakalpojums, bet nav interneta.
- Ierobežojumi attiecībā uz pakalpojumiem uz vietas.
- Tiek parādīta nepareiza atrašanās vieta.
- Trūkst viena scenārija var nozīmēt to, ka nav pieejami daudzi citi izšķirošie scenāriji vai testa gadījumi . Tam var būt liels negatīva ietekme Tā rezultātā tiek zaudēti lieli resursi (termiņi).
- Testēšanas scenāriji lielā mērā palīdz izvairīšanās no visaptverošas testēšanas. Tas nodrošina, ka tiek pārbaudītas visas svarīgākās un paredzamās biznesa plūsmas, kas vēl vairāk palīdz veikt lietojumprogrammas testēšanu no gala līdz galam.
- Tie ietaupa laiku. Tāpat nav nepieciešams daudz detalizētāks apraksts atbilstoši testa gadījumiem. Tiek norādīts vienas rindiņas apraksts par to, kas ir jāpārbauda.
- Testa scenāriji tiek rakstīti pēc prāta vētras sesijas Tādējādi iespējamība, ka tiks izlaists kāds scenārijs (izšķirošs vai mazsvarīgs), ir minimāla. Tas tiek darīts, paturot prātā programmatūras lietojumprogrammas tehniskās nianses un arī biznesa plūsmu.
- Turklāt testa scenārijus var apstiprināt vai nu biznesa analītiķis Klients, vai abi, kuriem ir skaidras zināšanas par testējamo lietojumprogrammu.
Tādējādi testēšanas scenāriji ir neatņemama SDLC daļa.
Testēšanas scenāriju īstenošana
Apskatīsim testa scenāriju īstenošanu jeb kā rakstīt testa scenārijus:
- tiek veidotas Epics/Biznesa prasības.
- Epic piemērs : Izveidojiet Gmail kontu. Epic var būt galvenā lietojumprogrammas funkcija vai uzņēmējdarbības prasība.
- Episkie stāsti tiek sadalīti mazākos lietotāja stāstos dažādos sprintos.
- Lietotāja stāsti tiek atvasināti no Epics. Šie lietotāja stāsti ir jāizstrādā un jāapstiprina ieinteresētajām pusēm.
- Testēšanas scenāriji tiek atvasināti no lietotāju stāstiem vai BRS (Business Requirement Document), SRS (System Requirement Specification Document) vai FRS (Functional Requirement Document), kas tiek pabeigti un pamatoti.
- Testētāji raksta testēšanas scenārijus.
- Atkarībā no organizācijas šos testa scenārijus apstiprina komandas vadītājs, biznesa analītiķis vai projekta vadītājs.
- Katram testa scenārijam jābūt piesaistītam vismaz vienam lietotāja stāstam.
- Jānosaka pozitīvie un negatīvie testa scenāriji.
- Lietotāja stāsti ietver Pieņemšanas kritēriji, piemēram. :
- Pieņemšanas kritēriji ir klientu prasību nosacījumu vai nodomu stāvokļa saraksts. Rakstot pieņemšanas kritērijus, tiek ņemtas vērā klientu gaidas un arī pārpratumi.
- Tie ir unikāli vienam lietotāja stāstam, un katram lietotāja stāstam ir jābūt vismaz vienam pieņemšanas kritērijam, kam jābūt neatkarīgi testējamam.
- Pieņemšanas kritēriji palīdz noteikt, kuras funkcijas ir projekta darbības jomā un kuras ir ārpus tās. Šajos kritērijos jāietver gan funkcionālās, gan nefunkcionālās funkcijas.
- Biznesa analītiķi raksta pieņemšanas kritērijus, un produkta īpašnieks tos apstiprina.
- Vai arī dažos gadījumos produkta īpašnieks pats var uzrakstīt kritērijus.
- Testēšanas scenārijus var iegūt no pieņemšanas kritērijiem.
Testa scenārija piemēri
#1) Testa scenāriji Kindle lietotnei
Kindle ir lietotne, kas ļauj e-grāmatu lasītājiem meklēt e-grāmatas tiešsaistē, lejupielādēt un iegādāties tās. Amazon Kindle nodrošina e-grāmatu lasītājam reālu pieredzi, kā turēt rokās grāmatu un lasīt to. Lietotnē pat lappušu pāršķiršana ir labi simulēta.
Tagad pierakstīsim testa scenārijus. ( Piezīme: Turpmāk ir uzskaitīti ierobežoti scenāriji, lai gūtu vispārēju priekšstatu par testa scenārija rakstīšanu. No tā var būt atvasināti vairāki testa gadījumi).
| Testa scenāriji # | Testēšanas scenāriji |
|---|---|
| 1 | Pārbaudiet, vai Kindle lietotne tiek palaista pareizi. |
| 2 | Pārbaudiet, vai ekrāna izšķirtspēja pielāgojas atbilstoši dažādām ierīcēm pēc lietotnes palaišanas. |
| 3 | Pārbaudiet, vai parādītais teksts ir salasāms. |
| 4 | Pārbaudiet, vai darbojas tālummaiņas un tālummaiņas opcijas. |
| 5 | Pārbaudiet, vai Kindle lietotnē importētie saderīgie faili ir lasāmi. |
| 6 | Pārbaudiet Kindle lietotnes atmiņas ietilpību. |
| 7 | Pārbaudiet, vai lejupielādes funkcija darbojas pareizi. |
| 8 | Pārbaudiet, vai lappuses pagriešanas simulācija darbojas pareizi |
| 9 | Pārbaudiet e-grāmatu formātu saderību ar Kindle lietotni. |
| 10 | Pārbaudiet Kindle lietotnē atbalstītos fontus. |
| 11 | Pārbaudiet Kindle lietotnes izmantoto akumulatora darbības laiku. |
| 12 | Pārbaudiet Kindle veiktspēju atkarībā no tīkla savienojamības (Wi-Fi, 3G vai 4G). |
No katra iepriekš minētā testa scenārija var atvasināt vairākus testa gadījumus.
#2) Google dokumentu pieņemšanas kritēriji
Google dokumenti ir tīmekļa lietojumprogramma, kas paredzēta teksta dokumentu, izklājlapu, diapozitīvu un veidlapu izveidei, rediģēšanai un kopīgošanai. Visiem failiem var piekļūt tiešsaistē, izmantojot tīmekļa pārlūkprogrammu ar interneta savienojumu.
Izveidotos dokumentus var kopīgot kā tīmekļa lapu vai izdrukas formātā sagatavotu dokumentu. Lietotājs var iestatīt ierobežojumus attiecībā uz to, kas var apskatīt un rediģēt dokumentus. Vienu dokumentu var kopīgi kopīgot un pie tā strādāt dažādas personas no dažādām ģeogrāfiskām vietām.
Vispārīgai izpratnei turpmāk ir minēti ierobežoti testa scenāriji. Padziļināti testēšanas scenāriji Google dokumentiem var būt pilnīgi atsevišķa tēma.
| Pieņemšanas kritēriji # | Pieņemšanas kritēriji |
|---|---|
| 1 | Programmu Word, lapas vai veidlapas var veiksmīgi atvērt bez kļūdām. |
| 2 | Ir pieejamas dokumentu, lapu un diapozitīvu veidnes. |
| 3 | Lietotājiem ir pieejamas pieejamās veidnes. |
| 4 | Izmantotā veidne ir rediģējama (piemēram: fonti, fontu lielums, teksta pievienošana, teksta dzēšana, slaida ievietošana). |
| 5 | Ja īslaicīgi nav pieejams interneta savienojums, failu var saglabāt lokāli un augšupielādēt, kad ir pieejams interneta savienojums. |
| 6 | Vairāku lietotāju veiktās izmaiņas netiek pārrakstītas. |
| 7 | Ar vienu dokumentu var strādāt vairāki lietotāji. |
| 8 | Paveiktais darbs tiek saglabāts, ja, augšupielādējot failu, tiek zaudēts interneta savienojums. |
| 9 | kopīgošanas ierobežojumi tiek piemēroti pareizi. |
| 10 | Skatīt ierobežojumu lietotāji nevar veikt dokumentu rediģēšanu. |
| 11 | Dokumentus var publicēt internetā, lai tos varētu apskatīt plaša sabiedrība. |
| 12 | Dokumentos veiktās izmaiņas tiek saglabātas ar laika zīmogu &; autora informācija. |
Google dokumentiem testa scenāriju skaits būs daudzskaitlīgs un ļoti liels. Šādos gadījumos parasti ieinteresētās personas nosaka un apstiprina tikai pieņemšanas kritērijus, un komandas locekļi strādā pie šiem pieņemšanas kritērijiem. Testa gadījumu vai drīzāk testa scenāriju rakstīšana var būt nogurdinošs uzdevums milzīgām lietojumprogrammām.
Šiem pieņemšanas kritērijiem ir liela nozīme iteratīvā procesa plānošanā, un tos nekad nevajadzētu aizmirst. To iepriekšēja un iepriekšēja definēšana ļauj izvairīties no pārsteigumiem vai satricinājumiem sprintu vai laidienu beigās.
Ņemot vērā priekšnosacījums.
Kad lai veiktu darbību.
Tad rezultāts ir gaidāms.
Pieņemšanas kritēriju norādīšanai ir noderīgi formāti Dots, Kad un Tad.
Testa scenārija veidnes paraugs
| Izmantojiet stāsta ID # | Testa scenārija ID # | Versija # | Testēšanas scenāriji | # Testa gadījumu skaits | Svarīgums |
|---|---|---|---|---|---|
| USID12.1 | TSID12.1.1 | Kin12.4 | Pārbaudiet, vai Kindle lietotne tiek palaista pareizi. | 4 | Augsts |
| USID12.1 | TSID12.1.2 | Kin12.4 | Pārbaudiet Kindle lietotnes atmiņas ietilpību. | 3 | Vidēja |
Secinājums
Jebkuras programmatūras testēšanā ļoti nozīmīgs elements ir dzīves cikla izpratne un testa scenāriju izstrāde. Programmatūras kvalitāti var uzlabot, ja ir labs pamats testa scenārijiem. Bieži vien testa gadījumu un testa scenāriju izmantošana var tikt sajaukta.
Tomēr pamatnoteikums ir tāds, ka testa scenārijs tiek izmantots, lai rakstītu vairākus testa gadījumus, vai arī var teikt, ka testa gadījumi tiek atvasināti no testa scenārijiem. Labi definēti testa scenāriji nodrošina labu programmatūras kvalitāti.