Stress Test a mobilfejlesztésben: mi ez, céljai és hogyan történik

Mi az a Stress Test?

Stress Test (stressztesztelés) a rendszer azon képességének értékelési folyamata, hogy a számított paramétereket meghaladó körülmények között működjön. Egy mobilalkalmazás esetében ez 10000 egyidejű push értesítést jelenthet 1000-es norma mellett, a backend esetében — 50000 RPS-t a várt 5000 helyett. A Stress Test fő különbsége a Load Test-től, hogy a cél nem a teljesítmény megerősítése, hanem a rendszer viselkedésének tanulmányozása a tervezett kapacitáson túl. A Netflix Engineering (2024) úgy határozza meg a Stress Test-et, mint “annak a hipotézisnek az ellenőrzése, hogy a rendszer előre jelezhető módon fog meghibásodni”.

A stressztesztelés két kötelező szakaszból áll: terhelés a meghibásodásig és a helyreállás megfigyelése. Helyreállás (recovery) a rendszer azon képessége, hogy visszatérjen a normál működéshez a túlterhelés megszüntetése után. Az a rendszer, amely újraindítás nélkül nem áll helyre, törékenynek tekintendő, még akkor is, ha rövid idejű túlterhelést elvisel. Az AWS Well-Architected Framework (2024) szerint a Stress Test utáni helyreállási idő nem haladhatja meg az 5 percet.

A mobil kliensek esetében a Stress Test magában foglalja a működés ellenőrzését a folyamatok kényszerített megszakítása, a hálózati kapcsolat megszakadása és a RAM kimerülése esetén. Android Low Memory Killer leállíthat egy háttérfolyamatot RAM-hiány esetén — a stressztesztnek ellenőriznie kell, hogy az alkalmazás helyesen állítja-e vissza az állapotot egy ilyen leállítás után. Az Apple UIKit (2024) javasolja a memory warning forgatókönyvek tesztelését az alkalmazás minden képernyőjén.

A stressztesztelés céljai

A meghibásodási pont meghatározása

A Stress Test első célja — a meghibásodási pont meghatározása (breaking point). Ez az a pillanat, amikor az egyik kulcsfontosságú teljesítménymutató átlépi a kritikus küszöböt: a p95 válaszidő meghaladja a 10 másodpercet, a HTTP 5XX hibák százaléka meghaladja az 5%-ot, vagy az átviteli sebesség az alapvonal 50%-a alá csökken. A meghibásodási pont rögzítése lehetővé teszi a csapat számára, hogy előre ismerje a rendszer skálázhatósági határát. Capacity planning éppen a Stress Test adataira támaszkodik, nem a Load Test-re, mivel a Load Test nem ellenőrzi a határfeltételeket.

A helyreállítási mechanizmusok ellenőrzése

A második cél — a helyreállítási mechanizmusok ellenőrzése. Miután a terhelés a normál szintre csökken, a rendszernek vissza kell térnie a standard mutatókhoz. Ha az adatbázis-kapcsolati pool nem szabadul fel vagy a gyorsítótár nem érvénytelenül, a Stress Test feltárja ezt a problémát. A circuit breaker-nek (Hystrix, Resilience4j) be kell kapcsolnia túlterhelés esetén, és automatikusan helyre kell állítania a kapcsolatot a stabilizálódás után. Health check végpontok segítenek figyelni az egyes szolgáltatások állapotát a teszt során.

Az auto-scaling validálása

A harmadik cél — az auto-scaling validálása. Ha az infrastruktúra Kubernetes-t vagy AWS Auto Scaling-et használ, a Stress Test ellenőrzi, hogy az új pod-ok vagy példányok elég gyorsan jönnek-e létre. A Google Kubernetes Engine (2024) szerint egy új pod telepítési ideje nem haladhatja meg a 30 másodpercet a HPA (Horizontal Pod Autoscaler) metrika aktiválódásától számítva. HPA-nak CPU, memória és egyéni metrikák alapján kell skálázódnia. A Cluster Autoscaler új csomópontokat ad hozzá, ha a meglévők nem férnek el a pod-oknak.

A Stress Test módszertana

A terhelés fokozatos növelése (Ramp-up Stress Test) — a leggyakoribb forgatókönyv. A kezdeti terhelés a várható 50%-ára van állítva, majd 2 percenként 10%-kal nő, amíg a rendszer meg nem hibásodik. Ez a forgatókönyv lehetővé teszi a robusztusság pontos határának megtalálását. Grafana Cloud k6 (2025) legfeljebb 10%-os növelési lépést javasol a válaszidő sima grafikonjának eléréséhez.

A terhelés hirtelen ugrása (Spike Stress Test) — a terhelés 10%-ról 500%-ra nő 10–30 másodperc alatt. Ez a forgatókönyv olyan helyzeteket modellez, mint a vírusterjesztés vagy DDoS-támadás. A Spike Stress Test nem annyira a teljesítményt, mint inkább a rendszer életképességét ellenőrzi: azt a képességet, hogy ne omoljon össze teljesen, és a stabilizálódás után visszatérjen a működéshez. API Gateway-nek rate limiting-et kell konfigurálnia a backend védelmére a hirtelen ugrásokkal szemben.

A túlterhelés hosszú távú fenntartása (Sustained Stress Test) — a rendszert 30–60 percig túlterhelt állapotban tartják. Ez a forgatókönyv olyan erőforrás-szivárgásokat tár fel, amelyek rövid távú teszteknél nem jelentkeznek. Memóriaszivárgás a Java/Kotlin alkalmazásokban 20–40 perc intenzív munka alatt halmozódik fel, és csak a Sustained Stress Test mutatja ki.

A meghibásodási pont és a helyreállás elemzése

A meghibásodási pont három kritérium alapján kerül meghatározásra: válaszidő, hibaszázalék és átviteli sebesség. Általában először a válaszidő küszöbértéke lépődik túl — a kérések hosszabb ideig tartanak, mint a megadott határérték. Ezután nő a hibaszázalék: a szerver nem győzi feldolgozni a kéréseket és 503-as hibát ad vissza. Utoljára csökken a Throughput — a rendszer még a minimális terheléssel sem birkózik meg. Metrika a meghibásodási pont rögzítésre kerül a terhelési profilban a kapacitástervezéshez.

A helyreállás elemzése három fázist foglal magában: azonnali reakció (az első 30 másodperc a terhelés megszüntetése után), stabilizálódás (1–5 perc) és teljes helyreállás (5–30 perc). Az azonnali reakció fázisában a válaszidőnek az alapvonal alá kell csökkennie — a rendszer felszabadul a sorokból. Ha ez nem történik meg, a probléma nem a terhelésben, hanem a felhalmozott állapotban van. Graceful degradation — a rendszer azon képessége, hogy túlterhelés esetén részleges funkcionalitást tartson fenn — az architektúra érettségének kulcsmutatója.

A Chaos Engineering kiegészíti a Stress Test-et a hibák szándékos bevezetésével: adatbázisszerver leállítása, hálózati késleltetés, mikroszolgáltatás leállítása. Chaos Monkey a Netflix-től (2024) véletlenszerűen megszakít folyamatokat éles környezetben, ellenőrizve a rendszer ellenálló képességét. Mobilalkalmazások esetében a Chaos Engineering a következő forgatókönyvek tesztelését jelenti: nincs hálózat, API nem elérhető, üres szerver válasz.

Eszközök a Stress Test-hez

k6 ramping-arrival-rate-tel

k6 támogatja a Stress Test-et az `execution` modulon keresztül ramping-arrival-rate konfigurációval. Ez a mód a másodpercenkénti kérések számát növeli, függetlenül az egyes kérések végrehajtási idejétől. A Load Test-hez képest a k6-ban a Stress Test agresszívebb thresholds beállítását és a gracefull-stop kikapcsolását igényli a hirtelen meghibásodás szimulálásához. A Grafana Cloud automatikusan észleli a meghibásodási pontot a válaszidő grafikon törése alapján. k6-operator Kubernetes-hez lehetővé teszi elosztott Stress Test-ek futtatását a klaszterből.

JMeter Ultimate Thread Group-pal

JMeter lehetővé teszi a Stress Test konfigurálását az Ultimate Thread Group-on keresztül — egy bővítményen, amely táblázatos formában adja meg a terhelési profilt: szálak száma, bemelegítési idő, fenntartási idő, csökkenési idő. Az Ultimate Thread Group kényelmes összetett, többfázisú forgatókönyvekhez. JMeter Backend Listener metrikákat küld az InfluxDB-be a meghibásodási pont grafikonjainak felépítéséhez. Stress Test esetén a JMeter-ben ajánlott kikapcsolni a kapcsolati időtúllépéseket a túlterhelés alatti viselkedés pontosabb méréséhez.

Gremlin Chaos Engineering-hez

Gremlin — Chaos Engineering platform az infrastruktúra Stress Test-jéhez. A Gremlin lehetővé teszi a hálózat leállítását, a CPU terhelését, a lemez megtöltését és a folyamatok megszakítását egyedi Kubernetes pod-ok szintjén. Az SRE csapatok a Gremlin-t a k6-tal együtt használják átfogó Stress Test-hez: a k6 terhelést hoz létre, a Gremlin hibákat vezet be. Game Day — rendszeres Stress Test ülések Gremlin-nel, amelyeket “kaosz jelentés”-ben dokumentálnak a rendszer ellenálló képességének elemzéséhez.

Stress Test példa k6-on

A bemutatott k6 script egy Stress Test-et demonstrál a terhelés fokozatos növelésével a meghibásodásig. Ramping-arrival-rate növeli a másodpercenkénti kérések számát, függetlenül a végrehajtási időtől. A thresholds agresszív degradáció-észlelésre vannak beállítva: p95 legfeljebb 2000 ms, error rate legfeljebb 5%. A küszöbértékek túllépésekor a k6 hibakóddal fejezi be a tesztet, ami lehetővé teszi a Stress Test CI/CD pipeline-ba való beépítését.

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,
    })
}

A stressztesztelés legjobb gyakorlatai

Kezdje a Stress Test-et staging-en — az éles környezetben végzett stressztesztelés fejlett monitorozást és visszaállítási tervet igényel. A Google SRE (2024) 100%-ban izolált környezetben javasolja a Stress Test végrehajtását, amely architektúrában és kapacitásban reprodukálja az éles környezetet. Sikeres staging teszt után áttérhet az éles környezetbe az SRE felügyelete alatt. Feature flag a funkcionalitás kikapcsolásához túlterhelés esetén kötelező elem.

Automatizálja a Stress Test-et CI/CD-ben a meghibásodási pont regressziós elemzéséhez. Ha az alkalmazás új verziójának meghibásodási pontja 20%-kal alacsonyabb, mint az előzőé, ez egy regresszió, amelyet a kiadás előtt ki kell javítani. Baseline breaking point a metrikákban tárolódik és automatikusan összehasonlításra kerül minden Stress Test eredményével. Riasztás akkor aktiválódik, ha a meghibásodási pont 10%-kal csökken.

Dokumentáljon minden Stress Test-et: terhelési profil, meghibásodási pont, helyreállási viselkedés és a felfedezett problémák listája. A Netflix Engineering (2024) “Game Day”-t tart — rendszeres Stress Test üléseket, amelyek eredményeit “kaosz jelentés”-ben dokumentálja. Jelentés a stressztesztelésről tartalmazza a “RPS — válaszidő” grafikont a megjelölt meghibásodási ponttal.