See õpetus selgitab, mis on testimisstsenaarium koos testimisstsenaariumi tähtsuse, rakendamise, näidete ja mallidega:

Mis tahes tarkvara funktsionaalsust/funktsiooni, mida saab testida, nimetatakse testimisstsenaariumiks. Testimisstsenaariumide koostamisel võetakse arvesse lõppkasutaja vaatenurka.

See õpetus aitab teil vastata küsimustele: miks on vaja teststsenaariume, millal teststsenaariume kirjutatakse ja kuidas teststsenaariume kirjutada.

Mis on testimisstsenaarium?

Mõelge hüpoteetilisele olukorrale: On suur ookean. Te peate reisima üle ookeani ühest merekaldast teise. Näiteks, Mumbaist, India mereäärsest kohast Colombosse, Srilanka mereäärsesse kohta.

Reisimisviisid, mida saate valida, on järgmised:

(i) Lennuväljad: Võtke lend Colombosse

(ii) Veeteed: eelistage laeva, et sõita Colombosse.

(iii) Raudtee: võtta rong Srilanka'sse.

Nüüd teststsenaariumid: Reisimine Mumbai merekaldalt Colombo merekaldale on funktsionaalsus, mida tuleb katsetada.

Testi stsenaariumid hõlmavad järgmist:

  • Reisimine lennuteedega,
  • Reisimine veeteedel või
  • Reisimine raudteel.

Nendel teststsenaariumidel on testjuhtumid.

Testjuhtumid, mida saab kirjutada ülaltoodud testimisstsenaariumide jaoks, hõlmavad järgmist:

Testi stsenaarium: Reisimine lennuteedega

Testjuhtumid võivad sisaldada selliseid stsenaariume nagu:

  1. Lend toimub vastavalt lennuplaanile.
  2. Lend ei toimu plaanipäraselt.
  3. Tekkinud on hädaolukord (tugevad vihmad ja torm).

Samamoodi võib kirjutada eraldi testjuhtumite komplekti ka teiste ülejäänud stsenaariumide jaoks.

Nüüd jõuame tehnoloogiliste katsestsenaariumide juurde.

Kõik, mida saab testida, on testimisstsenaarium. Seega võime väita, et mis tahes testitava tarkvara funktsionaalsust saab jagada mitmeks väiksemaks funktsionaalsuseks ja seda võib nimetada "testimisstsenaariumiks".

Enne mis tahes toote üleandmist kliendile tuleb toote kvaliteeti hinnata ja hinnata. Testi stsenaarium aitab hinnata ärinõuetele vastava tarkvararakenduse funktsionaalset kvaliteeti.

Testija stsenaarium on protsess, mille käigus testija testib tarkvararakendust lõppkasutaja vaatenurgast. Tarkvararakenduse toimivust ja kvaliteeti hinnatakse põhjalikult enne rakendust tootmiskeskkonnas.

Testimisstsenaariumi tähtsus

  • Ühel testimisstsenaariumil võib olla mitu "testjuhtumit". Seda võib kujutada kui suurt panoraampilti ja testjuhtumid on väikesed osad, mis on olulised panoraami täitmiseks.
  • Tegemist on ühe rea avaldusega ja testjuhtumid koosnevad samm-sammulisest kirjeldusest, et täita testistsenaariumi avalduse eesmärki.
  • Näide:

Testi stsenaarium: Tehke makse saadud taksoteenuse eest.

Sellel on mitu testjuhtumit, nagu allpool on märgitud:

(i) Kasutatav makseviis: PayPal, Paytm, krediit/deebetkaart.

(ii) Makse on edukalt sooritatud.

(iii) Tehtud makse on ebaõnnestunud.

(iv) Makseprotsess katkestati vahepeal.

(v) Ei saa juurdepääsu makseviisidele.

(vi) Rakendus laguneb vahepeal.

  • Teststsenaariumid aitavad seega hinnata tarkvara rakendust vastavalt tegelikele olukordadele.
  • Kui testimisstsenaariumid on kindlaks määratud, aitavad need testimise ulatust jagada.
  • Sellist jagamist nimetatakse prioriseerimiseks, mis aitab määrata kindlaks tarkvararakenduse olulised funktsioonid.
  • Funktsionaalsuste prioriteetne testimine aitab suurel määral kaasa tarkvararakenduse edukale rakendamisele.
  • Kuna testimisstsenaariumid seatakse prioriteediks, saab kõige olulisemad funktsioonid hõlpsasti kindlaks määrata ja neid testida vastavalt prioriteedile. See tagab, et enamik olulisi funktsioone töötab hästi ja sellega seotud puudused on nõuetekohaselt tuvastatud ja parandatud.
  • Testi stsenaariumid määravad tarkvara äriprotsessi voo ja seega on võimalik rakenduse läbiv testimine.

Testimisstsenaariumi ja testjuhtumi erinevus

Testi stsenaarium Testjuhtumid
Teststsenaarium on mõiste. Testjuhtumid on lahendused selle kontseptsiooni kontrollimiseks.
Testimisstsenaarium on kõrgetasemeline funktsionaalsus. Testjuhtumid on üksikasjalik menetlus kõrgetasemelise funktsionaalsuse testimiseks.
Testimisstsenaariumid on tuletatud nõuetest/ kasutajakäigu kirjeldustest. Testjuhtumid on tuletatud testimisstsenaariumidest .
Testimisstsenaarium on "Millist funktsionaalsust tuleb testida". Testjuhtumid on ' Kuidas testida funktsionaalsust '.
Teststsenaariumidel on mitu testjuhtumit. Testjuhtum võib olla seotud mitme testistsenaariumiga või mitte.
Üksikud testimisstsenaariumid ei ole kunagi korratavad. Ühte katsejuhtumit võib kasutada mitu korda erinevates stsenaariumides.
Vajalik lühike dokumentatsioon. Vajalik on üksikasjalik dokumentatsioon.
Testimisstsenaariumi lõplikuks koostamiseks on vaja ajurünnakuid. Vajalikud on üksikasjalikud tehnilised teadmised tarkvararakendusest
Ajasäästja, kuna minutilised üksikasjad ei ole vajalikud. See on aeganõudev, sest iga väiksemgi detail tuleb läbi vaadata.
Hoolduskulud on madalad, kuna vajaminevad ressursid on väikesed. Hoolduskulud on suured, kuna vajaminevad ressursid on suured

Miks on testimisstsenaariumid hädavajalikud?

Testimisstsenaariumid on tuletatud nõuetest või kasutaja lugudest.

  • Võtame näiteks takso broneerimise teststsenaariumi.
  • Stsenaariumid võivad olla takso broneerimise võimalused, makseviisid, GPS jälgimine, õigesti või mitte õigesti kuvatud teekaart, õigesti või mitte õigesti kuvatud takso ja juhi andmed jne, mis kõik on loetletud teststsenaariumi mallil.
  • Nüüd oletame, et teststsenaarium on kontrollida, kas asukohateenused on sisse lülitatud, ja kui need ei ole sisse lülitatud, kuvada sõnum "Turn on-location services. See stsenaarium on välja jäänud ja seda ei ole teststsenaariumide mallil loetletud.
  • Stsenaarium "Asukohateenus" annab alust teisteks sellega seotud testistsenaariumideks.

Need võivad olla:

    • Asukohateenus on hallis.
    • Asukohateenus on sisse lülitatud, kuid internetti ei ole.
    • Piirangud kohapeal osutatavatele teenustele.
    • Kuvatakse vale asukoht.
  • Puudub üks stsenaarium võib tähendada paljude teiste olulised stsenaariumid või testjuhtumid See võib olla suur negatiivne mõju See toob kaasa suure ressursside (tähtaegade) kaotuse.
  • Teststsenaariumid aitavad suurel määral kaasa ammendava testimise vältimine See tagab, et kõik olulised ja oodatavad ärivood saavad testitud, mis aitab kaasa rakenduse läbivale testimisele.
  • Need säästavad aega. Samuti ei ole vaja palju üksikasjalikumat kirjeldust vastavalt testjuhtumitele. Määratletakse ühesõnaline kirjeldus selle kohta, mida testida.
  • Teststsenaariumid kirjutatakse pärast ajurünnakud Seega on tõenäosus, et mõni stsenaarium (oluliste või vähemoluliste) jääb vahele, minimaalne. Seda tehakse, pidades silmas nii tehnilisi üksikasju kui ka tarkvararakenduse ärivoolu.
  • Lisaks sellele võib testimisstsenaariumid heaks kiita kas ärianalüütik-klient või mõlemad, kellel on selged teadmised testitavast rakendusest.

Seega on testimisstsenaariumid SDLC lahutamatu osa.

Testimisstsenaariumide rakendamine

Vaatame teststsenaariumide rakendamist või seda, kuidas teststsenaariume kirjutada:

  • Kujundatakse eeposed/ärinõuded.
    • Näide eepose kohta : Looge Gmaili konto. Epic võib olla rakenduse peamine funktsioon või ärinõue.
  • Eeposed jagatakse väiksemateks kasutajalugudeks üle sprindi.
  • Kasutajalood tuletatakse eepostidest. Need kasutajalood tuleb põhistada ja sidusrühmad peavad need heaks kiitma.

  • Testi stsenaariumid tuletatakse kasutajate lugudest või BRS (Business Requirement Document), SRS (System Requirement Specification Document) või FRS (Functional Requirement Document), mis on viimistletud ja põhistatud.
  • Testijad kirjutavad testimisstsenaariumid.
  • Need testimisstsenaariumid kiidab sõltuvalt organisatsioonist heaks meeskonnajuht, ärianalüütik või projektijuht.
  • Iga testimisstsenaarium peab olema seotud vähemalt ühe kasutajalooga.
  • Tuleb kindlaks määrata nii positiivsed kui ka negatiivsed testimisstsenaariumid.
  • Kasutaja lood koosnevad Vastuvõtukriteeriumid nagu :
    • Vastuvõtukriteeriumid on kliendi nõuete tingimuste või kavatsuste loetelu. Vastuvõtukriteeriumide kirjutamisel võetakse arvesse kliendi ootusi ja ka arusaamatusi.
    • Need on unikaalsed ühe kasutaja loo jaoks ja igal kasutaja lool peab olema vähemalt üks vastuvõtukriteerium, mis peaks olema iseseisvalt testitav.
    • Vastuvõtukriteeriumid aitavad kindlaks määrata, millised funktsioonid kuuluvad projekti ulatusse ja millised mitte. Need kriteeriumid peaksid hõlmama nii funktsionaalseid kui ka mittefunktsionaalseid funktsioone.
    • Ärianalüütikud kirjutavad vastuvõtukriteeriumid ja tooteomanik kiidab need heaks.
    • Või mõnel juhul võib tooteomanik ise kriteeriumid kirjutada.
    • Testi stsenaariumid saab vastuvõtukriteeriumidest.

Testi stsenaariumi näited

#1) Kindle'i rakenduse testimisstsenaariumid

Kindle on rakendus, mis võimaldab e-lugeritel e-raamatuid internetis otsida, alla laadida ja osta. Amazon Kindle annab e-raamatute lugejale reaalse kogemuse, nagu oleks raamat käes ja seda lugedes. Isegi lehekülgede keeramine on rakenduses kenasti simuleeritud.

Nüüd paneme kirja teststsenaariumid. ( Märkus: Allpool on loetletud piiratud stsenaariumid, et saada üldine ettekujutus testistsenaariumi kirjutamiseks. Sellest võib olla tuletatud mitu testjuhtumit).

Testi stsenaariumid # Testi stsenaariumid
1 Kontrollige, kas Kindle App käivitub korralikult.
2 Kontrollida, et ekraani resolutsioon kohandub vastavalt erinevatele seadmetele pärast rakenduse käivitamist.
3 Kontrollige, kas kuvatav tekst on loetav.
4 Kontrollige, kas suumimis- ja suumimisvõimalused toimivad.
5 Kontrollige, kas Kindle'i rakenduses imporditud ühilduvad failid on loetavad.
6 Kontrollige Kindle Appi salvestusmahtu.
7 Kontrollida, et allalaadimisfunktsioon töötab õigesti.
8 Kontrollida, et lehepöörde simulatsioon töötab õigesti
9 Kontrollige e-raamatu formaatide ühilduvust Kindle'i rakendusega.
10 Kontrollige Kindle'i rakenduse poolt toetatud fonte.
11 Kontrollige Kindle'i rakenduse poolt kasutatud aku kestust.
12 Kontrollige Kindle'i jõudlust sõltuvalt võrguühendusest (Wi-Fi, 3G või 4G).

Igast eespool nimetatud testimisstsenaariumist võib tuletada mitu testjuhtumit.

#2) Google Docs'i vastuvõtukriteeriumid

"Google docs" on veebipõhine rakendus, mille abil saab luua, redigeerida ja jagada tekstidokumente, arvutustabeleid, slaide ja vorme. Kõigile failidele saab veebis ligi, kasutades internetiühendusega veebibrauserit.

Loodud dokumente saab jagada veebilehe või trükivalmis dokumendina. Kasutaja saab kehtestada piiranguid, kes saavad dokumente vaadata ja muuta. Ühte dokumenti saavad ühiselt jagada ja selle kallal töötada erinevad isikud erinevatest geograafilistest asukohtadest.

Allpool on üldiseks mõistmiseks nimetatud piiratud testimisstsenaariumid. Google'i dokumentide põhjalikud testimisstsenaariumid võivad olla täiesti eraldi teema.

Vastuvõtukriteeriumid # Vastuvõtukriteeriumid
1 Word, Sheets või Forms saab edukalt avada ilma vigadeta.
2 Dokumentide, lehtede ja slaidide jaoks on saadaval mallid.
3 Kättesaadavad mallid on kasutajatele kättesaadavad.
4 Kasutatav mall on redigeeritav (nt: kirjatüübid, kirjasuurus, teksti lisamine, teksti kustutamine, slaidi lisamine).
5 Kui internetiühendus ei ole ajutiselt saadaval, saab faili salvestada lokaalselt ja laadida üles, kui internetiühendus on saadaval.
6 Mitme kasutaja tehtud muudatusi ei kirjutata üle.
7 Mitu kasutajat saab töötada ühe dokumendiga.
8 Tehtud töö salvestatakse, kui faili üleslaadimise ajal kaob internetiühendus.
9 Jagamispiiranguid rakendatakse õigesti.
10 Vaatepiiranguga kasutajad ei saa dokumente muuta.
11 Dokumendid võib avaldada Internetis üldsusele.
12 Dokumentidesse tehtud muudatused salvestatakse koos ajatempliga &; autori andmed.

Teststsenaariumide arv on Google Docs'i puhul mitu ja väga suur. Sellistel juhtudel määratakse ja kiidetakse sidusrühmade poolt heaks ainult vastuvõtukriteeriumid ja meeskonnaliikmed töötavad nende vastuvõtukriteeriumide alusel. Testjuhtumite või pigem teststsenaariumide kirjutamine võib olla tohutute rakenduste puhul ammendav ülesanne.

Need vastuvõtukriteeriumid mängivad olulist rolli iteratiivse protsessi planeerimisel ja neid ei tohiks kunagi tähelepanuta jätta. Nende eelnev ja eelnev määratlemine väldib üllatusi või šokke sprintide või versioonide lõpus.

Antud eeltingimus.

Kui teha tegevus.

Siis tulemus on oodatud.

Vastuvõtukriteeriumide täpsustamiseks on kasulikud vormid "Given", "When" ja "Then".

Näide testimisstsenaariumi malli kohta

Kasutage loo ID # Testi stsenaariumi ID # Versioon # Testi stsenaariumid # Testjuhtumite arv Tähtsus
USID12.1 TSID12.1.1 Kin12.4 Kontrollige, kas Kindle App käivitub korralikult. 4 Kõrge
USID12.1 TSID12.1.2 Kin12.4 Kontrollige Kindle Appi salvestusmahtu. 3 Keskmine

Kokkuvõte

Igasuguse tarkvara testimisel on elutsükli mõistmine ja testimisstsenaariumide kehtestamine väga oluline element. Tarkvara kvaliteeti saab parandada, kui testimisstsenaariumidele on hea alus. Sageli võidakse testjuhtumite ja testimisstsenaariumide kasutamine omavahel ära vahetada.

Siiski kehtib rusikareegel, et teststsenaariumi kasutatakse mitme testjuhtumi kirjutamiseks või võime öelda, et testjuhtumid on tuletatud teststsenaariumidest. Hästi määratletud teststsenaariumid tagavad kvaliteetse tarkvara.

Keri üles