Sort boks vs. hvid boks-testning: Ekspertsammenligning

Forskellen mellem hvidboks- og sortbokstest

Sortbokstest evaluerer softwarefunktionalitet uden kendskab til den interne kode og fokuserer på input og output. Hvidbokstest undersøger den interne kodestruktur og logik og kræver adgang til kildekoden.

Sortbokstest udføres typisk af QA-teams for at validere brugerrettet funktionalitet ved hjælp af teknikker som ækvivalenspartitionering og grænseværdianalyse.

Derimod udføres hvidbokstest af udviklere for at sikre kodens korrekthed og dækning ved hjælp af metoder som sætnings- og forgreningsdækning.

Kombinationen af begge tilgange forbedrer testdækningen og softwarekvaliteten.

I dette indlæg gennemgår jeg begge testtyper og forklarer, hvad de er, de vigtigste forskelle mellem dem, hvordan de bruges, samt deres fordele og ulemper. 

Hvad er sortbokstest?

Sortbokstest, som nogle gange kaldes adfærdstest, er en type softwaretest, hvor testeren ikke har adgang til kildekoden for det system, der testes. Den udføres normalt af kvalitetssikringsteamet og kræver ikke nødvendigvis avancerede tekniske færdigheder som programmering.  

Ved sortbokstest skrives testtilfælde baseret på input og output for AUT, som defineret i kravspecifikationerne.

De mest bemærkelsesværdige sortbokstestteknikker er:

• Ækvivalenspartitionering: hvor input opdeles i ækvivalensklasser (eller partitioner), hvilket betyder, at alle værdier i en klasse genererer det samme output. Der kræves kun ét testtilfælde pr. ækvivalensklasse for at opnå god testdækning.

Eksempel: Hvis et felt accepterer heltalsværdier mellem 1 og 10, indeholder den gyldige klasse alle tal mellem 1 og 10, og de to ugyldige klasser er tal mindre end 1 og tal større end 10. Det betyder, at 3 testtilfælde i alt er nok til at dække alle mulige klasser. 

• Grænseværdianalyse: hvor de ekstreme inputværdier, som har større risiko for at generere fejl, testes. 

Eksempel: Ved brug af det samme felt som ovenfor er de gyldige grænser 1 og 10, mens de ugyldige er 0 og 11. 

• Beslutningstabeltest: hvor relationerne mellem input og output vises i tabelformat. Tabellen har typisk kolonner for betingelser og rækker for de forskellige kombinationer. Hver række bør have et tilsvarende testtilfælde. 

Eksempel: Denne teknik fungerer ved mere komplekse scenarier. Lad os sige, at vi har en ansøgning om et banklån med følgende betingelser:

Vi har fire mulige kombinationer, så der skal udføres fire testtilfælde.

• Tilstandsovergangstest: verificerer et systems adfærd, når det skifter mellem forskellige tilstande.  

Eksempel: Lad os sige, at du tester et grundlæggende fejlsporingssystem. Statusdiagrammet er:

De tilgængelige overgange er:

• Fra Ny til I gang
• Fra I gang til I test
• Fra I test til Lukket
• Fra I test tilbage til I gang

For at opnå fuld dækning skal du sikre, at hver af overgangene og statusserne testes mindst én gang.

• Erfaringsbaseret test, såsom eksplorativ test. Denne type test indebærer, at tests udføres baseret på testerens erfaring med systemet eller med lignende systemer samt kendskab til appens adfærd. 

Eksempel: Forestil dig, at du tester en ny applikation til sociale medier. Dit mål er at udforske applikationen for at finde eventuelle defekter eller problemer, der skal håndteres. 

Under eksplorativ testning kan du udføre følgende handlinger:

• Oprette en ny konto
• Uploade et profilbillede
• Skrive et opslag
• Se din egen profil
• Søge efter venner
• Sende en venneanmodning
• Acceptere en venneanmodning
• Synes godt om og kommentere på et opslag

Ved hjælp af eksplorativ testning ville du udføre disse handlinger på en ustruktureret måde uden en forudbestemt plan. Fokus ville være på at finde defekter eller områder, hvor applikationen kan forbedres.  

Hvis du vil lære mere om eksplorativ testning, fandt jeg Elisabeth Hendricksons bog, Udforsk det!, meget nyttig.

Fordele og ulemper ved sortboks-testning

Der er naturligvis både fordele og ulemper ved at udføre sortboks-testning.

Fordele:

• Det er mere tidskrævende
• Kontrollen over testtilfælde er begrænset
• Nogle specifikke scenarier kan være vanskelige at teste
• Begrænset information om den grundlæggende årsag til fejlen
• Kan overse visse fejl
• Begrænsede muligheder for at teste ydeevne og skalerbarhed

Ulemper:

• Forberedelse af testmiljøet og udførelse af testene kan være mere tidskrævende
• Kontrollen over testtilfælde er begrænset
• Nogle specifikke scenarier kan være vanskelige at teste
• Begrænset information om den grundlæggende årsag til fejlen
• Kan overse visse fejl
• Begrænsede muligheder for at teste ydeevne og skalerbarhed

Hvornår skal sortboks-testning bruges?

Sortboks-testværktøjer kan bruges på alle testniveauer. Det er dog bedre at bruge dem på et højere niveau og overlade testning på lavere niveau til hvidboks-testning. Det betyder, at selvom metoden kan bruges til at teste på enhedsniveau, er sortboks-metoden mere velegnet til systemtest og accepttest.   

Sortboks-teknikker kan bruges til funktionelle og ikke-funktionelle test (såsom ydeevnetest, brugervenlighed og tilgængelighed). 

De bør også anvendes på nyimplementerede funktionaliteter, eller eksisterende testtilfælde, der er identificeret gennem disse teknikker, kan udføres under regressionstest.

Hvad er hvidboks-testning?

Hvidboks-testning (også kendt som klarboks-testning, glasboks-testning, kodebaseret testning eller strukturel testning) er en testmetode, der fokuserer på den interne funktionalitet i UAT.  

Tilgange til hvidboks-testning:

• Sætningsdækning: alle kodesætninger (kodelinjer) udføres mindst én gang på kildekodeniveau. Formlen til beregning af dækningen er:

Sætningsdækning = (Antal udførte sætninger / Samlet antal sætninger i kildekoden) * 100

Eksempel: Lad os sige, at vi har følgende kode:

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

• For fuld sætningsdækning skal du gennemgå hver kodelinje mindst én gang. Det betyder, at der er behov for flere test:
  • condition1=true condition2=false,  hvilket udskriver “test 1 OK”
  • condition1=false, condition2=false og condition3=true, hvilket udskriver “test 2 OK”.

• Forgreningsdækning: med denne teknik dækker testscenarierne alle forgreninger i kontrolflowgrafen. Hver betingelses mulige sande og falske output dækkes mindst én gang. Formlen, der bruges til forgreningsdækningen, er:

• Grendækning = (Antal udførte grene / Det samlede antal grene i koden) * 100 
• Eksempel: For den samme kode er sætningsdækningen 100 %, men ikke alle mulige grene er dækket. Du skal bruge en ekstra test, hvor:
  • condition1=false, condition2=false, condition3=false - på denne måde dækker vi også den falske sti i det andet if. Der bør ikke blive udskrevet noget i dette testtilfælde,
• Betingelsesdækning: en omfattende teknik, hvor alle stier testes. Den sikrer, at hver sti i applikationen er dækket af mindst én test. Den er især nyttig til komplekse applikationer. Eksempel: For koden ovenfor har vi brug for endnu en test for fuld betingelsesdækning:
  • condition1=false, condition1=true, hvilket giver samme resultat som den første test, men dækker en anden betingelse for at nå frem til resultatet.

Fordele og ulemper ved test med kendskab til intern kode

Lad os se på fordelene og ulemperne ved test med kendskab til intern kode.

Fordele:

• Kan finde fejl tidligt i softwareudviklingens livscyklus
• Tester kodens interne struktur.
• Tester kodedækning og logik.
• Forbedrer kendskabet til kodebasen.
• Kan bruges til test af ydeevne og skalerbarhed.

Ulemper:

• Fungerer bedre på et lavere testniveau 
• Kræver godt kendskab til systemets programmeringssprog
• Begrænset testning fra slutbrugerens perspektiv
• Kan overse scenarier fra den virkelige verden

Hvornår skal man bruge test med kendskab til intern kode? 

Test med kendskab til intern kode er bedst egnet til lavere niveauer, såsom enheds- og integrationstest. Det hjælper med at identificere fejl og mangler tidligt i udviklingsprocessen. Det er en god idé at udføre disse tests efter hver implementering, især når man arbejder i et CI/CD-miljø. 

Test med kendskab til intern kode kan bruges til at teste funktionalitet, men den kan også bruges til at afdække sårbarheder i systemet - noget, der ville være svært at opnå med testteknikker uden kendskab til intern kode.

Test uden kendskab til intern kode kontra test med kendskab til intern kode: Opsummering 

Lad os se på de vigtigste forskelle mellem test uden kendskab til intern kode og test med kendskab til intern kode:

Men lad os ikke glemme, at selvom begge tilgange har fordele og ulemper, bør vi bruge dem begge i vores testproces for at opnå god test- og kodedækning og finde de vigtigste fejl.

Konklusioner

Test uden kendskab til intern kode og test med kendskab til intern kode er to forskellige tilgange, og de fungerer hver især til forskellige behov under udviklingsprocessen. Test med kendskab til intern kode udføres for det meste af udviklere og anvendes til test på lavere niveauer, mens test uden kendskab til intern kode udføres af QA-teamet på højere niveauer, men de fungerer bedst, når de bruges sammen.

Hvis du kunne lide denne artikel, kan du abonnere på nyhedsbrevet for at modtage alle de nyudgivne artikler om testning og kvalitetssikring!