Selles õpetuses tutvustatakse seitset tarkvara testimise põhimõtet, mida kõik tarkvaratestijad ja kvaliteedi tagamise spetsialist peaksid teadma.
7 tarkvara testimise põhimõtted
- Testimine näitab defektide olemasolu
- Põhjalik testimine pole võimalik
- Varajane testimine
- Defektide rühmitamine
- Pestitsiidide paradoks
- Testimine sõltub kontekstist
- Vigade puudumine eksitus
Õppime testimise põhimõtteid järgmise video näite abil-
Kui videole pole juurdepääsu, klõpsake siin
Taust
On oluline, et saavutaksite optimaalsed testitulemused tarkvara testimise ajal eesmärgist kõrvale kaldumata. Kuidas aga teha kindlaks, et järgite testimiseks õiget strateegiat? Selleks peate kinni pidama mõnest peamisest testimispõhimõttest. Siin on seitse levinumat testimispõhimõtet, mida tarkvaratööstuses laialdaselt kasutatakse.
Selle mõistmiseks kaaluge stsenaariumi, kus teisaldate faili kaustast A kausta B.
Mõelge kõigile võimalikele viisidele, kuidas seda testida.
Peale tavapäraste stsenaariumite saate testida ka järgmisi tingimusi
- Proovitakse faili teisaldada, kui see on avatud
- Teil pole faili kausta B kleepimiseks turvaõigusi
- Kaust B on jagatud kettal ja mälumaht on täis.
- Kaustas B on juba samanimeline fail, tegelikult on loend lõputu
- Või oletame, et teil on testimiseks 15 sisendvälja, millest igaühel on 5 võimalikku väärtust, testitavate kombinatsioonide arv oleks 5 15
Kui prooviksite testida kõiki võimalikke kombinatsioone, tõuseksid EXECUTION TIME & COSTS hüppeliselt. Testimise optimeerimiseks vajame kindlaid põhimõtteid ja strateegiaid
Siin on 7 põhimõtet:
1) Põhjalik testimine pole võimalik
Jah! Põhjalik testimine pole võimalik. Selle asemel vajame optimaalset testimise kogust, mis põhineb rakenduse riskihinnangul.
Ja miljoni dollari küsimus on, kuidas te selle riski määrate?
Sellele vastamiseks teeme harjutuse
Milline operatsioon võib teie arvates kõige tõenäolisemalt põhjustada teie operatsioonisüsteemi tõrke?
Olen kindel, et enamik teist oleks arvanud, et avate korraga 10 erinevat rakendust.
Nii et kui te seda operatsioonisüsteemi testiksite, mõistaksite, et defekte leidub tõenäoliselt mitme ülesandega tegevuses ja neid tuleb põhjalikult testida, mis viib meid järgmise defektikobarate printsiibi juurde
2) Defektide rühmitamine
Defektiklaster, mis ütleb, et väike arv mooduleid sisaldab enamikku tuvastatud defektidest. See on Pareto põhimõtte rakendamine tarkvara testimisel: umbes 80% probleemidest leitakse 20% moodulitest.
Kogemuse järgi saate tuvastada sellised riskantsed moodulid. Kuid sellel lähenemisel on omad probleemid
Kui samu katseid korratakse ikka ja jälle, ei leia lõpuks samad testijuhud enam uusi vigu.
3) pestitsiidide paradoks
Sama pestitsiidide segu korduv kasutamine putukate hävitamiseks põlluharimise ajal viib aja jooksul putukatele pestitsiidide suhtes resistentsuse tekitamiseni, mistõttu pestitsiidid putukatel ebaefektiivsed. Sama kehtib tarkvara testimise kohta. Kui tehakse sama korduvate testide komplekt, on meetod uute defektide avastamiseks kasutu.
Selle ületamiseks tuleb testijuhud regulaarselt üle vaadata ja läbi vaadata, lisades uusi ja erinevaid testjuhtumeid, et aidata leida rohkem defekte.
Testijad ei saa sõltuda lihtsalt olemasolevatest testimisvõtetest. Ta peab testide efektiivsemaks muutmiseks pidevalt olemasolevaid meetodeid täiustama. Kuid isegi pärast seda higi ja rasket tööd testimisel ei saa te kunagi väita, et teie toode on veatud. Selle punkti koju sõitmiseks vaatame seda videot Windows 98 avalikust käivitamisest
Arvate, et selline ettevõte nagu MICROSOFT ei oleks oma OS-i põhjalikult testinud ja riskiks oma mainega, et näha nende OS-i lagunemist avalikul käivitamisel!
4) Testimine näitab defektide olemasolu
Seega ütleb testimise põhimõte, et - testimine räägib defektide olemasolust ega räägi defektide puudumisest. st Tarkvara testimine vähendab avastamata defektide püsimise tõenäosust tarkvaras, kuid isegi kui defekte ei leita, ei ole see tõend õigsuse kohta.
Aga mis siis, kui te töötate eriti kõvasti, rakendades kõiki ettevaatusabinõusid ja muutes oma tarkvaratoote 99% veatuks. Ja tarkvara ei vasta klientide vajadustele ja nõuetele.
See viib meid järgmise printsiibini, mis väidab seda - Vigade puudumine
5) Vea puudumine - eksitus
Võimalik, et tarkvara, mis on 99% veast vaba, on endiselt kasutamiskõlbmatu. See võib juhtuda juhul, kui süsteemis kontrollitakse põhjalikult valesid nõudeid. Tarkvara testimine ei ole pelgalt defektide leidmine, vaid ka kontrollimine, kas tarkvara vastab ettevõtte vajadustele. Vea puudumine on viga, st defektide leidmine ja parandamine ei aita, kui süsteemi ülesehitus on kasutamiskõlbmatu ega vasta kasutaja vajadustele ja nõuetele.
Selle probleemi lahendamiseks on järgmine testimise põhimõte öelnud, et Early Testing
6) Varajane testimine
Varajane testimine - testimist tuleks alustada võimalikult varakult tarkvaraarenduse olelusringi jooksul. Nii et nõuete või projekteerimisetapis esinevad defektid tuvastatakse varases staadiumis. Palju odavam on defekti parandada testimise varases staadiumis. Aga kui vara peaks katsetama hakkama? Viga on soovitatav leida hetkest, kui nõuded on määratletud. Sellest põhimõttest lähemalt hilisemas koolitusõpetuses.
7) Testimine sõltub kontekstist
Testimine sõltub kontekstist, mis tähendab põhimõtteliselt seda, et e-kaubanduse saidi testimisviis erineb sellest, kuidas testite kaubamärki riiulirakenduses. Kõik väljatöötatud tarkvara pole identsed. Sõltuvalt rakenduse tüübist võite kasutada erinevat lähenemist, metoodikaid, tehnikaid ja testimistüüpe. Näiteks testimine, jaemüügikaupluse mis tahes POS-süsteem erineb pangaautomaadi testimisest.
Müüt: "Põhimõtted on ainult viitamiseks. Ma ei hakka neid praktikas kasutama."
See on nii väga vale. Testimispõhimõtted aitavad teil luua tõhusa testimisstrateegia ja koostada tõrketeadete testimisjuhud.
Kuid testimispõhimõtete õppimine on nagu esmakordne juhtimise õppimine.
Esialgu pöörate sõidu õppimise ajal tähelepanu kõikidele asjadele, nagu käiguvahetus, kiirus, siduri käsitsemine jne. Kuid kogemuste põhjal keskendute lihtsalt ülejäänud juhtimisele. Sellised, et saate isegi vestlusi teiste autos reisijatega.
Sama kehtib testimispõhimõtete kohta. Kogenud testijad on sisendanud need põhimõtted tasemele, et nad rakendaksid neid ka mõtlemata. Seetõttu ei vasta müüt, et põhimõtteid praktikas ei kasutata, lihtsalt tõsi.