7 principles software testing
Sedem načel testiranja programske opreme: Vključno z več podrobnostmi o grozdanju napak, principu Pareto in paradoksu pesticidov.
Prepričan sem, da se vsi zavedajo ' Sedem načel testiranja programske opreme '.
Ta temeljna načela testiranja pomagajo preizkusnim skupinam, da izkoristijo svoj čas in trud, da bi postopek testiranja postal učinkovit. V tem članku bomo podrobno izvedeli o dveh načelih, tj. Grozdenje napak, Paretovo načelo in paradoks pesticidov .
Kaj se boste naučili:
- Sedem načel testiranja programske opreme
Sedem načel testiranja programske opreme
Preden poglobljeno preučimo ti dve načeli, na kratko razumemo sedem načel testiranja programske opreme.
Raziskujmo !!
# 1) Testiranje pokaže prisotnost napak
Vsaka aplikacija ali izdelek se sprosti v proizvodnjo po zadostnem številu preskusov s strani različnih skupin ali prehaja skozi različne faze, kot so testiranje sistemske integracije, testiranje sprejemljivosti uporabnika in testiranje beta itd.
Torej ali ste že kdaj videli ali slišali od katere koli preskusne skupine, da je programsko opremo v celoti preizkusila in v njej ni napak ? Namesto tega vsaka ekipa za testiranje potrdi, da programska oprema izpolnjuje vse poslovne zahteve in deluje v skladu s potrebami končnega uporabnika.
V industriji testiranja programske opreme nihče ne bo rekel, da obstaja brez napake v programski opremi, kar je povsem res, saj testiranje ne more dokazati, da programska oprema ne vsebuje napak ali napak.
Cilj testiranja pa je najti vedno več skritih napak z uporabo različnih tehnik in metod. Testiranje lahko razkrije neodkrite napake in če ne najdemo nobene napake, to še ne pomeni, da programska oprema nima napak.
Primer 1 :
Razmislite o aplikaciji za bančništvo, ta aplikacija je temeljito preizkušena in je podvržena različnim fazam testiranja, kot so SIT, UAT itd., Trenutno pa v sistemu niso ugotovljene nobene napake.
Vendar pa obstaja možnost, da dejansko kupec v produkcijskem okolju preizkusi funkcionalnost, ki se v bančnem sistemu redko uporablja, in preizkuševalci so to funkcijo spregledali, zato do danes niso našli nobene napake ali razvijalci kode še nikoli niso dotaknili .
2. primer:
Na televiziji smo videli več oglasov za mila, zobno pasto, pršila za roke ali razpršila, itd.
Razmislite o oglasu za ročno pranje, ki na televiziji pravi, da lahko 99% mikrobov odstranite, če uporabite to posebno ročno pranje. To jasno dokazuje, da izdelek ni 100% brez kalčkov. Tako lahko v našem konceptu testiranja trdimo, da nobena programska oprema ni brez napak.
# 2) Zgodnje testiranje
Preizkuševalci se morajo vključiti v zgodnji fazi življenjskega cikla razvoja programske opreme (SDLC). Tako je mogoče ugotoviti napake v fazi analize zahtev ali kakršne koli napake v dokumentaciji. Stroški odprave takšnih napak so zelo manjši v primerjavi s tistimi, ki jih najdemo v poznejših fazah testiranja.
Upoštevajte spodnjo sliko, ki prikazuje, kako se povečajo stroški odpravljanja napak, ko se testiranje premakne v živo.
(slika vir )
Zgornja slika kaže, da so stroški, potrebni za odpravo napake, ugotovljene med analizo zahtev, manjši in se povečujejo, ko se premikamo k fazi testiranja ali vzdrževanja.
Zdaj je vprašanje kako hitro naj bi se začelo testiranje ?
Ko so zahteve dokončne, morajo preskuševalci sodelovati pri testiranju. Testiranje je treba opraviti na zahtevanih dokumentih, specifikacijah ali kateri koli drugi vrsti dokumenta, tako da se lahko, če so zahteve nepravilno opredeljene, takoj popravi, namesto da se določijo v fazi razvoja.
# 3) Izčrpno testiranje ni mogoče
Med dejanskim preskušanjem ni mogoče preizkusiti vseh funkcionalnosti z vsemi veljavnimi in neveljavnimi kombinacijami vhodnih podatkov. Namesto tega pristopa se preskuša nekaj kombinacij, ki temeljijo na prednostnih nalogah z uporabo različnih tehnik.
Izčrpno testiranje bo zahtevalo neomejena prizadevanja in večina teh prizadevanj je neučinkovita. Prav tako časovni okviri projekta ne bodo omogočali preizkušanja toliko kombinacij. Zato je priporočljivo preskusiti vhodne podatke z različnimi metodami, kot sta enakovredna razdelitev in analiza mejnih vrednosti.
Na primer ,Če domnevamo, da imamo vnosno polje, ki sprejema samo abecede, posebne znake in številke od 0 do 1000. Predstavljajte si, koliko kombinacij bi se pojavilo za testiranje, ni mogoče preizkusiti vseh kombinacij za posamezno vrsto vnosa.
Prizadevanja za preizkušanje bodo velika, vplivala pa bodo tudi na časovni načrt in stroške projekta. Zato se vedno govori, da izčrpno testiranje praktično ni mogoče.
# 4) Testiranje je odvisno od konteksta
Na trgu je na voljo več domen, kot so bančništvo, zavarovalništvo, medicina, potovanja, oglaševanje itd., Vsaka domena pa ima več aplikacij. Tudi za vsako domeno imajo njihove aplikacije različne zahteve, funkcije, različne namene testiranja, tveganje, tehnike itd.
Različne domene se preizkušajo različno, zato testiranje temelji izključno na kontekstu domene ali aplikacije.
Na primer ,preskušanje bančne aplikacije se razlikuje od preskušanja katere koli aplikacije za e-poslovanje ali oglaševanje. Tveganje, povezano z vsako vrsto aplikacije, je različno, zato ni učinkovito uporabljati iste metode, tehnike in vrste testiranja za testiranje vseh vrst aplikacij.
# 5) Grozdenje napak
Med testiranjem se lahko zgodi, da je večina najdenih napak povezanih z majhnim številom modulov. Razlogov za to je lahko več, na primer moduli so lahko zapleteni, kodiranje v zvezi s takimi moduli je zapleteno itd.
To je Paretov princip testiranja programske opreme, kjer je 80% težav odkritih v 20% modulov. V nadaljevanju tega članka bomo izvedeli več o združevanju napak in načelu Pareto.
# 6) Paradoks pesticidov
Načelo pesticidov Paradox pravi, da če se isti niz testnih primerov vedno znova izvaja v določenem časovnem obdobju, potem ti sklopi testov niso dovolj sposobni prepoznati novih napak v sistemu.
Da bi premagali ta „paradoks pesticidov“, je treba nabor testnih primerov redno pregledovati in revidirati. Po potrebi se lahko doda nov sklop testnih primerov in obstoječi testni primeri se lahko izbrišejo, če ne morejo več odkriti napake v sistemu.
# 7) Odsotnost napake
Če je programska oprema v celoti preizkušena in če pred izdajo ne najdemo nobenih napak, lahko rečemo, da je programska oprema 99% brez napak. Kaj pa, če je ta programska oprema preizkušena glede na napačne zahteve? V takih primerih tudi iskanje napak in njihovo pravočasno odpravljanje ne bi pomagalo, saj se testiranje izvaja na napačnih zahtevah, ki niso v skladu s potrebami končnega uporabnika.
Na primer, predpostavimo, da je aplikacija povezana s spletnim mestom za e-poslovanje in zahtevami glede funkcionalnosti »Košarica ali košarica«, ki je napačno interpretirana in preizkušena. Tu tudi iskanje več napak ne pomaga premakniti aplikacije v naslednjo fazo ali v proizvodno okolje.
To je sedem načel testiranja programske opreme.
Zdaj pa raziščimo Gručiranje napak, Paretovo načelo in paradoks pesticidov v Ljubljani podrobnosti .
Gručenje napak
Med preskušanjem katere koli programske opreme preizkuševalci večinoma naletijo na situacijo, ko je večina najdenih napak povezanih z določeno funkcionalnostjo, ostale funkcije pa bodo imele manj napak.
Gručiranje napak pomeni majhno število modulov, ki vsebujejo večino napak. V bistvu napake niso enakomerno porazdeljene po celotni aplikaciji, temveč so napake koncentrirane ali centralizirane v dveh ali treh funkcionalnostih.
Včasih je to mogoče zaradi zapletenosti aplikacije, kodiranje je lahko zapleteno ali zapleteno, razvijalec lahko stori napako, ki lahko vpliva samo na določeno funkcionalnost ali modul.
Grozdenje napak temelji na Paretovo načelo ', Ki je znana tudi kot Pravilo 80-20 . To pomeni, da je 80% najdenih napak posledica 20% modulov v aplikaciji. Koncept Paretovega načela je sprva opredelil italijanski ekonomist - Vilfrodo Pareto .
Če preizkuševalci preučijo 100 napak, potem ne bo jasno, ali obstaja temeljni pomen teh 100 napak. Če pa je teh 100 napak razvrščenih po nekaterih posebnih merilih, bodo preizkuševalci morda lahko razumeli, da veliko število napak spada v zelo malo specifičnih modulov.
Na primer ,razmislimo o spodnji sliki, ki je preizkušena za eno od bančnih aplikacij in kaže, da je večina napak povezanih s funkcijo 'Overdraft'. Preostale funkcije, kot so Povzetek računa, Prenos sredstev, Stalna navodila itd., Imajo omejeno število napak.
(slika vir )
Zgornja slika navaja, da je okrog 18 funkcij prekoračitve od skupno 32 napak 18, kar pomeni, da je 60% napak najdenih v modulu “Overdraft”.
Zato se preizkuševalci med izvajanjem večinoma osredotočijo na to področje, da bi našli vedno več napak. Priporočljivo je, da se preskuševalci med preskušanjem podobno osredotočajo tudi na druge module.
Ko se ista koda ali modul znova in znova preizkuša z uporabo nabora testnih primerov kot med začetnimi ponovitvami, je število napak veliko, vendar se bo po nekaj ponovitvah število napak znatno zmanjšalo. Gručiranje napak kaže, da je treba območje, nagnjeno k napakam, temeljito preizkusiti med regresijskim testiranjem.
Paradoks pesticidov
Ko se ugotovi, da ima eden od modulov več napak, si preizkuševalci dodatno prizadevajo za preizkus tega modula.
Po nekaj ponovitvah testiranja se kakovost kode izboljša in število napak začne upadati, saj večino napak odpravi razvojna skupina, saj so razvijalci previdni tudi pri kodiranju določenega modula, kjer so preizkuševalci našli več napak.
Tako je v enem trenutku večina napak odkrita in odpravljena, tako da v tem modulu ni mogoče najti novih napak.
Včasih pa se lahko zgodi, da je med kodiranjem na določenem modulu previden (tukaj je v našem primeru ' Prekoračitev ”Modul), lahko razvijalec zanemari druge module, da ga pravilno kodira, ali pa spremembe, narejene v tem modulu, lahko negativno vplivajo na druge funkcije, kot so povzetek računa, prenos sredstev in trajna navodila.
Ko preizkuševalci uporabijo isti niz testnih primerov za izvajanje modula, kjer je odkrita večina napak (modul prekoračitve), potem po odpravi teh napak s strani razvijalcev ti testni primeri niso veliko učinkoviti za iskanje novih napak. Kot končni tok prekoračitve je modul temeljito preizkušen in razvijalci so tudi previdno napisali kodo za ta modul.
Te testne primere je treba pregledati in posodobiti. Prav tako je dobro dodati nove testne primere, da bodo na različnih področjih programske opreme ali aplikacije mogoče najti nove in več napak.
Preventivne metode pesticidov Paradox
Obstajata dve možnosti, s katerimi lahko preprečimo paradoks pesticidov, kot je prikazano spodaj:
do) Napišite nov nabor testnih primerov, ki se bodo osredotočili na različna področja ali module (razen prejšnjih modulov, ki so nagnjeni k napakam - Primer: (Prekoračitev)) programske opreme.
b) Pripravite nove testne primere in jih dodajte obstoječim.
V metoda A ”, Lahko preizkuševalci najdejo več napak v drugih modulih, v katerih med prejšnjim testiranjem niso bili osredotočeni ali razvijalci med kodiranjem niso bili previdni.
V našem zgornjem primeru lahko preizkuševalci najdejo več napak v modulih Povzetek računa, Prenos sredstev ali Stalna navodila z uporabo novega nabora testnih primerov.
Lahko pa se zgodi, da preizkuševalci zanemarijo prejšnji modul ( Primer: »Overdraft«), kjer je bila v prejšnji ponovitvi najdena večina napak, kar bi lahko predstavljalo tveganje, saj bi bil temu modulu (Overdraft) morda vstavljene nove napake po kodiranju drugih modulov.
V metoda B ”, So pripravljeni novi testni primeri, tako da lahko v ostalih modulih najdemo nove potencialne napake.
Tu v našem primeru bodo na novo ustvarjeni testni primeri lahko pomagali pri prepoznavanju napak v modulih, kot so Povzetek računa, Prenos sredstev in Stalna navodila. Vendar preizkuševalci ne morejo prezreti prejšnjih nagnjenih modulov ( Primer: „Overdraft“), saj so ti novi testni primeri združeni z obstoječimi testnimi primeri.
Obstoječi testni primeri so bili bolj osredotočeni na modul “Overdraft”, novi testni primeri pa na druge module. Zato se vsi nabori testnih primerov izvedejo vsaj enkrat, tudi če se na katerem koli modulu zgodi sprememba kode. To bo zagotovilo izvedbo ustrezne regresije in napako zaradi te spremembe kode.
Z drugim pristopom se skupno število testnih primerov znatno poveča in povzroči več truda in časa, potrebnega za izvedbo. To bo očitno vplivalo na časovni načrt projekta, predvsem pa na proračun projekta.
Za odpravo te težave je mogoče odvečne testne primere pregledati in nato odstraniti. Obstaja veliko testnih primerov, ki postanejo neuporabni po dodajanju novih testnih primerov in spreminjanju obstoječih testnih primerov.
Treba je preveriti, kateri testni primeri so neuspešni, da bi ugotovili napake v zadnjih 5 ponovitvah (predpostavimo 5 ponovitev) in kateri testni primeri niso veliko pomembni. Mogoče je tudi, da se lahko enojni pretok, zajet v nekaj testnih primerih, zajame v drugih preskusnih primerih od konca do konca in se odstranijo tisti testni primeri z enojnim tokom.
To pa bo zmanjšalo skupno število primerov.
Na primer ,imamo 50 testnih primerov, ki pokrivajo en določen modul, in videli smo, da od teh 50 testnih primerov 20 testnih primerov ni uspelo zaznati nove napake v zadnjih nekaj ponovitvah testiranja (predpostavimo 5 ponovitev). Zato je treba teh 20 testnih primerov temeljito pregledati in preveriti moramo, kako pomembni so ti testni primeri, ter se lahko ustrezno odločimo, ali bomo 20 testnih primerov obdržali ali jih odstranili.
Preden odstranite kateri koli testni primer, preverite, ali je tok funkcionalnosti, ki je zajet v teh testnih primerih, zajet v drugem testnem primeru. Ta postopek je treba upoštevati v vseh modulih, tako da se skupno število testnih primerov znatno zmanjša. To bo zagotovilo, da se skupno število testnih primerov zmanjša, vendar še vedno obstaja 100% pokritost zahtev.
Pomeni, da vsi preostali testni primeri pokrivajo vse poslovne zahteve, zato ni nobenega kompromisa glede kakovosti.
Zaključek
Testiranje programske opreme je bistven korak v SDLC, saj preverja, ali programska oprema deluje tako, kot potrebuje končni uporabnik ali ne.
Testiranje ugotovi čim več napak. Da bi lahko testiranje izvedli učinkovito in uspešno, bi se morali vsi zavedati in resnično razumeti sedem načel testiranja programske opreme, saj so znani kot stebri testiranja.
Večina preizkuševalcev je ta načela uresničila in jih izkusila med dejanskim preskušanjem.
j2ee intervju in vprašanja in odgovori pdf
Izraz načelo na splošno pomeni pravila ali zakone, ki jih je treba upoštevati. Zato morajo vsi v industriji testiranja programske opreme slediti tem sedmim načelom, in če kdo ignorira katero od teh načel, bo to za projekt morda stalo veliko.
Veselo branje !!
Priporočeno branje
- Najboljša orodja za testiranje programske opreme 2021 (QA Test Automation Tools)
- Testiranje programske opreme QA Assistant Job
- Tečaj preizkušanja programske opreme: kateremu inštitutu za preizkušanje programske opreme naj se pridružim?
- Izbira preizkušanja programske opreme kot vaše kariere
- Preizkušanje programske opreme Tehnična vsebina Writer Freelancer Job
- Kaj je tehnika preskušanja na podlagi pomanjkljivosti?
- Nekaj zanimivih vprašanj za preskušanje programske opreme
- Povratne informacije in pregledi tečaja za preizkušanje programske opreme