white box testing complete guide with techniques
Hva er White Box Testing?
Hvis vi går etter definisjonen, er 'White box testing' (også kjent som klar, glassboks eller strukturell testing) en testteknikk som evaluerer koden og den interne strukturen til et program.
Testing av hvit boks innebærer å se på strukturen til koden. Når du kjenner produktets interne struktur, kan det utføres tester for å sikre at de interne operasjonene utføres i henhold til spesifikasjonen. Og alle interne komponenter har blitt trent tilstrekkelig.
Hva du vil lære:
- Min erfaring
- Forskjellen mellom White-Box og Black-Box Testing
- Fremgangsmåte for å utføre WBT
- Typer og teknikker for White Box Testing
- Eksempel på testing av hvit boks
- White Box Testing Tools
- Konklusjon
- Anbefalt lesing
Min erfaring
Det er nesten et tiår nå siden jeg er interessert i programvaretesting og så langt har lagt merke til at testerne er de mest entusiastiske i hele programvareindustrien.
Hovedårsaken bak dette er - tester har alltid noe i sitt omfang å lære. Det være seg et domene, en prosess eller en teknologi, en tester kan ha en fullstendig utvikling hvis de ønsker det.
Men som de sier “Det er alltid en mørkere side” .
Testere unngår også en type testing som de føler er veldig kompliserte og utviklerens kakestykke. Ja, “White Box Testing”.
Dekning
White Box Testing er dekning av spesifikasjonen i koden:
1. Kodedekning
2. Segmentdekning: Forsikre deg om at hver kodeuttrykk utføres en gang.
3. Grensdekning eller testing av knuter: Dekningen av hver kodegren i fra alle mulige var.
4. Dekning av sammensatt tilstand: For flere forhold, test hver tilstand med flere baner og en kombinasjon av den forskjellige banen for å nå den tilstanden.
5. Basisbanetesting: Hver uavhengige bane i koden blir tatt for testing.
6. Dataflyttesting (DFT): I denne tilnærmingen sporer du de spesifikke variablene gjennom hver mulige beregning, og definerer dermed settet med mellomliggende baner gjennom koden. DFT har en tendens til å reflektere avhengigheter, men det er hovedsakelig gjennom sekvenser av datamanipulering. Kort sagt, hver datavariabel spores og bruken av den bekreftes. Denne tilnærmingen har en tendens til å avdekke feil som variabler som brukes, men ikke initialiseres, eller erklæres, men ikke brukes, og så videre.
7. Banetesting: Banetesting er der alle mulige baner gjennom koden er definert og dekket. Det er en tidkrevende oppgave.
8. Loop Testing: Disse strategiene gjelder testing av enkeltløkker, sammenkoblede sløyfer og nestede sløyfer. Uavhengige og avhengige kodeløkker og verdier testes med denne tilnærmingen.
Hvorfor utfører vi WBT?
Å forsikre seg om:
- At alle uavhengige baner i en modul har blitt utøvd minst en gang.
- Alle logiske avgjørelser bekreftet på deres sanne og falske verdier.
- Alle sløyfer utført ved sine grenser og innenfor deres operasjonelle grenser gyldighet for interne datastrukturer.
For å oppdage følgende typer feil:
- Logiske feil har en tendens til å krype inn i arbeidet vårt når vi designer og implementerer funksjoner, forhold eller kontroller som er utenfor programmet
- Designfeilene på grunn av forskjell mellom logisk flyt av programmet og den faktiske implementeringen
- Typografiske feil og syntakskontroll
Krever denne testen detaljerte programmeringsferdigheter?
Vi trenger å skrive test tilfeller som sikrer full dekning av programlogikken.
For dette trenger vi å kjenne programmet godt, dvs. vi bør kjenne spesifikasjonen og koden som skal testes. Kunnskap om programmeringsspråk og logikk er nødvendig for denne typen testing.
Begrensninger
Ikke mulig for å teste hver eneste bane til sløyfene i programmet. Dette betyr at uttømmende testing er umulig for store systemer.
Dette betyr ikke at WBT ikke er effektiv. Ved å velge viktige logiske baner og datastruktur for testing er praktisk mulig og effektiv.
Forskjellen mellom White-Box og Black-Box Testing
For å si det enkelt:
Under Blackbox-testing tester vi programvaren fra brukerens synspunkt, men i White box ser vi og tester den faktiske koden.
I Blackbox-testing utfører vi testing uten å se den interne systemkoden, men i WBT ser og tester vi den interne koden.
Hvitboks testteknikk brukes av både utviklerne og testere. Det hjelper dem å forstå hvilken kodelinje som faktisk utføres, og hvilken som ikke. Dette kan indikere at det enten er manglende logikk eller en skrivefeil, noe som til slutt kan føre til noen negative konsekvenser.
Anbefalt lesing => En komplett guide til Black Box-testing
Fremgangsmåte for å utføre WBT
Trinn 1 - Forstå funksjonaliteten til et program gjennom kildekoden. Noe som betyr at en tester må være godt kjent med programmeringsspråket og de andre verktøyene samt teknikker som brukes til å utvikle programvaren.
Steg 2 - Lag testene og utfør dem.
Når vi diskuterer testbegrepet, “ dekning ”Regnes som den viktigste faktoren. Her vil jeg forklare hvordan du får maksimal dekning fra konteksten av White box testing.
Les også=> Årsak og virkning Graf - Dynamisk testkasseteknikk for maksimal dekning
Typer og teknikker for White Box Testing
Det finnes flere typer og forskjellige metoder for hver testtype for hvit boks.
Se bildet nedenfor for din referanse.
I dag skal vi fokusere hovedsakelig på utførelsestestingstyper av ‘Unit testing white box technique’.
3 hovedteknikker for hvit boks:
- Uttalelsesdekning
- Grendekning
- Banedekning
Merk at uttalelsen, grenen eller stigdekningen ikke identifiserer noen feil eller mangler som må løses. Den identifiserer bare de kodelinjene som enten aldri blir utført eller forblir uberørt. Basert på dette kan ytterligere testing fokuseres på.
La oss forstå disse teknikkene en etter en med et enkelt eksempel.
# 1) Dekningsdekning:
På et programmeringsspråk er en uttalelse ingenting annet enn kodelinjen eller instruksjonene som datamaskinen skal forstå og handle deretter. En uttalelse blir en kjørbar uttalelse når den blir kompilert og konvertert til objektkoden og utfører handlingen når programmet er i kjøremodus.
Derfor “Dekningsdekning” , som navnet antyder, er det metoden for å validere om hver linje i koden utføres minst en gang.
# 2) Grendekning:
“Gren” i et programmeringsspråk er som “IF-utsagnene”. En IF-uttalelse har to grener: T rue og False .
Så i Branch-dekning (også kalt Beslutningsdekning), validerer vi om hver gren blir utført minst en gang.
I tilfelle en 'IF-uttalelse' vil det være to testbetingelser:
- En for å validere den sanne grenen og
- Annet for å validere den falske grenen.
Derfor, i teorien, er grendekning en testmetode som er når den utføres, sikrer at hver gren fra hvert avgjørelsespunkt blir utført.
# 3) Banedekning
Banedekning tester alle banene i programmet. Dette er en omfattende teknikk som sikrer at alle banene i programmet krysses minst en gang. Banedekning er enda kraftigere enn filialdekning. Denne teknikken er nyttig for å teste komplekse programmer.
La oss ta et enkelt eksempel for å forstå alle disse testboksene for hvit boks.
selskaper som betaler deg for å prøve produktene sine
Sjekk også=> Ulike typer testing
Eksempel på testing av hvit boks
Tenk på den enkle pseudokoden nedenfor:
INPUT A & B C = A + B IF C>100 PRINT “ITS DONE”
Til Uttalelsesdekning - vi trenger bare en testsak for å sjekke alle linjene i koden.
Det betyr:
Hvis jeg vurderer TestCase_01 å være (A = 40 og B = 70), da vil alle kodelinjene bli utført.
Nå oppstår spørsmålet:
- Er det tilstrekkelig?
- Hva om jeg anser testsaken min som A = 33 og B = 45?
Fordi uttalelsen dekker bare dekker den virkelige siden, for pseudo-koden, ville bare en testtilfelle IKKE være tilstrekkelig til å teste den. Som tester må vi også vurdere de negative tilfellene.
Derfor må vi vurdere for maksimal dekning ' Grendekning ' , som vil evaluere 'FALSE' -forholdene.
I den virkelige verden kan du legge til passende uttalelser når tilstanden mislykkes.
Så nå blir pseudokoden:
INPUT A & B C = A + B IF C>100 PRINT “ITS DONE” ELSE PRINT “ITS PENDING”
Siden uttalelsesdekning ikke er tilstrekkelig for å teste hele pseudokoden, vil vi kreve at filialdekning dekker maksimal dekning .
Så for filialdekning, vil vi kreve to testsaker for å fullføre testen av denne pseudokoden.
TestCase_01 : A = 33, B = 45
TestCase_02 : A = 25, B = 30
Med dette kan vi se at hver linje i koden utføres minst en gang.
Her er konklusjonene som er avledet så langt:
- Grendekning sikrer mer dekning enn uttalelse.
- Filialdekning er kraftigere enn Deklarasjon.
- 100% avdeling i seg selv betyr 100% dekningsdekning.
- Men 100% uttalelsesdekning garanterer ikke 100% filialdekning.
La oss nå gå videre til Banedekning:
Som sagt tidligere brukes banedekning til å teste de komplekse kodebitene, som i utgangspunktet involverer sløyfesetninger eller kombinasjon av sløyfer og beslutningsuttalelser.
Tenk på denne pseudokoden:
INPUT A & B C = A + B IF C>100 PRINT “ITS DONE” END IF IF A>50 PRINT “ITS PENDING” END IF
Nå for å sikre maksimal dekning, vil vi kreve 4 testsaker.
Hvordan? Enkelt sagt - det er to beslutningsuttalelser, så for hver avgjørelsesuttalelse trenger vi to grener for å teste. Den ene for sann og den andre for den falske tilstanden. Så for to avgjørelser, vil vi kreve to testsaker for å teste den sanne siden og to testsaker for å teste den falske siden, noe som utgjør totalt 4 testsaker.
For å forenkle disse, la oss vurdere nedenfor flytskjemaet for den pseudokoden vi har:
For å få full dekning trenger vi følgende testtilfeller:
TestCase_01: A = 50, B = 60
TestCase_02 : A = 55, B = 40
TestCase_03: A = 40, B = 65
TestCase_04: A = 30, B = 30
Så dekket vei vil være:
Rød linje - TestCase_01 = (A = 50, B = 60)
Blå linje = TestCase_02 = (A = 55, B = 40)
Oransje linje = TestCase_03 = (A = 40, B = 65)
Grønn linje = TestCase_04 = (A = 30, B = 30)
******************
= >> Kontakt oss for å foreslå oppføringen din her
*****************
White Box Testing Tools
Nedenfor er en liste over de beste verktøyene for hvit boks.
# 1) Veracode
hvordan du åpner .jar-filen
Veracodes testverktøy for hvit boks hjelper deg med å identifisere og løse programvarefeil raskt og enkelt til reduserte kostnader. Den støtter flere applikasjonsspråk som .NET, C ++, JAVA osv., Og lar deg også teste sikkerheten til stasjonære, web- og mobilapplikasjoner. Likevel er det flere andre fordeler med Veracode-verktøyet. For detaljert informasjon om Veracode White-boks testverktøy, vennligst sjekk lenken nedenfor.
Nettstedslink: Veracode
# 2) EclEmma
EclEmma ble opprinnelig designet for testkjøringer og analyser i Eclipse-arbeidsbenken. Det anses å være et gratis Java-kodedekkingsverktøy og har også flere funksjoner. For å installere eller vite mer om EclEmma, vennligst sjekk ut lenken nedenfor.
Nettstedslink: EclEmma
# 3) RCUNIT
Et rammeverk som brukes til testing av C-programmer er kjent som RCUNIT. RCUNIT kan brukes i samsvar med vilkårene i MIT-lisensen. Det er gratis å bruke, og for å installere eller vite mer om det, vennligst sjekk lenken nedenfor.
Nettstedslink: RCUNIT
# 4) cfix
cfix er en av enhetstestingsrammer for C / C ++ som utelukkende tar sikte på å gjøre utviklingen av testsuiter så enkelt og enkelt som mulig. I mellomtiden er cfix vanligvis spesialisert for NT Kernel-modus og Win32. For å installere og vite mer om cfix, vennligst sjekk ut lenken nedenfor
Nettstedslink: cfix
# 5) Google Test
Googletest er Googles C ++ testrammeverk. Testoppdagelse, dødstester, verdiparameterte tester, fatale og ikke-fatale feil, generering av XML-testrapport osv. Er få funksjoner i GoogleTest, men det er også flere andre funksjoner. Linux, Windows, Symbian, Mac OS X er få plattformer der GoogleTest har blitt brukt. For åLast ned, sjekk lenken nedenfor.
Last ned lenke: Google-test
# 6) EMMA
Emma er et brukervennlig gratis JAVA-kodedekkingsverktøy. Den inneholder flere funksjoner og fordeler. For å laste ned og vite mer om Emma, vennligst sjekk lenken nedenfor.
Last ned lenke: EMMA
# 7) NUnit
NUnit er et brukervennlig testkjerne med åpen kildekodeenhet som ikke krever noen manuell inngrep for å bedømme testresultatene. Den støtter alle .NET-språk. Den støtter også datadrevne tester og tester kjører parallelt under NUnit. Tidligere utgivelser av NUnit brukte NUnit-lisens, men NUnit 3 er utgitt under MIT-lisensen. Men begge lisensene tillater gratis bruk uten begrensninger. For å laste ned og vite mer om NUnit, vennligst sjekk lenken nedenfor.
Last ned lenke: NUnit
# 8) CppUnit
CppUnit er et enhetstestingsrammeverk skrevet i C ++ og anses å være havnen i JUnit. Testutgangen for CppUnit kan enten være i XML- eller tekstformat. Den oppretter enhetstester med sin egen klasse og kjører tester i testsuitene. Det er lisensiert under LGPL. For å laste ned og vite mer om CppUnit, vennligst sjekk lenken nedenfor.
Last ned lenke: CppUnit
# 9) JUnit
JUnit er et stille enkelt enhetstestingsrammeverk som støtter testautomatisering i Java Programming Language. Den støtter hovedsakelig i testdrevet utvikling og gir også testdekningsrapporten. Den er lisensiert under Eclipse Public License. For gratis nedlasting og for å vite mer om JUnit, vennligst sjekk lenken nedenfor.
Last ned lenke: JUnit
# 10) JsUnit
JsUnit anses å være havnen i JUnit to javascript. Og det er et open source-testrammeverk for å støtte klientsidet Javascript. Den er lisensiert under GNU Public License 2.0, GNU Lesser Public License 2.1 og Mozilla Public License 1.1. For å laste ned og vite mer om JsUnit, vennligst sjekk lenken nedenfor.
Last ned lenke: JsUnit
Sjekk også alle verktøyene vi har oppført under Statisk kodeanalyse her .
Foreslå gjerne mer enkle eller avanserte verktøy som du bruker til white box-teknikk.
Konklusjon
Det er ikke tilstrekkelig å stole på black box-testing for maksimal testdekning. Vi må ha en kombinasjon av både teknikker for svart boks og hvit boks dekke maksimale feil .
Hvis det gjøres riktig, vil White box testing absolutt bidra til programvarekvaliteten. Det er også bra for testere å delta i denne testingen, da det kan gi den mest 'upartiske' mening om koden. :)
Gi oss beskjed hvis du har spørsmål om metodene vi diskuterte i denne artikkelen.
Anbefalt lesing
- Viktige forskjeller mellom Black Box Testing og White Box Testing
- Black Box Testing: En grundig opplæring med eksempler og teknikker
- Funksjonstesting mot ikke-funksjonell testing
- Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
- Tenk ut av boksen mens du tester programvare!
- Bærbarhetstestveiledning med praktiske eksempler
- Alpha Testing og Beta Testing (En komplett guide)
- Typer programvaretesting: Ulike testtyper med detaljer