Stsenaariumi sissejuhatus

Testistsenaarium on kahe sõna kombinatsioon, st test ja stsenaarium. Test kujutab endast kontrollimise või valideerimise toimingut ja stsenaarium tähistab kasutaja teekonda. Igasugust testitavat funktsionaalsust nimetatakse testistsenaariumiks. Testistsenaariumi saab kirjeldada kui kasutaja teekonna kontrollimist või kinnitamist. See tuleb dokumentide kujul, mis sisaldab kõiki katsejuhtumeid, mis on üksikasjalikult kirjutatud, et testida rakenduste otsest funktsiooni. See on üks kõrgetasemeline nõuete kategooria, mis on kontrollitav. Seda tuntakse ka kui testimisvõimalust või katsetingimust.

Miks luua testistsenaariume?

Ühes testimisstsenaariumis võib käsitleda mitut testijuhtumit. Seetõttu on testistsenaariumide ja testjuhtumite vaheline seos üks mitmele. Kuid testija peab selle loomise ajal iga stsenaariumi eest hoolitsema. Testijad loovad selle rakenduse testimiseks lõppkasutaja seisukohast. Testijad otsivad kõigilt arendajatelt, huvirühmadelt ja klientidelt kriitilise tähtsusega ettevalmistamist.

Nende loomise põhjus on järgmine:

  • Täieliku ja korrektse testkatte tagab täiuslike testistsenaariumide loomine.
  • Nende loomine muutub programmi lõplike funktsioonide uurimiseks kriitiliseks.
  • Kõige olulisemaid ja kriitilisemaid lõpptehinguid või reaalajas rakenduste kasutamist saab nende õige abiga hästi kindlaks teha.
  • Neid saab kasutada tööjõu testimise kiireks määramiseks, mis aitab klientidel või organisatsioonidel tõhusalt ja tulemuslikult ettepanekuid koostada ja tööjõu testimise korraldamist aidata.
  • Rakenduste põhjaliku ja nõuetekohase testimise tagamiseks kinnitatakse see erinevatel tasanditel, sealhulgas klientidel, ärianalüütikutel, arendajatel jne.

Samuti võivad teatud olukorrad olla, mille korral tuleks selle loomist vältida.

  • Seda ei pruugita luua projektides, mis järgivad Agile metoodikaid, näiteks Scrum jne.
  • Kui testitavad rakendused on ebastabiilsed või liiga keerulised või kui projekt on kriitilises seisus, võib selle loomist vältida.
  • Selle loomist võib regressioonitesti või uue vea puhul vältida, kuna hooldusprojektides toimuks varasemates testitsüklites eelnevalt nende raske dokumenteerimine.

Kuidas saab testi stsenaariume kirjutada?

Testija saab katsestsenaariumide loomiseks läbi viia järgmised toimingud:

  • 1. samm: testitava rakenduse selliste nõuete dokumente nagu ärinõude spetsifikatsioon (BRS), funktsionaalsete nõuete spetsifikatsioon (FRS) ja süsteeminõude spetsifikatsioon (SRS) tuleks põhjalikult ja hoolikalt läbi lugeda. Sama jaoks võib viidata ka testitava rakenduse juhenditele, raamatutele, kasutusjuhtudele jne.
  • 2. samm: kõik võimalikud eesmärgid ja kasutajate toimingud tuleks iga nõude jaoks korralikult välja mõelda. Samuti tuleks kindlaks määrata iga nõude kõik tehnilised omadused.
  • 3. samm: süsteemi häkkimise ja kasutajate hindamise kõik võimalikud põhjused tuleks läbi viia häkkerite vaatenurgast. Kasutajate hindamiseks saab leida kõik rakenduste kasutajate töötamise võimalused.
  • 4. samm: pärast nõudedokumendi täielikku lugemist ja analüüsi koostamist tuleks koostada täielik loetelu kõigist võimalikest testjuhtumitest, et kontrollida rakenduse kõiki funktsioone.
  • 5. samm: pärast kõigi nende lisamist nõude ja selle stsenaariumi vastavuse kontrollimiseks tuleks luua jälgitavusmaatriks.
  • 6. samm . Juhendaja vaatab kõik loodud stsenaariumid üle ja hindab neid. Samuti kontrollivad seda ka kõik sidusrühmad.

Projekti protseduuri kohaselt peab iga katsestsenaarium sobima vähemalt ühe kasutaja loo või nõudega. Enne mitut nõuet ühes katsestsenaariumis on kohustuslik kontrollida iga katsestsenaariumi selle nõude suhtes eraldi. Lihtsuse huvides saab vältida keerulisi ja mitme nõudega katsestsenaariume. Hind on võrdeline nende arvuga. Seega on alati soovitatav joosta ainult valitud ja nõutud vastavalt kliendi prioriteedile.

Näited

Allpool on toodud mõned näited testistsenaariumist

Buykartsi veebiostude rakenduse testistsenaarium

Testistsenaariumid, mida saab veebikaubanduse rakenduse Buykart kontrollimisel arvesse võtta, on järgmised:

1. testi stsenaarium: sisselogimisfunktsioonide kontrollimine

Proovijuhtumid, mida saab loomise puhul arvestada, on järgmised:

  • Rakenduse käitumist kehtiva sisselogimis ID ja kehtiva parooli sisestamisel saab kontrollida.
  • Rakenduse käitumist kehtiva sisselogimis ID ja kehtetu parooli sisestamisel saab kontrollida.
  • Rakenduse käitumist vale sisselogimise ID ja kehtiva parooli sisestamisel saab kontrollida.
  • Rakenduse käitumist vale sisselogimise ID ja kehtetu parooli sisestamisel saab kontrollida.
  • Rakenduse käitumist sisselogimisel saab sisselogimise ID sisestamiseta ilma paroolita kontrollida.
  • Rakenduse käitumist sisselogimisel saab parooliga sisselogimisel ilma sisselogimis IDta kontrollida.
  • Rakenduse käitumist sisselogimisel ilma sisselogimise ID ja parooli sisestamata saab kontrollida.
  • Rakenduse käitumine, kui on valitud unustatud parool.

2. stsenaarium: otsingufunktsioonide kontrollimine

Proovijuhtumid, mida saab loomise puhul arvestada, on järgmised:

  • Rakenduse käitumine kehtiva toote otsimisel.
  • Rakenduse käitumine kehtetu toote otsimisel.

3. stsenaarium: toote üksikasjade kontrollimine

Proovijuhtumid, mida saab loomise puhul arvestada, on järgmised:

  • Rakenduse käitumine toote valimisel.
  • Rakenduse käitumine on toote loendis.
  • Rakenduse käitumine toote ostukorvi lisamisel.
  • Rakenduse käitumine, kui on valitud suvand Osta kohe.
  • Rakenduse käitumine vale aadressi sisestamisel.
  • Rakenduse käitumine kehtiva aadressi sisestamisel.
  • Rakenduse käitumine mitme maksevõimaluse kontrollimisel.

4. stsenaarium: maksefunktsioonide kontrollimine

Proovijuhtumid, mida saab loomise puhul arvestada, on järgmised:

  • Rakenduse käitumine iga maksevõimaluse valimisel.
  • Rakenduse käitumine kehtiva makseviisi valimisel.
  • Rakenduse käitumine kehtetu makseviisi valimisel.
  • Rakenduse käitumine makse õnnestumisel.
  • Rakenduse käitumine makse tagasilükkamise korral.

5. stsenaarium: tellige üksikasjade funktsionaalsuse kontrollimine

Proovijuhtumid, mida saab loomise puhul arvestada, on järgmised:

  • Rakenduse käitumine iga tellimuse valimisel.
  • Rakenduse käitumine, kui on valitud suvand Tagasta toode.
  • Rakenduse käitumine, kui on valitud tootevalik.
  • Rakenduse käitumine, kui on valitud suvand Toote ülevaade.

Järeldus

See toimib testijatele nõuetekohase juhendina ja aitab neil testimist tõhusamaks muuta. See aitab vähendada testimise keerukust ja koondamist. Iga katsejuhtum on parema mõistmise huvides üksikasjalikult kirjutatud. Testijate jaoks on see väga aja kokkuhoid.

Soovitatavad artiklid

See on olnud teemaks Mis on testistsenaarium. Siin arutleme erinevate stsenaariumide loomise üle erinevate näidetega. Võite lisateabe saamiseks vaadata ka järgmisi artikleid -

  1. Töökoha ebakindluse stress
  2. Ise motiveeritud ja pühendunud
  3. Mis on Agile testimine?
  4. Kuidas testijuhtumit kirjutada?

Kategooria:

Tarkvaraarendus