Et af mine yndlingsudtryk er: "arbejd smartere, ikke hårdere." Det gælder selvfølgelig også softwaretest. Det betyder, at jeg gerne vil have en måde at udføre mindst muligt arbejde på og samtidig skabe størst mulig værdi.
Så lad os tale om sortboks-testteknikker, og hvordan de kan anvendes til at oprette testtilfælde og finde de vigtigste fejl i den applikation, der testes.
Hvad er sortboks-testning?
Lad os begynde med at forstå, hvad sortboks-testning er—i modsætning til hvidboks-testning. Det er en type softwaretest, hvor testeren ikke har adgang til den interne struktur i den app, der testes. I stedet kan testeren kun få adgang til systemets input og output og teste softwarens funktionalitet ud fra kravspecifikationerne.
Husk, at sortboks-testning kun dækker softwarens eksterne funktionalitet og ikke verificerer den interne funktion af kildekoden. Derfor kaldes det nogle gange "adfærdsbaseret testning". Det bør derfor anvendes sammen med hvidboks-testning, som fokuserer på test af den interne kode. På den måde kan du være mere sikker på, at softwaren er fuldt testet og så fejlfri som muligt.
Have an account? Log In
5 typer af sortboks-testteknikker
Vi bruger disse sortboks-testteknikker til at øge testdækningen og samtidig reducere antallet af testtilfælde. Ved at identificere de rigtige testdata kan vi oprette det mindst mulige antal tests med den størst mulige dækning.
De teknikker, jeg vil gennemgå, kan anvendes på alle testniveauer—herunder enhedstest, integrationstest og systemtest samt funktionel og ikke-funktionel test.
1. Ækvivalensklasseinddeling
Ækvivalensklasseinddeling er en teknik, der bruges i softwaretest til at opdele de mulige input i et sæt ækvivalensklasser eller partitioner med det formål at finde og teste et repræsentativt sæt input fra hver klasse. Det forventes, at alle elementer, der tilhører en ækvivalensklasse, giver samme output, så det bør være tilstrækkeligt at teste én enkelt værdi fra sættet.
Det hjælper med at reducere antallet af testtilfælde, der skal oprettes og udføres, samtidig med at der stadig opnås god dækning. Klasserne defineres ud fra funktionelle eller ikke-funktionelle krav og kan tage højde for faktorer som datatyper, intervaller og relationer mellem inputværdier.
Når du definerer ækvivalensklasserne, skal du altid sørge for også at inkludere de ugyldige klasser for også at dække negative testscenarier. Efter min erfaring findes de fleste fejl ved brug af ugyldige input frem for gyldige.
Lad os se på et eksempel:
Du har et valgfrit felt, der kun tillader heltalsværdier mellem 1 og 10. Du vil have følgende ækvivalensklasser:
- ingen værdi (gyldig partition)
- værdier mellem 1 og 10 (gyldig partition)
- værdier mindre end 1 (ugyldig partition)
- værdier større end 10 (ugyldig partition)
Du har altså kun brug for 4 testtilfælde – 1 for hver partition. Det giver ingen ekstra værdi at genteste den samme partition med flere værdier—hvis du testede værdien 5, ville du få de samme resultater for værdierne 4, 8 og så videre.
2. Grænseværdianalyse
Grænseværdianalyse er en teknik, der bruges i softwaretest til at identificere og teste inputværdier ved eller tæt på kanten eller "grænsen" af programmets inputdomæne. Ideen er, at disse værdier med større sandsynlighed forårsager fejl eller uventet adfærd, fordi de ofte involverer specialtilfælde eller kanttilfælde, som programmet muligvis ikke er designet til at håndtere korrekt.
Hvis du for eksempel tester et program, der accepterer et interval af heltal mellem 1 og 100, vil grænseværdierne være 1, 100 og alle værdier lige uden for intervallet, såsom 0 og 101.
De to typer grænsetest er:
- Indre grænsetest: fokuserer på de inputværdier, der ligger lige inden for kanten af inputdomænet, såsom de tilladte minimums- og maksimumsværdier.
- Ydre grænsetest: fokuserer på de inputværdier, der ligger lige uden for kanten af inputdomænet, såsom værdier, der ligger lidt over eller under de tilladte minimums- og maksimumsværdier.
Grænseanalyse er en vigtig teknik til at finde fejl og sikre, at et program fungerer korrekt for alle input, ikke kun dem midt i inputdomænet. Dette kan hjælpe med at identificere og rette fejl, som ellers måske ikke ville blive opdaget.
3. Test af beslutningstabeller
Ved test af beslutningstabeller tester vi softwarens logik og adfærd, når flere betingelser er tilgængelige. Det er en måde at repræsentere forholdet mellem input og output i tabelform. Tabellen har typisk kolonner for betingelser og rækker for de forskellige kombinationer. For hver række skal du oprette et specifikt testtilfælde. Det forventede output for testtilfældet skal også medtages i tabellen.
Lad os forestille os et eksempel på et softwarekrav, hvor denne teknik kan anvendes: en app, der beregner prisen på et køb baseret på varen, antallet og forsendelsesmetoden:
I dette eksempel er Vare, Antal og Forsendelsesmetode inputtene, mens Pris er outputtet. Tabellen viser alle de mulige kombinationer af input og det tilsvarende output i hvert tilfælde. Ved at bruge denne tabel kan du hurtigt identificere testtilfældene og deres forventede resultater, hvilket gør det nemt at teste og verificere de tilgængelige kombinationer.
Test af beslutningstabeller er nyttigt, når et program har flere input og betingelser, der interagerer med hinanden på komplekse måder. Ved at opdele inputtene og betingelserne i en tabel bliver det nemmere at identificere og teste alle de mulige kombinationer og variationer.
4. Test af tilstandsovergange
Test af tilstandsovergange er en sortboks-testteknik, hvor vi tester et programs adfærd, når det skifter mellem forskellige tilstande eller tilstandsmåder. En tilstand er en betingelse eller et sæt af betingelser, som programmet kan befinde sig i, og en overgang er et skift fra én tilstand til en anden. Ideen bag test af tilstandsovergange er at identificere alle de mulige tilstande og overgange, som et program kan gennemgå, og derefter oprette testtilfælde for at verificere, at programmet fungerer korrekt i hver tilstand og foretager gyldige overgange mellem tilstandene.
Et eksempel på test af tilstandsovergange kunne være et e-handelswebsted, hvor kunder kan tilføje varer til deres indkøbskurv, gå videre til betaling, indtaste deres betalingsoplysninger og leveringsoplysninger og til sidst afgive en ordre. Tilstandene i dette eksempel ville være:
- Gennemse produkter
- Tilføje varer til indkøbskurven
- Gå videre til betaling
- Indtaste betalings- og leveringsoplysninger
- Ordrebekræftelse
Overgangene mellem disse tilstande ville være:
- Gennemse produkter -> Tilføje varer til indkøbskurven
- Tilføje varer til indkøbskurven -> Gå videre til betaling
- Gå videre til betaling -> Indtaste betalings- og leveringsoplysninger
- Indtaste betalings- og leveringsoplysninger -> Ordrebekræftelse
Denne teknik hjælper med at identificere og teste alle de mulige veje, som en bruger kan tage gennem systemet, og kan hjælpe med at finde og rette fejl relateret til bestemte forløb. Test af tilstandsovergange er særligt nyttigt til test af systemer med komplekse interaktioner, såsom finansielle systemer, e-handelssystemer eller systemer, der styrer fysiske enheder.
More Articles
5. Parvis testning
Parvis testning er en sortboks-testteknik, der bruges til at oprette testtilfælde, som dækker alle mulige parvise kombinationer af inputværdier for et givet sæt parametre. Den bruges, når antallet af tilgængelige input er højt, hvilket ville gøre det ekstremt vanskeligt at teste alle mulige kombinationer mellem dem.
Lad os sige, at vi har en app med 3 felter: A, B og C. Hvert felt kan acceptere 3 mulige værdier: 1, 2 eller 3.
Med traditionelle testmetoder skulle vi teste 27 (3^3) mulige kombinationer af input individuelt for at validere alle mulige kombinationer. Det ville være ekstremt tidskrævende og ineffektivt.
Med parvis testning kan du identificere anvendelsestilfælde, der dækker alle mulige unikke kombinationer af input. Det ville se nogenlunde sådan ud:
Som du kan se, er antallet af test blevet drastisk reduceret fra 27 til 9. Testdækningen er ikke ændret; vi sikrer stadig, at alle mulige kombinationer af værdier tages i betragtning.
Der findes flere værktøjer til parvis testning, som kan bruges. Herunder oplister jeg nogle eksempler:
- AllPairs: Et værktøj til oprettelse af parvise testtilfælde baseret på brugerspecificerede parameterlister og begrænsninger. Det findes både i open source- og kommercielle versioner.
- PICT (Pairwise Independent Combinatorial Testing): Et værktøj, der bruger en genetisk algoritme til at generere parvise testtilfælde. Det findes som et open source-værktøj.
- SmartBear TestComplete: Et kommercielt værktøj til testautomatisering, der inkluderer indbygget understøttelse af parvis testning.
- Generator til parvise testtilfælde: Et open source-værktøj, der er tilgængeligt på GitHub og kan bruges til at generere parvise testtilfælde.
- Parvise tests kan også genereres ved hjælp af Excel eller OpenOffice Calc ved hjælp af makroer eller plugins til at generere dine testtilfælde.
Dette er blot nogle få eksempler, og der kan også være andre tilgængelige værktøjer. Jeg anbefaler, at du undersøger og evaluerer de forskellige tilgængelige muligheder og ser, hvilket værktøj der fungerer bedst til dine specifikke behov og krav.
Afsluttende tanker
Brug af disse teknikker er en god måde at opnå god dækning på i alle faser af softwareudviklingens livscyklus. Det kan blive endnu bedre, hvis du kan tilføje andre testtyper til din testproces, såsom eksplorativ testning eller fejlbaseret testning, kompatibilitetstest, brugervenlighedstest og så videre.
Hvis de resulterende testtilfælde også ender i regressionstestpakken, bør du overveje at automatisere dem – til UI-tests kan du bruge værktøjer som Selenium, Cypress og Appium; til API-test kan udviklingsteamet skrive integrationstests, eller du kan bruge værktøjer som Postman.
Hvis du fandt denne artikel nyttig, foreslår jeg, at du abonner på QA Lead-nyhedsbrevet, hvor du kan læse om alt det nye indhold og alle vejledningerne om kvalitetssikring og testning.
