Load Test inom mobilutveckling — vad det är, scenarier och hur det utförs

Vad är Load Test?

Load Test (belastningstestning) är en process för att kontrollera hur systemet fungerar under förväntat antal samtidiga förfrågningar eller användare. Inom mobilutveckling tillämpas Load Test både på serversidan (API, databas, cache) och klientsidan (bearbetning av push-notiser, datasynkronisering). Huvudskillnaden från stresstestning — Load Test modellerar verklig, inte extrem, belastning. Enligt AWS Well-Architected Framework (2024) bör belastningstestning utföras med belastningsprofiler baserade på verklig användningsanalys.

Load Test kan utföras på nivån av HTTP-förfrågningar till API:et, på nivån av WebSocket-anslutningar eller på nivån av databastransaktioner. Målet är att säkerställa att svarstiden för varje förfrågan inte överskrider den fastställda tröskeln (vanligtvis 500–1000 ms för API) och att genomströmningskapaciteten (RPS — requests per second) uppfyller kraven. Google Cloud Armor (2024) definierar tröskelvärden baserade på percentiler: p95 för svarstid bör inte överstiga 2 sekunder för kritiska endpoints.

Belastningstestning av mobil backend inkluderar simulering av typiska scenarier: registrering, auktorisering, laddning av flöde, skicka formulär. Scenarierna spelas in i form av HAR-filer (HTTP Archive) och återskapas av belastningstestverktyget. Enligt k6-dokumentationen (2025) kan HAR-konvertering minska förberedelsetiden för Load Test med 60 %.

Mål med belastningstestning

Första målet med Load Test — bekräftelse av systemets genomströmningskapacitet. Om specifikationen kräver hantering av 1000 RPS måste belastningstestet bekräfta detta med 20 % marginal. Enligt Netflix Tech Blog (2024) utförs belastningstestning på Netflix med 2x marginal från toppbelastning: om 10000 RPS förväntas testar testet 20000 RPS. Detta tillvägagångssätt garanterar stabilitet vid plötsliga trafiktoppar.

Andra målet — identifiering av flaskhalsar (bottlenecks) i arkitekturen. Typiska flaskhalsar i mobila backends — databas (långsamma frågor), cache (felaktig invalidationsstrategi) och externa API:er (långsamma tredjepartstjänster). Distributed tracing (Jaeger, Zipkin) hjälper att lokalisera problemet på nivån av en specifik tjänst eller förfrågan.

Tredje målet — bestämning av mättnadspunkt (saturation point). Detta är ögonblicket när tillägg av nya användare slutar öka genomströmningskapaciteten. I mobilapplikationer inträffar mättnadspunkten ofta vid 70–80 % CPU-belastning på databasservrarna. Auto-scaling bör aktiveras innan denna punkt nås.

Belastningstestscenarier

Toppbelastning (Spike Test) — modellerar plötslig aktivitetsökning, till exempel morgonutskick av push-notiser eller lansering av reklamkampanj. Enligt Grafana k6 (2025) simulerar Spike Test en belastningsökning från 100 till 10000 RPS på 30 sekunder. Systemet bör klara detta utan att förlora förfrågningar och utan att svarstiden ökar med mer än 50 %.

Konstant belastning (Endurance Test) — kontroll av systemets stabilitet vid långvarig drift under belastning. Typisk varaktighet — 1–4 timmar. Endurance Test avslöjar minnesläckor i serverapplikationer, problem med databasanslutningspooler och försämring av cache-prestanda. PostgreSQLs anslutningspool under långvarig belastning utan korrekt konfiguration kan förbruka tillgängliga anslutningar inom 2–3 timmars drift.

Stegvis belastning (Step Load Test) — gradvis ökning av belastning med steg om 10–20 % var 2–5 minut. Detta scenario hjälper till att hitta den exakta gränsen där systemet försämras. InfluxDB och Prometheus samlar in mätvärden vid varje steg för att bygga en graf över svarstidens beroende av RPS.

Load Test-mätvärden

Svarstid

Svarstid (Response Time) — det huvudsakliga mätvärdet för Load Test. Mäts i millisekunder och analyseras baserat på percentiler: p50 (median), p95 och p99. Google SRE (2024) rekommenderar tröskel p95 på högst 1000 ms för REST API och högst 200 ms för gRPC. Percentiler är viktigare än genomsnittet eftersom de visar beteendet hos de sämsta förfrågningarna som användarna märker först. Apdex (Application Performance Index) — ett sammansatt mätvärde som tar hänsyn till andelen nöjda, toleranta och besvikna användare.

Genomströmningskapacitet

Genomströmningskapacitet (Throughput) — antalet lyckade förfrågningar per tidsenhet. Mäts i RPS (requests per second) eller TPS (transactions per second). Throughput-grafen i koordinaterna “tid — RPS” bör vara linjär fram till mättnadspunkten. Plötsligt fall i Throughput vid ökad belastning — tecken på att systemets gräns har nåtts. Apache Bench och wrk — enkla CLI-verktyg för snabb kontroll av Throughput i utvecklingsskedet.

Felfrekvens

Felfrekvens (Error Rate) — andelen svar med HTTP-status 4xx eller 5xx av det totala antalet förfrågningar. Tillåten tröskel — mindre än 1 %. Fel 429 (Too Many Requests) och 503 (Service Unavailable) under hög belastning indikerar behov av konfigurering av rate limiting och auto-scaling. Rate limiter på API Gateway-sidan skyddar backend från att överskrida tillåten belastning. Retry policy med exponentiell backoff hjälper klienter att hantera tillfälliga fel korrekt.

Verktyg för Load Test

k6 (Grafana)

k6 — det ledande Open Source-verktyget för belastningstestning från Grafana. Skript skrivs i JavaScript, stöder modulära scenarier, trösklar (thresholds) och integration med Prometheus och InfluxDB. k6 kan köras både i CLI och i molnet Grafana Cloud k6. Grafana Cloud bygger automatiskt instrumentpaneler baserat på Load Test-resultat och jämför dem med historiska data. k6 stöder Protocol Buffers och gRPC via en separat modul k6/net/grpc.

Apache JMeter

Apache JMeter — klassiskt verktyg för Load Test med grafiskt gränssnitt. Stöder ett brett spektrum av protokoll: HTTP, JDBC, JMS, FTP och TCP. JMeter passar bättre för komplexa scenarier med många olika typer av förfrågningar men kräver mer manuell konfiguration jämfört med k6. JMeter Plugins utökar funktionaliteten för WebSocket- och gRPC-testning. För distribuerad körning använder JMeter en master-slave-arkitektur med en kontroller.

Locust

Locust — ett Python-baserat verktyg som gör det möjligt att beskriva belastningsscenarier i kod. Locust är bekvämt för team som använder Python som huvudspråk för automatisering. Till skillnad från k6 och JMeter stöder Locust distribuerad körning direkt ur lådan: en master-nod koordinerar flera worker-noder. Distribuerad körning gör det möjligt att generera belastning upp till 100000 RPS från flera maskiner. Locust stöder även WebSocket-testning via anpassade tillägg.

import http from 'k6/http'
import check from 'k6'
import sleep from 'k6'

export const options = {
    stages: [
        { duration: '2m', target: 100 },
        { duration: '5m', target: 100 },
        { duration: '2m', target: 200 },
    ],
    thresholds: {
        http_req_duration: ['p(95)<500'],
        http_req_failed: ['rate<0.01'],
    }
}

export default function() {
    const res = http.get('https://api.example.com/users')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
    sleep(1)
}

Exempel på att skriva Load Test i k6

Skriptet ovan i k6 visar den typiska strukturen för ett belastningstest. Options definierar belastningsprofilen: ramp-up 2 minuter till 100 användare, sedan 5 minuters konstant belastning och ytterligare ramp-up till 200 användare. Thresholds anger kriterierna för att testet ska godkännas: p95 för förfrågningstid högst 500 ms, felfrekvens mindre än 1 %. Om trösklarna överskrids avslutar k6 testet med en kod som inte är noll — detta gör det möjligt att integrera Load Test i CI/CD.

Inom mobilutveckling är Load Test av serversidan särskilt viktigt vid lansering av nya funktioner som skapar extra belastning: gilla-markeringar, kommentarer, streaming. Rekommendation — utför Load Test på varje staging innan utrullning till produktion. Skapande av en baslinjebelastningsprofil i API-designskedet hjälper till att undvika arkitektoniska problem i senare skeden.