Na etapie, kiedy przechodzimy z uruchamiania prostych scenariuszy testowych do projektowania bardziej zaawansowanych frameworków, musimy wziąć pod uwagę wiele więcej czynników. Odpowiednio rozplanowane konfiguracje czy dokładna znajomość cyklu życia testów pozwala na ich skuteczne wdrożenie oraz zaplanowanie.
W dzisiejszej części serii omówimy sobie konfiguracje w k6, typy scenariuszy, executorów oraz cykl życia testów.
Cykl życia testu
Cykl życia tekstu w k6 dzieli się na cztery sekcje. Są nimi:
- Inicjacja (init) – wszystkie akcje, które dzieją się za trzema głównymi funkcjami. Można powiedzieć, że cały kod, który jest poza nimi (omawianymi w kolejnych punktach), to kod należący do sekcji init. Kod w tej sekcji wykonuje się jako pierwszy. W ramach cyklu „init” możemy przeprowadzić operacje, które są niezbędne do przygotowania środowiska testowego. Obejmują one wczytanie danych testowych z plików, ustawienie globalnych zmiennych, inicjalizację połączenia z bazą danych lub serwerem i wiele innych czynności.
- Przygotowanie (setup) – jest to specjalna funkcja przetrzymująca kod, który wywoływany jest między częścią inicjacji a faktycznym testem (część default).
- Część domyślna (default) – cały kod odpowiedzialny za wykonywanie operacji przez wirtualnego użytkownika. Z założenia, w momencie uruchomienia testu o dłuższym przebiegu niż jeden, funkcja default jest uruchamiana w kółko w porównaniu do części init, setup i teardown, które wywoływane są tylko raz.
- Zakończenie (teardown) – funkcja, która uruchamia się raz po zakończeniu testu. Służy między innymi do generowania niestandardowych raportów.
Ktoś mógłby powiedzieć, że część setup nie różni się od części init. Praktyczna różnica polega na tym, że sekcja init wykonuje się tylko raz dla każdego wirtualnego użytkownika. Natomiast setup i teardown wywołują się raz dla pełnego scenariusza obejmującego wszystkich wirtualnych użytkowników.
Implementacja stage’y wygląda następująco:
Konfiguracja
Konfigurowanie opcji (obiekt options) scenariuszy testowych może odbywać się na trzy sposoby:
- bezpośrednio w scenariuszu testowym,
- definiując odpowiednie zmienne środowiskowe,
- definiując parametr –config z odpowiednią ścieżką do pliku z konfiguracją.
Pierwszy ze sposobów jest dosyć toporny i w przypadku kilku środowisk – niezbyt elastyczny.
Drugi natomiast wymaga od nas wpisywania za każdym razem wielu parametrów, co może być nieczytelne. W niewielkich i szybkich projektach mogłoby to być wystarczające, natomiast do budowania całego frameworku – jest nieefektywne.
W związku z powyższym osobiście wybieram trzeci ze sposobów, który pozwala na zdefiniowanie kilku konfiguracji równocześnie dla kilku różnych środowisk. W ten sposób jesteśmy w stanie dopasować konfiguracje do stanu faktycznego środowiska.
Przyjrzyjmy się przykładowej konfiguracji w pliku config.json.
Po zdefiniowaniu konfiguracji możemy wskazać ją jako tą, która powinna zostać użyta w teście.
Typy modeli scenariuszy
Zanim przejdziemy do najcięższej kwestii dotyczącej konfiguracji k6 – executorów, musimy dokładnie zrozumieć koncept otwartego oraz zamkniętego modelu uruchomień (open and closed models). Są one podstawą do zaprojektowania executorów, czyli kontrolerów iteracji oraz wirtualnych użytkowników w testach.
Krótko mówiąc, w modelu zamkniętym iteracje wirtualnych użytkowników (VU) rozpoczynają się dopiero po zakończeniu ostatniej iteracji. Oznacza to, że nowe VU nie dołączają do testu, dopóki poprzednie iteracje nie zostaną zakończone. Z kolei w modelu otwartym VU pojawiają się niezależnie od zakończenia iteracji. Oznacza to, że nowe VU mogą dołączać do testu w dowolnym momencie, bez czekania na zakończenie poprzednich iteracji.
Oba modele mają swoje zastosowanie w różnych celach testowych.
Model zamknięty jest przydatny, gdy chcemy kontrolować liczbę VU i zapewnić, że test zostanie wykonany przez określoną liczbę VU bez interakcji z nowymi użytkownikami. Jest to szczególnie istotne w testach, które mają na celu ocenę wydajności systemu przy stałej liczbie użytkowników.
Z kolei model otwarty jest przydatny w scenariuszach, gdzie istotne jest testowanie skalowalności systemu i jego zdolności do obsługi dużej liczby użytkowników. Dzięki temu, że nowe VU mogą dołączać w dowolnym momencie, da się zaobserwować, jak system reaguje na dynamicznie zmieniające się obciążenie. Co stało za implementacją modelu otwartego?
W modelu zamkniętym dłuższe czasy odpowiedzi aplikacji oznaczają dłuższe iteracje i niższą częstotliwość pojawiania się nowych iteracji – i odwrotnie, w przypadku szybszych czasów reakcji. W literaturze dotyczącej testowania problem ten znany jest jako skoordynowane pomijanie. W związku z tym został wymyślony pomysł implementacji mechanizmu, który byłby bardziej niezależny od stanu aplikacji.
Typy executorów
Na podstawie opisanych powyżej modeli w k6 dostępnych jest siedem executorów. Jak już wcześniej wspomniałem, są to mechanizmy odpowiedzialne za manipulowanie ilością wirtualnych użytkowników (VU) oraz iteracjami. Rodzaj executora definiuje się w obiekcie options, który jest nam już znany. W zależności od wybranego rodzaju executora, będą dostępne różne konfiguracje. Nie będziemy tutaj omawiać każdej z nich. Na tym etapie ważne jest zrozumienie, kiedy należy użyć konkretnego executora.
Warto zauważyć, że aby skorzystać z danego executora, musimy go najpierw zdefiniować jako osobny scenariusz w polu scenario. To pole może zawierać kilka kolejnych następujących po sobie scenariuszy, co umożliwia dynamiczną manipulację obciążeniem.
Przejdźmy teraz po kolei przez każdy rodzaj executora wraz z przykładem kodu.
Shared iterations
Typ shared iterations to rodzaj executora, który równomiernie rozdziela iteracje pomiędzy określoną liczbę jednostek VU. Jest to szczególnie przydatne w przypadku testów regresji, gdy chcemy w prosty i szybki sposób ocenić wpływ dokonanych zmian w kodzie aplikacji.
Per VU iterations
Typ per-vu-iterations jest odpowiedzialny za przypisanie każdemu wirtualnemu użytkownikowi (VU) dokładnej liczbę iteracji do wykonania. Przy użyciu tego typu executora, jeśli zdefiniujemy na przykład 10 wirtualnych użytkowników z 30 iteracjami w ciągu maksymalnie 30 sekund, łączna liczba iteracji wyniesie 300 iteracji / 30 sekund, co daje 10 iteracji na sekundę.
Constant VUs
Dzięki opcji constant-vu możemy wskazać, że określona liczba wirtualnych użytkowników powinna kontynuować wykonywanie iteracji w nieskończoność przez określony czas. Oznacza to, że po zakończeniu jednej iteracji natychmiast rozpoczyna się kolejna iteracja do maksymalnego czasu zdefiniowanym w polu maxDuration.
Ramping VUs
Executor ramping-vus jest podobny do constant-vus, ale różni się od niego tym, że pozwala na bardziej zaawansowaną konfigurację testu. Główną rozbieżnością między nimi jest możliwość definiowania dodatkowych parametrów, które mają wpływ na przebieg testu. Przede wszystkim, testowanie jest podzielone na etapy (stages), którymi możemy manipulować. Dodatkowo, możemy określić początkową liczbę wirtualnych użytkowników oraz czas, po którym każda iteracja zostanie przerwana.
Test rozpoczyna się od dziesięciu jednoczesnych wirtualnych użytkowników, a ta liczba jest utrzymywana przez 20 sekund. Następnie, w ciągu 30 sekund, liczba użytkowników zostaje zmniejszona do zera. Jeśli w tym czasie trwa jakakolwiek iteracja, test jest przerywany (ze względu na zdefiniowane pole gracefulRampDown o wartości 0).
Constant arrival rate
Typ constant-arrival-rate wykonuje określoną liczbę iteracji w określonym czasie. Jest to otwarty model, który działa niezależnie od czasów odpowiedzi serwera. Oznacza to, że w przypadku spowolnienia odpowiedzi serwera, obciążenie będzie się zwiększać.
W powyższym przypadku wskazaliśmy wykonanie 30 iteracji na sekundę przez 30 sekund. Dodatkowo, zarezerwowaliśmy 30 wirtualnych użytkowników do wykonania testu.
Ramping arrival rate
ramping-arrival-rate działa podobnie jak poprzedni typ z tą różnicą, że wskazujemy w nim kilka etapów testu.
Externally controlled
Ostatnim z typów executora jest externally-controlled. Jest to kontroler, którego głównym zadaniem jest dynamiczne kontrolowanie działania testu (poprzez polecenia pause, resume, scale) z poziomu konsoli.
Podsumowanie
W dzisiejszej części omówiliśmy cykl życia testu w k6, typy executorów oraz porozmawialiśmy o konfiguracjach.
W kolejnej części zajmiemy się projektowaniem rzeczywistych przykładów scenariuszy testowych wydajnościowych oraz skupimy się na tworzeniu naszego frameworka testowego.
***
Jeśli jeszcze nie mieliście okazji zapoznać się z artykułami z serii o narzędziu k6, znajdziecie je tutaj:
Zostaw komentarz