Black Friday zwiększa presję na sklep internetowy w krótkim oknie czasowym. Nawet jeśli infrastruktura działa poprawnie przy codziennym ruchu, jednoczesne wejścia na promocje, wyszukiwanie produktów, logowanie i płatności mogą ujawnić wąskie gardła, których nie widać na wykresie średniej wydajności. Najbezpieczniejszy plan łączy testy obciążeniowe z monitoringiem, optymalizacją sklepu i procedurą awaryjną. Poniżej znajdziesz harmonogram oraz instrukcję, którą można przekazać zespołowi IT lub partnerowi technologicznemu.
Dlaczego Black Friday jest testem wytrzymałości dla Twojego sklepu?
Black Friday w e-commerce nie jest pojedynczą kampanią marketingową. To skoordynowane zdarzenie, w którym reklamy, mailingi, porównywarki cen, aplikacja mobilna i ruch organiczny kierują użytkowników do tych samych zasobów. Największe obciążenie może pojawić się po publikacji kodu rabatowego, uruchomieniu limitowanej promocji albo wysłaniu newslettera. Dlatego planowanie warto oprzeć na rzeczywistych danych z analityki: liczbie sesji w szczycie, udziale urządzeń mobilnych, popularnych kategoriach oraz proporcji przeglądania do koszyka i zakupu.
Błąd w trakcie promocji ma wymiar techniczny i biznesowy. Przerwane płatności obniżają konwersję, wolny koszyk zwiększa porzucenia, a niedostępna strona produktowa utrudnia kampanii wykorzystanie budżetu. Dodatkowo zespół traci możliwość odróżnienia problemu aplikacji od przeciążenia bazy danych, dostawcy płatności lub usługi zewnętrznej. Test przed sezonem pozwala ustalić granice systemu wtedy, gdy można jeszcze zmienić konfigurację, kod albo plan skalowania.
Jeżeli sklep wymaga przebudowy architektury, warto połączyć testy z pracami nad sklepem internetowym. W przypadku zmian infrastrukturalnych sprawdź również założenia dotyczące hostingu, CDN i automatycznego skalowania.
Czym są testy obciążeniowe i dlaczego potrzebujesz ich przed Black Friday?
Testy obciążeniowe (ang. load testing) sprawdzają, jak aplikacja zachowuje się przy określonym, kontrolowanym ruchu. Zespół odtwarza scenariusze użytkowników, stopniowo zwiększa obciążenie i porównuje wynik z ustalonymi kryteriami. Celem nie jest samo wygenerowanie dużej liczby żądań. Celem jest odpowiedź na pytanie, czy kluczowe procesy sklepu pozostają dostępne, poprawne i wystarczająco szybkie przy ruchu, którego spodziewasz się podczas Black Friday.
Testy obciążeniowe, testy wydajnościowe i stress test
W praktyce terminy bywają używane zamiennie, ale opisują różne pytania. Testy wydajnościowe są szerszą kategorią: obejmują pomiar czasu odpowiedzi, przepustowości i zużycia zasobów w różnych warunkach. Test obciążeniowy odpowiada na pytanie, jak system działa przy przewidywanym obciążeniu. Stress testing podnosi obciążenie ponad zakładany szczyt, aby znaleźć punkt degradacji lub awarii. Spike test symuluje nagły skok ruchu, a soak test utrzymuje obciążenie przez dłuższy czas, aby ujawnić wycieki pamięci, narastające kolejki i problemy z rotacją logów.
Przeczytaj więcej: Load testing vs stress testing vs spike testing. Czym się różnią i kiedy stosować?
Co dokładnie mierzą testy obciążeniowe?
Minimalny zestaw metryk powinien obejmować czas odpowiedzi, przepustowość i błędy. Zamiast patrzeć wyłącznie na średnią, analizuj percentyle, na przykład p95 i p99, ponieważ pokazują doświadczenie użytkowników dotkniętych opóźnieniem. Po stronie infrastruktury obserwuj CPU, pamięć, obciążenie bazy danych, liczbę połączeń, kolejki, cache hit ratio i limity usług zewnętrznych. Po stronie biznesowej połącz wynik z dostępnością karty produktu, dodaniem do koszyka, rozpoczęciem checkoutu i finalizacją płatności.
Wartość progową ustal przed testem. Przykładowo: nie więcej niż 1% błędów dla krytycznego scenariusza, p95 poniżej uzgodnionego limitu oraz brak wzrostu czasu odpowiedzi po 30 minutach stabilnego obciążenia. To nie są uniwersalne normy. Są to kryteria akceptacji, które należy dopasować do architektury, historii wyników i wymagań biznesu. Dokumentacja k6 opisuje progi jako warunki pass/fail, które można automatyzować w procesie testowym k6 thresholds.
Kiedy przeprowadzić testy? Harmonogram przed Black Friday
Zaplanuj co najmniej dwa pełne cykle testów: pierwszy do znalezienia problemów i drugi po wdrożeniu poprawek. Ostatni test kontrolny wykonaj na tyle wcześnie, aby nie łączyć dużych zmian z samym okresem sprzedaży.
Testy obciążeniowe krok po kroku
Krok 1 Zdefiniuj scenariusze testowe
Zacznij od ścieżek, które wpływają na przychód lub dostępność. Nie testuj całego serwisu z jednakową intensywnością. Zbuduj model ruchu złożony z proporcji, które przypominają realne zachowanie użytkowników.
- Ruch anonimowy — wejście z kampanii, strona kategorii, wyszukiwanie, filtr i karta produktu.
- Zakup — logowanie, dodanie produktu, koszyk, kod rabatowy, wybór dostawy, płatność i potwierdzenie zamówienia.
- Obsługa promocji — jednoczesne użycie kodu, limitowanej ceny, stanów magazynowych i reguł dostawy.
- Integracje — pobranie ceny i dostępności, system płatności, kurier, ERP, CRM, rekomendacje i wysyłka maili.
Zapisz dla każdego scenariusza liczbę wirtualnych użytkowników, tempo ich pojawiania się, czas trwania, dane testowe i oczekiwany rezultat. Dane osobowe zastępujemy danymi testowymi, a zewnętrzne płatności pomijamy, symulujemy albo wykorzystujemy metodę płatności niewymagającą kontaktu z bramką.
Najlepiej zacząć od modelu proporcji, a nie od jednej ambitnej liczby użytkowników. Jeśli analityka pokazuje, że większość sesji kończy się na przeglądaniu kategorii, ten etap powinien otrzymać największy udział w teście. Checkout będzie miał mniejszy wolumen, ale wyższy priorytet, bo każda nieudana transakcja ma bezpośredni koszt. Ustal też, czy promocja generuje ruch równomierny, czy skokowy. Newsletter i reklama z krótkim oknem emisji wymagają spike testu, a kolejka wejść z kampanii afiliacyjnej może bardziej przypominać długi test stabilnego obciążenia.
Jeśli nie mamy bezpiecznego środowiska testowego bramki płatniczej, w teście obciążeniowym lepiej ją pominąć. Ogranicza to ryzyko blokowania prawdziwych zamówień i ułatwia powtarzanie testu po każdej poprawce.
Krok 2 Przygotuj środowisko testowe
Najlepiej testować środowisko możliwie zbliżone do produkcji: z tą samą wersją aplikacji, konfiguracją cache, schematem bazy i integracjami. Jeśli testujesz produkcję, uzyskaj zgodę, ogranicz dane, ustal okno testowe i uzgodnij plan przerwania. Generator ruchu musi mieć zapas zasobów, aby nie stał się wąskim gardłem. Oddziel metryki generatora od metryk systemu testowanego.
Przygotuj dashboard, który pokazuje jednocześnie ruch, błędy, czasy odpowiedzi, zasoby aplikacji, bazę danych i usługi zależne. Ustal, kto obserwuje test, kto może zatrzymać obciążenie i kto podejmuje decyzję o wdrożeniu poprawki. Bez tego wynik testu pozostaje raportem technicznym, a nie narzędziem do decyzji.
Przed rozpoczęciem zrób krótką próbę z minimalnym obciążeniem. Sprawdź, czy logowanie, sesje, koszyk i asercje działają poprawnie, a dane nie są współdzielone między wirtualnymi użytkownikami. Zabezpiecz logi przed zapisywaniem danych kart i tokenów. Ustal także limit obciążenia, przy którym test zostanie automatycznie przerwany. Ten limit powinien uwzględniać nie tylko aplikację, lecz także budżet dostawcy chmurowego, limity API i wpływ na inne środowiska.
Krok 3 Przeprowadź testy z JMeter lub k6
Apache JMeter pozwala budować plany testów z grupami wątków, żądaniami HTTP, kontrolerami, ekstraktorami i asercjami. W scenariuszu zakupowym użyj danych z parametrów zamiast jednej stałej wartości, dodaj obsługę tokenów i sprawdzaj treść odpowiedzi, a nie tylko kod HTTP. Oficjalna dokumentacja JMeter opisuje między innymi konfigurację żądań HTTP i elementy planu testowego JMeter Component Reference.
Praktyczny przebieg w JMeter może wyglądać tak: utwórz Thread Group, dodaj HTTP Request Defaults, ustaw menedżera ciasteczek i nagłówków, rozdziel ścieżki kontrolerami, a następnie dodaj asercje dla odpowiedzi. Zwiększaj obciążenie etapami. Najpierw wykonaj krótki smoke test z minimalną liczbą użytkowników, potem test średniego ruchu, test szczytowy i osobny spike test. Wyniki zapisuj w formacie, który pozwala porównać kolejne uruchomienia. Scenariusz najlepiej przygotować i sprawdzić w interfejsie graficznym JMetera, a właściwy test obciążeniowy uruchamiać w trybie CLI/non-GUI, żeby ograniczyć obciążenie maszyny generującej ruch.
k6 jest dobrym wyborem, gdy zespół chce trzymać scenariusze jako kod i uruchamiać je w CI/CD. Gatling sprawdzi się w zespołach, które pracują w środowisku JVM i preferują model oparty na kodzie. Narzędzie nie zastępuje metodologii: w każdym przypadku trzeba zdefiniować ruch, dane, progi i sposób obserwacji. W przypadku dużych obciążeń rozważ rozproszony generator lub rozwiązanie chmurowe; AWS opisuje uruchamianie skryptów JMeter w rozwiązaniu Distributed Load Testing AWS Prescriptive Guidance.
Krok 4 Analizuj wyniki i znajdź wąskie gardła
Najpierw sprawdź poprawność testu. Czy scenariusz wykonał oczekiwane kroki? Czy cache nie ukrył błędu aplikacji? Czy dane testowe nie spowodowały nienaturalnego rozkładu? Czy generator osiągnął zaplanowane tempo? Dopiero potem interpretuj czasy odpowiedzi i przepustowość.
Szukaj korelacji. Wzrost czasu odpowiedzi przy wysokim CPU aplikacji może wskazywać na kod lub zbyt małą liczbę instancji. Opóźnienie przy niskim CPU, ale wysokim czasie zapytań może kierować uwagę do bazy danych. Błędy tylko w checkoutcie mogą wynikać z limitu dostawcy płatności, blokady transakcji lub błędnej obsługi sesji. Zespół powinien opisać hipotezę, dowód w metrykach i proponowaną zmianę, zamiast ograniczać raport do stwierdzenia, że system był wolny.
Krok 5 Wprowadź poprawki i wykonaj retest
Każdą poprawkę testuj osobno, jeśli to możliwe. Zmiana cache, indeksów i liczby instancji w jednym wdrożeniu utrudnia ocenę wpływu. Zachowaj identyczne scenariusze, dane i progi, aby porównanie było wiarygodne. Po pozytywnym retestcie wykonaj krótki test regresji kluczowych ścieżek biznesowych oraz sprawdź, czy poprawa jednego endpointu nie pogorszyła checkoutu lub panelu administracyjnego.
Wynik końcowy powinien zawierać decyzję: gotowe, gotowe z ograniczeniami albo wymagające dalszych prac. Dołącz listę ryzyk, właścicieli, warunki eskalacji oraz instrukcję wycofania zmian. To właśnie te elementy pomagają zarządowi ocenić budżet na testy w kategoriach kontrolowanego ryzyka i ochrony przychodu.
Raport powinien być zrozumiały dla dwóch odbiorców. Osoba techniczna potrzebuje wykresów, logów, korelacji i dokładnych parametrów uruchomienia. Osoba biznesowa potrzebuje odpowiedzi, czy klienci mogą wyszukać produkt, zastosować promocję i opłacić zamówienie w warunkach szczytowych. Dlatego każdą usterkę opisz w dwóch warstwach: przyczyna techniczna oraz wpływ na proces sprzedaży. Taki format ułatwia wybór między optymalizacją kodu, zwiększeniem zasobów i czasowym ograniczeniem funkcji niekrytycznych.
Jeśli wynik jest na granicy progu, nie traktuj go automatycznie jako porażki ani sukcesu. Sprawdź powtarzalność pomiaru, zmienność ruchu i zapas do limitu. P95 na poziomie akceptowalnym przy krótkim teście może pogorszyć się podczas dłuższego okna promocji, gdy rośnie liczba sesji, logów i zadań asynchronicznych. W decyzji uwzględnij także koszt poprawki: czas zespołu, ryzyko wdrożenia, koszt dodatkowej infrastruktury oraz wartość procesu, który zabezpieczasz. Dzięki temu test staje się podstawą świadomej decyzji, a nie konkursem na najniższy czas odpowiedzi.
Narzędzia do testów obciążeniowych
Przeczytaj więcej: Czym jest JMeter i dlaczego warto używać go do testów wydajnościowych?
Checklista przygotowania sklepu na Black Friday
Test obciążeniowy nie zastąpi przeglądu całego procesu sprzedaży. Przed sezonem sprawdź poniższe obszary i przypisz właściciela do każdego punktu.
- Infrastruktura — potwierdź limity autoscalingu, CDN, cache, połączenia do bazy, zapas zasobów i plan zwiększenia mocy.
- Baza danych — przejrzyj najwolniejsze zapytania, indeksy, blokady, połączenia i zadania wykonywane cyklicznie.
- Frontend — skompresuj obrazy, zastosuj lazy loading tam, gdzie nie pogorszy to UX, ogranicz skrypty stron trzecich i sprawdź mobilny checkout.
- Promocje — przetestuj reguły rabatowe, limity, łączenie kodów, stany magazynowe i zachowanie przy wyczerpaniu puli.
- Integracje — uzgodnij limity i procedury awaryjne dla płatności, dostaw, ERP, CRM, rekomendacji i mailingu.
- Monitoring — zbuduj dashboard z metrykami technicznymi i biznesowymi, ustaw alerty oraz kanał eskalacji.
- Plan B — opisz tryb ograniczonego checkoutu, czasowe wyłączenie niekrytycznych funkcji, komunikat dla klienta i rollback.
Na dzień przed startem promocji nie wprowadzaj dużych zmian bez planu wycofania. Wykonaj kontrolę wersji aplikacji, konfiguracji cache, certyfikatów, domen kampanii, webhooków płatniczych i alertów. Potwierdź, że zespół zna kanał eskalacji oraz że osoba dyżurna ma uprawnienia do skalowania zasobów i blokowania wadliwej funkcji. Po zakończeniu szczytu zachowaj metryki i logi, aby porównać sezon z kolejną kampanią.
Posłuchaj rozmowy: Jak zadbać o wydajność platformy e-commerce przed Black Friday?
Studium przypadku
Poniższy przykład jest scenariuszem hipotetycznym, który pokazuje sposób pracy z wynikiem testu. Nie przedstawia danych ani wyników konkretnego klienta.
Sklep z elektroniką przygotował promocję, która miała wygenerować około czterokrotnie większy ruch niż zwykły dzień. Pierwszy test wykazał, że karta produktu działała poprawnie, ale po zwiększeniu liczby użytkowników czas odpowiedzi koszyka rósł szybciej niż czas odpowiedzi katalogu. Monitoring pokazał wysokie wykorzystanie połączeń bazy danych oraz kolejkę zapytań związanych z walidacją kodów rabatowych.
Zespół rozdzielił odczyty katalogu od operacji checkoutu, dodał brakujący indeks i ograniczył częstotliwość walidacji kodu dla tego samego koszyka. W teście sprawdzono osobno katalog, koszyk i checkout, a następnie połączono je w jeden scenariusz. Zewnętrzny operator płatności został pominięty lub zasymulowany, jeśli nie był bezpośrednim przedmiotem testu. Najważniejszym rezultatem nie była pojedyncza liczba requests per second, lecz potwierdzenie, że krytyczny zakup utrzymuje uzgodnione progi przy obciążeniu szczytowym.
Najczęstsze błędy przy testach obciążeniowych
- Testowanie tylko strony głównej — nie pokazuje zachowania koszyka, promocji, logowania i płatności.
- Brak kryteriów akceptacji — bez progów zespół może uznać każdy wynik za „wystarczający”.
- Zbyt późny test — na tydzień przed promocją lista zmian jest długa, a czas na bezpieczny retest krótki.
- Sztuczny ruch — jedno powtarzane żądanie nie odtwarza sesji, cache, danych i kolejności działań prawdziwego użytkownika.
- Brak obserwacji usług zależnych — aplikacja może mieć wolne odpowiedzi z powodu płatności, ERP lub dostawcy wyszukiwania.
- Jednorazowy test bez porównania — bez baseline’u trudno ocenić, czy poprawka rzeczywiście zmieniła zachowanie systemu.
- Brak testu po zmianie promocji — reguła rabatowa lub nowy moduł merchandisingowy może zmienić liczbę zapytań mimo niezmienionego kodu checkoutu.
- Brak właściciela wyniku — jeśli nikt nie odpowiada za usunięcie wąskiego gardła, raport nie prowadzi do poprawy przed sezonem.
Podsumowanie i następny krok
Przygotowanie sklepu na Black Friday powinno zacząć się od danych i scenariuszy biznesowych, a zakończyć decyzją operacyjną. Zdefiniuj ruch, przygotuj środowisko, wykonaj testy obciążeniowe i wydajnościowe, przeanalizuj wąskie gardła, wdroż poprawki oraz powtórz pomiar. Uzupełnij ten proces o CDN, cache, bazę danych, monitoring i plan awaryjny.
Jeśli zespół nie ma zasobów, aby samodzielnie zaprojektować scenariusze, uruchomić JMeter lub zinterpretować metryki, zaplanuj wsparcie w zakresie testów wydajnościowych. Warto też połączyć testy z audytem UX, ponieważ szybki system nie rozwiąże problemu, jeśli checkout jest nieczytelny lub promocja nie działa zgodnie z oczekiwaniem użytkownika.
FAQ dotyczące testów obciążeniowych przed Black Friday
Ile czasu potrzebujesz na testy obciążeniowe sklepu?
Najczęściej potrzebujesz kilku tygodni, ponieważ praca obejmuje wybór scenariuszy, przygotowanie danych, test, analizę, poprawki i retest. Sama egzekucja może trwać krótko, ale nie powinna być traktowana jako cały projekt.
Czy JMeter wystarczy do testu sklepu internetowego?
JMeter wystarczy do testów protokołowych i API, jeśli scenariusze oraz asercje są dobrze przygotowane. Nie zastępuje testów realnego renderowania w przeglądarce ani obserwacji usług zewnętrznych. W razie potrzeby połącz test backendu z mniejszą liczbą scenariuszy browserowych.
Jakie metryki są najważniejsze?
Zacznij od p95 i p99 czasu odpowiedzi, odsetka błędów, przepustowości i poprawności kluczowych transakcji. Następnie dodaj CPU, pamięć, bazę danych, kolejki, cache i limity integracji. Metryki powinny prowadzić do decyzji, a nie tylko zwiększać objętość raportu.
Czy test obciążeniowy powinien odbyć się na produkcji?
Nie zawsze. Środowisko zbliżone do produkcji jest bezpieczniejszym punktem wyjścia. Test produkcyjny wymaga zgody, kontroli danych, okna testowego i możliwości szybkiego zatrzymania ruchu.
W wielu przypadkach lepiej wykonać pełny test na środowisku możliwie podobnym do produkcji, a na samej produkcji ewentualnie tylko krótki, kontrolowany test.
Media4U
