Testy wydajnościowe: co to jest, rodzaje, metryki, narzędzia i jak je przeprowadzić przed sezonem

Czas czytania: około 13 minut

Sklep działa bez zarzutu przez jedenaście miesięcy, a w Black Friday, w dniu, który ma zrobić kwartał, strona ładuje się dwanaście sekund, koszyk gubi produkty, a płatność zwraca błąd 502. Nikt nie zmienił kodu. Zmieniła się liczba ludzi, którzy weszli naraz. Testy wydajnościowe istnieją po to, żeby ten dzień przećwiczyć wcześniej, na środowisku testowym, z ruchem sztucznym, ale w liczbach prawdziwych.

W tym tekście wyjaśniamy, czym są testy wydajnościowe według ISTQB, jakie mają rodzaje i czym różni się test obciążeniowy od przeciążeniowego, jakie problemy wykrywają, które metryki liczą się naprawdę, jak przeprowadzić je krok po kroku, jakie narzędzia wybrać, kiedy je uruchamiać, ile kosztują i jakie błędy popełniają zespoły. Piszemy z projektów, w których system klienta wytrzymał sezon przy ruchu większym o 120 procent, a liczba awarii w szczycie spadła o 72 procent.

Czym są testy wydajnościowe?

Testy wydajnościowe to testy sprawdzające, w jakim stopniu system spełnia wymagania dotyczące wydajności: czasu odpowiedzi, przepustowości i wykorzystania zasobów pod określonym obciążeniem; nie szukają błędów funkcjonalnych, tylko odpowiadają, czy system wytrzyma realny ruch.

Tak ujmuje to słownik ISTQB: testowanie wydajnościowe to testowanie mające określić wydajność produktu. Za tym krótkim zdaniem kryją się trzy pytania, które zadaje każdy, kto odpowiada za system: ile czasu użytkownik czeka na odpowiedź, ilu użytkowników naraz system obsłuży bez degradacji i co się dzieje, gdy będzie ich więcej, niż zakładano. Testy wydajnościowe odpowiadają na nie liczbami, nie przypuszczeniami.

Testy wydajnościowe należą do testów niefunkcjonalnych, obok testów bezpieczeństwa, użyteczności i dostępności. Wymagają dedykowanych narzędzi generujących ruch, środowiska zbliżonego do produkcyjnego i kompetencji do czytania wyników. Zespół, który „przetestował wydajność”, otwierając aplikację na pięciu laptopach naraz, nie wykonał testu wydajnościowego, tylko uspokoił sumienie.

Dlaczego testy wydajnościowe mają znaczenie biznesowe?

Wydajność jest cechą, która zamienia się w pieniądze najszybciej ze wszystkich cech jakości: każda dodatkowa sekunda ładowania obniża konwersję, każda awaria w szczycie to utracony przychód z najdroższego dnia w roku, a przewymiarowana infrastruktura kupiona „na wszelki wypadek” to koszt stały bez pokrycia.

Google w swoich wytycznych Core Web Vitals przyjmuje, że największy element strony powinien pojawić się w 2,5 sekundy lub szybciej, żeby doświadczenie było dobre, i mierzy to u 75 procent użytkowników, nie u najszybszych. To próg dla stron publicznych, ale logika jest ta sama w systemach wewnętrznych: pracownik obsługi klienta, który czeka osiem sekund na kartę klienta przy każdej rozmowie, obsłuży w ciągu dnia mniej rozmów, i to jest koszt, który da się policzyć.

Liczby z projektów dla Autono (automotive i wynajem samochodów) oraz Argos (e-commerce), potwierdzone przez klientów. W obu przypadkach testy wydajnościowe nie były osobnym projektem, tylko częścią przygotowania do sezonu: najpierw test odzwierciedlający spodziewany ruch, potem naprawa wąskich gardeł, potem powtórka. Jak to wygląda w sklepie internetowym przed Black Friday, opisujemy w tekście o testowaniu e-commerce.

Jakie są rodzaje testów wydajnościowych?

ISTQB wyróżnia testy obciążeniowe (spodziewany ruch), przeciążeniowe (ruch ponad limit), skoków obciążenia (nagły wzrost), wytrzymałościowe (długi czas), skalowalności (czy da się dołożyć zasobów) i wolumenowe (duże ilości danych); każdy odpowiada na inne pytanie i żaden nie zastępuje pozostałych.

Definicje w słowniku ISTQB: load testing, stress testing, spike testing, endurance testing, scalability testing i volume testing. W praktyce większość projektów zaczyna od testu obciążeniowego i przeciążeniowego, a pozostałe dokłada wtedy, gdy ryzyko tego wymaga: wytrzymałościowy w systemach pracujących bez restartu, skoków w e-commerce i mediach, wolumenowy tam, gdzie dane rosną szybciej niż ruch.

Czym różnią się testy obciążeniowe od przeciążeniowych?

Test obciążeniowy sprawdza, czy system spełnia wymagania przy ruchu, którego się spodziewacie, a test przeciążeniowy szuka punktu, w którym przestaje je spełniać, i sprawdza, jak się wtedy zachowuje; pierwszy mówi „zdaliśmy”, drugi mówi „mamy zapas do tej liczby”.

Najczęstsza pomyłka to test obciążeniowy na poziomie ruchu z codziennego dnia zamiast z dnia szczytowego. Sklep, który ma średnio 200 użytkowników naraz, a w promocji 3 000, nie dowie się z testu na 200 niczego, co go uratuje. Poziom obciążenia w teście bierze się z prognozy najgorszego dnia, nie ze statystyki średniej, bo średnia nie psuje systemów.

Jakie problemy wykrywają testy wydajnościowe?

Testy wydajnościowe wykrywają wąskie gardła (wolne zapytania, brak indeksów, zbyt małe pule połączeń), wycieki pamięci, złą konfigurację serwera i sieci, brak skalowalności architektury oraz błędy, które pojawiają się tylko przy współbieżności, takie jak blokady i wyścigi.

Część z tych problemów to nie błędy w kodzie, tylko brak decyzji projektowych: co robić z nadmiarem ruchu, ile czekać na system zewnętrzny, kiedy odrzucić żądanie. Test wydajnościowy zadaje te pytania w środowisku testowym, zanim zada je produkcja. O tym, jak sprawdzać style z systemami zewnętrznymi, piszemy w tekście o testach integracyjnych.

Które metryki wydajności są najważniejsze?

Najważniejsze metryki to czas odpowiedzi w percentylach (p90, p95, p99, nie średnia), przepustowość w żądaniach na sekundę, odsetek błędów, liczba równoczesnych użytkowników oraz wykorzystanie zasobów (procesor, pamięć, połączenia do bazy, sieć); bez celu dla każdej z nich test nie ma kryterium zaliczenia.

Cele metryk ustala się przed testem, z biznesem, w wymaganiach niefunkcjonalnych. Bez nich test kończy się raportem z liczbami, o których nikt nie umie powiedzieć, czy są dobre. Najlepszy raport z testu wydajnościowego ma jedną tabelę: metryka, cel, wynik, zaliczone lub nie, i listę wąskich gardeł w kolejności od najdroższego. Jak takie cele wpisać w dokumentację, pokazujemy w tekście o planie testów.

Jak przeprowadzić testy wydajnościowe krok po kroku?

Testy wydajnościowe prowadzi się w sześciu krokach: wymagania i model ruchu, środowisko i dane, skrypty scenariuszy, wykonanie od małego obciążenia w górę, analiza wąskich gardeł oraz naprawa i powtórka; najwięcej czasu zabierają krok pierwszy i piąty, nie samo uruchomienie.

Krok szósty jest tym, który najczęściej ginie: test wykonany raz, przed premierą, a potem nigdy więcej, choć każde wydanie zmienia zapytania i konfigurację. Regresja wydajnościowa w pipeline, choćby w skróconej wersji, chroni przed powolnym psuciem się systemu między sezonami. O tym, jak układać testy w pipeline, piszemy w tekście o shift left testing.

Jakie narzędzia do testów wydajnościowych wybrać?

Do testów wydajnościowych wybiera się jedno z czterech narzędzi otwartych: JMeter (najszerszy, z interfejsem graficznym), Gatling (kod w Scali lub Javie, wydajny generator), k6 (skrypty w JavaScripcie, dobry w pipeline) albo Locust (Python, prosty do rozszerzania); wybór zależy od języka zespołu i miejsca uruchamiania, nie od rankingów.

Strony narzędzi: Apache JMeter, Gatling, k6, Locust. Uczymy pracy z trzema z nich na szkoleniach Testowanie wydajnościowe JMeter, Gatling i Locust. Narzędzie to najmniejszy problem w testach wydajnościowych; największy to model ruchu i środowisko, których żadne narzędzie nie zrobi za Was.

Przykład progów zaliczenia w skrypcie k6 (fragment)

export const options = {
  stages: [
    { duration: '5m',  target: 500  },   // rozgrzewka do 500 uzytkownikow
    { duration: '20m', target: 3000 },   // szczyt: prognoza Black Friday
    { duration: '5m',  target: 0    },   // wygaszenie, czy system wraca
  ],
  thresholds: {
    http_req_duration: ['p(95)<2000'],   // 95% zadan ponizej 2 s
    http_req_failed:   ['rate<0.001'],   // bledy ponizej 0,1%
  },
};

Kiedy w projekcie uruchamiać testy wydajnościowe?

Testy wydajnościowe uruchamia się przed każdym większym wydaniem i sezonem, po zmianach architektury, bazy danych lub infrastruktury, przed kampaniami o dużym zasięgu oraz w skróconej formie w pipeline; najgorszy moment to tydzień przed premierą, bo na naprawę wąskich gardeł nie ma już czasu.

• Wcześnie, na prototypie architektury. Test skalowalności na szkielecie systemu pokazuje, czy wybrana architektura w ogóle udźwignie cel, zanim powstanie kod, którego nie da się przepisać.
• Przed każdym większym wydaniem. Regresja wydajnościowa krytycznych ścieżek, porównana z poprzednim wynikiem. Wzrost p95 o 30 procent to sygnał, nawet jeśli nadal mieści się w limicie.
• Kilka tygodni przed sezonem. Pełny test obciążeniowy i przeciążeniowy na prognozie szczytu. Tygodnie, nie dni, bo wąskie gardła w bazie i architekturze naprawia się dłużej niż błędy w kodzie.
• Po zmianie infrastruktury. Migracja do chmury, nowa wersja bazy, zmiana dostawcy hostingu. Kod bez zmian, wydajność niekoniecznie.
• Przed kampanią o nieznanym zasięgu. Test skoków obciążenia na wielokrotności prognozy, bo kampania, która „wypali”, to ta, która położy system.

Ile kosztują testy wydajnościowe i kiedy zlecić je na zewnątrz?

Testy wydajnościowe pojedynczej aplikacji webowej wyceniamy od 7 500 zł; na koszt wpływa liczba scenariuszy, złożoność środowiska, liczba iteracji naprawy i powtórki oraz to, czy testy mają zostać w pipeline; na zewnątrz warto je zlecić, gdy zespół nie ma kompetencji do budowy modelu ruchu i analizy wyników albo gdy sezon jest bliżej niż czas potrzebny na ich zdobycie.

Ta sama kwota, którą podajemy w tekście o zamówieniach publicznych na testy, to punkt wyjścia dla jednej aplikacji z kilkoma ścieżkami krytycznymi. Umowa ramowa na cykliczne testy przed każdym sezonem to inna skala, bo obejmuje wielokrotne przebiegi i utrzymanie skryptów. Najdroższą opcją jest zawsze brak testów, bo jedna awaria w szczycie kosztuje więcej niż roczny cykl testów.

Zespołom, które chcą budować te kompetencje u siebie, oprócz szkoleń z narzędzi proponujemy Optymalizację wydajności aplikacji webowych, bo test bez umiejętności naprawy daje tylko raport. Firmom przed sezonem albo wdrożeniem prowadzimy testy wydajnościowe od modelu ruchu po powtórkę po naprawach. Wiedzę dla liderów jakości publikujemy na portalu Strefa QA.

Jakie są najczęstsze błędy w testach wydajnościowych?

Najczęstsze błędy to test na ruchu średnim zamiast szczytowym, środowisko wielokrotnie mniejsze od produkcji, scenariusze bez czasu namysłu i bez proporcji z analityki, czytanie średniej zamiast percentyli, brak monitoringu serwerów w trakcie testu, test wykonany raz i nigdy więcej oraz generator ruchu, który sam jest wąskim gardłem.

1. Ruch średni zamiast szczytowego. Test na 200 użytkownikach nie mówi nic o dniu z 3 000. Poziom bierze się z najgorszego dnia z zapasem.
2. Środowisko cztery razy mniejsze. Wynik przeskalowany „w głowie” nie jest wynikiem. Jeśli środowisko musi być mniejsze, musi być mniejsze proporcjonalnie i z tą samą konfiguracją.
3. Scenariusz bez namysłu. Skrypt, który klika bez przerwy, generuje ruch, jakiego nie ma. Czas namysłu użytkownika i proporcje ścieżek z analityki zmieniają wynik kilkukrotnie.
4. Średnia zamiast p95. Średnia 800 milisekund może ukrywać 5 procent użytkowników czekających 9 sekund. To oni piszą do obsługi klienta.
5. Brak monitoringu w trakcie. Bez metryk procesora, pamięci i bazy w czasie testu wiadomo, że jest wolno, ale nie wiadomo dlaczego.
6. Test jednorazowy. Wykonany przed premierą, a po roku wydań nikt nie wie, ile system dziś wytrzymuje.
7. Generator jako wąskie gardło. Jedna maszyna generująca 3 000 użytkowników sama się dławi i raport pokazuje jej limity, nie limity systemu. Ruch rozproszony z kilku maszyn albo z chmury.

Skrypty do testów wydajnościowych piszą coraz częściej testerzy automatyzujący, bo to ten sam warsztat: kod, repozytorium, pipeline. Jak wejść w tę specjalizację, opisujemy w tekście o ścieżkach rozwoju w testowaniu.

Najczęstsze pytania o testy wydajnościowe

Co to są testy wydajnościowe?

Testy wydajnościowe sprawdzają, jak system zachowuje się pod obciążeniem: jak szybko odpowiada, ilu użytkowników obsłuży, kiedy się degraduje i czy wraca do sprawności po szczycie. Należą do testów niefunkcjonalnych i wymagają narzędzi generujących ruch, nie da się ich wykonać ręcznie.

Jakie są rodzaje testów wydajnościowych?

Według ISTQB: obciążeniowe (spodziewany ruch), przeciążeniowe (ruch ponad limit), skoków obciążenia (nagły wzrost), wytrzymałościowe (długi czas), skalowalności (czy dołożenie zasobów pomaga) i wolumenowe (duże ilości danych). Większość projektów zaczyna od obciążeniowego i przeciążeniowego.

Czym różnią się testy obciążeniowe od przeciążeniowych?

Test obciążeniowy sprawdza, czy system spełnia wymagania przy spodziewanym ruchu, w tym szczytowym. Test przeciążeniowy zwiększa ruch ponad limit, żeby znaleźć punkt załamania i sprawdzić, jak system się degraduje i czy wraca do sprawności.

Które metryki są najważniejsze w testach wydajnościowych?

Czas odpowiedzi w percentylach (p95, p99), przepustowość w żądaniach na sekundę, odsetek błędów, liczba równoczesnych użytkowników i wykorzystanie zasobów serwera. Średnia czasu odpowiedzi jest myląca, bo ukrywa użytkowników czekających najdłużej.

Jakie narzędzia do testów wydajnościowych wybrać?

Najczęściej jedno z czterech otwartych: JMeter (interfejs graficzny, najwięcej protokołów), Gatling (kod, wydajny generator), k6 (JavaScript, dobry w pipeline) albo Locust (Python). Wybór zależy od języka zespołu i miejsca uruchamiania.

Kiedy przeprowadzać testy wydajnościowe?

Przed każdym większym wydaniem i sezonem, po zmianach architektury lub infrastruktury, przed kampaniami o dużym zasięgu oraz w skróconej formie w pipeline. Najgorszy moment to tydzień przed premierą, bo na naprawę wąskich gardeł nie ma już czasu.

Ile kosztują testy wydajnościowe?

W naszym cenniku testy wydajnościowe pojedynczej aplikacji webowej zaczynają się od 7 500 zł. Na koszt wpływa liczba scenariuszy, złożoność środowiska, liczba iteracji naprawy i powtórki oraz to, czy testy mają zostać w pipeline jako regresja.

Czy testy wydajnościowe można wykonać ręcznie?

Nie. Wymagają narzędzi generujących setki lub tysiące równoczesnych sesji, środowiska zbliżonego do produkcji i monitoringu zasobów w trakcie. Otwarcie aplikacji na kilku komputerach naraz nie jest testem wydajnościowym.

Powiązane na blogu Quality Island

• Testy niefunkcjonalne: wydajność, bezpieczeństwo, użyteczność i niezawodność
• Testowanie e-commerce: jak przygotować sklep na Black Friday
• Testy bezpieczeństwa i testy penetracyjne: co sprawdzają, rodzaje, etapy i jak je zlecić
• Testy integracyjne: co to jest, rodzaje, przykłady i jak je wykonywać krok po kroku
• Shift left testing: co to jest, zalety, wady i jak wdrożyć krok po kroku
• Zamówienia publiczne na testy oprogramowania

Pełna lista źródeł

• ISTQB Glossary, hasła performance testing, load testing, stress testing, spike testing, endurance testing, scalability testing i volume testing
• Google, Largest Contentful Paint oraz Core Web Vitals, próg 2,5 sekundy dla 75 procent wizyt
• Dokumentacja narzędzi: Apache JMeter, Gatling, k6, Locust
• Dane własne Quality Island z projektów dla Autono (automotive i wynajem samochodów: stabilność przy ruchu większym o 120 procent, 55 procent mniej błędów krytycznych w rezerwacjach) i Argos (e-commerce: 72 procent mniej awarii w szczycie, 12 procent wzrostu konwersji), liczby potwierdzone przez klientów; cennik własny od 7 500 zł za testy wydajnościowe jednej aplikacji webowej