Stress Test w rozwoju aplikacji mobilnych: co to jest, cele i jak przeprowadza się

Co to jest Stress Test?

Stress Test (testowanie stresowe) to proces oceny zdolności systemu do pracy w warunkach przekraczających obliczone parametry. Dla aplikacji mobilnej może to oznaczać 10000 jednoczesnych powiadomień push przy normie 1000, dla backendu — 50000 RPS przy oczekiwanych 5000. Główna różnica między Stress Test a Load Test polega na tym, że celem nie jest potwierdzenie wydajności, ale zbadanie zachowania systemu poza jego projektową mocą. Netflix Engineering (2024) definiuje Stress Test jako „sprawdzenie hipotezy, że system ulegnie awarii w przewidywalny sposób”.

Testowanie stresowe obejmuje dwa obowiązkowe etapy: obciążenie aż do awarii i obserwację odzyskiwania. Odzyskiwanie (recovery) to zdolność systemu do powrotu do normalnej pracy po zdjęciu przeciążenia. System, który nie odzyskuje sprawności bez restartu, uważany jest za kruchy, nawet jeśli wytrzymuje krótkotrwałe przeciążenie. Według AWS Well-Architected Framework (2024) czas odzyskiwania po Stress Test nie powinien przekraczać 5 minut.

Dla klientów mobilnych Stress Test obejmuje sprawdzenie działania przy wymuszonym zakończeniu procesów, odłączeniu sieci i wyczerpaniu pamięci RAM. Android Low Memory Killer może zakończyć proces w tle przy niedoborze RAM — test stresowy powinien sprawdzić, czy aplikacja poprawnie odzyskuje stan po takim zakończeniu. Apple UIKit (2024) zaleca testowanie scenariuszy memory warning na każdym ekranie aplikacji.

Cele testowania stresowego

Określenie punktu awarii

Pierwszy cel Stress Test — określenie punktu awarii (breaking point). To moment, w którym jeden z kluczowych wskaźników wydajności przekracza krytyczny próg: czas odpowiedzi p95 przekracza 10 sekund, procent błędów HTTP 5XX przekracza 5% lub przepustowość spada poniżej 50% baseline. Ustalenie punktu awarii pozwala zespołowi znać z góry granicę skalowalności systemu. Capacity planning opiera się właśnie na danych z Stress Test, a nie Load Test, ponieważ Load Test nie sprawdza warunków granicznych.

Sprawdzenie mechanizmów odzyskiwania

Drugi cel — sprawdzenie mechanizmów odzyskiwania. Po obniżeniu obciążenia do normalnego poziomu system powinien wrócić do standardowych wskaźników. Jeśli pula połączeń do bazy danych nie jest zwalniana lub pamięć podręczna nie jest unieważniana, Stress Test ujawni ten problem. Circuit breaker (Hystrix, Resilience4j) powinien zadziałać przy przeciążeniu i automatycznie przywrócić połączenie po stabilizacji. Health check endpointy pomagają monitorować stan każdego serwisu podczas testu.

Walidacja auto-scaling

Trzeci cel — walidacja auto-scaling. Jeśli infrastruktura używa Kubernetes lub AWS Auto Scaling, Stress Test sprawdza, czy nowe pod-y lub instancje są tworzone wystarczająco szybko. Według Google Kubernetes Engine (2024) czas wdrożenia nowego pod-a nie powinien przekraczać 30 sekund od momentu zadziałania metryki HPA (Horizontal Pod Autoscaler). HPA powinien skalować się na podstawie CPU, pamięci i niestandardowych metryk. Cluster Autoscaler dodaje nowe węzły, jeśli obecne nie mieszczą pod-ów.

Metodologia Stress Test

Stopniowe zwiększanie obciążenia (Ramp-up Stress Test) — najczęstszy scenariusz. Początkowe obciążenie ustawia się na poziomie 50% oczekiwanego, następnie co 2 minuty zwiększa się o 10%, aż do awarii systemu. Ten scenariusz pozwala znaleźć dokładną granicę odporności. Grafana Cloud k6 (2025) zaleca krok zwiększania nie większy niż 10% dla uzyskania gładkiego wykresu czasu odpowiedzi.

Gwałtowny skok obciążenia (Spike Stress Test) — obciążenie wzrasta z 10% do 500% w ciągu 10–30 sekund. Ten scenariusz modeluje sytuacje takie jak wirusowe rozprzestrzenianie treści lub atak DDoS. Spike Stress Test sprawdza nie tyle wydajność, co żywotność systemu: zdolność do nieupadnięcia całkowicie i powrotu do pracy po stabilizacji. API Gateway powinien skonfigurować rate limiting dla ochrony backendu przed gwałtownymi skokami.

Długotrwałe utrzymanie przeciążenia (Sustained Stress Test) — system utrzymywany jest w stanie przeciążenia przez 30–60 minut. Ten scenariusz ujawnia wycieki zasobów, które nie pojawiają się przy krótkotrwałych testach. Wyciek pamięci w aplikacjach Java/Kotlin narasta w ciągu 20–40 minut intensywnej pracy i tylko Sustained Stress Test go wykrywa.

Analiza punktu awarii i odzyskiwania

Punkt awarii określa się według trzech kryteriów: czas odpowiedzi, procent błędów i przepustowość. Jako pierwszy zwykle przekraczany jest próg czasu odpowiedzi — zapytania zaczynają się wykonywać dłużej niż ustalony limit. Następnie rośnie procent błędów: serwer nie nadąża z przetwarzaniem zapytań i zwraca 503. Jako ostatni spada Throughput — system przestaje sobie radzić nawet z minimalnym obciążeniem. Metryka punktu awarii jest rejestrowana w profilu obciążeniowym dla planowania wydajności.

Analiza odzyskiwania obejmuje trzy fazy: natychmiastowa reakcja (pierwsze 30 sekund po zdjęciu obciążenia), stabilizacja (1–5 minut) i pełne odzyskanie (5–30 minut). W fazie natychmiastowej reakcji czas odpowiedzi powinien spaść poniżej baseline — system uwalnia się z kolejek. Jeśli tak się nie dzieje, problem nie leży w obciążeniu, ale w nagromadzonym stanie. Graceful degradation — zdolność systemu do zachowania częściowej funkcjonalności przy przeciążeniu — kluczowy wskaźnik dojrzałości architektury.

Chaos Engineering uzupełnia Stress Test celowym wprowadzaniem awarii: odłączenie serwera bazy danych, opóźnienie sieci, zatrzymanie mikrousługi. Chaos Monkey od Netflix (2024) losowo kończy procesy w produkcji, sprawdzając resilience systemu. Dla aplikacji mobilnych Chaos Engineering oznacza testowanie scenariuszy: brak sieci, niedostępność API, pustą odpowiedź serwera.

Narzędzia do Stress Test

k6 z ramping-arrival-rate

k6 obsługuje Stress Test przez moduł `execution` z konfiguracją ramping-arrival-rate. Ten tryb zwiększa liczbę zapytań na sekundę niezależnie od czasu wykonania każdego zapytania. W porównaniu z Load Test, Stress Test w k6 wymaga ustawienia bardziej agresywnych thresholds i wyłączenia gracefull-stop dla imitacji gwałtownej awarii. Grafana Cloud automatycznie wykrywa punkt awarii na podstawie załamania wykresu czasu odpowiedzi. k6-operator dla Kubernetes pozwala uruchamiać rozproszone Stress Test z klastra.

JMeter z Ultimate Thread Group

JMeter umożliwia skonfigurowanie Stress Test przez Ultimate Thread Group — wtyczkę, która zadaje profil obciążenia w formie tabeli: liczba wątków, czas rozgrzewania, czas utrzymania, czas spadku. Ultimate Thread Group jest wygodna dla złożonych scenariuszy wielofazowych. JMeter Backend Listener wysyła metryki do InfluxDB w celu budowania wykresów punktu awarii. Dla Stress Test w JMeter zaleca się wyłączenie timeoutów połączeń, aby dokładniej zmierzyć zachowanie przy przeciążeniu.

Gremlin dla Chaos Engineering

Gremlin — platforma Chaos Engineering do Stress Test infrastruktury. Gremlin pozwala odłączać sieć, obciążać CPU, wypełniać dysk i kończyć procesy na poziomie pojedynczych pod-ów Kubernetes. Zespoły SRE używają Gremlin wraz z k6 do kompleksowego Stress Test: k6 tworzy obciążenie, Gremlin wprowadza awarie. Game Day — regularne sesje Stress Test z użyciem Gremlin, które są dokumentowane w „chaos report” do analizy odporności systemu.

Przykład Stress Test na k6

Przedstawiony skrypt na k6 demonstruje Stress Test ze stopniowym zwiększaniem obciążenia aż do awarii. Ramping-arrival-rate zwiększa liczbę zapytań na sekundę niezależnie od czasu wykonania. Thresholds są ustawione na agresywne wykrywanie degradacji: p95 nie więcej niż 2000 ms, error rate nie więcej niż 5%. Przy przekroczeniu progów k6 kończy test z kodem błędu, co pozwala wbudować Stress Test w pipeline 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,
    })
}

Najlepsze praktyki testowania stresowego

Rozpoczynaj Stress Test na staging — testowanie stresowe na produkcji wymaga zaawansowanego monitorowania i planu wycofania. Google SRE (2024) zaleca przeprowadzanie Stress Test w 100% izolowanym środowisku, które powtarza produkcję pod względem architektury i mocy. Po udanym teście na staging można przejść do produkcji pod nadzorem SRE. Feature flag do wyłączania funkcjonalności przy przeciążeniu — obowiązkowy element.

Automatyzuj Stress Test w CI/CD dla analizy regresyjnej punktu awarii. Jeśli nowa wersja aplikacji ma punkt awarii o 20% niższy niż poprzednia, jest to regresja, którą należy naprawić przed wydaniem. Baseline breaking point jest przechowywany w metrykach i automatycznie porównywany z wynikiem każdego Stress Test. Alert uruchamia się przy spadku punktu awarii o 10%.

Dokumentuj każdy Stress Test: profil obciążenia, punkt awarii, zachowanie przy odzyskiwaniu i listę wykrytych problemów. Netflix Engineering (2024) prowadzi „Game Day” — regularne sesje Stress Test, których wyniki są dokumentowane w „chaos report”. Raport z testowania stresowego powinien zawierać wykres „RPS — czas odpowiedzi” z zaznaczonym punktem awarii.