Stress Test în dezvoltarea mobilă: ce este, scopuri și cum se efectuează

Ce este Stress Test?

Stress Test (testarea de stres) este procesul de evaluare a capacității sistemului de a funcționa în condiții care depășesc parametrii calculați. Pentru o aplicație mobilă, aceasta poate însemna 10000 de notificări push simultane la o normă de 1000, pentru backend — 50000 RPS la 5000 așteptate. Principala diferență dintre Stress Test și Load Test este că scopul nu este confirmarea performanței, ci studierea comportamentului sistemului dincolo de capacitatea sa proiectată. Netflix Engineering (2024) definește Stress Test ca “verificarea ipotezei că sistemul va ceda într-un mod previzibil”.

Testarea de stres include două etape obligatorii: încărcarea până la defectare și observarea recuperării. Recuperarea (recovery) este capacitatea sistemului de a reveni la funcționarea normală după eliminarea suprasarcinii. Un sistem care nu se recuperează fără repornire este considerat fragil, chiar dacă suportă o suprasarcină de scurtă durată. Potrivit AWS Well-Architected Framework (2024), timpul de recuperare după Stress Test nu trebuie să depășească 5 minute.

Pentru clienții mobili, Stress Test include verificarea funcționării la terminarea forțată a proceselor, deconectarea rețelei și epuizarea memoriei RAM. Android Low Memory Killer poate termina un proces de fundal când RAM-ul este insuficient — testul de stres trebuie să verifice dacă aplicația își recuperează corect starea după o astfel de terminare. Apple UIKit (2024) recomandă testarea scenariilor de memory warning pe fiecare ecran al aplicației.

Scopurile testării de stres

Determinarea punctului de defectare

Primul scop al Stress Test — determinarea punctului de defectare (breaking point). Acesta este momentul în care unul dintre indicatorii cheie de performanță depășește un prag critic: timpul de răspuns p95 depășește 10 secunde, procentul de erori HTTP 5XX depășește 5% sau debitul scade sub 50% din baseline. Fixarea punctului de defectare permite echipei să cunoască din timp limita de scalabilitate a sistemului. Capacity planning se bazează tocmai pe datele de la Stress Test, nu de la Load Test, deoarece Load Test nu verifică condițiile limită.

Verificarea mecanismelor de recuperare

Al doilea scop — verificarea mecanismelor de recuperare. După ce sarcina scade la nivelul normal, sistemul trebuie să revină la indicatorii standard. Dacă pool-ul de conexiuni la baza de date nu se eliberează sau cache-ul nu se invalidează, Stress Test va releva această problemă. Circuit breaker (Hystrix, Resilience4j) trebuie să se activeze la suprasarcină și să restabilească automat conexiunea după stabilizare. Health check endpoint-urile ajută la monitorizarea stării fiecărui serviciu în timpul testului.

Validarea auto-scaling

Al treilea scop — validarea auto-scaling. Dacă infrastructura folosește Kubernetes sau AWS Auto Scaling, Stress Test verifică dacă pod-urile sau instanțele noi sunt create suficient de rapid. Potrivit Google Kubernetes Engine (2024), timpul de implementare a unui pod nou nu trebuie să depășească 30 de secunde de la momentul declanșării metricii HPA (Horizontal Pod Autoscaler). HPA trebuie să se scaleze pe baza CPU, memoriei și metricilor personalizate. Cluster Autoscaler adaugă noduri noi dacă cele existente nu pot găzdui pod-urile.

Metodologia Stress Test

Creșterea graduală a sarcinii (Ramp-up Stress Test) — cel mai comun scenariu. Sarcina inițială este setată la 50% din cea așteptată, apoi la fiecare 2 minute crește cu 10% până când sistemul cedează. Acest scenariu permite găsirea limitei exacte de rezistență. Grafana Cloud k6 (2025) recomandă un pas de creștere de cel mult 10% pentru a obține un grafic neted al timpului de răspuns.

Saltul brusc al sarcinii (Spike Stress Test) — sarcina crește de la 10% la 500% în 10–30 de secunde. Acest scenariu modelează situații precum răspândirea virală a conținutului sau atacul DDoS. Spike Stress Test verifică nu atât performanța, cât viabilitatea sistemului: capacitatea de a nu cădea complet și de a reveni la funcționare după stabilizare. API Gateway trebuie să configureze rate limiting pentru a proteja backend-ul de salturile bruște.

Menținerea prelungită a suprasarcinii (Sustained Stress Test) — sistemul este menținut în stare de suprasarcină timp de 30–60 de minute. Acest scenariu relevă scurgeri de resurse care nu se manifestă în testele de scurtă durată. Scurgerea de memorie în aplicațiile Java/Kotlin se acumulează în 20–40 de minute de lucru intens și numai Sustained Stress Test o detectează.

Analiza punctului de defectare și a recuperării

Punctul de defectare se determină după trei criterii: timpul de răspuns, procentul de erori și debitul. De obicei, primul prag depășit este timpul de răspuns — cererile încep să se execute mai mult decât limita stabilită. Apoi crește procentul de erori: serverul nu mai face față procesării cererilor și returnează 503. Ultimul scade Throughput-ul — sistemul nu mai face față nici măcar sarcinii minime. Metrica punctului de defectare se înregistrează în profilul de încărcare pentru planificarea capacității.

Analiza recuperării include trei faze: reacția imediată (primele 30 de secunde după eliminarea sarcinii), stabilizarea (1–5 minute) și recuperarea completă (5–30 de minute). În faza de reacție imediată, timpul de răspuns trebuie să scadă sub baseline — sistemul se eliberează din cozi. Dacă acest lucru nu se întâmplă, problema nu este în sarcină, ci în starea acumulată. Graceful degradation — capacitatea sistemului de a păstra funcționalitatea parțială la suprasarcină — este un indicator cheie al maturității arhitecturii.

Chaos Engineering completează Stress Test prin introducerea intenționată de defecțiuni: deconectarea serverului de bază de date, întârzierea rețelei, oprirea microserviciului. Chaos Monkey de la Netflix (2024) încheie aleatoriu procese în producție, verificând reziliența sistemului. Pentru aplicațiile mobile, Chaos Engineering înseamnă testarea scenariilor: lipsa rețelei, indisponibilitatea API, răspunsul gol al serverului.

Instrumente pentru Stress Test

k6 cu ramping-arrival-rate

k6 suportă Stress Test prin modulul `execution` cu configurația ramping-arrival-rate. Acest mod crește numărul de cereri pe secundă independent de timpul de execuție al fiecărei cereri. Comparativ cu Load Test, Stress Test în k6 necesită setarea unor thresholds mai agresive și dezactivarea gracefull-stop pentru simularea unei defectări bruște. Grafana Cloud detectează automat punctul de defectare pe baza frângerii graficului timpului de răspuns. k6-operator pentru Kubernetes permite rularea de Stress Test distribuite din cluster.

JMeter cu Ultimate Thread Group

JMeter permite configurarea Stress Test prin Ultimate Thread Group — un plugin care definește profilul de încărcare sub formă de tabel: numărul de fire, timpul de încălzire, timpul de menținere, timpul de scădere. Ultimate Thread Group este convenabil pentru scenarii complexe multifazice. JMeter Backend Listener trimite metrici către InfluxDB pentru construirea graficelor punctului de defectare. Pentru Stress Test în JMeter se recomandă dezactivarea timeout-urilor de conexiune pentru a măsura mai precis comportamentul la suprasarcină.

Gremlin pentru Chaos Engineering

Gremlin — platformă de Chaos Engineering pentru Stress Test al infrastructurii. Gremlin permite deconectarea rețelei, încărcarea CPU, umplerea discului și terminarea proceselor la nivelul pod-urilor individuale Kubernetes. Echipele SRE folosesc Gremlin împreună cu k6 pentru Stress Test complex: k6 creează sarcină, Gremlin introduce defecțiuni. Game Day — sesiuni regulate de Stress Test cu Gremlin, documentate în “raport chaos” pentru analiza rezilienței sistemului.

Exemplu de Stress Test pe k6

Scriptul pe k6 prezentat demonstrează un Stress Test cu creștere graduală a sarcinii până la defectare. Ramping-arrival-rate crește numărul de cereri pe secundă independent de timpul de execuție. Thresholds sunt configurate pentru detectarea agresivă a degradării: p95 nu mai mult de 2000 ms, error rate nu mai mult de 5%. La depășirea pragurilor, k6 încheie testul cu cod de eroare, ceea ce permite încorporarea Stress Test în pipeline-ul CI/CD.

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

Cele mai bune practici de testare a stresului

Începeți Stress Test pe staging — testarea de stres în producție necesită monitorizare avansată și un plan de revenire. Google SRE (2024) recomandă efectuarea Stress Test într-un mediu 100% izolat care reproduce producția ca arhitectură și capacități. După un test reușit pe staging, se poate trece la producție sub supravegherea SRE. Feature flag pentru dezactivarea funcționalității la suprasarcină este un element obligatoriu.

Automatizați Stress Test în CI/CD pentru analiza de regresie a punctului de defectare. Dacă o nouă versiune a aplicației are un punct de defectare cu 20% mai jos decât precedenta, aceasta este o regresie care trebuie corectată înainte de lansare. Baseline breaking point este stocat în metrici și comparat automat cu rezultatul fiecărui Stress Test. Alerta se declanșează la o scădere a punctului de defectare de 10%.

Documentați fiecare Stress Test: profilul de încărcare, punctul de defectare, comportamentul la recuperare și lista problemelor descoperite. Netflix Engineering (2024) organizează “Game Day” — sesiuni regulate de Stress Test ale căror rezultate sunt documentate în “chaos report”. Raportul de testare a stresului trebuie să conțină graficul “RPS — timp de răspuns” cu punctul de defectare marcat.