Stress Test v mobilním vývoji: co to je, cíle a jak se provádí

Co je Stress Test?

Stress Test (zátěžové testování) je proces hodnocení schopnosti systému pracovat v podmínkách přesahujících vypočtené parametry. Pro mobilní aplikaci to může znamenat 10 000 současných push oznámení při normě 1 000, pro backend — 50 000 RPS při očekávaných 5 000. Hlavní rozdíl mezi Stress Testem a Load Testem je v tom, že cílem není potvrzení výkonu, ale studium chování systému mimo jeho navrženou kapacitu. Netflix Engineering (2024) definuje Stress Test jako „ověření hypotézy, že systém selže předvídatelným způsobem“.

Zátěžové testování zahrnuje dvě povinné fáze: zatížení až do selhání a pozorování obnovy. Obnova (recovery) je schopnost systému vrátit se k normálnímu provozu po odstranění přetížení. Systém, který se bez restartu neobnoví, je považován za křehký, i když vydrží krátkodobé přetížení. Podle AWS Well-Architected Framework (2024) by doba obnovy po Stress Testu neměla přesáhnout 5 minut.

Pro mobilní klienty zahrnuje Stress Test kontrolu práce při nuceném ukončení procesů, odpojení sítě a vyčerpání paměti RAM. Android Low Memory Killer může ukončit proces na pozadí při nedostatku RAM — zátěžový test by měl ověřit, že aplikace po takovém ukončení správně obnoví stav. Apple UIKit (2024) doporučuje testovat scénáře memory warning na každé obrazovce aplikace.

Cíle zátěžového testování

Určení bodu selhání

Prvním cílem Stress Testu — určení bodu selhání (breaking point). Je to okamžik, kdy jeden z klíčových ukazatelů výkonu překročí kritickou hranici: doba odezvy p95 přesáhne 10 sekund, procento chyb HTTP 5XX přesáhne 5 % nebo propustnost klesne pod 50 % baseline. Zaznamenání bodu selhání umožňuje týmu předem znát limit škálovatelnosti systému. Capacity planning se opírá právě o data ze Stress Testu, ne z Load Testu, protože Load Test nekontroluje okrajové podmínky.

Kontrola mechanismů obnovy

Druhým cílem — kontrola mechanismů obnovy. Po poklesu zatížení na normální úroveň by se měl systém vrátit ke standardním ukazatelům. Pokud se fond připojení k databázi neuvolní nebo cache není zneplatněna, Stress Test tento problém odhalí. Jistič (circuit breaker) (Hystrix, Resilience4j) by se měl aktivovat při přetížení a automaticky obnovit připojení po stabilizaci. Health check koncové body pomáhají monitorovat stav každé služby během testu.

Validace automatického škálování

Třetím cílem — validace automatického škálování. Pokud infrastruktura používá Kubernetes nebo AWS Auto Scaling, Stress Test kontroluje, zda jsou nové pod-y nebo instance vytvářeny dostatečně rychle. Podle Google Kubernetes Engine (2024) by doba nasazení nového pod-u neměla přesáhnout 30 sekund od okamžiku aktivace metriky HPA (Horizontal Pod Autoscaler). HPA by se měl škálovat na základě CPU, paměti a vlastních metrik. Cluster Autoscaler přidává nové uzly, pokud stávající nepojmou pod-y.

Metodologie Stress Testu

Postupné zvyšování zatížení (Ramp-up Stress Test) — nejběžnější scénář. Počáteční zatížení je nastaveno na 50 % očekávaného, poté každé 2 minuty roste o 10 %, dokud systém neselže. Tento scénář umožňuje najít přesnou hranici odolnosti. Grafana Cloud k6 (2025) doporučuje krok zvyšování nejvýše 10 % pro dosažení hladkého grafu doby odezvy.

Náhlý skok zatížení (Spike Stress Test) — zatížení vzroste z 10 % na 500 % během 10–30 sekund. Tento scénář modeluje situace jako virové šíření obsahu nebo DDoS útok. Spike Stress Test kontroluje ne tolik výkon, jako spíše životaschopnost systému: schopnost zcela nespadnout a vrátit se k práci po stabilizaci. API Gateway by měl nakonfigurovat omezování rychlosti (rate limiting) pro ochranu backendu před náhlými skoky.

Dlouhodobé udržení přetížení (Sustained Stress Test) — systém je udržován ve stavu přetížení po dobu 30–60 minut. Tento scénář odhaluje úniky zdrojů, které se neprojevují při krátkodobých testech. Únik paměti v Java/Kotlin aplikacích se kumuluje během 20–40 minut intenzivní práce a pouze Sustained Stress Test jej odhalí.

Analýza bodu selhání a obnovy

Bod selhání se určuje podle tří kritérií: doba odezvy, procento chyb a propustnost. Obvykle je jako první překročena hranice doby odezvy — požadavky se začínají vykonávat déle než stanovený limit. Poté roste procento chyb: server nestíhá zpracovávat požadavky a vrací 503. Jako poslední klesá propustnost — systém přestává zvládat i minimální zatížení. Metrika bodu selhání se zaznamenává do profilu zatížení pro plánování kapacity.

Analýza obnovy zahrnuje tři fáze: okamžitou reakci (prvních 30 sekund po odstranění zatížení), stabilizaci (1–5 minut) a úplnou obnovu (5–30 minut). Ve fázi okamžité reakce by doba odezvy měla klesnout pod baseline — systém se uvolňuje z front. Pokud se tak nestane, problém není v zatížení, ale v nahromaděném stavu. Graceful degradation — schopnost systému zachovat částečnou funkčnost při přetížení — klíčový ukazatel vyspělosti architektury.

Chaos Engineering doplňuje Stress Test záměrným vnášením poruch: vypnutí databázového serveru, zpoždění sítě, zastavení mikroslužby. Chaos Monkey od Netflixu (2024) náhodně ukončuje procesy v produkci a testuje odolnost systému. Pro mobilní aplikace Chaos Engineering znamená testování scénářů: absence sítě, nedostupnost API, prázdná odpověď serveru.

Nástroje pro Stress Test

k6 s ramping-arrival-rate

k6 podporuje Stress Test prostřednictvím modulu `execution` s konfigurací ramping-arrival-rate. Tento režim zvyšuje počet požadavků za sekundu nezávisle na době provedení každého požadavku. Ve srovnání s Load Testem vyžaduje Stress Test v k6 nastavení agresivnějších prahů (thresholds) a vypnutí gracefull-stop pro simulaci náhlého selhání. Grafana Cloud automaticky detekuje bod selhání podle zlomu v grafu doby odezvy. k6-operator pro Kubernetes umožňuje spouštět distribuované Stress Testy z clusteru.

JMeter s Ultimate Thread Group

JMeter umožňuje konfiguraci Stress Testu prostřednictvím Ultimate Thread Group — pluginu, který definuje profil zatížení ve formě tabulky: počet vláken, doba zahřívání, doba držení, doba poklesu. Ultimate Thread Group je vhodný pro složité vícefázové scénáře. JMeter Backend Listener odesílá metriky do InfluxDB pro vytváření grafů bodu selhání. Pro Stress Test v JMeteru se doporučuje vypnout časové limity připojení pro přesnější měření chování při přetížení.

Gremlin pro Chaos Engineering

Gremlin — platforma Chaos Engineering pro Stress Test infrastruktury. Gremlin umožňuje vypnout síť, zatížit CPU, zaplnit disk a ukončit procesy na úrovni jednotlivých Kubernetes pod-ů. Týmy SRE používají Gremlin společně s k6 pro komplexní Stress Test: k6 vytváří zatížení, Gremlin vnáší poruchy. Game Day — pravidelné relace Stress Testu s Gremlinem, které jsou dokumentovány v „chaos reportu” pro analýzu odolnosti systému.

Příklad Stress Testu na k6

Představený skript na k6 demonstruje Stress Test s postupným zvyšováním zatížení až do selhání. Ramping-arrival-rate zvyšuje počet požadavků za sekundu nezávisle na době provedení. Prahy (thresholds) jsou nastaveny na agresivní detekci degradace: p95 ne více než 2000 ms, chybovost ne více než 5 %. Při překročení prahů k6 ukončí test s chybovým kódem, což umožňuje začlenit Stress Test do CI/CD pipeline.

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

Nejlepší postupy zátěžového testování

Začněte Stress Test na stagingu — zátěžové testování v produkci vyžaduje pokročilé monitorování a plán vrácení. Google SRE (2024) doporučuje provádět Stress Test ve 100% izolovaném prostředí, které reprodukuje produkci z hlediska architektury a kapacity. Po úspěšném testu na stagingu lze přejít do produkce pod dohledem SRE. Feature flag pro vypnutí funkcionality při přetížení je povinný prvek.

Automatizujte Stress Test v CI/CD pro regresní analýzu bodu selhání. Pokud má nová verze aplikace bod selhání o 20 % nižší než předchozí, jedná se o regresi, kterou je třeba opravit před vydáním. Baseline breaking point je uložen v metrikách a automaticky porovnáván s výsledkem každého Stress Testu. Výstraha se aktivuje při poklesu bodu selhání o 10 %.

Dokumentujte každý Stress Test: profil zatížení, bod selhání, chování při obnově a seznam objevených problémů. Netflix Engineering (2024) provozuje „Game Day” — pravidelné relace Stress Testu, jejichž výsledky jsou dokumentovány v „chaos reportu”. Zpráva o zátěžovém testování by měla obsahovat graf „RPS — doba odezvy” s vyznačeným bodem selhání.