Valge kasti testimine
Valge kasti testimine on tarkvara testimise tehnika, mille käigus testitakse tarkvara sisemist struktuuri, disaini ja kodeerimist sisend-väljundvoo kontrollimiseks ning disaini, kasutatavuse ja turvalisuse parandamiseks. Valge kasti testimisel on kood testijatele nähtav, nii et seda nimetatakse ka selge kasti testimiseks, avatud kasti testimiseks, läbipaistva kasti testimiseks, koodipõhiseks testimiseks ja klaasist kasti testimiseks.
See on üks tarkvara testimise lähenemisviisi kahest osast. Selle kolleeg Blackbox testimine hõlmab testimist välise või lõppkasutaja tüüpi vaatenurgast. Teiselt poolt põhineb tarkvaratehnikas valge kasti testimine rakenduse sisemistel töödel ja käib sisemise testimise ümber.
Terminit "WhiteBox" kasutati läbipaistva kasti kontseptsiooni tõttu. Selge kast või WhiteBoxi nimi sümboliseerib võimalust näha tarkvara väliskest (või "kast") läbi selle sisemise töö. Samamoodi sümboliseerib "musta kasti" jaotises "Musta kasti testimine" tarkvara sisemise toimimise puudumist, nii et saab katsetada ainult lõppkasutaja kogemusi.
Selles valge kasti testimise õpetuses saate teada
- Mis on valge kasti testimine?
- Mida kontrollite valge kasti testimisel?
- Kuidas teete valge kasti testimist?
- WhiteBoxi testimise näide
- Valge kasti testimise tehnikad
- Valge kasti testimise tüübid
- Valge kasti testimisvahendid
- Valge kasti testimise eelised
- WhiteBoxi testimise puudused
Mida kontrollite valge kasti testimisel?
Valge kasti testimine hõlmab järgmise tarkvara tarkvarakoodi testimist:
- Sisemised turvaaugud
- Katkised või halvasti struktureeritud teed kodeerimisprotsessides
- Konkreetsete sisendite voog läbi koodi
- Eeldatav väljund
- Tingimuslike silmuste funktsionaalsus
- Iga väite, objekti ja funktsiooni testimine individuaalselt
Testimist saab teha tarkvaraarenduse süsteemi-, integreerimis- ja ühikutasanditel. Whiteboxi testimise üks põhieesmärke on kontrollida rakenduse töövoogu. See hõlmab mitme etteantud sisendi testimist eeldatavate või soovitud väljundite suhtes, nii et kui konkreetne sisend ei anna oodatud väljundit, olete kohanud viga.
Kui videole pole juurdepääsu, klõpsake siin
Kuidas teete valge kasti testimist?
Valge kasti testimise lihtsustatud selgituse andmiseks jagasime selle kaheks põhietapiks . Testijad teevad rakenduse testimisel valge kasti testimistehnikat järgmiselt:
1. SAMM) MÕISTA ALLIKA KOODIST
Esimene asi, mida testija sageli teeb, on õppida ja mõista rakenduse lähtekoodi. Kuna valge kasti testimine hõlmab rakenduse sisemise töö testimist, peab testija olema väga tundlik programmeerimiskeeltes, mida testitavad rakendused kasutavad. Samuti peab testiv isik olema teadlik turvalistest kodeerimispraktikatest. Turvalisus on tarkvara testimise üks peamisi eesmärke. Testija peaks suutma leida turvaprobleeme ja takistada häkkerite ja naiivsete kasutajate rünnakuid, kes võivad teadlikult või teadmatult rakendusse pahatahtlikku koodi sisestada.
2. samm. LOE TESTJUHTUMID JA TÄITA
Valge kasti testimise teine põhietapp hõlmab rakenduse lähtekoodi korraliku voo ja struktuuri testimist. Üks võimalus on kirjutada rakenduse lähtekoodi testimiseks rohkem koodi. Testija töötab rakenduses iga protsessi või protsesside seeria jaoks välja vähe teste. See meetod eeldab, et testijal peavad olema koodist lähedased teadmised ja seda teeb sageli arendaja. Muud meetodid hõlmavad käsitsi testimist, proovide ja vigade testimist ning testimisvahendite kasutamist, nagu me seda artiklit edasi selgitame.
WhiteBoxi testimise näide
Mõelge järgmisele koodijupile
Printme (int a, int b) {------------ Printme on funktsioonint tulemus = a + b;Kui (tulemus> 0)Prindi ("Positiivne", tulemus)MuiduPrindi ("Negatiivne", tulemus)} ----------- Lähtekoodi lõpp
Tarkvaraarenduse WhiteBoxi testimise eesmärk on kontrollida koodis kõiki otsuste harusid, tsükleid, avaldusi.
Ülaltoodud valge kasti testimise näite väidete kasutamiseks oleksid WhiteBoxi testijuhud
- A = 1, B = 1
- A = -1, B = -3
Valge kasti testimise tehnikad
Peamine valge kasti testimise tehnika on Code Coverage'i analüüs. Koodikatvuse analüüs kõrvaldab testijuhtumikomplekti lüngad. See tuvastab programmi piirkonnad, mida testjuhtumite komplekt ei kasuta. Kui lüngad on tuvastatud, loote koodi testimata osade kontrollimiseks testjuhtumid, tõstes seeläbi tarkvaratoote kvaliteeti
Koodi levianalüüsi tegemiseks on saadaval automatiseeritud tööriistad. Allpool on toodud mõned katvuse analüüsimeetodid, mida kastitestija saab kasutada:
Avalduse katvus : - see tehnika nõuab, et tarkvaratehnika testimisprotsessi käigus testitakse koodis kõiki võimalikke väiteid vähemalt korra.
Haru katvus - see meetod kontrollib tarkvararakenduse kõiki võimalikke teid (kui-muud ja muud tingimuslikud silmused).
Lisaks ülaltoodule on arvukalt levialade tüüpe, nagu seisundi katvus, mitmekordne seisundi katvus, raja katvus, funktsioonide katvus jne. Igal tehnikal on oma eelised ja katsed tarkvarakoodi kõiki osi testida (katta). Kasutades aruande ja haru katvust, saavutate tavaliselt 80-90% koodi katvuse, mis on piisav. Järgmised on olulised WhiteBoxi testimistehnikad:
- Avalduse katvus
- Otsuse katvus
- Filiaali katvus
- Seisundi katvus
- Mitme seisundi katvus
- Lõppseisundi masina katvus
- Tee katvus
- Kontrollvoolu testimine
- Andmevoo testimine
Lisateabe saamiseks lugege seda artiklit https://www.guru99.com/code-coverage.html
Valge kasti testimise tüübid
Valge kasti testimine hõlmab mitut testimistüüpi, mida kasutatakse rakenduse, koodiploki või konkreetse tarkvarapaketi kasutatavuse hindamiseks. Need on loetletud allpool -
-
Ühikute testimine: see on sageli rakenduse esimene testimise tüüp. Üksuse testimine viiakse läbi iga üksuse või koodiploki juures, kui see on välja töötatud. Ühikute testimise teeb sisuliselt programmeerija. Tarkvaraarendajana töötate välja mõned koodiread, ühe funktsiooni või objekti ja testite, kas see töötab enne, kui üksuse testimine aitab tarkvara arenduse elutsükli alguses tuvastada enamiku vigadest. Selles etapis tuvastatud vead on odavamad ja neid on lihtne parandada.
-
Mälulekete testimine : aeglasemalt töötavate rakenduste peamised põhjused on mälulekked. Kvaliteedikontrolli spetsialist, kellel on kogemusi mälulekete tuvastamisel, on hädavajalik juhtudel, kui teil on aeglaselt töötav tarkvararakendus.
Lisaks ülaltoodule on mõned testimistüübid nii musta kui ka valge kasti testimise osa. Need on loetletud allpool
- Valge kasti läbitungimise testimine: selles testimises on testeril / arendajal täielik teave rakenduse lähtekoodi, üksikasjaliku võrguteabe, kaasatud IP-aadresside ja kogu serveri kohta käiva teabe kohta. Eesmärk on rünnata koodi mitme nurga alt, et paljastada turvaohud
- Valge kasti mutatsioonitestimine : mutatsioonitestimist kasutatakse sageli tarkvaralahenduse laiendamiseks kasutatavate parimate kodeerimisvõtete avastamiseks.
Valge kasti testimisvahendid
Allpool on loetelu peamistest valge kasti testimise tööriistadest.
- Parasoft Jtest
- EclEmma
- NUnit
- PyUnit
- HTMLUnit
- CppUnit
Valge kasti testimise eelised
- Koodi optimeerimine peidetud vigade leidmisega.
- Valge kasti testide juhtumeid saab hõlpsasti automatiseerida.
- Testimine on põhjalikum, kuna kõik koodirajad on tavaliselt kaetud.
- Testimist võib SDLC-s alustada varakult, isegi kui GUI pole saadaval.
WhiteBoxi testimise puudused
- Valge kasti testimine võib olla üsna keeruline ja kulukas.
- Arendajad, kes tavaliselt täidavad valge kasti testimisjuhtumeid, jälestavad seda. Arendajate valge kasti testimine pole üksikasjalik, mis võib põhjustada tootmisvigu.
- Valge kasti testimine nõuab professionaalseid ressursse ning programmeerimise ja rakendamise üksikasjalikku mõistmist.
- Valge kasti testimine on aeganõudev, suuremate programmeerimisrakenduste täielik testimine võtab aega.
Lõppmärkused:
- Valge kasti testimine võib olla üsna keeruline. Keerukus on testitava rakendusega palju seotud. Väikest rakendust, mis sooritab ühe lihtsa toimingu, võiks mõne minutiga testida valge kastiga, samas kui suuremate programmeerimisrakenduste täielik testimine võtab päevi, nädalaid ja isegi kauem.
- Valge kasti testimine tarkvara testimisel tuleks teha tarkvararakendusel, nagu seda arendatakse pärast selle kirjutamist ja uuesti pärast iga modifikatsiooni