Wydajność pod kontrolą z k6 – dobre praktyki, tworzenie zbiorów testów i konfiguracja

Dobre praktyki w programowaniu testów wydajnościowych w kontekście k6 obejmują szereg technik i podejść, które pomagają w efektywnym, wiarygodnym i skutecznym testowaniu wydajności aplikacji. Ponadto, dobre praktyki mają za zadanie wskazać, w jaki sposób tworzyć scenariusze testowe, aby były one łatwe w przygotowaniu i utrzymywaniu.

Upraszczanie scenariuszy testowych

Do tej pory skupialiśmy się na tworzeniu prostych scenariuszy testowych. Ich problem polega na tym, że mimo reużywania wielu elementów w scenariuszu, istnieje możliwość jego dalszego uproszczenia.

W tym celu wykorzystamy moduł httpx oparty na API k6. Zmienia on podejście do tworzenia scenariuszy testowych, sprawiając, że stają się bardziej intuicyjne i łatwiejsze w utrzymaniu. Jest też uznawany za jedną z wielu dobrych praktyk stosowanych w k6.

Podstawą korzystania z modułu httpx jest tworzenie sesji użytkownika. Przywodzi to na myśl podejście stosowane w narzędziach takich jak JMeter. Na obiekcie sesji możemy zdefiniować pola takie jak bazowy adres URL czy nagłówki, które zostaną dołączone do każdego kolejnego żądania. Dodatkowo, istnieje możliwość zdefiniowania ustawień globalnych, takich jak czas, po którym otrzymamy timeout w przypadku braku odpowiedzi aplikacji.

Przyjrzyjmy się przykładowemu scenariuszowi testowemu.

W powyższym przykładzie nie musimy już definiować za każdym razem nagłówków czy pełnego adresu URL aplikacji.

Pokrywanie żądaniami http zasobów statycznych

Inną ciekawą praktyką jest pokrywanie żądaniami HTTP zasobów statycznych. Pliki statyczne często zmieniają się na stronie, co może powodować uciążliwe edycje scenariuszy testowych przy każdej zmianie. W związku z tym, stworzymy katalog utils, w którym będziemy przechowywać nasze funkcje pomocnicze. Następnie, umieścimy w tym katalogu plik o nazwie helper.js z poniższą zawartością:

W pliku znajdują się dwie funkcje. Pierwsza z nich jest nam już znana i odpowiada za przerwanie działania tekstu. Druga funkcja natomiast służy do wydobycia wszystkich żądań dotyczących zasobów statycznych na stronie, a następnie wykonuje na nich żądanie GET. Ta funkcja może zostać rozbudowana o odpowiednie tagowanie i sprawdzanie czy domena należy do tych, które nas interesują.

Ponadto, moglibyśmy dodać możliwość wykonywania sześciu równoczesnych asynchronicznych wywołań statycznych zasobów równocześnie. Skutkowałoby to tym, że nasze testy jeszcze bardziej przypominałyby działanie przeglądarki.

Tworzenie zbioru testów

Bazując na wiedzy zdobytej z całej serii artykułów, spróbujmy utworzyć dwa scenariusze testowe, które będą oparte na aplikacji Sii. Załóżmy, że chcemy pokryć poniższe, uproszczone scenariusze testowe:

1. Scenariusz o nazwie search-article.js – odpowiada za wyszukiwanie artkułów na stronie, a następnie wejście w ten, który nas interesuje:

Implementacja w k6:

2. Scenariusz o nazwie search-training.js. – ten scenariusz wyszukuje interesujące nas szkolenie:

Implementacja w k6:

Konfiguracje scenariuszy

W poprzednich częściach omawialiśmy różne typy executorów stosowanych w k6. Jest to o tyle kluczowe, że w przypadku, kiedy chcielibyśmy zmienić rodzaj, konieczna będzie edycja kodu wewnątrz scenariusza. Inną możliwością jest duplikowanie tego samego scenariusza testowego.

Oba rozwiązania w długiej perspektywie są ciężkie w utrzymywaniu i niepraktyczne. W związku z tym wykorzystuje się różne konfiguracje testowe, które mogą zostać użyte uniwersalne dla każdego ze scenariuszy. Przyjrzyjmy się dwóm konfiguracjom:

1. smoke.json – konfiguracja odpowiedzialna za pojedynczy przebieg scenariusza:

2. load.json – docelowa konfiguracja zwiększająca obciążenie wraz z czasem trwania testu:

Definiowanie własnych poleceń

Ostatnim z etapów jest zdefiniowanie poleceń do uruchomienia docelowych scenariuszy. Skorzystamy ze znanego już nam mechanizmu z pliku konfiguracyjnego package.json:

Zdefiniowaliśmy cztery polecenia, z których pierwsze odpowiadają za uruchomienie dwóch testów z konfiguracją pojedynczej iteracji. W przypadku ostatnich, wykonanie dotyczy konfiguracji testów obciążeniowych.

Jednym z aspektów, który można ulepszyć, jest dynamiczne definiowanie ilości wirtualnych użytkowników wykorzystywanych w drugim z konfiguracji scenariuszy. To ulepszenie sprawiłoby, że konfiguracje stałyby się jeszcze bardziej uniwersalne dla każdego scenariusza. W końcu obciążenie stosowne dla pierwszego scenariusza będzie się najpewniej różnić od tego w drugim. Moglibyśmy to osiągnąć za pomocą zmiennych środowiskowych.

Podsumowanie

W szóstym już artykule serii artykułów o k6 omówiliśmy dobre praktyki pisania scenariuszy testowych w k6, stworzyliśmy przykładowe scenariusze testowe i utworzyliśmy konfiguracje do nich. Dzięki temu, mogliśmy zwiększyć uniwersalność frameworka testowego.

Nasza podróż z narzędziem jeszcze się nie kończy – w kolejnej części, z wykorzystaniem Grafany, InfluxDB oraz Dockera, rozwiniemy framework i dostosujemy go do naszych potrzeb, aby zapewnić jakość oraz niezawodność tworzonych aplikacji.

***

Jeśli jeszcze nie mieliście okazji zapoznać się z artykułami z serii o narzędziu k6, znajdziecie je tutaj:

• Wydajność pod kontrolą – co skłania mnie do wyboru k6?
• Wydajność pod kontrolą z k6 – nagrywanie, parametryzacja i uruchamianie pierwszego scenariusza testowego
• Wydajność pod kontrolą z k6 – metryki, progi jakości, tagowanie
• Wydajność pod kontrolą z k6 – dodatkowe konfiguracje, typy modeli scenariuszy oraz executorów
• Wydajność pod kontrolą z k6 – inicjalizacja frameworka

Ponadto, zachęcam do zapoznania się z Repozytorium projektu.