JMeter. Testujemy odpowied藕 serwera 馃懆馃従鈥嶐煔

JMeter – czyli narz臋dzie do testowania wydajno艣ci aplikacji – mo偶e r贸wnie偶 by膰 u偶yty w testach funkcjonalnych. Mog膮 wyst膮pic sytuacje, kiedy b臋dziesz chcia艂(a) napisa膰 test kt贸ry przetestuje czy Twoje API zwraca to co powinno. Dobrymi przyk艂adami s膮 testy sprawdzaj膮ce wynik odpowiedzi, status kodu czy te偶 ca艂a sekwencja zdarze艅.


Cze艣膰 馃檪

Dzisiejszy artyku艂 jest kontynuacj膮 serii o narz臋dziu JMeter i testowaniu. Pierwszy artyku艂 – teoretyczny – by艂 o podstawach test贸w wydajno艣ciowych, a w ostatnim opisywa艂em podstawowe funkcje JMetera – tak aby m贸c odpali膰 pierwsze testy.

W dzisiejszym artykule napiszemy kilka scenariuszy do publicznego API do test贸w, dzi艣 dowiesz si臋


Co mo偶na sprawdza膰 przy pomocy JMetera

JMeter udost臋pnia kilka ciekawych asercji. Jednak z punktu widzenia typowego developera – g艂贸wnie korzysta si臋 ze znacznie zaw臋偶onego grona asercji (response, duration, size).

  • Response Assertionu偶ywana najcz臋艣ciej. Pozwala na sprawdzenie mi臋dzy innymi odpowiedzi wiadomo艣ci, zwracane kody, nag艂贸wki.
  • Duration Assertionprosta i przydatna asercja, szczeg贸lnie w testach wydajno艣ciowych. Weryfikuje czy dany test zako艅czy艂 si臋 w zadanym czasie. Je偶eli wprowadzony czas zostanie przekroczony asercja zwr贸ci b艂膮d.
  • Size assertion – sprawdza wielko艣膰 odpowiedzi czy jest zgodna z oczekiwan膮 (mniejsza/wi臋ksza/r贸wna/r贸偶na). Mo偶emy sprawdzi膰 zar贸wno ca艂膮 odpowied藕 jak te偶 poszczeg贸lne komponenty, np. tylko headery czy te偶 cia艂o odpowiedzi. Warto艣膰 jest definiowana w bajtach!
  • XML Assertion – waliduje czy odpowied藕 posiada poprawnie sformatowany dokument XML. Jest to walidacja poprawno艣ci dokumentu tylko pod k膮tem poprawno艣ci tag贸w XML itp. Walidacja nie obejmuje schemy, DTD czy te偶 innych walidacji!
  • HTML Assertion – sprawdza poprawno艣膰 zwr贸conego pliku HTML.

Jak sprawdzanie wynik贸w wp艂ywa na wydajno艣膰 test贸w

Pomimo i偶 sprawdzanie ka偶dej zwr贸conej odpowiedzi mo偶e by膰 kusz膮ce nale偶y pami臋ta膰, 偶e ka偶da asercja ma sw贸j koszt w postaci dodatkowego obci膮偶enia CPU czy te偶 pami臋ci. Je偶eli masz zamiar wykonywa膰 testy wydajno艣ciowe to zastan贸w si臋 wcze艣niej czy aby na 100% potrzebujesz sprawdza膰 konkretn膮 rzecz! Je偶eli tak – to ogranicz sprawdzanie odpowiedzi tylko do najwa偶niejszych!

AssertionCPU/Memory Usage
Response Assertion艢rednie
Duration AssertionNiskie
Size AssertionNiskie
XML AssertionWysokie
Beanshell AssertionZmienne (zale偶ne od skryptu)
MD5Hex AssertionNiskie
HTML AssertionWysokie
XPath AssertionWysokie
XML Schema AssertionWysokie
JSR223 AssertionZmienne (zale偶ne od skryptu)
Compare AssertionWysokie
SMIME Assertion艢rednie
Json AssertionWysokie

Tabelka pochodzi z tego wpisu. Do kt贸rego zreszt膮 zach臋cam je偶eli chcesz wi臋cej szczeg贸艂贸w o asercjach w JMeter.


Testujemy sprawdzenie odpowiedzi API

Zacznijmy od czego艣 prostego. Chcemy zweryfikowa膰 偶e dost臋p do naszego API faktycznie wymaga uwierzytelnienia. B臋dziemy pr贸bowali wywo艂a膰 jeden z endpoint贸w (gorest.co.in//public-api/users) bez u偶ycia authorization tokenu.

Przy normalnym strzale bez u偶ycia autoryzacji dostajemy taki komunikat:

Naszym zadaniem jest wi臋c sprawdzenie czy status cia艂a odpowiedzi (result.status) jest r贸wny 401. Kluczowe jest to, 偶e sprawdzamy status cia艂a odpowiedzi, nie status zwracanego kodu! Nasz request zawsze zwraca status 200.

No to zaczynamy. Tworzymy prost膮 struktur臋 – thread group, http request sampler, dwa listenery (view result tree i assertion results). Do HTTP Request Samplera dodajemy 2 asercje (response i json – json tylko w celach pokazowych, 偶e taka opcja jest). Proste ustawienia – walniemy 2 requesty i sprawdzamy czy status si臋 zgadza.

O ile wynik pozytywnej odpowiedzi nie jest specjalnie ciekawy bo po prostu zwr贸ci nam 偶e wszystko si臋 uda艂o. O tyle je偶eli w oczekiwanych statusach zmieni臋 z 401 na 402, to mam szybki feedback ze strony narz臋dzia co dok艂adnie posz艂o nie tak.

Teraz to ju偶 jest Twoja decyzja pod jakim k膮tem projektujesz testy. Je偶eli testujesz funkcjonalno艣膰 e2e, chcesz mie膰 szczeg贸艂y, co dok艂adnie posz艂o nie tak – projektuj testy tak aby wyci膮gn膮膰 z nich jak najwi臋cej informacji. Pobaw si臋 nieco API Jmetera zanim napiszesz finalny test. Zauwa偶 np. 偶e przy JSON Responsie w szczeg贸艂ach mam informacj臋 co zosta艂o zwr贸cone, natomiast w text response tej informacji ju偶 nie ma. Takie szczeg贸liki mog膮 p贸藕niej by膰 przydatne gdy faktycznie jakie艣 testy zaczn膮 si臋 sypa膰 a Ty chcesz w miar臋 przyst臋pnie znale藕膰 co jest nie tak.


Przetestujmy ograniczenie

Tak jak w poprzednim akapicie – zn贸w b臋dziemy atakowali te same API.

GoRest ogranicza (umo偶liwia ograniecznie) request贸w jakie mo偶emy wys艂a膰 do API w przeci膮gu minuty. Maksymalnie mo偶emy ustawi膰 60 偶膮da艅 na minut臋. Teraz ustawimy 偶eby nasze API by艂o atakowane przez 10 u偶ytkownik贸w, 5 razy. Czyli razem 100 request贸w (ka偶dy test to 2 requesty – jeden do pobrania wszystkich u偶ytkownik贸w i drugi do pobrania konkretnego).

I tak si臋 prezentuj膮 wyniki:

Zauwa偶 偶e w wyniku Assertion Result, odpowiedzi jakie dostajemy (pomimo u偶ycia Response Assertion) w miar臋 dok艂adnie wskazuj膮 nam problem, tzn. wy艣wietlaj膮 co by艂o oczekiwane i co przysz艂o. Dzieje si臋 tak dlatego, 偶e w Response Assertion u偶yli艣my Custom failure message, gdzie u偶ywamy warto艣ci odpowiedzi z JSON Extractora. Oczywi艣cie mo偶na by by艂o doda膰 bardziej szczeg贸艂owy output odpowiedzi w przypadku b艂臋du – ja jednak skupi艂em si臋 tylko na tym aby zaprezentowa膰 Ci, 偶e jest taka mo偶liwo艣膰.

Taki jeszcze ma艂y tip do tego wszystkiego. Je偶eli Twoim celem jest zwalidowanie poprawno艣ci dzia艂ania ca艂ego flow, gdzie ka偶dy kolejny request jest zale偶ny od poprawno艣ci poprzednich krok贸w to pami臋taj aby w艂膮czy膰 opcj臋 Start Next Thread Loop (opcja w Thread Group). Dzi臋ki temu, je偶eli kt贸ra艣 z Twoich asercji zg艂osi b艂膮d – flow aktualngo w膮tku zostanie przerwane, przez co unikniesz b艂臋d贸w, kt贸re w danym te艣cie najprawdopodobniej by si臋 pojawi艂y.

Jako przyk艂ad, za艂贸偶my, 偶e testujesz zakup w sklepie internetowym. Tw贸j test wymaga艂 uwierzytelnienia si臋, nast臋pnie wybrania produkt贸w dost臋pnych tylko dla zalogowanych klient贸w a p贸藕niej ca艂y proces zakupu. Co艣 jednak posz艂o nie tak w trakcie uwierzytelniania – asercja wywali艂a b艂膮d. Je偶eli zaznaczy艂e艣 Start Next Thread Loop to dostaniesz znacznie mniej wynik贸w do analizy, bo kolejne requesty po prostu si臋 nie wykonaj膮. W przeciwnym wypadku ca艂e f艂ow zostanie wykonane, co oczywi艣cie b臋dzie powodowa膰 tylko nowe b艂臋dy.


Podsumowanie

JMeter jest pot臋偶nym narz臋dziem i to bez dw贸ch zda艅. Pozwala na pisanie test贸w funkcjonalnych pod k膮tem weryfikacji API i w pe艂ni spe艂nia w tym swoje zadanie. Gdyby艣 chcia艂 sam potestowa膰 to, co opisa艂em w artykule, to na Githuba wrzuci艂em test (pami臋taj aby w HTTP Header Managerze podmieni膰 API key).

Je偶eli temat Ci臋 zainteresowa艂 bardziej – bo to co ja opisa艂em w artykule to jest to tylko wierzcho艂ek g贸ry lodowej – to odsy艂am Ci臋 do link贸w z kt贸rych sam korzysta艂em przy tworzeniu tego wpisu:


Za tydzie艅

B臋dzie co艣 nietypowego – czyli ma艂y agregator (moim zdaniem) najlepszych 藕r贸de艂 do nauki programowania na naszym polskim podw贸rku. Ps. kiedy post b臋dzie si臋 publikowa艂, ja b臋d臋 zdobywa艂 Rysy (albo przynajmniej ich podn贸偶ek 馃榾 )

5 1 vote
Article Rating
Subscribe
Powiadom o
guest
0 komentarzy
Inline Feedbacks
View all comments