Hvit Box Testing – Hva er, teknikker, eksempler og typer

by: Thomas Hamilton Thomas Hamilton
Hours oppdatert

Hvit Box Testing

Hvit Box Testing er en testteknikk der programvarens interne struktur, design og koding testes for å verifisere input-output flyt og forbedre design, brukervennlighet og sikkerhet. I white box testing er kode synlig for testere, så det kalles også Clear box testing, Open box testing, Transparent box testing, Code-basert testing og Glass box testing.

Det er en av to deler av Box Testtilnærming til programvaretesting. Motstykket, Blackbox-testing, innebærer testing fra et eksternt eller sluttbrukerperspektiv. På den annen side er White box-testing i programvareteknikk basert på den indre funksjonen til en applikasjon og dreier seg om intern testing.

Begrepet "HvitBox” ble brukt på grunn av konseptet med gjennomsiktig boks. Den klare boksen eller hvitBox navnet symboliserer muligheten til å se gjennom programvarens ytre skall (eller "boks") inn i dens indre funksjoner. På samme måte er den "svarte boksen" i "Svart Box Testing” symboliserer ikke å kunne se den indre funksjonen til programvaren slik at bare sluttbrukeropplevelsen kan testes.

Hvit Box Test video

Klikk her. hvis videoen ikke er tilgjengelig

Hva bekrefter du i hvitt Box Testing?

White box-testing innebærer testing av programvarekoden for følgende:

  • Innvendige sikkerhetshull
  • Ødelagte eller dårlig strukturerte baner i kodeprosessene
  • Flyten av spesifikke innganger gjennom koden
  • Forventet utgang
  • Funksjonaliteten til betingede løkker
  • Testing av hvert utsagn, objekt og funksjon på individuell basis

Testingen kan gjøres på system-, integrasjons- og enhetsnivå for programvareutvikling. Et av de grunnleggende målene med whitebox-testing er å verifisere en arbeidsflyt for en applikasjon. Det innebærer å teste en serie forhåndsdefinerte innganger mot forventede eller ønskede utganger, slik at når en spesifikk inngang ikke resulterer i forventet utgang, har du støtt på en feil.

Hvordan utfører du White Box Testing?

Vi har delt det inn i to grunnleggende trinn for å gi deg en forenklet forklaring på testing av hvit boks. Dette er hva testere gjør når de tester en applikasjon ved hjelp av testteknikken for hvit boks:

TRINN 1) FORSTÅ KILDEKODEN

Det første en tester ofte vil gjøre er å lære og forstå kildekoden til applikasjonen. Siden testing av hvit boks innebærer testing av den indre funksjonen til en applikasjon, må testeren være svært kunnskapsrik i programmeringsspråkene som brukes i applikasjonene de tester. Testpersonen må også være svært bevisst på sikker kodingspraksis. Sikkerhet er ofte et av hovedmålene for å teste programvare. Testeren skal være i stand til å finne sikkerhetsproblemer og forhindre angrep fra hackere og naive brukere som kan injisere ondsinnet kode i applikasjonen enten bevisst eller ubevisst.

TRINN 2) OPPRETT TESTCASES OG UTFØR

Det andre grunnleggende trinnet til white box-testing innebærer å teste applikasjonens kildekode for riktig flyt og struktur. En måte er å skrive mer kode for å teste applikasjonens kildekode. Testeren vil utvikle små tester for hver prosess eller serie av prosesser i applikasjonen. Denne metoden krever at testeren må ha inngående kjennskap til koden og gjøres ofte av utvikleren. Andre metoder inkluderer Manuell testing, prøve- og feiltesting og bruk av testverktøy som vi vil forklare videre i denne artikkelen.

HvitBox Testing

HvitBox Testeksempel

Tenk på følgende kodebit

Printme (int a, int b) {                       ------------  Printme is a function 
    int result = a+ b; 
    If (result> 0)
    	Print ("Positive", result)
    Else
    	Print ("Negative", result)
    }                                        -----------   End of the source code

Målet til WhiteBox testing i programvareteknikk er å verifisere alle beslutningsgrener, løkker og utsagn i koden.

For å utøve utsagnene i testeksemplet ovenfor, WhiteBox testtilfeller ville være

  • A = 1, B = 1
  • A = -1, B = -3

Hvit Box Testteknikker

En viktig testteknikk for hvit boks er analyse av kodedekning. Kodedekningsanalyse eliminerer hull i en Testsak suite. Den identifiserer områder i et program som ikke utøves av et sett med testtilfeller. Når hull er identifisert, oppretter du testtilfeller for å verifisere ikke-testede deler av koden, og øker dermed kvaliteten på programvareproduktet

Det er automatiserte verktøy tilgjengelig for å utføre Kodedekningsanalyse. Nedenfor er noen få dekningsanalyseteknikker en bokstester kan bruke:

Uttalelsesdekning:- Denne teknikken krever at alle mulige utsagn i koden testes minst én gang under testprosessen til software engineering.

Filialdekning – Denne teknikken sjekker alle mulige stier (if-else og andre betingede løkker) til en programvareapplikasjon.

Bortsett fra ovenfor, er det mange dekningstyper som tilstandsdekning, multippel tilstandsdekning, banedekning, funksjonsdekning osv. Hver teknikk har sine egne fordeler og forsøk på å teste (dekke) alle deler av programvarekoden. Ved å bruke Statement og Branch-dekning oppnår du vanligvis 80-90% kodedekning som er tilstrekkelig.

Følgende er viktige hviteBox Testteknikker:

  • Uttalelsesdekning
  • Beslutningsdekning
  • Filialdekning
  • Tilstandsdekning
  • Dekning for flere tilstander
  • Finite State Machine Dekning
  • Banedekning
  • Kontrollstrømtesting
  • Dataflyttesting

RELATERTE ARTIKLER

Typer hvit Box Testing

Testing av hvit boks omfatter flere testtyper som brukes til å evaluere brukervennligheten til en applikasjon, kodeblokk eller spesifikk programvarepakke. Det er listet opp nedenfor -

  • Enhetstesting: Det er ofte den første typen testing som gjøres på en applikasjon. Enhetstesting utføres på hver enhet eller kodeblokk etter hvert som den utvikles. Enhetstesting utføres i hovedsak av programmereren. Som programvareutvikler utvikler du noen få linjer med kode, en enkelt funksjon eller et objekt og tester det for å sikre at det fungerer før du fortsetter. Enhetstesting hjelper til med å identifisere et flertall av feil tidlig i programvareutviklingens livssyklus. Feil identifisert i dette stadiet er billigere og enkle å fikse.
  • Tester for minnelekkasjer: Minnelekkasjer er ledende årsaker til tregere kjørende programmer. En QA-spesialist som har erfaring med å oppdage minnelekkasjer er avgjørende i tilfeller der du har en programvareapplikasjon som kjører sakte.

Bortsett fra det ovennevnte, er noen få testtyper en del av både black box og white box testing. De er listet opp nedenfor

  • Hvit Box Penetrasjonstesting: I denne testingen har testeren/utvikleren full informasjon om applikasjonens kildekode, detaljert nettverksinformasjon, IP-adresser involvert og all serverinformasjon applikasjonen kjører på. Målet er å angripe koden fra flere vinkler for å avsløre sikkerhetstrusler.
  • Hvit Box Mutasjonstesting: Mutasjonstesting brukes ofte til å oppdage de beste kodeteknikkene som kan brukes for å utvide en programvareløsning.

Hvit Box Testverktøy

Nedenfor er en liste over de beste testverktøyene for hvit boks.

Fordeler med hvit Box Testing

  • Kodeoptimalisering ved å finne skjulte feil.
  • White box testsaker kan enkelt automatiseres.
  • Testing er mer grundig ettersom alle kodestier vanligvis dekkes.
  • Testingen kan starte tidlig SDLC selv om GUI ikke er tilgjengelig.

Ulemper med hvitBox Testing

  • White box testing kan være ganske komplisert og kostbart.
  • Utviklere som vanligvis utfører testtilfeller med hvite bokser, avskyr det. Den hvite boks-testingen av utviklere er ikke detaljert og kan føre til produksjonsfeil.
  • White box-testing krever profesjonelle ressurser med en detaljert forståelse av programmering og implementering.
  • White-box-testing er tidkrevende, større programmeringsapplikasjoner tar deg tid til å teste fullt ut.

Konklusjon

  • White box-testing kan være ganske komplisert. Kompleksiteten som er involvert har mye å gjøre med applikasjonen som testes. En liten applikasjon som utfører en enkelt enkel operasjon kan testes i en hvit boks på få minutter, mens større programmeringsapplikasjoner tar dager, uker og enda lenger tid å teste fullstendig.
  • White box-testing i programvaretesting bør gjøres på en programvareapplikasjon ettersom den utvikles etter at den er skrevet og igjen etter hver modifikasjon.