Load Test w tworzeniu aplikacji mobilnych — co to jest, scenariusze i jak przeprowadza się go

Co to jest Load Test?

Load Test (testowanie obciążeniowe) — to proces sprawdzania, jak system działa przy oczekiwanej liczbie jednoczesnych żądań lub użytkowników. W kontekście tworzenia aplikacji mobilnych Load Test stosuje się zarówno do części serwerowej (API, baza danych, pamięć podręczna), jak i klienckiej (przetwarzanie powiadomień push, synchronizacja danych). Główna różnica w stosunku do testów stresowych polega na tym, że Load Test modeluje rzeczywiste, a nie ekstremalne obciążenie. Według AWS Well-Architected Framework (2024), testowanie obciążeniowe powinno być przeprowadzane z użyciem profili obciążenia opartych na rzeczywistej analityce użytkowania.

Load Test może być przeprowadzany na poziomie żądań HTTP do API, na poziomie połączeń WebSocket lub na poziomie transakcji bazy danych. Celem jest upewnienie się, że czas odpowiedzi każdego żądania nie przekracza zadanego progu (zwykle 500–1000 ms dla API), a przepustowość (RPS — requests per second) odpowiada wymaganiom. Google Cloud Armor (2024) określa wartości progowe na podstawie percentyli: p95 czasu odpowiedzi nie powinien przekraczać 2 sekund dla krytycznych endpointów.

Testowanie obciążeniowe mobilnego backendu obejmuje symulację typowych scenariuszy: rejestracja, autoryzacja, ładowanie kanału, wysyłanie formularza. Scenariusze są zapisywane w postaci plików HAR (HTTP Archive) i odtwarzane przez narzędzie do testowania obciążeniowego. Według dokumentacji k6 (2025), konwersja HAR pozwala skrócić czas przygotowania Load Test o 60%.

Cele testowania obciążeniowego

Pierwszym celem Load Test jest potwierdzenie przepustowości systemu. Jeśli specyfikacja wymaga obsługi 1000 RPS, test obciążeniowy musi to potwierdzić z zapasem 20%. Według Netflix Tech Blog (2024), testowanie obciążeniowe w Netflix jest przeprowadzane z zapasem 2x od szczytowego obciążenia: jeśli oczekiwane jest 10000 RPS, test sprawdza 20000 RPS. Takie podejście gwarantuje stabilność przy nagłych skokach ruchu.

Drugim celem jest wykrywanie wąskich gardeł (bottlenecks) w architekturze. Typowe wąskie gardła w mobilnych backendach — baza danych (wolne zapytania), pamięć podręczna (nieprawidłowa strategia unieważniania) i zewnętrzne API (wolne usługi firm trzecich). Distributed tracing (Jaeger, Zipkin) pomaga zlokalizować problem na poziomie konkretnej usługi lub żądania.

Trzecim celem jest określenie punktu nasycenia (saturation point). To moment, w którym dodanie nowych użytkowników przestaje zwiększać przepustowość. W aplikacjach mobilnych punkt nasycenia często następuje przy 70–80% obciążenia CPU na serwerach bazy danych. Auto-scaling powinien zadziałać przed osiągnięciem tego punktu.

Scenariusze testowania obciążeniowego

Obciążenie szczytowe (Spike Test) — modeluje gwałtowny wzrost aktywności, na przykład poranną wysyłkę powiadomień push lub uruchomienie kampanii reklamowej. Według Grafana k6 (2025), Spike Test symuluje wzrost obciążenia ze 100 do 10000 RPS w ciągu 30 sekund. System powinien radzić sobie bez utraty żądań i bez przekraczania czasu odpowiedzi o więcej niż 50%.

Stałe obciążenie (Endurance Test) — sprawdzenie stabilności systemu przy długotrwałej pracy pod obciążeniem. Typowy czas trwania — 1–4 godzin. Endurance Test wykrywa wycieki pamięci w aplikacjach serwerowych, problemy z pulą połączeń do bazy danych i degradację wydajności pamięci podręcznej. Pula połączeń PostgreSQL przy długotrwałym obciążeniu bez prawidłowej konfiguracji może wyczerpać dostępne połączenia po 2–3 godzinach pracy.

Obciążenie stopniowe (Step Load Test) — stopniowe zwiększanie obciążenia o krok 10–20% co 2–5 minut. Ten scenariusz pomaga znaleźć dokładną granicę, po przekroczeniu której system ulega degradacji. InfluxDB i Prometheus zbierają metryki na każdym kroku do budowy wykresu zależności czasu odpowiedzi od RPS.

Metryki Load Test

Czas odpowiedzi

Czas odpowiedzi (Response Time) — podstawowa metryka Load Test. Mierzony w milisekundach i analizowany według percentyli: p50 (mediana), p95 i p99. Google SRE (2024) zaleca próg p95 nie większy niż 1000 ms dla REST API i nie większy niż 200 ms dla gRPC. Percentyle są ważniejsze od średniej, ponieważ pokazują zachowanie najgorszych żądań, które użytkownicy zauważają w pierwszej kolejności. Apdex (Application Performance Index) — złożona metryka uwzględniająca udziały zadowolonych, tolerujących i sfrustrowanych użytkowników.

Przepustowość

Przepustowość (Throughput) — liczba udanych żądań w jednostce czasu. Mierzona w RPS (requests per second) lub TPS (transactions per second). Wykres przepustowości we współrzędnych „czas — RPS” powinien być liniowy aż do punktu nasycenia. Gwałtowny spadek przepustowości przy zwiększaniu obciążenia — oznaka osiągnięcia limitu systemu. Apache Bench i wrk — proste narzędzia CLI do szybkiego sprawdzenia przepustowości na etapie rozwoju.

Procent błędów

Procent błędów (Error Rate) — udział odpowiedzi z kodem HTTP 4xx lub 5xx w ogólnej liczbie żądań. Dopuszczalny próg — poniżej 1%. Błędy 429 (Too Many Requests) i 503 (Service Unavailable) przy wysokim obciążeniu wskazują na potrzebę konfiguracji rate limiting i auto-scaling. Rate limiter po stronie API Gateway chroni backend przed przekroczeniem dopuszczalnego obciążenia. Retry policy z exponential backoff pomaga klientom poprawnie obsługiwać tymczasowe błędy.

Narzędzia do Load Test

k6 (Grafana)

k6 — wiodące narzędzie Open Source do testowania obciążeniowego od Grafany. Skrypty pisze się w JavaScript, obsługiwane są modularne scenariusze, progi (thresholds) i integracja z Prometheus i InfluxDB. k6 może być uruchamiane zarówno w CLI, jak i w chmurze Grafana Cloud k6. Grafana Cloud automatycznie buduje dashboardy na podstawie wyników Load Test i porównuje je z danymi historycznymi. k6 obsługuje Protocol Buffers i gRPC przez oddzielny moduł k6/net/grpc.

Apache JMeter

Apache JMeter — klasyczne narzędzie do Load Test z interfejsem graficznym. Obsługuje szeroki zakres protokołów: HTTP, JDBC, JMS, FTP i TCP. JMeter lepiej nadaje się do złożonych scenariuszy z wieloma różnymi typami żądań, ale wymaga więcej ręcznej konfiguracji w porównaniu do k6. JMeter Plugins rozszerzają funkcjonalność do testowania WebSocket i gRPC. Do rozproszonego uruchomienia JMeter używa architektury master-slave z jednym kontrolerem.

Locust

Locust — narzędzie w Pythonie, które pozwala opisywać scenariusze obciążenia w kodzie. Locust jest wygodny dla zespołów używających Pythona jako głównego języka do automatyzacji. W przeciwieństwie do k6 i JMeter, Locust obsługuje rozproszone uruchomienie od razu po wyjęciu z pudełka: jeden master-węzeł koordynuje kilka worker-węzłów. Uruchomienie rozproszone pozwala generować obciążenie do 100000 RPS z kilku maszyn. Locust obsługuje również testowanie WebSocket przez niestandardowe rozszerzenia.

import http from 'k6/http'
import check from 'k6'
import sleep from 'k6'

export const options = {
    stages: [
        { duration: '2m', target: 100 },
        { duration: '5m', target: 100 },
        { duration: '2m', target: 200 },
    ],
    thresholds: {
        http_req_duration: ['p(95)<500'],
        http_req_failed: ['rate<0.01'],
    }
}

export default function() {
    const res = http.get('https://api.example.com/users')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
    sleep(1)
}

Przykład pisania Load Test w k6

Przedstawiony powyżej skrypt w k6 demonstruje typową strukturę testu obciążeniowego. Options określa profil obciążenia: ramp-up przez 2 minuty do 100 użytkowników, następnie 5 minut stałego obciążenia i ponowny ramp-up do 200 użytkowników. Thresholds określają kryteria zaliczenia testu: p95 czasu żądania nie więcej niż 500 ms, procent błędów poniżej 1%. Jeśli progi zostaną przekroczone, k6 kończy test z kodem niezerowym — to pozwala wbudować Load Test w CI/CD.

W tworzeniu aplikacji mobilnych Load Test części serwerowej jest szczególnie ważny przy uruchamianiu nowych funkcji, które generują dodatkowe obciążenie: polubienia, komentarze, streaming. Zalecenie — przeprowadzać Load Test na każdym stagingu przed wdrożeniem do produkcji. Stworzenie bazowego profilu obciążeniowego na etapie projektowania API pomaga uniknąć problemów architektonicznych na późniejszych etapach.