1. Strategie a typy výkonnostních testů
Návrh zátěžového profilu musí odpovídat požadovanému scénáři a cílům testování. Provádí se cílená simulace provozu k měření specifických systémových charakteristik.
- Load Testing (Běžná zátěž): Simuluje standardní a očekávaný provozní stav. Ověřuje plynulost odezvy, propustnost a stabilitu systému při nominální zátěži (např. běžná denní provozní špička aktivních uživatelů).
- Stress Testing (Zátěžový test kapacity): Zátěžové testování za hranicí nominální kapacity. Slouží k identifikaci bodu selhání (breaking point) a sledování chování systému při extrémním vytížení. Cílem je ověřit, zda systém degraduje kontrolovaně (graceful degradation) bez ztráty datové integrity.
- Spike Testing (Šoková zátěž): Simuluje skokový nárůst požadavků z minimální na maximální hodnotu v řádu sekund. Aplikuje se k ověření stability systému při nárazových událostech (např. marketingové kampaně, hromadné notifikace).
- Endurance / Soak Testing (Dlouhodobá zátěž): Aplikuje konstantní zátěž po delší časový úsek (zpravidla 24–72 hodin). Měření je zaměřeno na stabilitu výkonu v čase, uvolňování systémových prostředků a detekci úniků paměti (memory leaks).
2. Definice metrik a Test Case šablona
Výkonnostní exekuce musí být měřitelná vůči exaktně definovaným akceptačním kritériím (Pass/Fail Criteria) vycházejícím ze Service Level Agreement (SLA).
| Komponenta | Specifikace profilu a metrik |
|---|---|
| Identifikace testu | PERF-API-XXX (např. zátěž endpointu pro zápis entit). |
| Zátěžový profil (Load Profile) | Cílový počet virtuálních uživatelů (VUs) nebo počet požadavků za sekundu (RPS). Definice fází: Ramp-up, Sustained Load, Tear-down. |
| Datové prerekvizity | Příprava syntetických testovacích dat. Z důvodu výkonu nesmí docházet k manuální nebo synchronní tvorbě dat během zátěže; vyžadován je předgenerovaný datový pool v databázi. |
| Metrika 1: Doba odezvy (Latency) | Odezva na 95. percentilu (P95 Latency) nesmí překročit stanovený limit (např. < 500 ms). |
| Metrika 2: Chybovost (Error Rate) | Procento neúspěšných požadavků musí být < 1 %. Očekávány jsou ojedinělé chyby způsobené rate limitingem, plošné selhání spojení je nepřípustné. |
| Metrika 3: Systémové zdroje | Utilizace CPU a alokace RAM na aplikačních a databázových uzlech nesmí dlouhodobě překročit úroveň 80 %. |
3. Parametry testovacího scénáře
Předmět: Validace kapacity backendového endpointu (/api/v1/it-visit) pro zpracování paralelních požadavků na zápis do databáze.
| Parametr exekuce | Krok (Action) |
|---|---|
| Cíl testu (Objective) | Dosažení a udržení zátěže 500 RPS bez selhání databázové vrstvy a výskytu deadlocků. |
| Ramp-up (Náběh) | Lineární nárůst zátěže z 0 na 500 VUs v časovém okně 120 sekund. |
| Sustained Load (Držení) | Udržení konstantní zátěže na úrovni 500 VUs po dobu 15 minut. |
| Tear-down (Doběh) | Lineární snížení zátěže z 500 na 0 VUs v časovém okně 60 sekund. |
| Akceptační kritéria | • Max P95 Latency < 800 ms. • Zero data corruption, úspěšně dokončené transakční zápisy. |
4. Architektura exekuce a Monitoring
Vzhledem k hardwarové náročnosti se výkonnostní testy neintegrují do standardního CI pipeline při každém commitu. Konfigurují se jako naplánované noční exekuce (Nightly Builds) nebo se spouštějí na vyžádání v dedikovaných prostředích.
Sběr metrik a vizualizace:
Klíčovým aspektem je agregace a korelace dat z vrstvy testovacího generátoru a z vrstvy sledované infrastruktury.
- Testovací generátor (Load Generator): Kontejnerizovaný nástroj (např. k6, JMeter) provádějící distribuovanou zátěž na definované cíle. Zodpovídá za odesílání telemetrie o časech odezvy a stavových kódech.
- Infrastrukturní monitoring: Měřicí agenti (např. Zabbix) sledující utilizaci výpočetních zdrojů, I/O operace disků a síťovou propustnost na aplikačních serverech, load balancerech a databázích.
- Analytický Dashboarding: Ukládání agregovaných výsledků do Time-Series databází (např. OpenSearch, Prometheus) a vizualizace (Grafana).
- Best Practice vizualizace: Při tvorbě analytických panelů je nutné provádět agregaci dat na úrovni databázových dotazů (queries). Z důvodu prevence selhání renderingu a zvýšení celkové spolehlivosti vizualizací je zakázáno využívat komplexní klientské UI transformace (např. funkci
Reduce fields).
- Best Practice vizualizace: Při tvorbě analytických panelů je nutné provádět agregaci dat na úrovni databázových dotazů (queries). Z důvodu prevence selhání renderingu a zvýšení celkové spolehlivosti vizualizací je zakázáno využívat komplexní klientské UI transformace (např. funkci
Vizuální diagram architektury výkonnostních testů:
5. Dokumentace k výkonnostním testům (Test Plan)
Před zahájením zátěžového testování musí být formálně sepsán Test Plan. Dokument definuje technické předpoklady a limity exekuce a sjednocuje očekávání napříč týmy (QA, Vývoj, IT Operations).
Přípravná dokumentace obsahuje:
- Byznysový cíl (Business Objective): Specifikace primárního důvodu testu (např. ověření škálovatelnosti architektury před nasazením nové verze, audit limitů před marketingovou kampaní).
- Rozsah testu (Scope): Vymezení testovaných a úmyslně netestovaných komponent (např. vyjmutí distribuce statického obsahu přes CDN za účelem fokusování zátěže na aplikační běhové prostředí).
- Datový model: Stanovení objemu a logické struktury databáze před spuštěním (např. nutnost vygenerovat 100 000 uživatelských profilů pro simulaci reálné velikosti indexů).
- Topologie prostředí: Zdokumentování odchylek mezi testovacím a produkčním prostředím (hardwarová specifikace, konfigurace clusterů). Pokud testovací prostředí disponuje nižším výpočetním výkonem, je nutné určit metodu pro extrapolaci konečných výsledků.
6. Závěrečný report (Test Summary Report)
Test Summary Report slouží jako formální auditní artefakt hodnotící připravenost sledovaného systému k provozu nebo nasazení. Dokument je strukturován tak, aby poskytoval okamžitou analytickou hodnotu a definoval jasné nápravné kroky.
Standardní struktura reportu:
- A. Manažerské shrnutí (Executive Summary): Finální vyhodnocení stavu (PASS / FAIL / CONDITIONAL PASS). Poskytuje bezprostřední interpretaci výsledku bez nutnosti technické analýzy (např. „Systém splnil výkonnostní kritéria do zátěže 500 RPS bez degradace. Aplikace plní podmínky nasazení.“).
- B. Vyhodnocení SLA: Datová korelace naměřených výsledků oproti definovaným parametrům. Obsahuje tabulkové či grafické shrnutí klíčových metrik (P95 Latency, Error Rate, propustnost).
- C. Detekovaná úzká hrdla (Bottleneck Analysis): Identifikace hardwarových, síťových nebo softwarových limitů odhalených během zátěže (např. limitace na úrovni databázových IOPS při zachování 40 % nevyužité kapacity aplikačního CPU).
- D. Akční kroky a doporučení (Action Items): Návrhy k optimalizaci (např. implementace nového databázového indexu, modifikace parametrů connection poolu, doporučení k horizontálnímu škálování).
