Stress Test inom mobilutveckling: vad det är, mål och hur det utförs

Vad är Stress Test?

Stress Test (stresstestning) är processen att utvärdera systemets förmåga att fungera under förhållanden som överskrider beräknade parametrar. För en mobilapplikation kan detta innebära 10 000 samtidiga push-notiser vid en norm på 1 000, för backend — 50 000 RPS vid förväntade 5 000. Huvudskillnaden mellan Stress Test och Load Test är att målet inte är att bekräfta prestanda, utan att studera systemets beteende utanför dess designade kapacitet. Netflix Engineering (2024) definierar Stress Test som “testning av hypotesen att systemet kommer att misslyckas på ett förutsägbart sätt”.

Stresstestning omfattar två obligatoriska steg: belastning tills fel och observation av återhämtning. Återhämtning (recovery) är systemets förmåga att återgå till normal drift efter att överbelastningen har avlägsnats. Ett system som inte återhämtar sig utan omstart anses vara skört, även om det klarar kortvarig överbelastning. Enligt AWS Well-Architected Framework (2024) bör återhämtningstiden efter Stress Test inte överstiga 5 minuter.

För mobila klienter inkluderar Stress Test kontroll av funktion vid tvungen avslutning av processer, nätverksfrånkoppling och uttömning av RAM-minne. Android Low Memory Killer kan avsluta en bakgrundsprocess vid RAM-brist — stresstestet bör kontrollera att applikationen korrekt återställer tillståndet efter en sådan avslutning. Apple UIKit (2024) rekommenderar att testa memory warning-scenarier på varje skärm i applikationen.

Mål med stresstestning

Bestämning av felpunkt

Det första målet med Stress Test — bestämning av felpunkt (breaking point). Detta är ögonblicket då en av de viktigaste prestandaindikatorerna överskrider en kritisk tröskel: svarstiden p95 överstiger 10 sekunder, andelen HTTP 5XX-fel överstiger 5% eller genomströmningen sjunker under 50% av baslinjen. Registrering av felpunkten gör att teamet i förväg kan känna till systemets skalbarhetsgräns. Capacity planning förlitar sig just på data från Stress Test, inte Load Test, eftersom Load Test inte kontrollerar gränsvillkor.

Kontroll av återhämtningsmekanismer

Det andra målet — kontroll av återhämtningsmekanismer. Efter att belastningen sjunkit till normal nivå bör systemet återgå till standardindikatorer. Om anslutningspoolen till databasen inte frigörs eller cachen inte ogiltigförklaras, kommer Stress Test att avslöja detta problem. Kretsbrytare (Hystrix, Resilience4j) bör aktiveras vid överbelastning och automatiskt återställa anslutningen efter stabilisering. Health check-slutpunkter hjälper till att övervaka status för varje tjänst under testet.

Validering av automatisk skalning

Det tredje målet — validering av automatisk skalning. Om infrastrukturen använder Kubernetes eller AWS Auto Scaling, kontrollerar Stress Test om nya poddar eller instanser skapas tillräckligt snabbt. Enligt Google Kubernetes Engine (2024) bör distributionstiden för en ny pod inte överstiga 30 sekunder från det att HPA-metriken (Horizontal Pod Autoscaler) aktiveras. HPA bör skalas baserat på CPU, minne och anpassade mätvärden. Cluster Autoscaler lägger till nya noder om de befintliga inte rymmer poddarna.

Metodik för Stress Test

Gradvis ökning av belastning (Ramp-up Stress Test) — det vanligaste scenariot. Den initiala belastningen ställs in på 50% av förväntad, sedan ökar den varannan minut med 10% tills systemet misslyckas. Detta scenario gör det möjligt att hitta den exakta gränsen för motståndskraft. Grafana Cloud k6 (2025) rekommenderar ett ökningssteg på högst 10% för att få en jämn graf över svarstiden.

Plötslig topp i belastning (Spike Stress Test) — belastningen ökar från 10% till 500% inom 10–30 sekunder. Detta scenario modellerar situationer som viral spridning av innehåll eller DDoS-attack. Spike Stress Test kontrollerar inte så mycket prestanda som systemets livskraft: förmågan att inte kollapsa helt och återgå till arbete efter stabilisering. API Gateway bör konfigurera hastighetsbegränsning (rate limiting) för att skydda backend från plötsliga toppar.

Långvarigt upprätthållande av överbelastning (Sustained Stress Test) — systemet hålls i överbelastningstillstånd i 30–60 minuter. Detta scenario avslöjar resursläckor som inte uppträder vid kortvariga tester. Minnesläcka i Java/Kotlin-applikationer ackumuleras under 20–40 minuters intensivt arbete och endast Sustained Stress Test upptäcker den.

Analys av felpunkt och återhämtning

Felpunkt bestäms utifrån tre kriterier: svarstid, felfrekvens och genomströmning. Vanligtvis överskrids svarstidströskeln först — förfrågningar börjar ta längre tid än den fastställda gränsen. Sedan ökar felfrekvensen: servern hinner inte bearbeta förfrågningar och returnerar 503. Sist sjunker genomströmningen — systemet klarar inte ens minimal belastning. Mätvärde för felpunkten registreras i belastningsprofilen för kapacitetsplanering.

Återhämtningsanalys omfattar tre faser: omedelbar reaktion (första 30 sekunderna efter borttagning av belastning), stabilisering (1–5 minuter) och full återhämtning (5–30 minuter). I den omedelbara reaktionsfasen bör svarstiden sjunka under baslinjen — systemet frigörs från köer. Om detta inte händer ligger problemet inte i belastningen utan i ackumulerat tillstånd. Graceful degradation — systemets förmåga att behålla partiell funktionalitet vid överbelastning — en nyckelindikator på arkitekturmognad.

Chaos Engineering kompletterar Stress Test genom att avsiktligt introducera fel: avstängning av databasserver, nätverksfördröjning, stopp av mikrotjänst. Chaos Monkey från Netflix (2024) avslutar slumpmässigt processer i produktion och testar systemets motståndskraft. För mobila applikationer innebär Chaos Engineering testning av scenarier: inget nätverk, API inte tillgängligt, tomt serversvar.

Verktyg för Stress Test

k6 med ramping-arrival-rate

k6 stöder Stress Test via `execution`-modulen med ramping-arrival-rate-konfiguration. Detta läge ökar antalet förfrågningar per sekund oberoende av exekveringstiden för varje förfrågan. Jämfört med Load Test kräver Stress Test i k6 inställning av mer aggressiva tröskelvärden och inaktivering av gracefull-stop för simulering av plötsligt fel. Grafana Cloud upptäcker automatiskt felpunkten baserat på brytpunkten i svarstidsgrafen. k6-operator för Kubernetes gör det möjligt att köra distribuerade Stress Test från klustret.

JMeter med Ultimate Thread Group

JMeter möjliggör konfiguration av Stress Test via Ultimate Thread Group — ett plugin som definierar belastningsprofilen i tabellform: antal trådar, uppvärmningstid, hålltid, nedgångstid. Ultimate Thread Group är praktiskt för komplexa flerfasscenarier. JMeter Backend Listener skickar mätvärden till InfluxDB för att bygga grafer över felpunkten. För Stress Test i JMeter rekommenderas att inaktivera anslutningstimeouter för att mer exakt mäta beteendet vid överbelastning.

Gremlin för Chaos Engineering

Gremlin — en Chaos Engineering-plattform för Stress Test av infrastruktur. Gremlin gör det möjligt att stänga av nätverket, belasta CPU, fylla disk och avsluta processer på nivån av enskilda Kubernetes-poddar. SRE-team använder Gremlin tillsammans med k6 för omfattande Stress Test: k6 skapar belastning, Gremlin introducerar fel. Game Day — regelbundna Stress Test-sessioner med Gremlin som dokumenteras i “kaosrapport” för analys av systemets motståndskraft.

Exempel på Stress Test på k6

Det presenterade skriptet på k6 visar ett Stress Test med gradvis ökning av belastning tills fel. Ramping-arrival-rate ökar antalet förfrågningar per sekund oberoende av exekveringstiden. Tröskelvärden är inställda för aggressiv detektering av degradering: p95 högst 2000 ms, felfrekvens högst 5%. Vid överskridande av trösklarna avslutar k6 testet med felkod, vilket gör det möjligt att integrera Stress Test i CI/CD-pipelinen.

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

export const options = {
    scenarios: {
        stress: {
            executor: 'ramping-arrival-rate',
            startRate: 50,
            timeUnit: '1s',
            stages: [
                { duration: '2m', target: 200 },
                { duration: '5m', target: 500 },
                { duration: '2m', target: 1000 },
            ],
            preAllocatedVUs: 50,
            maxVUs: 200,
        },
    },
    thresholds: {
        http_req_duration: ['p(95)<2000'],
        http_req_failed: ['rate<0.05'],
    },
}

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

Bästa praxis för stresstestning

Börja Stress Test på staging — stresstestning i produktion kräver avancerad övervakning och en återställningsplan. Google SRE (2024) rekommenderar att utföra Stress Test i en 100% isolerad miljö som efterliknar produktion i arkitektur och kapacitet. Efter framgångsrikt test på staging kan man gå över till produktion under SRE-övervakning. Feature flag för att inaktivera funktionalitet vid överbelastning är ett obligatoriskt element.

Automatisera Stress Test i CI/CD för regressionsanalys av felpunkten. Om en ny version av applikationen har en felpunkt som är 20% lägre än den föregående, är detta en regression som måste åtgärdas före lansering. Baslinjens brytpunkt lagras i mätvärden och jämförs automatiskt med resultatet av varje Stress Test. En varning utlöses när felpunkten sjunker med 10%.

Dokumentera varje Stress Test: belastningsprofil, felpunkt, återhämtningsbeteende och lista över upptäckta problem. Netflix Engineering (2024) genomför “Game Day” — regelbundna Stress Test-sessioner vars resultat dokumenteras i “kaosrapport”. Rapport om stresstestning bör innehålla en graf “RPS — svarstid” med markerad felpunkt.