7 Tarkvara testimise põhimõtted koos näidetega

See õpetus tutvustab seitset põhilist tarkvara testimise põhimõtet, mida iga tarkvara testija ja kvaliteedikontrolli spetsialist peaks teadma.

Õppime testimise põhimõtteid järgmisega video näide-

Click siin kui video pole juurdepääsetav

Taust

Tarkvara testimise ajal on oluline saavutada optimaalsed testitulemused eesmärgist kõrvale kaldumata. Aga kuidas teha kindlaks, kas järgite õiget testimisstrateegiat? Selleks peate järgima mõningaid testimise põhiprintsiipe. Siin on seitse ühist testimispõhimõtet, mida tarkvaratööstuses laialdaselt kasutatakse.

Selle mõistmiseks kaaluge stsenaariumit, kus teisaldate faili kaustast A kausta B.

Mõelge kõigile võimalikele viisidele, kuidas seda testida.

Lisaks tavapärastele stsenaariumidele saate testida ka järgmisi tingimusi

• Püüab faili teisaldada, kui see on avatud
• Teil pole turvaõigusi faili kleepimiseks kausta B
• Kaust B on jagatud kettal ja mälumaht on täis.
• Kaustas B on juba sama nimega fail, tegelikult on see nimekiri lõputu
• Või oletame, et teil on testimiseks 15 sisendvälja, millest igaühel on 5 võimalikku väärtust, testitavate kombinatsioonide arv on 5^15

Kui te testiksite kõiki võimalikke kombinatsioone, kasvaksid projekti TÄITMISAEG JA KULUD plahvatuslikult. Testimistöö optimeerimiseks vajame teatud põhimõtteid ja strateegiaid

Siin on 7 põhimõtet:

1) Ammendavat testimist ei ole võimalik teha

Jah! Ammendavat testimist ei ole võimalik teha. Selle asemel vajame optimaalset testimismahtu, mis põhineb rakenduse riskihinnangul.

Ja miljoni dollari küsimus on, kuidas seda riski määrata?

Sellele vastamiseks teeme harjutust

Milline operatsioon põhjustab teie arvates kõige tõenäolisemalt teie Operakas süsteem ebaõnnestub?

Olen kindel, et enamik teist oleks arvanud, et saate korraga avada 10 erinevat rakendust.

Nii et kui te seda testiksite Operasüsteemi, siis mõistaksite, et mitme ülesande täitmisel leitakse tõenäoliselt defekte ja neid tuleb põhjalikult testida, mis viib meid järgmise põhimõtteni Defekt Clusterse

2) Defekt Clusterse

Defekt Clustermis väidab, et väike arv mooduleid sisaldab enamikku tuvastatud defektidest. See on Pareto põhimõtte rakendamine tarkvara testimisel: ligikaudu 80% probleemidest leitakse 20% moodulitest.

Kogemuste põhjal saate sellised riskantsed moodulid tuvastada. Kuid sellel lähenemisviisil on oma probleemid

Kui samu teste korratakse ikka ja jälle, siis lõpuks ei leia samad testjuhtumid enam uusi vigu.

3) Pestitsiidide paradoks

Sama pestitsiidisegu korduv kasutamine putukate hävitamiseks põlluharimise ajal põhjustab aja jooksul putukatel pestitsiidi suhtes resistentsuse, mistõttu pestitsiidid on putukate puhul ebaefektiivsed. Sama kehtib ka tarkvara testimise kohta. Kui tehakse sama komplekt korduvaid teste, on meetod uute defektide avastamiseks kasutu.

Selle ületamiseks tuleb testjuhtumeid regulaarselt üle vaadata ja üle vaadata, lisades uusi ja erinevaid testjuhtumeid, et aidata leida rohkem defekte.

Testijad ei saa lihtsalt sõltuda olemasolevatest testimistehnikatest. Ta peab pidevalt püüdma täiustada olemasolevaid meetodeid, et muuta testimine tõhusamaks. Kuid isegi pärast kogu seda higistamist ja rasket tööd testimisel ei saa te kunagi väita, et teie toode on vigadeta. Sellesse punkti koju sõitmiseks vaatame seda videot selle avalikust käivitamisest Windows 98

Arvate, et selline ettevõte nagu MICROSOFT poleks oma OS-i põhjalikult testinud ja riskiks oma mainega lihtsalt selleks, et näha, kuidas nende OS selle avaliku käivitamise ajal kokku jookseb!

4) Testimine näitab defektide olemasolu

Seega ütleb testimise põhimõte, et – Testimine räägib defektide olemasolust ja ei räägi defektide puudumisest. st Tarkvara testimine vähendab tõenäosust, et tarkvarasse jäävad avastamata defektid, kuid isegi kui defekte ei leita, ei ole see tõend õigsuse kohta.

Aga mis siis, kui töötate eriti kõvasti, järgides kõiki ettevaatusabinõusid ja muudate oma tarkvaratoote 99% veavabaks. Ja tarkvara ei vasta klientide vajadustele ja nõuetele.

See viib meid meie järgmise põhimõtte juurde, mis ütleb, et - vea puudumine

5) Vea puudumine – eksitus

Võimalik, et tarkvara, mis on 99% veavaba, on endiselt kasutuskõlbmatu. See võib juhtuda siis, kui süsteemi testitakse põhjalikult valede nõuete osas. Tarkvara testimine ei ole pelgalt defektide leidmine, vaid ka selle kontrollimine, kas tarkvara vastab ettevõtte vajadustele. Vea puudumine on viga, st defektide leidmine ja parandamine ei aita, kui süsteemi ehitamine on kasutuskõlbmatu ega vasta kasutaja vajadustele ja nõuetele.

Selle probleemi lahendamiseks ütleb järgmine testimise põhimõte, et varajane testimine

6) Varajane testimine

Varajane testimine – testimine peaks algama tarkvaraarenduse elutsükli jooksul võimalikult varakult. Nii et kõik nõuete või projekteerimisetapi defektid tuvastatakse varajases staadiumis. Testimise algfaasis on defekti parandamine palju odavam. Aga kui varakult tuleks testimist alustada? Soovitatav on alustada vea leidmist kohe, kui nõuded on määratletud. Sellest põhimõttest lähemalt hilisemas koolitusõpetuses.

7) Testimine on kontekstist sõltuv

Testimine sõltub kontekstist, mis tähendab põhimõtteliselt seda, et e-kaubandussaidi testimine erineb sellest, kuidas testite riiulirakendust. Kõik väljatöötatud tarkvarad ei ole identsed. Sõltuvalt rakenduse tüübist võite kasutada teistsugust lähenemist, metoodikat, tehnikaid ja testimistüüpe. Näiteks testimine, mis tahes kassasüsteem jaekaupluses erineb sularahaautomaadi testimisest.

Müüt: "Põhimõtted on vaid viitamiseks. Praktikas ma neid ei kasuta. ”

See on väga vale. Testipõhimõtted aitavad teil luua tõhusa Testistrateegia ja testjuhtumite vea püüdmise mustand.

Kuid testimispõhimõtete õppimine on sama, mis esimest korda sõitma õppimine.

Esialgu, kui õpid sõitma, pöörad tähelepanu kõigele ja kõigele, nagu käiguvahetus, kiirus, siduri käsitsemine jne. Kuid kogemusega keskendud lihtsalt juhtimisele, ülejäänu tuleb iseenesest. Selliseid, et peate isegi autos teiste reisijatega vestlusi.

Sama kehtib ka testimispõhimõtete kohta. Kogenud testijad on need põhimõtted sisendanud tasemele, et nad rakendavad neid isegi mõtlemata. Seetõttu ei vasta müüt, et põhimõtteid praktikas ei kasutata.