Aby skutecznie korzystać z narzędzi i frameworków, konieczne jest pełne zrozumienie ich fundamentalnych zasad i funkcjonalności. W dzisiejszej części serii „Wydajność pod kontrolą z k6” przedstawimy proces nagrywania scenariuszy testowych oraz sposoby ich parametryzacji. Omówimy również, jak grupować scenariusze i przygotować kod w taki sposób, aby był łatwy do długoterminowego utrzymania.
Nagrywanie scenariuszy testowych
Podstawowym elementem przygotowania scenariuszy testowych jest pokrycie żądań HTTP oraz operacji wykonywanych przez inne protokoły używane w aplikacji. Najczęstszy przypadek stanowi tworzenie prostych żądań do interfejsu API.
Istnieją dwa główne sposoby przygotowania scenariuszy:
- pierwszy z nich polega na ręcznym tworzeniu żądań na podstawie dokumentacji i widocznych żądań w przeglądarce,
- drugi sposób to nagrywanie ruchu sieciowego za pomocą dostępnego proxy.
Omówmy dwa najpopularniejsze sposoby nagrywania ruchu za pośrednictwem proxy:
- przy użyciu rozszerzenia dla k6 stworzonego przez twórców narzędzia k6,
- korzystając z pliku HAR z przeglądarki.
K6 Browser Recorder
K6 Browser Recorder to rozszerzenie dla przeglądarek Firefox i Chrome, które pozwala na generowanie skryptu w formacie k6 na podstawie ruchu wygenerowanego w przeglądarce. Jest to odpowiednik rozszerzenia Blazemeter dla narzędzia JMeter. Różnią się one jedynie tym, że dane są zapisywane w chmurze k6, zamiast lokalnie jak w przypadku Blazemetera.
Po kliknięciu przycisku „Start recording” i wykonaniu ścieżki testowej, należy zatrzymać nagrywanie, co przeniesie nas do panelu z zapisanym scenariuszem.
Z panelu scenariusza będziemy mieli możliwość wykonania różnych działań, takich jak wykluczenie żądań do domen trzecich, dodanie automatycznych opóźnień (sleeps) oraz uwzględnienie plików statycznych.
Nas interesują tylko żądania dotyczące głównej domeny, bez uwzględniania plików statycznych. Po kontynuacji procesu generacji, zostanie wygenerowany scenariusz testowy na podstawie wskazanej konfiguracji.
W obecnej postaci wiele elementów, takich jak nagłówki, jest powtarzalnych. Ponadto, brakuje asercji i odpowiedniego nazewnictwa. Przed przystąpieniem do edycji omówimy jednak drugi sposób nagrywania scenariuszy testowych.
Konwersja plików HAR
Deweloperzy Grafany przewidzieli możliwość generowania scenariuszy testowych z innych źródeł niż przeglądarki Firefox i Chrome. Wszystkie przeglądarki generują ruch sieciowy podczas interakcji użytkownika na stronie internetowej. Ten ruch można zapisywać w formacie HAR (HTTP Archive).
Plik HAR zawiera:
- opis żądań HTTP,
- odpowiedzi,
- pliki zasobów,
- czasy ładowania,
- błędy i inne metadane związane z interakcjami.
Pliki HAR można generować za pomocą różnych narzędzi diagnostycznych i deweloperskich, takich jak narzędzia deweloperskie wbudowane w przeglądarki internetowe, serwery proxy lub narzędzia do testowania wydajności stron internetowych. Na przykład, w przeglądarce Firefox możemy ściągnąć plik HAR z żądaniami z zakładki „Network” w narzędziach deweloperskich.
Przykładowa część pliku HAR ma następujący format:
Deweloperzy z Grafana Labs stworzyli narzędzie o nazwie „har-to-k6”, które umożliwia konwersję plików w formacie HAR na scenariusze k6. Aby je zainstalować, należy skorzystać z menedżera pakietów Node.js.
Po pomyślnej instalacji, możemy użyć konwertera do przetworzenia pobranego pliku w formacie HAR.
Po użyciu narzędzia „har-to-k6” zostanie wygenerowany scenariusz testowy k6 o nazwie scenario.js. Oto przykładowa zawartość wygenerowanego skryptu:
W porównaniu z k6 Browser Recorder, korzystanie z konwertera „har-to-k6” jest mniej elastyczne. Struktura pliku HAR nie ma swojej pełnej dokumentacji, co czasami prowadzi do problemów z nieobsłużonymi polami w narzędziach. Świadczyć o tym może niedawno wykryty problem w znanym narzędziu „mitmproxy”.
Omówienie wygenerowanego scenariusza
Po wygenerowaniu scenariusza testowego, konieczne jest jego edytowanie i dostosowanie. Wróćmy do przykładowego scenariusza utworzonego przez rozszerzenie k6 Browser, aby go omówić.
Scenariusz w powyższym przypadku składa się z dwóch głównych elementów. Pierwszym z nich jest obiekt options.
Definiując obiekt options, możemy określić różne parametry, takie jak:
- liczba równocześnie działających wirtualnych użytkowników (vus),
- czas trwania testu (duration),
- progi jakości (thresholds).
Szczegółowo omówimy ten obiekt i jego możliwości w kolejnych częściach serii. Obecnie istnieje ponad 50 różnych opcji, które można zdefiniować.
Drugim elementem wygenerowanego scenariusza jest funkcja main(). To w niej definiujemy żądania HTTP i operacje na danych.
Parametryzacja
Aktualnie jednym z najczęstszych błędów jest brak możliwości wielokrotnego wykorzystania nagłówków HTTP i adresów URL. Aby temu zaradzić, możemy nieco zmodyfikować scenariusz, aby nie było konieczne ponowne definiowanie ich przy każdym żądaniu HTTP.
Kolejnym istotnym elementem testu jest czas interakcji między poszczególnymi częściami strony. W przypadku wygenerowanego scenariusza, czas spoczynku użytkownika wynosi 9,1s oraz 9,6s. Zakładamy, że czas reakcji może wahać się od 3 do 10 sekund.
Na tym etapie spróbujmy również wprowadzić nieco losowości przy otwieraniu odpowiednich artykułów. W ramach tego testu zakładamy, że istnieje jedynie pięć artykułów, które są stałe. Aby wprowadzić losowość, możemy skorzystać z biblioteki k6-utils.
Do wydobycia danych z aplikacji, takich jak nazwa artykułu czy adres źródłowy, skorzystaliśmy z wbudowanych funkcji do manipulacji plikami HTML. Te funkcje mogą przypominać inne, znane z frameworków do automatycznego testowania funkcjonalnego, takich jak Cypress czy Selenium.
Zwróćmy uwagę na umiejscowienie zmiennych articleName i articleHref – dlaczego są one zdefiniowane przed grupą? Porozmawiajmy o tym nieco szerzej.
Grupowanie żądań
Aby utrzymać spójność w krokach testowych, warto stosować grupowanie. Można to porównać do kontrolerów transakcji w JMeterze. W k6 wszystkie zmienne zdefiniowane w grupie są dostępne tylko w jej obrębie. Na przykład, jeśli zdefiniujemy articleName wewnątrz drugiej grupy, jego wartość nie będzie dostępna w trzeciej grupie.
Grupowanie jest również przydatne w przypadku, gdy chcemy gromadzić kilka żądań wykonanych na tym samym etapie testu. Na przykład, gdy wchodzimy na stronę główną, często wykonujemy kilka równoległych żądań HTTP. W takim przypadku wszystkie te żądania mogą być w jednej grupie o nazwie „Open main page”. Wprowadźmy zmianę nazewnictwa w naszym teście.
W ten sposób będziemy mogli utrzymywać testy w prosty sposób, nawet gdy dodamy lub usuniemy odpowiednie żądania. Nie będzie problemu z ich identyfikacją, a ponadto, jak przekonamy się w kolejnych częściach serii artykułów, ułatwi to analizę w narzędziach trzecich.
Asercje i checki
Zwróćmy uwagę na brak asercji w naszym scenariuszu testowym. Asercja w programowaniu to mechanizm służący do sprawdzania warunków lub założeń podczas wykonywania programu. Jest to sposób weryfikacji, czy pewne oczekiwania są spełnione, co pomaga w wykrywaniu błędów. W przypadku nieprawidłowej asercji podczas testu, jego uruchomienie jest przerywane.
W implementacji narzędzia k6 zrezygnowano z asercji na rzecz checków. Checki podobne do asercji, z tą różnicą, że test nie jest domyślnie przerywany po otrzymaniu błędnej odpowiedzi.
Checki przyjmują jako pierwszy argument obiekt response. Obiekt ten zawiera wiele pól, na których można wykonywać asercje.
Najczęściej używane w nich pola to:
- status serwera (status),
- treść odpowiedzi (body),
- nagłówki odpowiedzi (headers).
Zdefiniujmy przykładowy check, który sprawdza, czy status odpowiedzi jest poprawny, a treść odpowiedzi zawiera oczekiwany tekst.
Wykorzystując powyższy mechanizm, edytujmy nasz skrypt.
Jeśli zdecydujemy się na użycie tradycyjnej asercji, będziemy musieli skorzystać z własnej, zdefiniowanej funkcji. W przeciwieństwie do wbudowanej funkcji check, która zwraca true lub false, możemy wykorzystać tę informację, aby przerwać bieżący przebieg testu (goroutine) i rozpocząć nowy.
Do tego celu możemy użyć wbudowanej funkcji fail.
Podsumowanie
Niniejszy artykuł wprowadził nas w podstawowe funkcje narzędzia k6. Nauczyliśmy się nagrywać przypadki testowe, parametryzować je i tworzyć podstawowy scenariusz testowy. W kolejnych częściach skupimy się na ustawianiu progów jakości, omówimy tagowanie oraz poznamy różne rodzaje metryk.
Jeżeli nie mieliście okazji przeczytać poprzedniej części wprowadzającej, zachęcamy do zapoznania się z nią. Znajdziecie tam więcej informacji na temat k6 oraz motywacji do wyboru tego narzędzia.
W kolejnych artykułach będziemy kontynuować rozwijanie naszego scenariusza testowego, aby dostosować go do bardziej zaawansowanych potrzeb i zagłębić się w funkcjonalności k6. Zachęcamy do śledzenia naszej serii, aby dowiedzieć się więcej o tej potężnej platformie do testowania wydajności.
Przydatne linki
Zostaw komentarz