Aplikacja działa świetnie na demie dla trzech osób, a w dniu premiery pada przy pierwszym większym ruchu. Znam ten scenariusz z praktyki i dlatego namawiam zespoły, żeby sprawdzić granice wydajności zanim zrobią to za nich użytkownicy. Testy wydajnościowe JMeter to najprostszy punkt wejścia, narzędzie jest darmowe, otwarte i wystarcza do większości typowych potrzeb. W tym artykule pokażę, kiedy warto je uruchomić, jakie pojęcia musisz znać i jak zrobić pierwszy sensowny test bez zakopywania się w konfiguracji.
Kiedy naprawdę potrzebujesz testów wydajnościowych
Nie każdy projekt wymaga testów obciążeniowych, ale są momenty, w których ich brak to proszenie się o kłopoty. W praktyce sięgam po nie, gdy:
- szykuje się kampania, premiera lub sezonowy szczyt ruchu (np. Black Friday, zapisy, terminy podatkowe);
- wystawiasz publiczne API, z którego korzystają integracje innych firm;
- migrujesz na nową infrastrukturę i chcesz porównać „przed” z „po”;
- użytkownicy skarżą się na losowe spowolnienia, których nie widać na pojedynczym wywołaniu.
Cel testu wydajnościowego nie brzmi „czy działa”, tylko „do jakiego momentu działa i co pęka jako pierwsze”. To zupełnie inne pytanie niż w testach funkcjonalnych, jeśli dopiero układasz szerszą strategię, zajrzyj do wpisu o tym, od czego zacząć plan testów.
Podstawowe pojęcia, które musisz rozumieć
Bez kilku terminów wyniki JMetera będą tylko kolorowymi wykresami:
- Throughput: liczba żądań przetworzonych w jednostce czasu (req/s). To Twoja realna przepustowość.
- Latency i response time: w JMeterze latency to czas do pierwszego bajta odpowiedzi, a response time (elapsed) to pełny czas obsługi żądania.
- Virtual users (wątki): symulowani równocześni użytkownicy. W JMeterze to po prostu wątki w Thread Group.
- Ramp-up: czas, w którym JMeter „rozkręca” wszystkich użytkowników. Ramp-up 60 s dla 100 wątków znaczy: co ~0,6 s dochodzi jeden użytkownik. Zbyt krótki ramp-up daje sztuczny skok i fałszywy obraz.
Load vs stress vs soak: trzy różne pytania
| Typ testu | Pytanie, na które odpowiada |
|---|---|
| Load (obciążeniowy) | Czy system wytrzymuje spodziewany, realny ruch? |
| Stress (przeciążeniowy) | Gdzie jest granica i jak system zachowuje się po jej przekroczeniu? |
| Soak (wytrzymałościowy) | Czy przy stałym obciążeniu przez wiele godzin nie pojawiają się wycieki pamięci i degradacja? |
Najczęściej zaczyna się od load, a dopiero potem sięga po stress i soak. Każdy z nich wymaga innego czasu trwania i innej interpretacji wyników.
Testy wydajnościowe JMeter krok po kroku
JMeter potrafi przytłoczyć liczbą opcji, więc trzymaj się prostej ścieżki. Pierwszy działający test złożysz w kilkanaście minut:
- Utwórz Test Plan i dodaj Thread Group. Ustaw liczbę wątków, ramp-up i liczbę powtórzeń (lub czas trwania). Na start wystarczy 10 wątków i ramp-up 10 s.
- Dodaj HTTP Request Sampler. Wpisz protokół, host, ścieżkę i metodę. To pojedyncze żądanie, które JMeter będzie zwielokrotniał.
- Dodaj HTTP Header Manager, jeśli API wymaga nagłówków (np.
Authorization,Content-Type). - Dodaj asercje. Response Assertion na kod odpowiedzi 200 pilnuje, żeby JMeter nie liczył błędów 500 jako „szybkich sukcesów”. To najczęściej pomijany, a kluczowy krok.
- Podłącz listenery do analizy: Summary Report i Aggregate Report.
Ważna zasada: GUI służy tylko do budowania i debugowania scenariusza. Właściwy test uruchamiasz z linii komend (jmeter -n -t plan.jmx -l wynik.jtl), bo tryb graficzny sam zjada zasoby i zaniża wyniki. To ta sama logika co w testach E2E, gdzie scenariusz debugujesz lokalnie z podglądem, a uruchamiasz headless w CI, pisałem o tym przy okazji wyboru między Selenium a Playwright.
Częste pułapki, które psują wyniki
Większość „dziwnych” wyników nie bierze się z aplikacji, tylko z błędów w samym teście. Oto te, na które trafiam najczęściej:
- Testowanie na środowisku innym niż produkcyjne. Słabszy serwer, inna baza czy współdzielony host dają liczby, których nie da się przełożyć na produkcję. Dokumentuj konfigurację środowiska przy każdym wyniku.
- Te same dane dla każdego wątku. Setka użytkowników logujących się na to samo konto to nie test, a trafienie w cache. Użyj CSV Data Set Config i realnie zróżnicowanych danych wejściowych.
- Generator obciążenia jako wąskie gardło. Jeśli maszyna z JMeterem ma zajęty procesor, mierzysz jej limity, nie aplikacji. Obserwuj też host generujący ruch.
- Patrzenie na średnią zamiast percentyli. Średnia ukrywa problemy. Zawsze czytaj p90/p95/p99. To one pokazują, co odczuwają najbardziej pokrzywdzeni użytkownicy.
Co właściwie mierzyć
Sam JMeter pokaże Ci stronę klienta, ale prawdziwy obraz powstaje dopiero po zestawieniu tego z metrykami serwera. Minimalny zestaw, który zawsze zbieram:
- throughput (req/s) i czas odpowiedzi w percentylach p90/p95/p99;
- error rate, odsetek żądań zakończonych błędem pod obciążeniem;
- zasoby po stronie serwera: CPU, pamięć, liczba połączeń do bazy, długość kolejek;
- punkt załamania, obciążenie, przy którym czasy gwałtownie rosną lub pojawiają się błędy.
Gdy masz już powtarzalny scenariusz, naturalnym krokiem jest wpięcie go w pipeline CI/CD, regularne uruchomienia wychwytują regresje wydajności, zanim urosną w problem produkcyjny.
Jak pomagam w tym jako QA Sensei
Od 20 lat pracuję w IT, od siedmiu zajmuję się jakością oprogramowania i regularnie widzę, że testy wydajnościowe wdraża się dopiero po pierwszej awarii. Pomagam zrobić to wcześniej: układam realistyczne scenariusze w JMeterze, dobieram środowisko i dane, uruchamiam testy load, stress oraz soak, a przede wszystkim tłumaczę wyniki na konkretne decyzje, co zoptymalizować, gdzie skalować, co monitorować. Pracuję zdalnie w całej Polsce, a w okolicach Wrocławia także u klienta. Zobacz zakres usług oraz to, jak wygląda proces, a jeśli rozważasz szersze wsparcie, przeczytaj, kiedy opłaca się outsourcing QA.