how write test cases
V tej poglobljeni vadnici o tem, kako pisati testne primere, sem opisal podrobnosti, kaj je testni primer, njegove standardne definicije in tehnike oblikovanja testnih primerov.
Kaj je testni primer?
Testni primer vsebuje komponente, ki opisujejo vnos, dejanje in pričakovani odziv, da se ugotovi, ali funkcija aplikacije deluje pravilno.
Testni primer je sklop navodil za “KAKO” za potrditev določenega testnega cilja / cilja, ki nam bo v nadaljevanju sporočil, ali je pričakovano vedenje sistema zadovoljeno ali ne.
Seznam vaj, zajetih v tej seriji za pisanje testnih primerov:
Kako pisati:
Vadnica št. 1: Kaj je testni primer in kako napisati testne primere (ta vadnica)
Vadnica # 2: Vzorčna predloga testnega primera s primeri (prenos) (morati prebrati)
Vadnica št. 3: Pisanje testnih primerov iz dokumenta SRS
Vadnica # 4: Kako napisati testne primere za dani scenarij
Vadnica št. 5: Kako se pripraviti na pisanje testnih primerov
Vadnica # 6: Kako pisati negativne testne primere
Primeri:
Vadnica št. 7: 180+ vzorčnih testnih primerov za spletne in namizne aplikacije
Vadnica št. 8: 100+ pripravljenih testnih scenarijev (kontrolni seznam)
Tehnike pisanja:
želim preizkusiti izdelke za podjetja
Vadnica št. 9: Graf vzrokov in posledic - dinamična tehnika pisanja testnih primerov
Vadnica št. 10: Državna prehodna preizkusna tehnika
Vadnica št. 11: Tehnika preskušanja pravokotnih nizov
Vadnica # 12: Tehnika ugibanja napak
Vadnica št. 13: Tehnika oblikovanja preizkusa tabele za validacijo polja (FVT)
Testni primeri proti testnim scenarijem:
Vadnica št. 14: Testni primeri proti testnim scenarijem
Vadnica št. 15: Razlika med testnim načrtom, testno strategijo in testnim primerom
Avtomatizacija:
Vadnica št. 16: Kako izbrati pravilne testne primere za avtomatizacijsko preskušanje
Vadnica # 17: Kako prevesti primere ročnih preizkusov v skripte za avtomatizacijo
Orodja za upravljanje testov:
Vadnica # 18: Najboljša orodja za upravljanje testov
Vadnica št. 19: TestLink za upravljanje testnih primerov
Vadnica št. 20: Ustvarjanje in upravljanje testnih primerov s pomočjo HP Quality Center
Vadnica št. 21: Izvajanje testnih primerov z uporabo ALM / QC
Primeri, specifični za domeno:
Vadnica št. 22: Testni primeri za uporabo ERP
Vadnica # 23: JAVA testni primeri
Vadnica # 24: Analiza mejne vrednosti in delitev enakovrednosti
Nadaljujmo s prvo vadnico v tej seriji.
Priporočena orodja:
Preden nadaljujete s postopkom pisanja testnih primerov, priporočamo, da prenesete to orodje za upravljanje testnih primerov. To vam bo olajšalo postopek pisanja testnih primerov, omenjen v tej vadnici:
# 1) TestRail
=> Prenesite orodje za upravljanje testnih primerov TestRail
# 2) TestMonitor
Vrhunsko spletno upravljanje testov. Revolucionarno enostavno.
TestMonitor je celovito orodje za upravljanje testov za vsako organizacijo. Preprost, intuitiven pristop k testiranju. Ne glede na to, ali izvajate programsko opremo za podjetja, potrebujete preverjanje kakovosti, gradite kakovostno aplikacijo ali potrebujete pomoč pri preizkusnem projektu, je TestMonitor pokril vas.
=> Obiščite spletno mesto TestMonitor
Kaj se boste naučili:
- Kaj je testni primer in kako napisati testne primere?
- Nasveti za pisanje testov
- Kako doseči odličnost v dokumentaciji o testnih primerih
- Koristni nasveti in triki
- # 1) Ali je vaš testni dokument v dobri obliki?
- # 2) Ne pozabite pokrivati negativnih primerov
- # 3) Izvedite atomske preizkusne korake
- # 4) Dajte prednost preskusom
- # 5) Zaporedje je pomembno
- # 6) Komentarjem dodajte časovni žig in ime preizkuševalca
- # 7) Vključi podrobnosti brskalnika
- # 8) V dokumentu hranite dva ločena lista - „Napake“ in „Povzetek“
- Koristni nasveti in triki
- Kako NE pisati testov
- Kako izboljšati učinkovitost testnih primerov
- Pomen standardizacije testnih primerov
Kaj je testni primer in kako napisati testne primere?
Pisanje učinkovitih primerov je spretnost. In tega se lahko naučite iz izkušenj in poznavanja preizkušene aplikacije.
Za osnovna navodila o pisanju testov si oglejte naslednji video:
Zgornji viri bi nam morali dati osnove postopka pisanja testa.
Stopnje postopka pisanja testa:
- 1. stopnja: Na tej ravni boste napisali osnovni primeri iz razpoložljive specifikacije in uporabniško dokumentacijo.
- 2. stopnja: To je praktična stopnja v katerih so primeri pisanja odvisni od dejanskega funkcionalnega in sistemskega toka aplikacije.
- 3. stopnja: To je stopnja, v kateri boste razvrstili nekaj primerov in napiši testni postopek . Preskusni postopek ni nič drugega kot skupina majhnih primerov, morda največ 10.
- 4. stopnja: Avtomatizacija projekta. To bo zmanjšalo človekovo interakcijo s sistemom, zato se bo QA lahko osredotočil na trenutno posodobljene funkcionalnosti za testiranje, namesto da bi bil zaseden z regresijskim testiranjem.
Zakaj pišemo teste?
Osnovni cilj pisanja primerov je za potrditev testne pokritosti aplikacije.
Če delate v kateri koli organizaciji CMMi, se preizkusni standardi natančneje upoštevajo. Pisanje primerov prinaša neke vrste standardizacijo in zmanjšuje priložnostni pristop pri testiranju.
Kako napisati testne primere?
Polja:
- ID testnega primera
- Enota za testiranje: Kaj preveriti?
- Predpostavke
- Podatki o preskusu: Spremenljivke in njihove vrednosti
- Koraki, ki jih je treba izvesti
- pričakovani rezultati
- Dejanski rezultat
- Pass / Fail
- Komentarji
Osnovna oblika izjave o testnem primeru
Preverite
Uporaba (ime orodja, ime oznake, pogovorno okno itd.)
S (pogoji)
Za (kaj je vrnjeno, prikazano, prikazano)
Preverite: Uporablja se kot prva beseda preizkusne izjave.
Uporaba: Ugotoviti, kaj se testira. Tukaj lahko namesto uporabe vnesete ali izberete, odvisno od situacije.
Za katero koli aplikacijo morate zajeti vse vrste testov, kot so:
- Funkcionalni primeri
- Negativni primeri
- Primeri mejne vrednosti
Medtem ko pišem te vse svoje TC bi morali biti preprosti in lahko razumljivi .
**************************************************
Nasveti za pisanje testov
Ena najpogostejših in glavnih dejavnosti preizkuševalca programske opreme (oseba SQA / SQC) je pisanje testnih scenarijev in primerov.
S to glavno dejavnostjo je povezanih nekaj pomembnih in kritičnih dejavnikov. Najprej si oglejmo te dejavnike iz ptičje perspektive.
Pomembni dejavniki pisnega procesa:
a) TC so nagnjeni k redni reviziji in posodobitvi:
Živimo v nenehno spreminjajočem se svetu, kar velja tudi za programsko opremo. Spremembe programske opreme neposredno vplivajo na primere. Kadar koli se zahteve spremenijo, je treba posodobiti TC.
Vendar ni le sprememba zahteve tista, ki bi lahko povzročila revizijo in posodobitev TC. Med izvajanjem TC-jev se v mislih porajajo številne ideje in lahko se prepoznajo številni podpogoji enega TC-ja. Vse to povzroča posodobitev TC-jev in včasih celo vodi do dodajanja novih TC-jev.
Poleg tega med regresijskim testiranjem več popravkov in / ali valovanj zahteva revidirane ali nove TC.
b) TC-ji so nagnjeni k distribuciji med preizkuševalci, ki jih bodo izvedli:
Seveda skoraj ni take situacije, da bi en preskuševalec izvedel vse TC. Običajno obstaja več preizkuševalcev, ki preizkušajo različne module ene same aplikacije. Torej so TC-ji razdeljeni med preizkuševalce glede na njihova področja aplikacije, ki se preskuša.
Nekatere TC-je, ki so povezani z integracijo aplikacije, lahko izvaja več preskuševalcev, druge TC-je pa lahko izvaja samo en preskuševalec.
c) TC-ji so nagnjeni k združevanju in združevanju:
Običajno in običajno je, da TC, ki pripadajo enemu preskusnemu scenariju, običajno zahtevajo njihovo izvedbo v določenem zaporedju ali v obliki skupine. Obstajajo lahko nekateri predpogoji za TC, ki zahtevajo izvedbo drugih TC pred samim zagonom.
Podobno lahko v skladu s poslovno logiko AUT en sam TC prispeva k več preskusnim pogojem, en preskusni pogoj pa je lahko sestavljen iz več TC.
d) TC imajo tendenco medsebojne odvisnosti:
To je tudi zanimivo in pomembno vedenje TC, ki pomeni, da so lahko medsebojno odvisni. Ta težnja je bolj vidna od srednje do velikih aplikacij s kompleksno poslovno logiko.
Najbolj jasno področje katere koli aplikacije, kjer je to vedenje vsekakor mogoče opaziti, je interoperabilnost med različnimi moduli enakih ali celo različnih aplikacij. Preprosto povedano, kjer koli so različni moduli ene same aplikacije ali več aplikacij medsebojno odvisni, se enako vedenje odraža tudi v TC.
e) TC-ji so nagnjeni k distribuciji med razvijalci (zlasti v testnem razvojnem okolju):
Pomembno dejstvo pri TC je, da jih preizkuševalci ne smejo uporabljati samo. V običajnem primeru, ko razvijalci odpravijo napako, posredno uporabljajo TC za odpravo težave. Podobno, če se sledi preizkusnemu razvoju, razvijalci neposredno uporabljajo TC-je, da gradijo svojo logiko in zajemajo vse scenarije v svoji kodi, ki jih obravnavajo TC-ji.
Nasveti za pisanje učinkovitih testov:
Upoštevajoč zgornjih 5 dejavnikov, tukaj je nekaj nasvetov za pisanje učinkovitih TC.
Začnimo!!!
# 1) Naj bo preprosto, vendar ne preveč preprosto; naj bo zapleteno, vendar ne preveč zapleteno:
Ta izjava se zdi paradoksna. Vendar obljubim, da ni tako. Naj bodo vsi koraki TC-jev atomski in natančni. Omenite korake s pravilnim zaporedjem in pravilno preslikavo pričakovanih rezultatov. Testni primer mora biti samoumeven in enostaven za razumevanje. To je tisto, kar želim poenostaviti.
Zdaj je to zapleteno sredstvo, da ga integriramo s testnim načrtom in drugimi TC. Kadar in kadar je to potrebno, se obrnite na druge TC-je, ustrezne artefakte, GUI-je itd. Toda to storite uravnoteženo. Ne naredite preizkuševalca, ki bi se med kupom dokumentov premikal sem in tja za izvedbo enega samega preskusnega scenarija.
Po drugi strani pa preskuševalcu ne dovolite, da teh kompaktnih dokumentov dokumentira na zelo kompakten način. Med pisanjem TC-jev ne pozabite, da jih boste morali vi ali kdo drug popraviti in posodobiti.
# 2) Po dokumentiranju testnih primerov enkrat preglejte kot Tester:
Nikoli ne mislite, da je delo končano, ko napišete zadnji TC testnega scenarija. Pojdite na začetek in enkrat preglejte vse TC, vendar ne z miselnostjo pisca TC ali načrtovalca testiranj. Preglejte vse TC z mislijo preizkuševalca. Razmišljajte racionalno in poskušajte svoje TC-je suho zagnati.
Ocenite vse korake in preverite, ali ste jih jasno razumeli na razumljiv način in ali so pričakovani rezultati v skladu s temi koraki.
Prepričajte se, da podatki o preskusu določeno v TC je izvedljivo ne samo za dejanske preizkuševalce, temveč tudi glede na realno časovno okolje. Prepričajte se, da med TC-ji ni navzkrižja odvisnosti in preverite, ali so vsi sklici na druge TC-je / artefakte / GUI-je točni. V nasprotnem primeru imajo preizkuševalci lahko velike težave.
# 3) Vezani in olajšajte preizkuševalce:
Podatkov o preskusu ne puščajte na preizkuševalcih. Dajte jim vrsto vhodnih podatkov, zlasti tam, kjer je treba opraviti izračune ali če je vedenje aplikacije odvisno od vhodnih podatkov. Lahko jim dovolite, da sami določijo vrednosti preskusnih podatkov, vendar jim nikoli ne dajo svobode, da sami izberejo preskusne podatke.
Ker lahko namerno ali nenamerno znova in znova uporabljajo iste preskusne podatke, nekateri pomembni preskusni podatki pa se med izvajanjem TC lahko prezrejo.
Poskrbite, da bodo preizkuševalci enostavni, tako da organizirate TC-je po kategorijah preskušanja in povezanih področjih aplikacije. Jasno je, da poučite in omenite, kateri TC so medsebojno odvisni in / ali serijski. Prav tako izrecno navedite, kateri TC so neodvisni in izolirani, tako da lahko preizkuševalec ustrezno upravlja svojo splošno dejavnost.
Na tej točki vas bo morda zanimalo prebrati o analizi mejnih vrednosti, ki je strategija oblikovanja testnih primerov, ki se uporablja pri testiranju črne škatle. Kliknite tukaj če želite vedeti več o tem.
# 4) Bodite sodelavec:
Nikoli ne sprejemajte FS ali projektnega dokumenta, kakršen je. Vaša naloga ni le, da preberete FS in določite testne scenarije. Ker ste vir QA, nikoli ne oklevajte in prispevajte k poslu ter dajte predloge, če menite, da je mogoče v aplikaciji nekaj izboljšati.
Predlagajte tudi razvijalcem, zlasti v razvojnem okolju, ki ga vodi TC. Predlagajte spustne sezname, kontrolnike koledarja, izbirni seznam, izbirne gumbe za skupine, bolj smiselna sporočila, opozorila, pozive, izboljšave, povezane z uporabnostjo itd.
Ker ste QA, ne samo preizkušajte, ampak spremenite razliko!
# 5) Nikoli ne pozabite na končnega uporabnika:
Najpomembnejši deležnik je „končni uporabnik“, ki bo končno uporabil aplikacijo. Zato ga nikoli ne pozabite na nobeni stopnji pisanja strokovnjakov. Dejansko končnega uporabnika v SDLC ne bi smeli prezreti v nobeni fazi. Vendar je moj dosedanji poudarek le povezan z mojo temo.
Torej med prepoznavanjem testnih scenarijev nikoli ne spreglejte tistih primerov, ki jih bo uporabnik večinoma uporabil, ali primerov, ki so poslovno kritični, četudi se uporabljajo manj pogosto. Ostanite na mestu končnega uporabnika in nato preglejte vse TC in presodite praktično vrednost izvajanja vseh svojih dokumentiranih TC.
**************************************************
Kako doseči odličnost v dokumentaciji o testnih primerih
Kot preizkuševalec programske opreme se boste zagotovo strinjali z mano, da je priprava popolnega testnega dokumenta res zahtevna naloga.
Vedno pustimo nekaj možnosti za izboljšave pri svojem Dokumentacija o testnem primeru . Včasih prek TC-jev ne moremo zagotoviti 100-odstotne pokritosti s preizkusi, včasih pa predloga preizkusa ni enaka ali pa preskusom ne zagotavljamo dobre berljivosti in jasnosti.
Kot preskuševalec, kadar koli boste pozvani, da napišete testno dokumentacijo, ne začnite le ad hoc. Zelo pomembno je, da dobro razumete namen pisanja testnih primerov, še preden se lotite dokumentacijskega postopka.
Preizkusi morajo biti vedno jasni in jasni. Zapisani naj bodo tako, da preskuševalcu omogočajo enostavno izvedbo celotnega testiranja, tako da sledijo korakom, opredeljenim v vsakem od testov.
Poleg tega mora dokument o testnem primeru vsebovati toliko primerov, kolikor jih je treba predložiti pokritost s testom . Na primer , poskusite zajeti preskušanje vseh možnih scenarijev, ki se lahko pojavijo v vaši programski aplikaciji.
Upoštevajoč zgornje točke, vas bom zdaj vodil skozi predstavitev o tem, kako doseči odličnost v testni dokumentaciji.
Koristni nasveti in triki
Tukaj vam bom dal nekaj koristnih smernic, ki vam bodo omogočile, da se v svoji testni dokumentaciji umaknete od ostalih.
# 1) Ali je vaš testni dokument v dobri obliki?
Najboljši in preprost način za organiziranje testnega dokumenta je, če ga razdelite na več uporabnih odsekov. Celotno testiranje razdelite na več testnih scenarijev. Nato vsak scenarij razdelite na več testov. Na koncu razdelite vsak primer na več testnih korakov.
Če uporabljate excel, dokumentirajte vsak testni primer na poseben list delovne zvezke, kjer vsak testni primer opisuje en celoten testni potek.
# 2) Ne pozabite pokrivati negativnih primerov
Kot preizkuševalec programske opreme morate premišljeno razmišljati in pripraviti vse možnosti, s katerimi se srečuje vaša aplikacija. Kot preizkuševalci moramo preveriti, ali je treba ustaviti in prijaviti kakršen koli neupravičen poskus vstopa v programsko opremo ali kakršne koli neveljavne podatke, ki tečejo po aplikaciji.
Tako je negativni primer tako pomemben kot pozitiven primer. Prepričajte se, da za vsak scenarij, ki ga imate dva testna primera - en pozitiven in en negativen . Pozitivni mora pokrivati predvideni ali običajni pretok, negativni pa nenamerni ali izredni pretok.
# 3) Izvedite atomske preizkusne korake
Vsak testni korak mora biti atomski. Nadaljnjih pod korakov ne bi smelo biti. Preprostejši in jasnejši je testni korak, lažje bi bilo nadaljevati s testiranjem.
# 4) Dajte prednost preskusom
Pogosto imamo stroge časovne roke za dokončanje testiranja za aplikacijo. V tem primeru lahko zamudimo preizkus nekaterih pomembnih funkcionalnosti in vidikov programske opreme. Da bi se temu izognili, morate med dokumentiranjem označiti prednost pri vsakem preizkusu.
Za določanje prioritete testa lahko uporabite katero koli kodiranje. Na splošno je bolje uporabiti katero koli od treh stopenj, visoka, srednja in nizka ali 1, 50 in 100. Torej, ko imate strogo časovno os, morate najprej opraviti vse teste z visoko prioriteto in nato preiti na teste s srednjo in nizko prioriteto.
Na primer - za nakupovalno spletno mesto je preverjanje zavrnitve dostopa zaradi neveljavnega poskusa prijave v aplikacijo lahko zelo prednostna naloga, preverjanje prikaza ustreznih izdelkov na uporabniškem zaslonu je lahko srednje prednostna naloga in preverjanje barve besedila, prikazanega na zaslonski gumbi so lahko preskus z nizko prioriteto.
# 5) Zaporedje je pomembno
Preverite, ali je zaporedje korakov v testu popolnoma pravilno. Napačno zaporedje korakov lahko povzroči zmedo. Po možnosti bi morali koraki definirati tudi celotno zaporedje od vstopa v aplikacijo do izstopa iz aplikacije za določen scenarij, ki se preskuša.
# 6) Komentarjem dodajte časovni žig in ime preizkuševalca
V nekaterih primerih lahko preizkušate aplikacijo, nekdo spreminja vzporedno z isto aplikacijo ali pa jo lahko nekdo po končanem testiranju posodobi. To vodi do situacije, ko se lahko rezultati testa s časom spreminjajo.
Zato je vedno bolje, da v komentarje testiranja dodate časovni žig z imenom preizkuševalca, da lahko rezultat testa (opravljen ali neuspešen) pripišemo stanju aplikacije v določenem času. Lahko pa imate Datum izvršitve «, Dodan ločeno v testni primer, ki bo izrecno opredelil časovni žig testa.
# 7) Vključi podrobnosti brskalnika
Kot veste, se lahko rezultati testa, če gre za spletno aplikacijo, razlikujejo glede na brskalnik, v katerem se test izvaja. Za lažjo uporabo drugih preizkuševalcev, razvijalcev ali tistih, ki pregledujejo testni dokument, dodajte ohišju ime in različico brskalnika, da bo napako mogoče enostavno ponoviti.
# 8) V dokumentu hranite dva ločena lista - „Napake“ in „Povzetek“
Če dokumentirate v excelu, bi morala biti prva dva lista delovnega zvezka Povzetek in napake. List Povzetek mora povzeti testni scenarij, list Napake pa mora vsebovati vse težave, ki so se pojavile med testiranjem. Pomen dodajanja teh dveh listov je v tem, da bo bralcu / uporabniku dokumenta omogočil jasno razumevanje testiranja.
Torej, kadar je čas omejen, se lahko ta dva lista izkažeta za zelo koristna pri zagotavljanju pregleda preskusov.
Testni dokument mora zagotavljati najboljšo možno pokritost s testom, odlično berljivost in mora biti v celoti v enaki obliki.
Odličnost v testni dokumentaciji lahko dosežemo tako, da imamo v mislih le nekaj bistvenih nasvetov, kot je organizacija dokumenta o testnem primeru, dajanje prednostnih nalog TC, vse v ustreznem zaporedju, vključno z vsemi obveznimi podrobnostmi za izvedbo TC, in zagotavljanje jasnih in jasnih preskusnih korakov, itd., kot je razloženo zgoraj.
**************************************************
Kako NE pisati testov
Večino časa porabimo za pisanje, pregledovanje, izvajanje ali vzdrževanje le-teh. Zelo žalostno je, da so tudi testi najbolj nagnjeni k napakam. Razlike v razumevanju, praksah organizacijskega testiranja, pomanjkanju časa itd. So nekateri razlogi, da pogosto vidimo teste, ki puščajo veliko želenega.
Na naši spletni strani je veliko člankov o tej temi, a tukaj bomo videli Kako NE pisati testnih primerov - nekaj nasvetov, ki bodo ključni za ustvarjanje prepoznavnih, kakovostnih in učinkovitih testov.
Preberite si in upoštevajte, da so ti nasveti namenjeni tako novim kot izkušenim preizkuševalcem.
3 najpogostejše težave v testnih primerih
- Sestavljeni koraki
- Vedenje aplikacije se šteje za pričakovano
- Več pogojev v enem primeru
Ti trije morajo biti na mojem seznamu 3 najpogostejših težav v postopku pisanja testa.
Zanimivo je, da se to dogaja tako z novimi kot z izkušenimi preizkuševalci, mi pa še naprej sledimo istim pomanjkljivim postopkom, ne da bi se zavedali, da lahko nekaj preprostih ukrepov stvari enostavno popravi.
Pojdimo k njemu in se podrobno pogovorimo o vsakem:
# 1) Sestavljeni koraki
Najprej, kaj je sestavljeni korak?
Na primer, dajete navodila od točke A do točke B: če rečete: 'Pojdite na kraj XYZ in nato v ABC', to ne bo imelo velikega smisla, ker se tu znajdemo v razmišljanju - 'Kako naj najprej pridite do XYZ «- namesto tega se začnite z» Od tu zavijte levo in pojdite 1 miljo, nato zavijte desno na Rd. št. 11, ki prispe na XYZ “, bi lahko dosegel boljše rezultate.
Popolnoma ista pravila veljajo tudi za teste in njihove korake.
Na primer Pišem test za Amazon.com - naročite kateri koli izdelek.
Sledijo moji preizkusni koraki (Opomba: pišem samo korake in ne vseh ostalih delov testa, kot je pričakovani rezultat itd.)
do . Zaženite Amazon.com
b . Poiščite izdelek tako, da v polje za iskanje na vrhu zaslona vnesete ključno besedo / ime izdelka.
c . Med prikazanimi rezultati iskanja izberite prvega.
d . Na strani s podrobnostmi o izdelku kliknite Dodaj v košarico.
je . Odjava in plačilo.
f . Preverite stran za potrditev naročila.
Zdaj, lahko prepoznate, kateri od teh je sestavljen korak? Desni korak (e)
Ne pozabite, da se pri testih vedno govori o tem, kako preizkusiti, zato je pomembno, da v test napišete natančne korake v razdelku »Kako plačati«.
Zato je zgornji primer učinkovitejši, če je napisan spodaj:
do . Zaženite Amazon.com
b . Poiščite izdelek tako, da v polje za iskanje na vrhu zaslona vnesete ključno besedo / ime izdelka.
c . Med prikazanimi rezultati iskanja izberite prvega.
d . Na strani s podrobnostmi o izdelku kliknite Dodaj v košarico.
je . Na strani nakupovalne košarice kliknite Checkout.
f . Vnesite podatke o CC, podatke o pošiljanju in obračunu.
g . Kliknite Checkout.
h . Preverite stran za potrditev naročila.
Zato je sestavljeni korak tisti, ki ga lahko razdelimo na več posameznih korakov. Ko bomo naslednjič pisali teste, bodimo pozorni na ta del in prepričan sem, da se boste strinjali z mano, da to počnemo pogosteje, kot se zavedamo.
# 2) Vedenje aplikacije se šteje za pričakovano
V današnjem času se mora vse več projektov spoprijeti s to situacijo.
Pomanjkanje dokumentacije, ekstremno programiranje, hitri razvojni cikli so redki razlogi, zaradi katerih se moramo zanašati na aplikacijo (starejša različica ali tako), da bodisi napišemo teste bodisi temeljimo na samem testiranju. Kot vedno je to dokazano slaba praksa - ne vedno v resnici.
Neškodljivo je, če ohranjate odprtost in pričakujete, da - »AUT bi lahko bil napačen«. Šele takrat, ko ne mislite, da je tako, stvari delujejo slabo. Kot vedno bomo pustili, da bodo primeri govorili.
Če je spodaj stran, za katero pišete / oblikujete preskusne korake:
Primer 1:
Če so koraki za testni primer naslednji:
- Zaženite spletno mesto za nakupovanje.
- Kliknite Pošiljanje in vračilo - Pričakovani rezultat: Na strani s pošiljanjem in vračilom se prikaže stran za pošiljanje in vračilo ter gumb »Nadaljuj«.
Potem to ni pravilno.
Primer 2:
- Zaženite spletno mesto za nakupovanje.
- Kliknite Pošiljanje in vrnitev.
- V polje za vnos številke naročila na tem zaslonu vnesite številko naročila.
- Kliknite Nadaljuj - Pričakovani rezultat: Prikažejo se podrobnosti naročila v zvezi s pošiljanjem in vračili.
Primer 2 je boljši testni primer, ker čeprav se referenčna aplikacija obnaša nepravilno, jo vzamemo le kot smernico, opravimo nadaljnje raziskave in napišemo pričakovano vedenje v skladu s pričakovano pravilno funkcionalnostjo.
Spodnja črta: Aplikacija kot referenca je hitra bližnjica, vendar ima svoje nevarnosti. Dokler smo previdni in kritični, to prinaša neverjetne rezultate.
# 3) Več pogojev v enem primeru
Še enkrat se učimo od Primer .
Oglejte si spodnje korake preizkusa: V nadaljevanju so preskusni koraki v enem preizkusu za prijavo.
a. Vnesite veljavne podatke in kliknite Pošlji.
b. Polje uporabniškega imena pustite prazno. Kliknite Pošlji.
c. Pustite polje za geslo prazno in kliknite Pošlji.
d. Izberite že prijavljeno uporabniško ime / geslo in kliknite Pošlji.
Kar bi morali biti štirje različni primeri, se združi v enega. Morda razmišljate - kaj je s tem narobe? Prihrani veliko dokumentacije in kaj lahko naredim v 4, delam v 1-, ni to super? No, ne čisto. Razlogi?
Beri naprej:
vprašanja in odgovori na agilni metodologiji
- Kaj pa, če eden od pogojev ne uspe - celoten test moramo označiti kot 'neuspešen'. Če celoten primer označimo kot »neuspešen«, to pomeni, da vsi 4 pogoji ne delujejo, kar v resnici ne drži.
- Testi morajo imeti pretok. Od predpogoja do koraka 1 in skozi korake. Če sledim temu primeru, bom v koraku (a), če bo uspešen, prijavljen na stran, kjer možnost »prijava« ni več na voljo. Torej, ko pridem do koraka (b) - kam bo tester vnesel uporabniško ime? Veste, tok je prekinjen.
Torej, pisanje modularnih testov . Sliši se veliko dela, vendar je vse, kar potrebujete, ločiti stvari in uporabiti naše najboljše prijatelje Ctrl + C in Ctrl + V, da delajo za nas. :)
**************************************************
Kako izboljšati učinkovitost testnih primerov
Preizkuševalci programske opreme bi morali svoje teste pisati že v zgodnejši fazi življenjskega cikla razvoja programske opreme, najbolje v fazi zahtev za programsko opremo.
Vodja preskusov ali vodja preverjanja kakovosti mora zbrati in pripraviti največ možnih dokumentov v skladu s spodnjim seznamom.
Zbirka dokumentov za testno pisanje
# 1) Dokument o uporabniških zahtevah
To je dokument, ki navaja poslovni proces, uporabniške profile, uporabniško okolje, interakcijo z drugimi sistemi, zamenjavo obstoječih sistemov, funkcionalne zahteve, nefunkcionalne zahteve, zahteve za licenciranje in namestitev, zahteve glede učinkovitosti, varnostne zahteve, uporabnost in sočasne zahteve itd. .,
# 2) Dokument o poslovni uporabi
Ta dokument podrobno opisuje primer uporabe scenarij funkcionalnih zahtev s poslovnega vidika. Ta dokument zajema poslovne akterje (ali sistem), cilje, predpogoje, post-pogoje, osnovni pretok, nadomestni pretok, možnosti, izjeme za vsak poslovni tok sistema v skladu z zahtevami.
# 3) Dokument o funkcionalnih zahtevah
Ta dokument podrobno opisuje funkcionalne zahteve vsake funkcije sistema v skladu z zahtevami.
Dokument o funkcionalnih zahtevah je običajno skupni repozitorij tako za razvojno in preizkusno skupino kot tudi za zainteresirane strani v projektu, vključno s strankami za zavezane (včasih zamrznjene) zahteve, kar bi bilo treba obravnavati kot najpomembnejši dokument za razvoj programske opreme.
# 4) Načrt programske opreme (neobvezno)
Dokument, ki opisuje podrobnosti projekta, cilje, prednostne naloge, mejnike, dejavnosti, organizacijsko strukturo, strategijo, spremljanje napredka, analizo tveganja, predpostavke, odvisnosti, omejitve, zahteve glede usposabljanja, odgovornosti strank, časovni načrt projekta itd.,
# 5) Načrt za zagotavljanje kakovosti / preskus
Ta dokument podrobno opisuje sistem vodenja kakovosti, standarde dokumentacije, mehanizem nadzora sprememb, kritične module in funkcionalnosti, sistem upravljanja konfiguracije, načrte preskušanja, sledenje napakam, kriterije sprejemljivosti itd.
The testni načrt dokument se uporablja za identifikacijo lastnosti, ki jih je treba preizkusiti, lastnosti, ki jih ni treba preizkusiti, dodelitve preskusne skupine in njihov vmesnik, zahteve po virih, časovni razpored testiranja, pisanje preizkusov, pokritost s preizkusi, končni rezultati preskusov, predpogoj za izvedbo testa, poročanje o napakah in sledenje mehanizem, meritve preskusov itd.,
Pravi primer
Poglejmo, kako učinkovito napisati testne primere za znan in preprost zaslon za prijavo, kot je prikazano na spodnji sliki. The pristop testiranja bo skoraj enak tudi za zapletene zaslone z več informacijami in kritičnimi funkcijami.
# 1) Prvi pristop za vsak postopek preizkusa bo pridobitev prototipa zaslona (ali žičnih okvirjev), kot je opisano zgoraj, če je na voljo. To morda ni na voljo za nekatere funkcionalnosti in je odvisno od kritičnosti oblikovanja prototipa v zgodnejših fazah razvoja.
Če pa SRS Dokument (Specifikacija zahtev za programsko opremo) je na voljo za projekt, večino prototipov zaslona razvije projektna skupina. Tovrstni zaslon poenostavi preizkuševalčevo delo in poveča učinkovitost testov.
#two) Nato, specifikacije funkcionalnih zahtev . Odvisno od organizacijskega postopka, na voljo bo v paketu več dokumentov.
Odločite se torej za najboljši dokument za pisanje primerov, bodisi gre za dokument z zahtevami uporabnika ali za specifikacije funkcionalnih zahtev (ali celo za dokument SRS, če je testna skupina to lahko razumljivo), ki bo zagotovil popoln funkcionalni tok izbranega funkcija, ki jo je treba preizkusiti.
# 3) Ko so prototip zaslona in funkcionalne specifikacije na mestu, mora tester začeti pisati primere z naslednjim pristopom in merili.
- Testi uporabniškega vmesnika :Kontrole / polja, ki so vidna uporabniku. Za funkcijo, ki jo je treba preizkusiti, so na voljo statični nadzor in dinamični nadzor. Na primer, na zgornjem zaslonu za prijavo so besedila »Uporabniško ime in geslo« statična polja, ki ne zahtevajo uporabnikove interakcije, samo za prikaz besedila.
- Funkcionalni primeri :Po drugi strani pa sta gumb za prijavo in hiperpovezave (Pozabljeno geslo? & Registracija) dinamična polja, ki zahtevajo interakcijo uporabnika s klikom na kontrolnike, ki bodo nato nekaj ukrepali.
- Primeri zbirke podatkov :Ko uporabnik vnese uporabniško ime in geslo, se lahko preskusi napišejo, da se preveri, ali je v ustrezni zbirki podatkov in tabeli preverjeno uporabniško ime in geslo in ali ima uporabnik dovoljenje za prijavo v preizkušeno aplikacijo.
- Preskusi procesov :To je povezano s postopkom (ne z dejanji, povezanimi z vidnimi kontrolniki, ki so na voljo na zaslonu), povezanimi s funkcijo in funkcionalnostjo. Na primer, s klikom povezave Pozabljeno geslo na zgornjem vzorčnem zaslonu lahko uporabniku pošljete e-poštno sporočilo. Torej, morda je treba e-pošto preizkusiti za pravilen postopek in potrditev.
4) Na koncu obdržite Mantra BAOE ', Pomeni i) Osnovni tok ii) Nadomestni tok iii) Možnosti in iv) Izjeme za popolno pokritost funkcionalnega toka in funkcije, ki jo je treba preizkusiti. Vsak koncept je treba uporabiti za pozitivne in negativne teste.
Na primer, poglejmo preprost pristop BAOE za zgornji vzorec prijavnega zaslona.
- Osnovni tok: V kateri koli brskalnik vnesite pot URL-ja za prijavo in vnesite zahtevane podatke ter se prijavite v aplikacijo.
- Nadomestni pretok: Namestite aplikacijo v mobilno napravo in vnesite zahtevane podatke ter se prijavite v aplikacijo.
- Opcije: Katere možnosti so na voljo na istem prijavnem zaslonu? Na primer, po prijavi v aplikacijo lahko s klikom na 'Odjava' prikaže isti zaslon, ali če je potekla seja ali potekla seja, lahko uporabnik pride na zaslon za prijavo.
- Izjeme: Kakšne so izjeme, če so moji testi negativni? Na primer, če so na zaslonu za prijavo vnesene napačne poverilnice, ali bo uporabnik prejel sporočilo o napaki ali nobeno dejanje ni povezano.
Z vsemi temi informacijami v roki začnimo pisati TC za prijavni zaslon v obliki s popolno pokritostjo in sledljivostjo ter s podrobnimi informacijami. Logično zaporedje in oštevilčenje identifikacije „ ID testnega primera “ bo zelo koristno za hitro identifikacijo zgodovine izvajanja testnih primerov.
Preberite tudi=> 180+ vzorcev, pripravljenih za uporabo testnih primerov za spletne in namizne aplikacije.
Dokument o testnem primeru
Opomba : Preskusni stolpci niso omejeni na spodnji vzorec testnega dokumenta, ki ga je mogoče ohraniti v Excelovem listu, da ima toliko stolpcev, kot je potrebno za popolno matriko sledljivosti, in sicer prednost, namen preskušanja, vrsta preskušanja, lokacija zaslona napak itd.,
Preberite tudi=> Vzorčna predloga testnega primera s primeri.
Za lažjo preprostost in berljivost tega dokumenta spodaj podrobno napišite korake za reprodukcijo, pričakovano in dejansko obnašanje testov za prijavni zaslon.
Opomba : Na koncu te predloge dodajte stolpec Dejansko vedenje.
Ne. | Koraki za reprodukcijo | Pričakovano vedenje |
---|---|---|
7. | Kliknite povezavo za registracijo | Če kliknete povezavo, se uporabnik prikaže na ustrezni zaslon. |
1. | Odprite brskalnik in vnesite URL za zaslon za prijavo. | Prikaže se zaslon za prijavo. |
2. | Namestite aplikacijo v telefon Android in jo odprite. | Prikaže se zaslon za prijavo. |
3. | Odprite zaslon za prijavo in preverite, ali so razpoložljiva besedila pravilno napisana. | Besedilo „Uporabniško ime“ in „Geslo“ mora biti prikazano pred ustreznim besedilnim poljem. Na gumbu za prijavo mora biti napis »Prijava«. „Ste pozabili geslo?“ In „Registracija“ bi morala biti na voljo kot povezave. |
Štiri. | Besedilo vnesite v polje Uporabniško ime. | Besedilo lahko vnesete s klikom miške ali ostrenjem z zavihkom. |
5. | Besedilo vnesite v polje za geslo. | Besedilo lahko vnesete s klikom miške ali ostrenjem z zavihkom. |
6. | Kliknite Pozabljeno geslo? Povezava. | Če kliknete povezavo, se uporabnik prikaže na ustrezni zaslon. |
8. | Vnesite uporabniško ime in geslo ter kliknite gumb Prijava. | Če kliknete gumb Prijava, se odpre ustrezen zaslon ali aplikacija. |
9. | Pojdite v bazo podatkov in preverite, ali je pravilno ime tabele potrjeno glede na vhodne poverilnice. | Ime tabele je treba preveriti in posodobiti zastavico stanja za uspešno ali neuspešno prijavo. |
10. | Kliknite Prijava, ne da bi v polje uporabniško ime in geslo vnesli besedilo. | Kliknite gumb Prijava, da opozorite na polje s sporočilom »Uporabniško ime in geslo sta obvezna«. |
enajst. | Kliknite Prijava, ne da bi v polje Uporabniško ime vnesli besedilo, ampak v polje Geslo. | Kliknite gumb Prijava, da opozorite na polje za sporočilo »Geslo je obvezno«. |
12. | Kliknite Login, ne da bi v polje za geslo vnesli besedilo, ampak v polje User Name. | Kliknite gumb Prijava, da opozorite na polje s sporočilom „Uporabniško ime je obvezno“. |
13. | V polja Uporabniško ime in geslo vnesite največje dovoljeno besedilo. | Sprejmi lahko največ 30 dovoljenih znakov. |
14. | Vnesite uporabniško ime in geslo, začenši s posebnimi znaki. | Ne sme sprejeti besedila, ki se začne s posebnimi znaki, kar pri registraciji ni dovoljeno. |
petnajst. | Vnesite uporabniško ime in geslo, začenši s praznimi presledki. | Ne sme sprejeti besedila s praznimi presledki, kar pri registraciji ni dovoljeno. |
16. | Vnesite besedilo v polje za geslo. | Ne bi smelo prikazovati dejanskega besedila, temveč simbol *. |
17. | Osvežite stran za prijavo. | Stran je treba osvežiti tako, da sta polja Uporabniško ime in Geslo prazna. |
18. | Vnesite uporabniško ime. | Odvisno od nastavitev samodejnega izpolnjevanja brskalnika morajo biti predhodno vnesena uporabniška imena prikazana kot spustni meni. |
19. | Vnesite geslo. | Odvisno od nastavitev samodejnega izpolnjevanja brskalnika, predhodno vnesena gesla ne smejo biti prikazana kot spustni meni. |
dvajset. | Premaknite fokus na povezavo Pozabljeno geslo s tabulatorko. | Tako miška kot tipka za vnos bi morali biti uporabni. |
enaindvajset. | Premaknite fokus na povezavo Registracija s pomočjo zavihka Tab. | Tako miška kot tipka za vnos bi morali biti uporabni. |
22. | Osvežite stran za prijavo in pritisnite tipko Enter. | Gumb za prijavo je treba osredotočiti in sprožiti povezano dejanje. |
2. 3. | Osvežite stran za prijavo in pritisnite tipko Tab. | Prvi poudarek na zaslonu za prijavo mora biti polje Uporabniško ime. |
24. | Vnesite uporabnika in geslo ter stran za prijavo pustite 10 minut nedejavno. | V opozorilnem polju mora biti prikazano opozorilo „Seja je potekla, znova vnesite uporabniško ime in geslo“, tako da sta oba polja za uporabniško ime in geslo izbrisana. |
25. | V brskalnike Chrome, Firefox in Internet Explorer vnesite prijavni URL. | Zaslon za isto prijavo mora biti prikazan brez večjega odstopanja pri videzu in poravnavi ter poravnavi kontrolnikov za besedilo in obrazce. |
26. | Vnesite poverilnice za prijavo in preverite dejavnost prijave v brskalnikih Chrome, Firefox in Internet Explorer. | Dejanje gumba za prijavo mora biti eno in isto v vseh brskalnikih. |
27. | Preverite, ali povezava Pozabljeno geslo in registracija v brskalnikih Chrome, Firefox in Internet Explorer ni prekinjena. | Obe povezavi bi morali voditi na ustrezna zaslona v vseh brskalnikih. |
28. | Preverite, ali funkcionalnost prijave deluje pravilno v mobilnih telefonih Android. | Funkcija prijave bi morala delovati enako, kot je na voljo v spletni različici. |
29. | Preverite, ali funkcija za prijavo deluje pravilno v jezičkih Tab in iPhone. | Funkcija prijave bi morala delovati enako, kot je na voljo v spletni različici. |
30. | Preverite zaslon za prijavo omogoča sočasnim uporabnikom sistema in vsi uporabniki dobijo zaslon za prijavo brez zamud in v določenem času 5-10 sekund. | To je treba doseči z uporabo številnih kombinacij operacijskega sistema in brskalnikov bodisi fizično bodisi navidezno ali pa to doseči z uporabo nekaterih orodij za testiranje zmogljivosti / obremenitve. |
Zbiranje testnih podatkov
Med pisanjem testnega primera je najpomembnejša naloga katerega koli preizkuševalca zbiranje testnih podatkov. Številni preizkuševalci to dejavnost preskočijo in spregledajo ob predpostavki, da je mogoče testne primere izvesti z nekaterimi vzorčnimi podatki ali lažnimi podatki in jih lahko pošljejo, kadar so podatki res potrebni. To je kritično napačno prepričanje, da se vzorčni podatki ali vhodni podatki hranijo iz miselnega spomina v času izvajanja testnih primerov.
Če se v času pisanja testov podatki v testnem dokumentu ne zberejo in ne posodobijo, bi preizkuševalec v času izvedbe testa porabil neobičajno več časa za zbiranje podatkov. Podatke o preskusu je treba zbirati tako za pozitivne kot negativne primere z vseh vidikov funkcionalnega toka funkcije. Dokument o poslovni uporabi je v tej situaciji zelo koristen.
Poiščite vzorec dokumenta s testnimi podatki za zgoraj napisane teste, kar vam bo pomagalo pri tem, kako učinkovito lahko zbiramo podatke, ki nam bodo olajšali delo v času izvajanja testa.
Da ne | Namen testnih podatkov | Dejanski podatki o preskusu |
---|---|---|
7. | Preizkusite uporabniško ime in geslo z vsemi majhnimi znaki | skrbnik (admin2015) |
1. | Preizkusite pravilno uporabniško ime in geslo | Skrbnik (admin2015) |
2. | Preizkusite največjo dolžino uporabniškega imena in gesla | Skrbnik glavnega sistema (admin2015admin2015admin2015admin) |
3. | Preizkusite prazna mesta za uporabniško ime in geslo | Vnesite prazne prostore z uporabo preslednice za uporabniško ime in geslo |
Štiri. | Preizkusite neprimerno uporabniško ime in geslo | Skrbnik (aktivirano) (digx ## $ taxk209) |
5. | Preizkusite uporabniško ime in geslo z nenadzorovanimi presledki med. | Administrator istrator (admin 2015) |
6. | Preizkusite uporabniško ime in geslo, začenši s posebnimi znaki | $% # @ # $ Administrator (% # * # ** # admin) |
8. | Preizkusite uporabniško ime in geslo z vsemi velikimi znaki | UPRAVNIK (ADMIN2015) |
9. | Preizkusite prijavo z istim uporabniškim imenom in geslom hkrati z več sistemi hkrati. | Administrator (admin2015) - za Chrome v istem računalniku in drugem računalniku z operacijskim sistemom Windows XP, Windows 7, Windows 8 in Windows Server. Administrator (admin2015) - za Firefox v istem računalniku in drugem računalniku z operacijskim sistemom Windows XP, Windows 7, Windows 8 in Windows Server. Administrator (admin2015) - za Internet Explorer v istem računalniku in drugem računalniku z operacijskim sistemom Windows XP, Windows 7, Windows 8 in Windows Server. |
10. | Preizkusite prijavo z uporabniškim imenom in geslom v mobilni aplikaciji. | Administrator (admin2015) - za Safari in Opera v mobilnih napravah Android, iPhones in tabličnih računalnikih. |
**************************************************
Pomen standardizacije testnih primerov
V tem zasedenem svetu nihče ne more ponavljati stvari iz dneva v dan z enako stopnjo zanimanja in energije. Še posebej nisem navdušen nad tem, da v službi vedno znova opravljam isto nalogo. Všeč mi je upravljanje stvari in prihranek časa. Vsak v IT bi moral biti tak.
Vsa IT-podjetja izvajajo različne vrste projektov. Ti projekti lahko temeljijo na izdelkih ali storitvah. Od teh projektov jih večina dela okoli spletnih strani in testiranje spletnih strani . Dobra novica o tem je, da imajo vsa spletna mesta veliko podobnosti. Če so spletna mesta za isto domeno, imajo tudi več skupnih lastnosti.
Vprašanje, ki me vedno zmede, je: »Če je večina aplikacij podobnih, na primer: na primer spletna mesta, ki so bila že tisočkrat preizkušena,« Zakaj moramo pisati testne primere za še eno spletno mesto iz nič? ' Ali ne bo prihranilo tone časa z izvlečenjem obstoječih testnih skriptov, ki so bili uporabljeni za testiranje prejšnjega spletnega mesta?
Seveda bomo morda morali narediti nekaj majhnih popravkov, vendar je na splošno tudi to lažje, učinkovitejše, prihrani čas in denar, zato vedno pomaga ohranjati visoke ravni obresti preizkuševalcev. Kdo rad večkrat piše, pregleduje in vzdržuje iste testne primere, kajne? Ponovna uporaba obstoječih testov lahko to v veliki meri reši in tudi vaše stranke bodo to našle pametno in logično.
Torej logično sem začel vleči obstoječe skripte iz podobnih spletnih projektov, naredil spremembe in jih hitro pregledal. Z barvnim kodiranjem sem uporabil tudi prikazane spremembe, tako da se lahko pregledovalec osredotoči le na del, ki je bil spremenjen.
Razlogi za ponovno uporabo testnih primerov
# 1) Večina funkcionalnih področij spletnega mesta je skoraj prijava, registracija, dodajanje v košarico, seznam želja, plačilo, možnosti pošiljanja, možnosti plačila, vsebina strani izdelka, nedavno ogledani, ustrezni izdelki, pripomočki za promocijsko kodo itd.
#two) Večina projektov je le izboljšav ali sprememb obstoječe funkcionalnosti.
# 3) Sistemi za upravljanje vsebin, ki določajo reže za nalaganje slik s statičnimi in dinamičnimi načini, so običajni tudi za vsa spletna mesta.
# 4) Spletna mesta za prodajo na drobno imajo DOP Tudi sistem (storitve za stranke).
# 5) Backend sistem in aplikacija skladišča z uporabo JDA uporabljajo tudi vsa spletna mesta.
# 6) Tudi koncept piškotkov, časovna omejitev in varnost so pogosti.
# 7) Spletni projekti so pogosto nagnjeni k spremembam zahtev.
# 8) The vrste preskušanja potrebni so pogosti, kot brskalnik preskus združljivosti , testiranje učinkovitosti , preskušanje varnosti
Veste, veliko je skupnega in podobnega.
Če rečem, da gre za večkratno uporabo, včasih same spremembe lahko trajajo več ali manj časa. Včasih se komu zdi, da je bolje začeti iz nič, kot pa toliko spremeniti.
To je enostavno rešiti z ustvarjanjem nabora standardnih testnih primerov za vsako skupno funkcijo.
Kaj je standardni test pri spletnem testiranju?
- Ustvarite testne primere, ki so dokončani - koraki, podatki, spremenljivka itd. To bo zagotovilo, da je mogoče neskladne podatke / spremenljivko preprosto zamenjati, kadar je potreben podoben testni primer.
- Merila za vstop in izstop morajo biti pravilno opredeljena.
- Spreminljive korake ali stavek v korakih je treba označiti z drugo barvo za hitro iskanje in zamenjavo.
- Jezik, ki se uporablja za izdelavo standardnega testnega primera, mora biti splošen.
- V testnih primerih je treba zajeti vse funkcije vsakega spletnega mesta.
- Ime testnih primerov mora biti ime funkcije ali funkcije, ki jo testni primer zajema. To bo olajšalo iskanje testnega primera iz nabora.
- Če obstaja osnovni ali standardni vzorec ali datoteka GUI ali posnetek zaslona funkcije, jo je treba priložiti z ustreznimi koraki.
Z uporabo zgornjih nasvetov lahko ustvarite nabor standardnih skriptov in jih uporabite z malo ali potrebnimi spremembami za različna spletna mesta.
Tudi te standardne testne primere je mogoče avtomatizirati, vendar je ponovno poudarjanje ponovne uporabnosti vedno plus. Tudi če avtomatizacija temelji na GUI, ponovna uporaba skriptov na več URL-jih ali spletnih mestih je nekaj, kar se mi osebno nikoli ni zdelo učinkovito.
Uporaba standardnega nabora ročnih testnih primerov za različna spletna mesta z manjšimi spremembami je najboljši način za testiranje spletnega mesta. Vse, kar potrebujemo, je ustvariti in vzdrževati testne primere z ustreznimi standardi in uporabo.
Zaključek
Izboljšanje učinkovitosti testnih primerov ni preprosto opredeljen izraz, ampak je vaja in ga je mogoče doseči z dozorelim postopkom in redno prakso.
Preizkusna skupina se ne bi smela naveličati vključevanja v izboljšanje takšnih nalog, saj je to najboljše orodje za večje dosežke v svetu kakovosti, kar dokazujejo številne preskusne organizacije po vsem svetu pri kritičnih projektih in zapletenih aplikacijah.
Upam, da bi pridobili neizmerno znanje o konceptu testnih primerov. Oglejte si našo serijo vadnic, če želite izvedeti več o testnih primerih in izraziti svoje misli v spodnjem oddelku za komentarje!
Priporočeno branje
- Funkcionalno testiranje vs nefunkcionalno testiranje
- Vodič za preizkušanje prenosljivosti s praktičnimi primeri
- Vrste preizkušanja programske opreme: različne vrste preskušanja s podrobnostmi
- Najboljša orodja za testiranje programske opreme 2021 (QA Test Automation Tools)
- Alfa testiranje in beta testiranje (popoln vodnik)
- Kaj je sistemsko testiranje - vodnik za začetnike
- Vzorčni vprašalniki z odgovori na testiranje ISTQB za testiranje
- Kako napisati tedensko poročilo o preizkušanju programske opreme