5 typer svartboks-testingsteknikker + eksempler

Et av favorittuttrykkene mine er «jobb smartere, ikke hardere». Dette gjelder selvfølgelig også programvaretesting. Det betyr at jeg ønsker en måte å gjøre minst mulig arbeid på og samtidig skape størst mulig verdi.

Så la oss snakke om svartboks-testteknikker og hvordan de kan brukes til å lage testtilfeller og finne de viktigste feilene i applikasjonen som testes.

Hva er svartbokstesting?

La oss begynne med å forstå hva svartbokstesting er—i motsetning til hvitbokstesting. Det er en type programvaretesting der testeren ikke har tilgang til den interne strukturen i appen som testes. I stedet har testeren bare tilgang til systemets inndata og utdata og kan teste programvarens funksjonalitet basert på kravspesifikasjonene.

Husk at svartbokstesting bare dekker programvarens eksterne funksjonalitet og ikke verifiserer hvordan kildekoden fungerer internt. Derfor kalles det noen ganger «atferdstesting». Det bør derfor brukes sammen med hvitbokstesting, som fokuserer på testing av den interne koden. På denne måten kan du føle deg tryggere på at programvaren er grundig testet og så feilfri som mulig.

5 typer svartboks-testteknikker

Vi bruker disse svartboks-testteknikkene for å øke testdekningen og samtidig redusere antallet testtilfeller. Ved å identifisere riktige testdata kan vi lage færrest mulig tester med størst mulig dekning.

Teknikkene jeg skal snakke om, kan brukes på alle testnivåer—inkludert enhetstesting, integrasjonstesting og systemtesting, samt funksjonell og ikke-funksjonell testing.

1. Ekvivalensklasseinndeling

Ekvivalensklasseinndeling er en teknikk som brukes i programvaretesting for å dele mulige inndata inn i et sett med ekvivalensklasser eller partisjoner, med mål om å finne og teste et representativt utvalg av inndata fra hver klasse. Alle elementene som tilhører en ekvivalensklasse, forventes å gi samme utdata, så det bør være tilstrekkelig å teste én enkelt verdi fra settet.

Dette bidrar til å redusere antallet testtilfeller som må opprettes og kjøres, samtidig som man opprettholder god dekning. Klassene defineres basert på funksjonelle eller ikke-funksjonelle krav og kan ta hensyn til faktorer som datatyper, intervaller og forhold mellom inndataverdier.

Når du definerer ekvivalensklassene, bør du alltid sørge for å inkludere de ugyldige også, slik at du dekker negative testscenarioer. Etter min erfaring finner man de fleste feilene ved bruk av ugyldige inndata, ikke gyldige.

La oss se på et eksempel:

Du har et valgfritt felt som bare tillater heltallsverdier mellom 1 og 10. Da får du følgende ekvivalensklasser:

• ingen verdi (gyldig partisjon)
• verdier mellom 1 og 10 (gyldig partisjon)
• verdier mindre enn 1 (ugyldig partisjon)
• verdier større enn 10 (ugyldig partisjon)

Du trenger altså bare 4 testtilfeller – ett for hver partisjon. Det gir ingen ekstra verdi å teste den samme partisjonen på nytt med flere verdier—hvis du testet verdien 5, ville du fått de samme resultatene for verdiene 4, 8 og så videre.   

2. Grenseverdianalyse

Grenseverdianalyse er en teknikk som brukes i programvaretesting for å identifisere og teste inndataverdier ved eller nær kanten, eller «grensen», av programmets inndatadomene. Tanken er at disse verdiene har større sannsynlighet for å forårsake feil eller uventet atferd fordi de ofte omfatter spesialtilfeller eller grenseverdier som programmet kanskje ikke er utformet for å håndtere på riktig måte.

Hvis du for eksempel tester et program som godtar et heltallsintervall mellom 1 og 100, vil grenseverdiene være 1, 100 og alle verdiene like utenfor intervallet, for eksempel 0 og 101.

De to typene grensetesting er:

• Testing av indre grenser: fokuserer på inndataverdiene som ligger like innenfor kanten av inndatadomenet, for eksempel de minste og største tillatte verdiene.
• Testing av ytre grenser: fokuserer på inndataverdiene som ligger like utenfor kanten av inndatadomenet, for eksempel verdier som er litt høyere eller lavere enn de minste og største tillatte verdiene.

Grenseverdianalyse er en viktig teknikk for å finne feil og sikre at et program oppfører seg korrekt for alle inndata, ikke bare for dem midt i inndataområdet. Dette kan bidra til å identifisere og rette feil som ellers kanskje ikke ville blitt oppdaget.

3. Testing med beslutningstabell

Ved testing med beslutningstabell tester vi logikken og oppførselen til programvaren når flere betingelser er tilgjengelige. Det er en måte å representere forholdet mellom inndata og utdata i tabellform. Tabellen har vanligvis kolonner for betingelser og rader for de ulike kombinasjonene. For hver rad må du opprette et spesifikt testtilfelle. Forventet utdata for testtilfellet bør også inkluderes i tabellen.

La oss se for oss et eksempel på et programvarekrav der denne teknikken kan brukes: en app som beregner kostnaden for et kjøp basert på varen, antallet og fraktmetoden:

I dette eksempelet er vare, antall og fraktmetode inndataene, mens kostnaden er utdataen. Tabellen viser alle mulige kombinasjoner av inndata og den tilsvarende utdataen i hvert tilfelle. Ved å bruke denne tabellen kan du raskt identifisere testtilfellene og de forventede resultatene, noe som gjør det enkelt å teste og verifisere de tilgjengelige kombinasjonene.

Testing med beslutningstabell er nyttig når et program har flere inndata og betingelser som påvirker hverandre på komplekse måter. Ved å bryte ned inndataene og betingelsene i en tabell blir det enklere å identifisere og teste alle mulige kombinasjoner og variasjoner.

4. Testing av tilstandsoverganger

Testing av tilstandsoverganger er en svartboks-testteknikk der vi tester oppførselen til et program når det går mellom ulike tilstander eller moduser. En tilstand er en betingelse eller et sett med betingelser som programmet kan befinne seg i, og en overgang er en endring fra én tilstand til en annen. Tanken bak testing av tilstandsoverganger er å identifisere alle mulige tilstander og overganger et program kan gå gjennom, og deretter opprette testtilfeller for å kontrollere at programmet oppfører seg korrekt i hver tilstand og foretar gyldige overganger mellom tilstandene.

Et eksempel på testing av tilstandsoverganger kan være et nettsted for netthandel der kunder kan legge varer i handlekurven, gå videre til utsjekking, angi betalingsinformasjon og leveringsopplysninger og til slutt legge inn en bestilling. Tilstandene i dette eksempelet vil være:

• Se på produkter
• Legge varer i handlekurven
• Gå til utsjekking
• Angi betalings- og leveringsopplysninger
• Bekreftelse av bestilling

Overgangene mellom disse tilstandene vil være:

• Se på produkter -> Legge varer i handlekurven
• Legge varer i handlekurven -> Gå til utsjekking
• Gå til utsjekking -> Angi betalings- og leveringsopplysninger
• Angi betalings- og leveringsopplysninger -> Bekreftelse av bestilling

Denne teknikken bidrar til å identifisere og teste alle mulige veier en bruker kan ta gjennom systemet, og kan bidra til å finne og rette feil knyttet til bestemte flyter. Testing av tilstandsoverganger er spesielt nyttig for testing av systemer med komplekse samhandlinger, for eksempel økonomiske systemer, netthandelssystemer eller systemer som styrer fysiske enheter.

5. Parvis testing

Parvis testing er en svartboks-testteknikk som brukes til å opprette testtilfeller som dekker alle mulige par av kombinasjoner av inndataverdier for et gitt sett med parametere. Den brukes når antallet tilgjengelige inndata er høyt, noe som gjør det svært vanskelig å teste alle mulige kombinasjoner mellom dem.

La oss si at vi har en app med tre felt: A, B og C. Hvert felt kan godta tre mulige verdier: 1, 2 eller 3.

Med tradisjonelle testmetoder måtte vi teste 27 (3^3) mulige kombinasjoner av inndata individuelt for å validere alle mulige kombinasjoner. Dette ville vært svært tidkrevende og ineffektivt.

Med parvis testing kan du identifisere brukstilfeller som dekker alle mulige unike kombinasjoner av inndata. Det kan se omtrent slik ut:

Som du ser, er antallet tester redusert drastisk, fra 27 til 9. Testdekningen har ikke endret seg; vi sikrer fortsatt at alle mulige kombinasjoner av verdier tas med i betraktningen.

Det finnes flere tilgjengelige verktøy for parvis testing. Nedenfor lister jeg noen eksempler:

• AllPairs: Et verktøy for å opprette parvise testtilfeller basert på brukerspesifiserte parameterlister og begrensninger. Det er tilgjengelig i både åpen kildekode- og kommersielle versjoner.
• PICT (parvis uavhengig kombinatorisk testing): Et verktøy som bruker en genetisk algoritme til å generere parvise testtilfeller. Det er tilgjengelig som et verktøy med åpen kildekode.
• SmartBear TestComplete: Et kommersielt testautomatiseringsverktøy som inkluderer innebygd støtte for parvis testing.
• Pairwise Test Case Generator: Et verktøy med åpen kildekode som er tilgjengelig på GitHub, og som kan brukes til å generere parvise testtilfeller.
• Parvis testing kan også genereres ved hjelp av Excel eller OpenOffice Calc, ved å bruke makroer eller programtillegg til å generere testtilfellene dine.

Dette er bare noen få eksempler, og det kan også finnes andre tilgjengelige verktøy. Jeg anbefaler at du undersøker og vurderer de ulike tilgjengelige alternativene, og ser hvilket verktøy som fungerer best for dine spesifikke behov og krav.

Avsluttende tanker

Å bruke disse teknikkene er en flott måte å oppnå god dekning på ethvert stadium av livssyklusen for programvareutvikling. Det kan bli enda bedre hvis du kan legge til andre typer i testprosessen, for eksempel utforskende testing eller feilgjetting, kompatibilitetstesting, brukervennlighetstesting og så videre.

Hvis de resulterende testtilfellene også ender opp i regresjonstestpakken, bør du vurdere å automatisere dem—for UI-tester kan du bruke verktøy som Selenium, Cypress og Appium, for API-testing kan du ha integrasjonstester skrevet av utviklingsteamet, eller du kan bruke verktøy som Postman. 

Hvis du syntes denne artikkelen var nyttig, foreslår jeg at du abonnerer på QA Lead-nyhetsbrevet, der du får vite om alt det nye innholdet og veiledningene om kvalitetssikring og testing.