Hvad er performance testing?

Question

Accepted Answer

**Performance testing** evaluerer, hvordan et system klarer sig under belastning — ved at måle **hastighed, skalerbarhed og stabilitet** under forskellige forhold. Typerne omfatter load, stress, spike og soak testing. Det er væsentligt for at sikre, at systemer håndterer real-verden (og peak) forbrug acceptabelt.

## Hvad performance testing måler

```text
Non-functional testing of HOW WELL the system performs (not just correctness):
  → RESPONSE TIME / latency (how fast?), THROUGHPUT (requests/sec handled)
  → SCALABILITY (behavior as load grows), RESOURCE usage (CPU, memory)
  → STABILITY under sustained or extreme load
→ ensures the system meets performance requirements and handles real usage.
```

## Typer af performance tests

```text
LOAD testing → expected/normal load → does it meet targets under typical usage?
STRESS testing → BEYOND normal limits → find the breaking point; how it fails/recovers
SPIKE testing → sudden sharp load increase → handles bursts? (e.g. a flash sale)
SOAK / endurance → sustained load over a LONG time → finds memory leaks, degradation
SCALABILITY → how performance changes as load/resources scale
```

## Hvordan og hvorfor

```text
✓ Tools: k6, JMeter, Gatling, Locust → simulate many virtual users / high request rates
✓ Define performance REQUIREMENTS/SLAs (e.g. p95 latency < 200ms at X users) → test against them
✓ Test realistic scenarios; measure under controlled conditions; find BOTTLENECKS
✓ WHY: poor performance → bad UX, lost users/revenue, outages under load; find issues
  BEFORE production (e.g. before a big launch/traffic event)
```

## Hvorfor det betyder noget

At forstå performance testing er værdifuld viden på seniorniveau, fordi **performance er en kritisk kvalitetsattribut** — systemer skal kunne håndtere real-verden og peak load acceptabelt — så test af det er vigtig for pålidelighed og brugeroplevelse, hvilket gør denne viden brugbar.

Performance testing evaluerer **hvor godt et system klarer sig** (responstid, throughput, skalerbarhed, ressourceforbrug, stabilitet) under belastning — en ikke-funktionel kvalitet, der er forskellig fra korrekthed, men kritisk, fordi dårlig performance forårsager dårlig UX, tabte brugere og indtægter og nedetid under belastning.

At forstå **typerne** og deres formål er nøglen: **load testing** (verifikation af performance under forventet belastning), **stress testing** (presse ud over grænserne for at finde brudpunktet og hvordan systemet fejler/genopretter), **spike testing** (håndtering af pludselige stigninger, som et flashsalg), **soak/endurance testing** (vedvarende belastning over tid, opdagelse af hukommelses lekager og forringelse), og skalerbarhedstesting — hver besvarer forskellige spørgsmål om, hvordan systemet opfører sig under forskellige forhold.

At forstå **hvordan og hvorfor** — ved at bruge værktøjer (k6, JMeter, Gatling, Locust) til at simulere belastning, definere performance-krav/SLA'er at teste mod (f.eks. p95 latency-mål ved en given brugertælling), teste realistiske scenarier for at finde flaskehalse, og kritisk at gøre dette **før produktion** (især før større lanceringar eller trafikbegivenheder) for at fange performance-problemer, før de forårsager rigtige fejl — afspejler den praktiske værdi.

Performance testing forhindrer det dyrt scenario, hvor et system fejler under rigtig belastning (en lancering går ned, et websted bremser til ubrugelighed under spidstid).

Da performance er en kritisk kvalitetsattribut (hvor dårlig performance forårsager rigtig forretnings- og UX-skade) og performance testing (load, stress, spike, soak) verificerer, at systemer håndterer real-verden og peak forbrug før produktion, og da forståelse af typerne, værktøjerne og værdien er vigtig for at sikre, at systemer klarer sig under belastning, er forståelse af performance testing værdifuld viden på seniorniveau — vigtig for at verificere en kritisk ikke-funktionel kvalitet, sikre at systemer håndterer real-verden forbrug, og fange performance-problemer før de forårsager produktionsfejl, hvilket afspejler bredden af kvalitetsproblemer, som senioringeniører adresserer.