Brugscase-testning med eksempler
⚡ Smart opsummering
Use Case Testing validerer end-to-end-transaktioner ved at udføre interaktionerne mellem en aktør og systemet. Teknikken driver testcases på system- og acceptniveau, afdækker integrationshuller og supplerer kontroller på enhedsniveau med realistiske brugerarbejdsgange.

Hvad er Use Case Testing?
Use Case Test er en softwaretestteknik, der identificerer testcases, der dækker et helt system transaktion for transaktion, fra start til slut. Testcases beskriver interaktionerne mellem brugere og softwareapplikationen. Use case-testning afdækker huller, der muligvis ikke afsløres ved at teste individuelle softwarekomponenter isoleret.
A brug tilfælde I test er en kort beskrivelse af en bestemt brug af softwaren af en aktør eller bruger. Brugsscenarier skrives ud fra brugerhandlinger og de tilsvarende svar fra applikationen, og de bruges i vid udstrækning til at udlede test tilfælde på system- og acceptniveauer.
Nøglekomponenter i en use case
Hvert use case er bygget op fra de samme byggesten. At kende delene på forhånd gør det nemmere at designe dækning, der er præcist tilpasset testcases:
- Skuespiller: brugeren eller det eksterne system, der initierer en interaktion. Repræsenteret som "A" i tekstflow.
- System: den software, der testes, og som reagerer på aktøren. Repræsenteret som "S".
- Forudsætninger: den tilstand, systemet skal være i, før use casen kan starte.
- Primært successcenarie: Den lykkelige sti-sekvens af aktør- og systemtrin.
- Udvidelser / alternative strømme: grene, der håndterer undtagelser, valideringsfejl eller alternative valg.
- Efterbetingelser: den tilstand, systemet befinder sig i, når use casen er afsluttet.
Sådan gør du Use Case Test: Eksempel
I et use case er aktøren repræsenteret af "A" og systemet af "S". Eksemplet nedenfor beskriver login-funktionaliteten i en webapplikation.
| Vigtigste successcenarie | Trin | Beskrivelse |
|---|---|---|
| A: Aktør S: System | 1 | A: Indtast agentnavn og adgangskode |
| 2 | S: Valider adgangskode | |
| 3 | S: Tillad kontoadgang | |
| Udvidelser | 2a | Adgangskoden er ikke gyldig S: Vis besked og bed om at forsøge igen (op til 4 gange) |
| 2b | Adgangskoden er ikke gyldig 4 gange S: Luk ansøgning |
Ovenstående flow beskriver én lykkelig vej og to forlængelser. Læsning trin for trin:
- Aktøren indtaster en e-mail og adgangskode som det første trin i det komplette login-flow.
- Systemet validerer adgangskoden.
- Hvis adgangskoden er korrekt, gives der adgang.
- Hvis adgangskoden er ugyldig, viser systemet en meddelelse og beder om op til fire nye forsøg.
- Hvis adgangskoden forbliver ugyldig efter fire forsøg, blokerer systemet yderligere forsøg (i dette eksempel ved at udelukke IP-adressen).
Ud fra denne use case ville du teste successcenariet plus ét tilfælde af hver udvidelse. Det giver mindst tre testcases: et gyldigt login, en gendannelig ugyldig adgangskode og en låsning efter gentagne fejl.
Fordele ved use case-testning
Use case-testning passer naturligt ind mellem krav og testcases. De vigtigste fordele er:
- Dækning fra start til slut: tester transaktioner på tværs af moduler, ikke isolerede funktioner.
- Brugerfokuseret validering: Hvert scenarie afspejler, hvordan en reel aktør bruger systemet.
- Slet valg tracevne: Anvendelsessager knyttes direkte til acceptkriterier for interessentens godkendelse.
- Forebyggelse af defekter: viser integrationsgab, før regressionscyklusser begynder.
- Genanvendelige artefakter: Den samme use case føder testcases, træningsmateriale og brugerdokumentation.
Begrænsninger ved use case-testning
Teknikken er effektiv, men ikke udtømmende. Vær opmærksom på følgende begrænsninger:
- Ikke en erstatning for enhedstestning: Lavniveau-komponentfejl kræver stadig målrettede tests.
- Afhænger af præcise anvendelsesscenarier: Tvetydige flows producerer tvetydige tests.
- Begrænset til ikke-funktionel dækning: Ydeevne, sikkerhed og tilgængelighed kræver deres egne teknikker.
- Vedligeholdelsesomkostninger: Brugsscenarier skal opdateres, når forretningsreglerne ændres.

