Meni

Testni scenarij in testni primer: Kakšna je razlika med njimi?

test scenario vs test case

Preizkusite Naš Instrument Za Odpravo Težav

Razlika med testnim scenarijem in testnim primerom.

Pred 6 leti , medtem ko sem med delom s srednje velikim MNC, ko sem predlagal dokumentiranje testnih scenarijev, namesto da bi zapravljal čas za pripravo celotnega dokaznega dokumenta, imenovanega testni primeri, so se vse glave moteče obrnile name.

Pogled na obrazih je jasno kazal, da sem naredil veliko napako, ko sem jo predlagal. Čeprav nihče ni zanikal ideje, je ni nihče niti sprejel. Vsi so menili, da bi bilo upoštevanje tradicije, torej pisanje testnih primerov, varnejše. Nisem mogel trditi.

Preskusni scenarij proti testnemu primeru

Po 4 letih , je podjetje prejelo projekt testiranja, pri katerem je bila edina omejitev čas in edino pričakovanje popoln dokaz testiranje.

Spet smo bili na sestanku in razpravljali o idejah, da bi dosegli kritični rok. V aplikaciji je šlo predvsem za iskanje in ustvarjanje različnih poročil prek različnih elementov menija. Dokumentiranje testnih primerov naj bi večino časa ugrabilo in nismo bili prepričani, koliko dokumenta bo stranki namenil.

Predlagal sem dokumentiranje testnih scenarijev in nekako z nekaj obotavljanja so se vsi strinjali. Ni treba omenjati, da bi lahko prihranili dragocen čas dokumentacije in ga lahko uporabili za testiranje.

Kaj se boste naučili:

Ali se testni primeri hitro zamenjajo s testnimi scenariji?

Sčasoma, ko se vse spreminja, so se tudi industrija programske opreme in procesi zelo spremenili.

kako dobiti omrežni varnostni ključ za wifi -

Tradicionalno Slap in V-models nadomeščajo gibčni in ponavljajoči se modeli. Potrebna je dokumentacija toda za izpolnitev rokov in lažji in preglednejši postopek je mogoče spremeniti način dokumentiranja.

Kdaj je dokumentacija o testnih primerih pomembna?

  1. Naročnik je zahteval enako kot del projekta.
  2. Časovna omejitev ni (mislim, da to ni mogoče).
  3. Preizkuševalci so bolj sveži ali neznani.
  4. Politika podjetja (trdno verjamem, da jo je mogoče spremeniti).

Naj z vami delim eno izkušnjo:

Jaz in moja ekipa smo sodelovali pri testiranju projekta podjetja Fortune 500 s prilagodljivimi roki. Testne primere smo dokumentirali z najboljšo razpoložljivo predlogo in jo odobrila stranka.

Ko se je gradnja začela objavljati za ekipo QA, smo bili večino dneva dolžni mehanično slediti 100 testnim primerom na dan, posodobiti dokument z rezultatom pass / fail in ga konec dneva poslati stranki. Večino od člani ekipe so se začeli pritoževati monotono delo vendar je podjetje ustvarjalo prihodke.

Potem je bil vmes odmor za en dan, brez nove gradnje za preizkus. Na začetku dneva smo sedeli skupaj in se dogovarjali, kaj bomo naredili za ta dan. Ko sem predlagal, da bi ustvarili več idej za izboljšanje dokumenta o testnem primeru, so vsi člani ekipe zanikali, da bi si prizadevali.

Glede nanje ni bilo več o čem razmišljati, saj smo zajeli vse scenarije. In jih prepričal razmišljajte iz škatle in ustvarite več idej je bilo res težko.

Ko dokumentiramo testne primere in tudi to, ko jih stranka odobri, večino časa misli, da smo opravili svoje delo in naš um samodejno preneha razmišljati o kakršnem koli prizadevanju za razmislek o drugih načinih testiranja izdelka.

In verjemite mi, ko pripravimo dokument o testnih primerih, ga želimo le mehanično upoštevati. Povejte mi, kolikokrat ste v svoji karieri doživeli, da ste vi ali sotekmovalec v odobreni dokument o testnih primerih ponudili dodatne testne primere?

ukaz grep v unixu s primeri

Še ena izkušnja:

Med tedenskimi timskimi izzivi smo napovedali prijavo in člane ekipe pozvali, naj vlijejo testne scenarije.

Vsi člani ekipe, vključno s tistimi, ki so pozno odgovorili ali se niso odzvali, so dali ideje. Zakaj? Ni bilo formalne dokumentacije, kjer bi morali izpolniti pričakovani rezultat za vsako zaporedje funkcionalnosti in predpogoj za vsak testni primer. Na dan smo zbrali 40 testnih scenarijev in to je bila odlična izkušnja.

Da bi favorizirali svoje izkušnje, Predstavil bi primer.

Vzemite vzorčno aplikacijo, recimo prijavno stran z gumbi za uporabniško ime, geslo, prijavo in preklic. Na zahtevo, da napišemo testne primere za iste, bomo na koncu napisali več kot 50 testnih primerov s kombiniranjem različnih možnosti in podrobnosti.

Če pa bodo napisani testni scenariji, bo šlo za 10 vrstic, kot je prikazano spodaj:

Scenarij na visoki ravni: Funkcionalnost prijave
Scenariji na nizki ravni :

1. Če želite preveriti, ali se aplikacija zažene
2. Za preverjanje besedilne vsebine na prijavni strani
3. Če želite preveriti polje Uporabniško ime
4. Če želite preveriti polje za geslo
5. Če želite preveriti funkcijo gumba za prijavo in gumba za preklic

Poglej tudi=> 180+ vzorčnih testnih scenarijev za testiranje spletnih in namiznih aplikacij.

Ker nam vsem primanjkuje časa, testni scenariji delujejo kot razpršilo proti bolečinam in ne kot stari IODEX. In še vedno je učinek enak.

Razlike med preskusnim scenarijem in testnim primerom v tabelarni obliki

Na koncu bi rad povzel razliko med testnim scenarijem in testnim primerom:

Testni primeriPreskusni scenariji
Kaj je => Koncept, ki vsebuje podrobne informacije, kaj preizkusiti, korake, ki jih je treba izvesti, in pričakovani rezultat istegaKoncept, ki ponuja enovrstične informacije o tem, kaj preizkusiti.
Gre za => Gre bolj za dokumentiranje podrobnosti.Gre bolj za razmišljanje in razpravljanje o podrobnostih.
Pomen => Pomembno je, če testiranje ni potrebno, razvoj pa je na mestu. Pisanje testnih primerov s podrobnostmi bo sinhroniziralo tako razvijalce kot tudi ekipo za zagotavljanje kakovosti.Pomembno je, ko je časa manj in se večina članov ekipe lahko strinja / razume podrobnosti iz scenarija ene linije.
Prednost => Enkratna dokumentacija vseh testnih primerov je koristna za spremljanje 1000-ih krogov regresijskega testiranja v prihodnosti.
Največkrat je koristno pri poročanju o napakah. Preizkuševalec mora le navesti referenčno številko testnega primera in ne zahteva omembe podrobnosti vsake minute.
Prihranek časa in dejavnost ustvarjanja idej, ki jo daje prednost skupnosti za testiranje programske opreme nove generacije.
Spreminjanje in dodajanje je preprosto in ni specifično za osebo.
Za velik projekt, pri katerem skupina ljudi pozna samo določene module, ta aktivnost daje priložnost vsem, da pogledajo druge module in nevihte v možganih ter razpravljajo o njih.
Koristno za => Popolnoma dokazni dokument o testnem primeru je življenjska črta za novega preizkuševalca.Dobro preskusno pokritost lahko dosežemo z delitvijo uporabe v testnih scenarijih in zmanjšuje ponovljivost in kompleksnost izdelka
Pomanjkljivost => Zahteva čas in denar, saj zahteva več sredstev za podrobno določitev vsega, kaj in kako testiratiČe ga je ustvarila določena oseba, pregledovalec ali drug uporabnik morda ne bo sinhroniziral natančne ideje, ki stoji za tem. Potrebujete več razprav in skupinske napore.

Zaključek

Testni primeri so najpomembnejši del življenjskega cikla razvoja programske opreme in brez njega je težko nekaj izslediti, razumeti, slediti in utemeljiti. Toda v dobi Agile se testni primeri hitro zamenjajo s testnimi scenariji.

Pogost testni kontrolni seznam za vsako vrsto testiranja (testiranje baz podatkov, testiranje grafičnega uporabniškega vmesnika, funkcionalnost itd.), skupaj s testnimi scenariji, je sodobna artilerija za programske preizkuševalce. Razprave, usposabljanje, vprašanja in praksa lahko vsekakor spremenijo končni graf svojo produktivnost kot tudi matrico poročil o napakah.

Kot običajno pozdravljamo vaše misli in vprašanja. Prosim, nastavite se.

PREV Vadnica | NASLEDNJA Vadnica

Priporočeno branje

^