Kako napisati testne primere: Ultimate Guide z primeri

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:

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)

želim preizkusiti izdelke za podjetja

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?
  • Zakaj pišemo teste?
  • Kako napisati testne primere?
  • Osnovna oblika izjave o testnem primeru
• Nasveti za pisanje testov
  • • # 1) Naj bo preprosto, vendar ne preveč preprosto; naj bo zapleteno, vendar ne preveč zapleteno:
    • # 2) Po dokumentiranju testnih primerov enkrat preglejte kot Tester:
    • # 3) Vezani in olajšajte preizkuševalce:
    • # 4) Bodite sodelavec:
    • # 5) Nikoli ne pozabite na končnega uporabnika:
• 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“
• Kako NE pisati testov
  • 3 najpogostejše težave v testnih primerih
    • # 1) Sestavljeni koraki
    • # 2) Vedenje aplikacije se šteje za pričakovano
    • # 3) Več pogojev v enem primeru
• Kako izboljšati učinkovitost testnih primerov
  • Zbirka dokumentov za testno pisanje
  • Pravi primer
  • Dokument o testnem primeru
  • Zbiranje testnih podatkov
• Pomen standardizacije testnih primerov
  • Razlogi za ponovno uporabo testnih primerov
  • Kaj je standardni test pri spletnem testiranju?
  • Zaključek
  • Priporočeno branje

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

1. Sestavljeni koraki
2. Vedenje aplikacije se šteje za pričakovano
3. 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:

1. Zaženite spletno mesto za nakupovanje.
2. 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:

1. Zaženite spletno mesto za nakupovanje.
2. Kliknite Pošiljanje in vrnitev.
3. V polje za vnos številke naročila na tem zaslonu vnesite številko naročila.
4. 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:

• 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. :)

vprašanja in odgovori na agilni metodologiji

**************************************************

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.

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.

**************************************************

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!

Naslednja vadnica

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