Stabil drift og kapacitet
Belastningstest: kan appen holde til flere brugere?
En app kan virke hurtigt, når udvikleren klikker alene, og stadig blive langsom eller fejle, når medarbejdere gemmer, søger og henter data samtidig. En belastningstest efterligner de vigtigste brugerforløb under en aftalt mængde trafik. Målet er ikke at skabe et flot tal, men at finde flaskehalse og farlige fejl, før de rammer den daglige drift.
En almindelig test beviser funktion – ikke kapacitet
En funktionstest spørger typisk, om en handling giver det rigtige resultat. En belastningstest spørger, om handlingen stadig lykkes hurtigt og korrekt, når mange handlinger overlapper. Begge dele er nødvendige, men de finder forskellige fejl.
| Test | Spørgsmål | Kan blandt andet afsløre |
|---|---|---|
| Funktionstest | Kan brugeren oprette en sag? | Forkert validering eller brudt arbejdsgang |
| Belastningstest | Kan mange oprette og søge samtidig? | Langsomme svar, fejl, køer og manglende kapacitet |
| Stresstest | Hvor går grænsen, og kommer appen tilbage? | Brudpunkt, dårlig nedskalering eller fastlåste ressourcer |
| Langtidstest | Holder appen til vedvarende belastning? | Hukommelseslæk, voksende køer eller udtømte forbindelser |
Begynd med en lille smoke-test af selve testscriptet og en realistisk belastningstest. Stress-, spidsbelastnings- og langtidstest giver mest værdi, når appens risiko og forventede brug kræver dem.
Vælg et kritisk forløb – ikke bare forsiden
Den mest besøgte URL er ikke nødvendigvis den vigtigste belastning. Vælg et forløb, hvor ventetid, fejl eller forkerte data har en tydelig konsekvens for virksomheden. Beskriv handlingerne i den rækkefølge, en rigtig bruger udfører dem.
- Sagsarbejde: Log ind, find kunde, åbn sag, gem ændring og genindlæs resultatet.
- Booking eller ordre: Søg, kontrollér tilgængelighed, opret og bekræft uden dubletter.
- Rapport eller dashboard: Hent den datamængde og de filtre, som medarbejderne faktisk bruger.
- Filbehandling: Upload, scanning, konvertering og statusvisning med de aftalte størrelser og typer.
- Integration: Modtag eller send hændelser, og kontrollér både svartid, kø og endeligt resultat.
Sæt mål ud fra den virkelige arbejdsdag
Et vilkårligt antal virtuelle brugere fortæller ikke, om appen er klar. Tag udgangspunkt i, hvor mange mennesker og automatiske processer der kan være aktive på samme tid, hvilke spidsperioder der findes, og hvor længe den konkrete handling må tage, før arbejdet går i stå.
- Belastning
- Samtidige brugere, handlinger pr. tidsenhed, automatiske jobs og realistisk fordeling mellem forløb.
- Svartid
- Målet for hele brugerhandlingen og relevante delsystemer – vurderet på fordelingen, ikke kun gennemsnittet.
- Fejl
- Tilladte og ikke-tilladte fejl samt krav om, at data ikke mistes, overskrives eller oprettes dobbelt.
- Gendannelse
- Hvordan køer, autoskalering, forbindelser og svartid skal normaliseres, når belastningen falder.
Microsoft anbefaler målbare performancekrav og tydelige bestået/ikke bestået-kriterier, men advarer mod at vælge servicemål, før brugerforløb og forretningsbehov er forstået. Gem derfor antagelserne sammen med resultatet, så et grønt testresultat ikke bliver brugt som bevis for en anden belastning end den, der faktisk blev kørt.
Testmiljøet skal ligne det, resultatet skal sige noget om
En test mod en lille udviklingsdatabase kan kontrollere scriptet, men ikke bevise produktionskapacitet. Sammenlign hostingplan, autoskalering, database, indeks, cache, netværk, køer, datamængde og eksterne afhængigheder med produktion. Dokumentér forskellene, hvis et identisk miljø ikke er praktisk.
- Brug kontrollerede testdata: Lav navngivne testbrugere og data, som kan ryddes op uden at ramme rigtige kunder.
- Beskyt eksterne handlinger: Brug leverandørens testmiljø eller en realistisk mock, så testen ikke sender fakturaer, mails, beskeder eller betalinger.
- Kontrollér kvoter og omkostning: Trafikken kan udløse skalering, databaseforbrug og tredjepartskald. Aftal loft og stopkriterier på forhånd.
- Hold secrets ude af scriptet: Brug testidentiteter og sikker konfiguration; læg ikke tokens eller produktionsadgange i repositoryet eller resultatfiler.
- Vær varsom med produktion: En kontrolleret produktionstest kræver risikovurdering, overvågning, ekstra kapacitet, stopmulighed og en dokumenteret vej tilbage.
Mål hele kæden, mens testen kører
Testværktøjet kan vise svartid og fejl fra brugerens side, men det forklarer ikke alene årsagen. Kobl testen til appens eksisterende målinger, så resultatet kan følges gennem frontend, API, database, køer og eksterne tjenester.
Det brugeren oplever
- Gennemførte og fejlede forløb
- Svartidsfordeling og langsomme ydertilfælde
- Ventetid i browseren og synlig status
- Korrekt resultat efter genindlæsning
Det systemet bruger
- API-fejl, throughput og timeouts
- CPU, hukommelse og samtidighed
- Databaseforbindelser, langsomme queries og låse
- Kølængde, retries og eksterne fejl
Kontrollér også forretningsdata efter testen. Et hurtigt svar er ikke en succes, hvis en ordre blev oprettet to gange, en ændring forsvandt, eller et baggrundsjob stadig står fast. Brug et fælles test-id i requests og logs, så de relevante hændelser kan findes uden at logge følsomme payloads.
En praktisk arbejdsgang
- 1. Vælg risikoen. Beskriv den arbejdsgang, hvor langsomhed eller fejl vil gøre mest skade.
- 2. Skriv belastningen. Brug forventede samtidige brugere, handlinger, tænketid og spidsperioder – ikke et rundt tal uden forklaring.
- 3. Aftal bestået. Fastlæg svartid, fejl, datakorrekthed og gendannelse ud fra forretningsbehovet.
- 4. Klargør miljø og data. Dokumentér afvigelser fra produktion, beskyt eksterne tjenester, og gør oprydning mulig.
- 5. Kør småt først. Bevis at script og målinger virker, og øg derefter gradvist belastningen under aktiv overvågning.
- 6. Find flaskehalsen. Sammenhold brugeroplevelse, API, database, køer, platformskvoter og tredjepartskald.
- 7. Ret og gentag identisk. Sammenlign samme scenarie, data, miljø og belastning, og gem baseline, version og resultat.
Typiske fejl
- Kun forsiden rammes: Testen belaster statiske filer, mens database og kritiske handlinger næsten ikke berøres.
- Der måles kun gennemsnit: Enkelte meget langsomme forløb skjules, selv om de rammer rigtige brugere.
- Testen opretter rigtige handlinger: Kunder modtager beskeder, lager ændres, eller betalinger og fakturaer udløses.
- Udviklingsmiljøet bruges som kapacitetsbevis: Ressourcer, datamængde og skalering matcher ikke produktion.
- Belastningen springer direkte til maksimum: Appen eller en leverandør rammes uden baseline, stopkriterier eller mulighed for at se det første brudpunkt.
- Kun HTTP-status tælles: Svaret er 200, men data er forkerte, dublerede eller aldrig færdigbehandlet.
- To forskellige testkørsler sammenlignes: Ændret data, miljø eller trafikmønster gør forbedringen umulig at tilskrive.
Tjekliste før flere får adgang til appen
- ☐ Et kritisk brugerforløb og dets forretningskonsekvens er valgt.
- ☐ Samtidighed, trafikmønster, tænketid og datamængde bygger på dokumenterede antagelser.
- ☐ Svartid, fejl, datakorrekthed og gendannelse har tydelige acceptkriterier.
- ☐ Testmiljøets forskelle fra produktion er kendt og indgår i vurderingen.
- ☐ Testbrugere og testdata er adskilt, sporbare og kan ryddes sikkert op.
- ☐ Betalinger, mails, beskeder og andre eksterne handlinger bruger testtilstand eller kontrollerede mocks.
- ☐ Secrets og rigtige kundedata ligger ikke i script, repository, logs eller resultatfiler.
- ☐ Platformskvoter, omkostningsrisiko, stopkriterier og ansvarlig er afklaret.
- ☐ Logs og målinger dækker frontend, API, database, køer og relevante integrationer.
- ☐ Efterkontrol beviser, at data ikke blev mistet, overskrevet eller oprettet dobbelt.
- ☐ Testversion, scenarie, miljø, belastning, resultat og kendte begrænsninger er gemt.
- ☐ Den samme test kan gentages efter rettelser og væsentlige arkitekturændringer.
Relaterede guides
Officielle kilder
Den konkrete test skal tilpasses appens brugerforløb, arkitektur og platform. Rådene er kontrolleret mod aktuelle officielle kilder om performancekrav, testmiljøer, trafikmodeller, målinger og sikker testafvikling.