Svartboks- versus hvitbokstesting: Ekspertsammenligning

Forskjellen mellom testing med hvit boks og svart boks

Testing med svart boks evaluerer programvarefunksjonalitet uten kjennskap til den interne koden, med fokus på inndata og utdata. Testing med hvit boks undersøker den interne kodens struktur og logikk, og krever tilgang til kildekoden.

Testing med svart boks utføres vanligvis av kvalitetssikringsteam for å validere funksjonalitet som er synlig for brukeren, ved hjelp av teknikker som ekvivalensklassedeling og grenseverdianalyse.

Testing med hvit boks utføres derimot av utviklere for å sikre at koden er korrekt og har tilstrekkelig testdekning, ved hjelp av metoder som setnings- og greningsdekning.

Ved å kombinere begge tilnærmingene forbedres testdekningen og programvarekvaliteten.

I dette innlegget skal jeg gå gjennom begge testtypene og forklare hva de er, de viktigste forskjellene mellom dem, hvordan de brukes, samt fordelene og ulempene. 

Hva er testing med svart boks?

Testing med svart boks, noen ganger kalt atferdstesting, er en type programvaretesting der testeren ikke har tilgang til kildekoden til systemet som testes. Den utføres vanligvis av kvalitetssikringsteamet og krever ikke nødvendigvis avanserte tekniske ferdigheter, for eksempel programmering.  

Ved testing med svart boks skrives testtilfellene basert på inndataene og utdataene til AUT, slik de er definert i kravspesifikasjonene.

De mest kjente teknikkene for testing med svart boks er:

• Ekvivalensklassedeling: der inndataene kategoriseres i ekvivalensklasser (eller partisjoner), noe som betyr at hver verdi i en klasse vil generere samme utdata. Det er nødvendig med bare ett testtilfelle per ekvivalensklasse for god testdekning.

Eksempel: Hvis et felt godtar heltallsverdier mellom 1 og 10, inneholder den gyldige klassen alle tall mellom 1 og 10, mens de to ugyldige klassene er tall mindre enn 1 og tall større enn 10. Det betyr at totalt 3 testtilfeller er nok til å dekke alle mulige klasser. 

• Grenseverdianalyse: der de ekstreme inndataverdiene, som har større sannsynlighet for å føre til feil, testes. 

Eksempel: Med det samme feltet som ovenfor er de gyldige grensene 1 og 10, mens de ugyldige er 0 og 11. 

• Testing med beslutningstabeller: der forholdene mellom inndata og utdata vises i tabellformat. Tabellen har vanligvis kolonner for betingelser og rader for de ulike kombinasjonene. Hver rad bør ha et tilsvarende testtilfelle. 

Eksempel: Denne teknikken fungerer for mer komplekse scenarioer. La oss si at vi har en søknad om banklån med følgende betingelser:

Vi har fire mulige kombinasjoner, så fire testtilfeller må utføres.

• Tilstandsovergangstesting: verifiserer systemets atferd når det går mellom ulike tilstander.  

Eksempel: La oss si at du tester et enkelt feilsporingssystem. Statusdiagrammet er:

De tilgjengelige overgangene er:

• Fra Ny til Pågår
• Fra Pågår til Under testing
• Fra Under testing til Lukket
• Fra Under testing tilbake til Pågår

For fullstendig dekning må du sørge for at hver av overgangene og statusene testes minst én gang.

• Erfaringsbasert testing, for eksempel utforskende testing. Denne typen testing innebærer å utføre tester basert på testerens erfaring med systemet eller med lignende systemer, samt kunnskap om appens atferd. 

Eksempel: Forestill deg at du tester en ny applikasjon for sosiale medier. Målet ditt er å utforske applikasjonen for å finne eventuelle feil eller problemer som må løses. 

Under utforskende testing kan du utføre følgende handlinger:

• Registrere en ny konto
• Laste opp et profilbilde
• Skrive et innlegg
• Se din egen profil
• Søke etter venner
• Sende en venneforespørsel
• Godta en venneforespørsel
• Like og kommentere på et innlegg

Ved å bruke utforskende testing ville du utført disse handlingene på en ustrukturert måte, uten en forhåndsbestemt plan. Fokuset ville vært på å finne feil eller områder som kan forbedres i applikasjonen.  

Hvis du vil lære mer om utforskende testing, syntes jeg boken til Elisabeth Hendrickson, Explore It!, var svært nyttig.

Fordeler og ulemper ved svartboks-testing

Det finnes selvsagt både fordeler og ulemper ved å utføre svartboks-testing.

Fordeler:

• Det er mer tidkrevende
• Kontrollen over testtilfellene er begrenset
• Enkelte spesifikke scenarier kan være vanskelige å teste
• Begrenset informasjon om den underliggende årsaken til feilen
• Kan overse enkelte feil
• Begrensede muligheter for å teste ytelse og skalerbarhet

Ulemper:

• Det kan være mer tidkrevende å klargjøre testmiljøet og utføre testene
• Kontrollen over testtilfellene er begrenset
• Enkelte spesifikke scenarier kan være vanskelige å teste
• Begrenset informasjon om den underliggende årsaken til feilen
• Kan overse enkelte feil
• Begrensede muligheter for å teste ytelse og skalerbarhet

Når bør man bruke svartboks-testing?

Verktøy for svartboks-testing kan brukes på alle testnivåer. Det er imidlertid bedre å bruke dem på et høyere nivå og overlate testing på lavere nivå til hvitboks-testing. Dette betyr at selv om metoden kan brukes til å teste på enhetsnivå, er svartboks-metodikken mer egnet for systemtesting og akseptansetesting.   

Svartboks-teknikker kan brukes til funksjonelle og ikke-funksjonelle tester (for eksempel ytelsestesting, brukervennlighet og tilgjengelighet). 

De bør også brukes på nyimplementert funksjonalitet, eller eksisterende testtilfeller som identifiseres gjennom disse teknikkene, kan utføres under regresjonstesting.

Hva er hvitboks-testing?

Hvitboks-testing (noen ganger kjent som testing av klar boks, testing av glassboks, kodebasert testing eller strukturell testing) er en testmetode som fokuserer på den interne virkemåten til UAT.  

Tilnærminger til hvitboks-testing:

• Dekning av instruksjoner: alle kodeinstruksjonene (kodelinjene) kjøres minst én gang på kildekodenivå. Formelen for å beregne dekningen er:

Dekning av instruksjoner = (Antall kjørte instruksjoner / Totalt antall instruksjoner i kildekoden) * 100

Eksempel: La oss si at vi har følgende kode:

 if(condition1 or condition2)) {
       print(“test 1 OK”)
    }
    else {
       if(condition3) {
          print(“test 2 OK”)
       }
}

• For full instruksjonsdekning må du gå gjennom hver kodelinje minst én gang. Dette betyr at flere tester er nødvendige:
  • condition1=true condition2=false,  som skriver ut “test 1 OK”
  • condition1=false, condition2=false og condition3=true, som skriver ut “test 2 OK”.

• Grenedekning: med denne teknikken dekker testscenarioene alle grener i kontrollflytgrafen. Hver mulig sann- og usann-verdi for betingelsene dekkes minst én gang. Formelen som brukes for grenedekning er:

• Grenedekning = (Antall utførte grener / Totalt antall grener i koden) * 100 
• Eksempel: For den samme koden er setningsdekningen 100 %, men ikke alle mulige grener er dekket. Du trenger en ekstra test der:
  • condition1=false, condition2=false, condition3=false – på denne måten dekker vi også den falske banen i den andre if-setningen. Ingenting skal skrives ut i dette testtilfellet,
• Betingelsesdekning: en omfattende teknikk der alle banene testes. Den sikrer at hver programbane er dekket av minst én test. Dette er spesielt nyttig for komplekse apper. Eksempel: For koden ovenfor trenger vi én test til for full betingelsesdekning:
  • condition1=false, condition1=true, som vil ha samme resultat som den første testen, men dekker en annen betingelse for å nå resultatet.

Fordeler og ulemper med hvitboks-testing

La oss se på fordelene og ulempene ved hvitboks-testing.

Fordeler:

• Kan finne feil tidlig i livssyklusen for programvareutvikling
• Tester den interne kodestrukturen.
• Tester kodedekning og logikk.
• Forbedrer kjennskapen til kodebasen.
• Kan brukes i ytelses- og skalerbarhetstesting.

Ulemper:

• Fungerer bedre på et lavere testnivå 
• Krever god kjennskap til systemets programmeringsspråk
• Begrenset testing fra sluttbrukerens perspektiv
• Kan overse scenarier fra den virkelige verden

Når bør du bruke hvitboks-testing? 

Hvitbokstester egner seg best på lavere nivåer, for eksempel enhets- og integrasjonstesting. Dette bidrar til å identifisere feil og mangler tidlig i utviklingsprosessen. Det er lurt å kjøre disse testene etter hver distribusjon, spesielt når du arbeider i et CI/CD-miljø. 

Hvitboks-testing kan brukes til å teste funksjonalitet, men den kan også brukes til å avdekke sårbarheter i systemet – noe som ville vært vanskelig å oppnå med svartboks-testingsteknikker.

Svartboks-testing kontra hvitboks-testing: Sammendrag 

La oss se på de viktigste forskjellene mellom svartboks-testing og hvitboks-testing:

Men la oss ikke glemme at selv om begge tilnærmingene har fordeler og ulemper, bør vi bruke begge i testprosessen vår for å oppnå god test- og kodedekning og finne de viktigste feilene.

Konklusjoner

Svartboks-testing og hvitboks-testing er to ulike tilnærminger, og de fungerer for ulike behov under utviklingsprosessen. Hvitboks-testing utføres for det meste av utviklere og brukes til testing på lavere nivåer, mens svartboks-testing utføres av QA-teamet på høyere nivåer. De fungerer best når de brukes sammen.

Hvis du likte denne artikkelen, kan du abonnere på nyhetsbrevet for å motta alle de nylig publiserte artiklene om testing og kvalitetssikring!