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.

