test coverage software testing
Popoln vodnik za testiranje programske opreme za testiranje: Kako preizkusiti več, prihraniti čas in doseči boljše rezultate testiranja:
Testiranje programske opreme je bistvena dejavnost v življenjskih ciklih razvoja in vzdrževanja programske opreme. To je praksa, ki se pogosto uporablja za odločanje in izboljšanje kakovosti programske opreme.
Danes je razvoj bolj sistematičen in organizacije iščejo ukrepe za preverjanje popolnosti in učinkovitosti, da bi pokazale merila za dokončanje preizkusa. Med vsemi velja pokritost še posebej dragocena.
Kaj se boste naučili:
- Kaj je testna pokritost?
- Preizkusi pokritost in pokritost kode
- Moje izkušnje
- Pomen pokritosti preskusa
- Kako sprejeti pravilno metodo kritja preskusov?
- Kako se prepričati, da je vse preizkušeno?
- Kritična področja in metode za učinkovito preskušanje
- Prednosti preizkušanja zavedanja pokritosti za testerja:
- Zaključek
- Priporočeno branje
Kaj je testna pokritost?
Preprosto povedano je 'Kaj testiramo in koliko testiramo?'
Zajetje testov pomaga spremljati kakovost testiranja in preskuševalcem pomaga pri ustvarjanju testov, ki pokrivajo področja, ki manjkajo ali niso potrjena.
Večina ekip svoje izračune pokritosti opira samo na funkcionalne zahteve. Pošteno je tudi zato, ker mora aplikacija najprej delati tisto, kar naj bi storila. Če ne, njegova hitrost ali varnost ali enostavnost uporabe - nič od tega ni pomembno.
Vendar, če je namenjen in neodvisen nefunkcionalno preskušanje ekipe delajo na uspešnosti, varnosti, preizkušanju uporabnosti itd., nato bodo morale spremljati svoje zahteve vse do izvedbe s pomočjo analitike pokritosti preskusov.
Preizkusi pokritost in pokritost kode
Pokritost testa pogosto zamenjamo s pokritostjo kode. Čeprav sta osnovni načeli enaki, gre za dve različni stvari.
Pokritost kode res govori o praksah enotnega testiranja, ki morajo vsaj enkrat ciljati na vsa področja kode, in to izvajajo razvijalci.
Testna pokritost pa je testiranje vsake zahteve vsaj enkrat in je očitno dejavnost QA skupine.
Kaj resnično izpolnjuje pogoje za kritje, je odvisno od razlage vsake ekipe.
Na primer , Nekatere ekipe zahtevajo kritje zahteve, če obstaja vsaj en testni primer. Včasih je zajeto, če mu je dodeljen vsaj en član ekipe. Ali pa, če se izvedejo vsi z njim povezani testni primeri.
- Če je ustvarjenih 10 zahtev in 100 preskusov - ko teh 100 preskusov cilja na vseh 10 zahtev in nobene ne izpusti - temu rečemo ustrezna pokritost s testiranjem na ravni zasnove.
- Ko se izvede le 80 ustvarjenih testov in ciljajo le na 6 zahtev. Pravimo, da 4 zahteve niso zajete, čeprav je opravljenih 80% testiranj. To je statistika pokritosti na ravni izvrševanja.
- Kadar je preizkuševalcem dodelilo le 90 testov, ki se nanašajo na 8 zahtev, preostali pa ne, rečemo, da je pokritost s testnimi nalogami 80% (8 od 10 zahtev).
Pomembno je tudi, kdaj izračunati pokritost.
Če boste to storili prezgodaj, boste videli veliko vrzeli, ker so stvari še vedno nepopolne. Tako je na splošno priporočljivo počakajte do zadnje gradnje tj. Končna regresijska gradnja. To bo omogočilo pravilno pokritost testov, opravljenih za dane zahteve.
Preberite tudi => Postopek upravljanja izdaje in uvajanja
Moje izkušnje
Prizor pred 8 leti: Ko sem imel dve leti izkušenj v industriji preizkušanja programske opreme, sem mislil, da je v redu, če ne poznam nekaterih osnov o preizkušanju programske opreme, saj se česa lahko naučimo z izkušnjami in tudi jaz.
Imel sem prav - in tudi napačno.
Prav zato, ker se z izkušnjami naučite videti širšo sliko, razumete pravi pomen 'kritične situacije' in bolj razumete končnega uporabnika.
Napačno, ker nobena od omenjenih stvari ne zahteva izkušenj, ampak zgodnje učenje, kar sem razumel zelo pozno. To je spodbuden dejavnik za pisanje te objave.
Tu so moje izkušnje iz enega od takratnih intervjujev:
Kako poskrbite, da je pokritost s testom popolna ali največja? Vprašali so me.
Ummmm …… Preizkusim vse funkcije , Rekel sem.
S o pravite, da ko preizkusite vse funkcionalnosti, začutite, da ste v smislu testiranja pokrili največ aplikacij / izdelkov , anketar se je vrnil.
Ummm ... no ... .mmmm ... .da, ker ko preizkusite vse funkcionalnosti, ste prepričani o vedenju aplikacije / izdelka, Odgovor sem podprl .
Strinjam se, toda moje vprašanje je - ali vam bo to zaupalo, da je vaša pokritost s testiranjem največja ali popolna? izpraševalec me ni bil razpoložen, da bi me izpustil.
Zdaj sem postajal nestrpen, neznan o tem, da se bom naučil ene najpomembnejših tem o testiranju programske opreme - ' Testna pokritost ' .
kako razglasiti večdimenzionalno polje v javi
Namesto da bi reproduciral izvlečke intervjuja, tukaj povzemam, kaj sem se tistega dne naučil o testiranju pokritosti. Pred tem pa bodimo jasni pri eni točki - pokritost s testiranjem nikoli ne pomeni vedeti, ali testirate dovolj ali ne, niti ne pomeni, da testirate popolnoma ali ne.
Pomen pokritosti preskusa
Obseg testiranja ima lahko v različnih okoliščinah drugačen pomen. Odkrijmo te kontekste posamično:
Pokritost izdelka - Katere vidike izdelka ste si ogledali?
Da, pri merjenju pokritosti s testiranjem glede na izdelek je glavno področje, na katerega se morate osredotočiti, - katera področja izdelka ste preizkusili in katera ostanejo nepreverjena?
1. primer:
Če je 'nož' izdelek, testirate; samo ne osredotočajte se na preverjanje, ali pravilno reže zelenjavo / sadje. Poiskati je treba še druge vidike, na primer - uporabnik mora biti sposoben z njim udobno ravnati.
2. primer:
Če je program »notepad« aplikacija, preizkušate, preverjanje ustreznih funkcij je nujno.
Toda drugi vidiki, ki jih je treba paziti, so - aplikacija se pravilno odziva, medtem ko hkrati uporablja druge aplikacije, aplikacija se ne zruši ko uporabnik poskuša narediti nekaj nenavadnega , uporabniku so zagotovljena ustrezna opozorila / sporočila o napakah, uporabnik lahko razume in uporablja aplikacijo, vsebina pomoči je na voljo po potrebi.
Če ne preučite omenjenih scenarijev, ne morete trditi, da je pokritost s testom za aplikacijo popolna.
Kritje tveganj - Za katera tveganja ste se preizkusili?
Kritje tveganj je še en vidik popolne pokritosti s testiranji. Izdelka ali aplikacije ne morete označiti kot »preizkušenega«, dokler ne preizkusite tudi s tem povezanih tveganj. Pokritost s tem povezanih tveganj je pomemben dejavnik pri celotni pokritosti s testiranjem.
1. primer:
Če vam preskuševalec med preskušanjem letala pove, da je v celoti preizkusil notranji sistem letala in deluje dobro, vendar med preskušanjem ni bila zajeta le letalna sposobnost letala - kakšna bi bila vaša reakcija?
No, to pomeni pokritje tveganj. Ugotavljanje tveganja glede na aplikacijo / izdelek in njegovo temeljito testiranje je vedno dobra praksa.
2. primer:
Med preskušanjem spletnega mesta za e-poslovanje je preizkuševalec upošteval vse učinkovite dejavnike, vendar ni upošteval tveganja, da bi število uporabnikov hkrati in na dan Super PONUDBO dostopalo do tega spletnega mesta, vendar se je neizpolnjeno tveganje izkazalo za veliko napako.
Priporočeno branje =>
Zajetje zahtev - Za katere zahteve ste preizkusili?
Če je izdelek ali aplikacija razvita zelo dobro, če pa se ne ujema z zahtevami kupca, potem ne koristi. Pokrivanje zahtev med testiranjem je enako pomembno kot pokritost izdelkov.
1. primer:
Navdušeni nad družinsko funkcijo ste prosili krojača, naj vam zašije obleko in si na vrat izreže tiste pav modre gumbe za prikaz.
Med šivanjem obleke je krojač mislil, da dajanje teh gumbov na izrez ne bo videti dobro, zato je namesto tega našil zlato obrobljen rob. Na poskusni dan je zagotovo nesrečna stranka kričala na krojača, da se ne drži zahtev.
2. primer:
Med preizkušanjem aplikacije za klepet je tester poskrbel za vse pomembne točke, kot so klepeti več uporabnikov v skupini, dva uporabnika, ki klepetata neodvisno, na voljo so vse vrste čustvenih simbolov, posodobitve, poslane uporabniku, itd. omenil, da je treba, če dva uporabnika klepetata neodvisno, omogočiti možnost video klica.
Stranka je tržila aplikacijo za klepet, češ da dovoljuje klicanje, medtem ko dva uporabnika klepetata neodvisno. Lahko si predstavljate, kaj bi se zgodilo z aplikacijo za klepet.
Tudi preberite => Kako ustvariti matriko sledljivosti zahtev
Kako sprejeti pravilno metodo kritja preskusov?
Zavedanje je vse:
Najprej je treba, da ekipa QA ve, koliko dela je vključenih in kje so naloge oblikovanja. Tako se bodo zavedali, ali je treba dodati več testov. Če želite to narediti, lahko uporabite RTM, kot je običajna praksa.
=> Oglejte si ta članek, če želite izvedeti več o njem in kako ga uporabljati: Kako ustvariti matriko sledljivosti zahtev - natančen postopek z vzorčno predlogo
Drugič, preverite dodelitev virov in postopek izvedbe testa da preverimo, ali je vse preizkušeno na učinkovitejši način.
V pomoč je lahko spodnja tabela:
Vrsta preskusa | Skupaj primerov | Izvršeni primeri | Stanje | Komentarji |
---|---|---|---|---|
Delujoč | 100 | 80 | 50 podaj, 30 ne | |
Kompatibilnost | 100 | petdeset | 45 podaj, 5 ne | |
Uporabnost | 100 | 100 | 98 podaj, 2 ne | |
Končna regresija | 100 | 100 | 99 podaj, 1 neuspeh |
Kako se prepričati, da je vse preizkušeno?
- Vsak preizkuševalec se mora zavedati zahtev in preskusnih metod
- Prednostno postavite svoje zahteve in svojo energijo usmerite tja, kjer je najbolj potrebna
- Bodite obveščeni o tem, kako se določena izdaja razlikuje od prejšnje, da boste lahko natančneje prepoznali kritične zahteve in se osredotočili na maksimalno pozitivno pokritost
- Prilagodite testno avtomatizacijo
- Uporabite orodja za upravljanje testov da vedno ostanejo seznanjeni
- Pametna delovna naloga - usmerite svoje najboljše vire v kritične naloge in dovolite, da novi preizkuševalci raziščejo več za novo perspektivo
- Vzdrževanje a kontrolni seznam za vsa opravila in razne dejavnosti
- Več sodelujte s svojimi ekipami za razvijalce / Scrum / BA, da dobite vpogled v vedenje aplikacije
- Spremljajte vse svoje cikle gradnje in popravke
- V začetnih gradnjah sam prepoznajte težave, ki najbolj vplivajo (kadar je to mogoče), da lahko kasnejši delujejo za boljšo stabilnost in dosežejo območja, ki so jih blokirali predhodni problemi.
Kritična področja in metode za učinkovito preskušanje
# 1)Premeščanje virov: Izmenjajte si naloge med člani svoje ekipe. To pomaga izboljšati sodelovanje in preprečiti koncentracijo znanja.
#two)Pokritost združljivosti: Prepričajte se, da ste seznanjeni in vključeni različni brskalniki in platforme da preizkusite svojo aplikacijo.
# 3)Lastništvo: Naredite preizkuševalce odgovornimi in jim dajte prosto pot (seveda s spremljanjem in podporo) za modul / nalogo, na kateri delajo. To pomaga graditi odgovornost in jim omogoča, da preizkusijo ustvarjalne načine, namesto da bi sledili pretepljenim.
# 4)Roki: Poznavanje rokov za izdajo pred začetkom faze testiranja pomaga pri učinkovitem načrtovanju
# 5)Komunikacija : Ostanite v stiku z razvijalcem in drugimi ekipami med cikli izdaje, da vemo, kaj se dogaja.
# 6)Vzdrževanje RTM: Deluje kot dobra izpeljanka iz Zainteresirane strani ali stranke , na podlagi katerega je mogoče potrditi razpored izdaje
Prednosti preizkušanja zavedanja pokritosti za testerja:
- Pomaga predvsem pri določanju prednostnih nalog pri testiranju
- Pomaga doseči 100% pokritost zahtev ali z drugimi besedami, preprečuje uhajanje zahtev
- Analiza vplivov postane lažje
- Uporabno pri določanju Merila EXIT
- Omogoča testni vodnik za pripravo jasnega poročilo o zaključku testa
Zaključek
Obseg testov se ne konča z omenjenim kontekstom. Pri pokritosti s testiranjem je treba upoštevati še veliko drugih točk.
Ni vedno res, da ko testirate več, so rezultati boljši. Pravzaprav, ko preizkusite več brez očitne strategije, boste na koncu verjetno vložili veliko časa.
Z bolj strukturiranim pristopom, katerega cilj je 100-odstotno kritje zahtev in učinkovite metode testiranja, ne boste ogrozili kakovosti.
Upamo, da vam bodo tehnike, opisane v tem članku, pokazale nekaj napotkov.
Vlijte svoje komentarje in poglede na objavo. Kot običajno vas radi slišimo.
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
- Ali je testiranje programske opreme čustveno opravilo?
- Nekaj zanimivih vprašanj za preskušanje programske opreme
- Povratne informacije in pregledi tečaja za preizkušanje programske opreme