Rozwój aplikacji w ciągu ostatnich lat jest niezaprzeczalny. Aplikacje stały się bardziej zaawansowane i złożone, oferując użytkownikom coraz więcej funkcji i interakcji. Jednak ich rosnący poziom skomplikowania niesie ze sobą nowe wyzwania, które wymagają wprowadzenia innowacyjnych rozwiązań takich jak CI/CD (Continuous Integration/Continuous Deployment). Do ich wdrażania konieczne jest używanie narzędzi stworzonych na miarę naszych czasów.
Jednym z takich narzędzi jest k6 – rozwiązanie bogatsze niż inne narzędzia do przeprowadzania testów wydajnościowych.
Metryki
W narzędziu k6, metryki to liczbowe wartości lub statystyki, które pomagają analizować i monitorować wydajność aplikacji oraz zachowanie scenariuszy testowych. K6 oferuje dwa rodzaje metryk – wbudowane oraz tworzone przez użytkownika.
Wszystkie metryki mają jeden z czterech dostępnych typów:
- Counters – sumują wartości danych (np. liczba wykrytych błędów),
- Gauges – najmniejsze, największe i najnowsze wartości (np. liczba użytkowników wykorzystywanych w teście),
- Rates – częstotliwość występowania wartości niezerowych (np. liczba udanych asercji),
- Trend – statystyki dla wielu wartości, takie jak średnie czasy, percentyle, mediany czy średnie czasy (np. czasy odpowiedzi serwera).
Metryki te są przydatne nie tylko do podsumowań, ale również do wizualizacji przy użyciu zewnętrznych narzędzi takich jak Grafana.
Aby zdefiniować własne metryki, należy utworzyć instancję odpowiedniej klasy, do której można następnie dodać przykładowe wartości.
W trakcie trwania testu możemy operować na metrykach lub przesyłać w czasie rzeczywistym do baz danych takich jak InfluxDB.
Tagowanie
K6 wyposażono w funkcję tagowania, która umożliwia przypisanie etykiet lub kategorii do konkretnych elementów scenariusza testowego. Tagowanie pomaga w kategoryzacji poszczególnych elementów testu, co z kolei ułatwia filtrowanie wyników. Tagi są potężnym i elastycznym mechanizmem, który automatycznie dodaje metryki do odpowiednich elementów. Weźmy prosty przykład żądania HTTP jako ilustrację tego mechanizmu.
W powyższym przykładzie zdefiniowaliśmy tag o nazwie „name” o wartości GET / dla żądania strony głównej. Dzięki temu, automatycznie zostanie utworzona metryka o typie Trend, która będzie przechowywać dane dotyczące czasu odpowiedzi serwera, minimalnej i maksymalnej wartości, mediany i percentyli.
Na podstawie tagów łatwo możemy filtrować zgromadzone dane oraz wykonywać na nich zaawansowane operacje.
Nie wszystkie otagowane dane są automatycznie widoczne w podsumowaniu testu. W otwartoźródłowej wersji k6 jedynym sposobem na ich wyświetlenie jest zdefiniowanie odpowiednich progów jakości.
Czym są progi jakości?
Progi jakości (ang. Quality Gates) to punkty kontrolne lub kryteria, które muszą zostać spełnione przez oprogramowanie w trakcie procesu dostarczania, aby umożliwić jego kontynuację do kolejnej fazy. Są one wykorzystywane w procesie ciągłego dostarczania (Continuous Delivery) i ciągłego wdrażania (Continuous Deployment) jako mechanizm automatycznej kontroli jakości w cyklu życia oprogramowania.
Podczas procesu dostarczania oprogramowania, różne etapy takie jak: budowa, testowanie, wdrażanie i dostarczanie, muszą być monitorowane, a jakość oprogramowania musi być stale kontrolowana. Progi jakości są zestawem zdefiniowanych kryteriów, które określają, czy dany etap lub wersja oprogramowania są gotowe do przemieszczenia się do kolejnego etapu lub środowiska. Jeśli któryś z warunków nie zostanie spełniony, proces może zostać zatrzymany, a problem musi zostać naprawiony przed ponownym próbą kontynuacji.
W kontekście testów wydajnościowych, progów jakości będziemy używać do ustalenia wielkości metryk, które są akceptowalne. Będą to między innymi czasy odpowiedzi serwera, ilość wykrytych błędów w aplikacji czy ilość przesłanych danych. Tak jak omówiliśmy wcześniej, część z tagów jest widoczna w podsumowaniu testu.
Metryki te są ogólnym sposobem oceny stanu aplikacji. W k6 progi jakości definiuje się za pomocą obiektu options.
Utwórzmy prosty scenariusz, na podstawie którego będziemy mogli zobrazować progi jakości.
W powyższym przykładzie przyjęliśmy założenie, że 95% czasów odpowiedzi wszystkich żądań powinno wynosić poniżej 200 ms. Jeśli czas odpowiedzi przekroczy ten limit, test zostanie uznany za nieudany. Składnia progów jakości przedstawia się następująco:
Jak już wspomnieliśmy wcześniej, metryki mają różne typy, co oznacza, że metoda agregacji będzie różna dla każdego z typów. Poniżej znajduje się lista dostępnych typów metryk wraz z możliwymi agregacjami:
| Metryka | Metoda agregacji |
| Counter | count, rate |
| Gauge | value |
| Rate | rate |
| Trend | avg, min, max, med i p(N), gdzie N jest przedziałem z zakresu od 0.0 do 100, na przykład p(43.12). Dane te są w milisekundach |
Dodatkowo, jedna metryka może mieć kilka różnych założeń.
Wróćmy na chwilę do tagowania. Wspomnieliśmy wcześniej, że w podstawowym podsumowaniu tagi nie są widoczne. Spróbujmy teraz utworzyć próg jakości dla czasów żądań HTTP oznaczonych tagiem name o wartości GET /.
W ten sposób, po uruchomieniu testu, będziemy mogli zauważyć, że nasze otagowane żądanie zostało uwzględnione w podsumowaniu.
Podsumowanie
W dzisiejszej, już trzeciej, części serii omówiliśmy różne rodzaje metryk oraz tagowanie w k6. Ponadto, nauczyliśmy się, czym są oraz jak stosować progi jakości w testach. W naszym kolejnym wpisie skupimy się na rodzaju executorów oraz typach modeli scenariuszy.
Jeśli jeszcze nie mieliście okazji zapoznać się z artykułami z serii, znajdziecie je tutaj:
Zostaw komentarz