Cześć 

W dzisiejszym artykule:

• Testy End to End – czym są?
• Kiedy i czy warto pisać testy E2E?
• Testy E2E moim okiem

Testy End to End – czym są?

Testy end to end (E2E), akceptacyjne, czy też funkcjonalne, to wszystko sprowadza się do jednego – do testów weryfikujących pewne zachowanie aplikacji całościowo. Ten rodzaj testowania weryfikuje funkcjonalność od początku do końca (end to end), symulując zachowanie użytkowników lub procesu. W pozostałej części artykułu, słownictwo: testy e2e, akceptacyjne czy funkcjonalne, będę używał wymiennie.

Jeżeli nie masz doświadczenia z tego rodzaju testami, to możesz wyobrazić to sobie jako użytkownika klikającego twoją aplikację i weryfikującego czy zostały spełnione założone wyniki. Oczywiście różnica jest taka, że w przypadku testów automatycznych, kroki te wykonują się same i mogą być odpalone w dowolnym momencie.

Wydaje się to być idealnym rozwiązaniem? No nie do końca. Trzeba pamiętać, że testy te, po pierwsze trzeba napisać. A i to nie wszystko.. bo jeżeli pracujesz w tej branży nieco dłużej to wiesz doskonale, że aplikacje ewoluują. Z czasem będą dochodziły nowe wymagania, które trzeba zaimplementować. Obecna implementacja też nie jest wieczna. Pod wpływem zmieniających się trendów ona również wymaga konserwacji (lub po prostu refaktoru), a co za tym idzie – musimy uwzglednić przy tym testy, które już posiadamy.

Dlaczego testy E2E są popularne / zachęcające?

Nurt testów akceptacyjnych zyskał dużą popularność szczególnie wśród ludzi z biznesu, ale nie tylko. Nawet słynna piramida testów uwzględnia ten rodzaj weryfikacji. Dlaczego tak jest? Z punktu widzenia biznesu zachęcająca jest świadomość, że taki test symuluje realne zachowanie użytkownika. A to prowadzi do kolejnej zalety, czyli poczucia bezpieczeństwa, że dany scenariusz działa prawidłowo. Z punktu widzenia developera plusem jest ich łatwość pisania – nie ma potrzeby pisania mocków lub symulowania komunikacji z bazą danych czy brokerem wiadomości.

Jakie są wady testowania E2E?

Oprócz wcześniej już wspomnianego wysiłku potrzebnego na napisanie takich testów i ich utrzymanie jedną z poważniejszych wad jest długość czasu wykonania. Nikt nie lubi oczekiwania, a testy e2e dodają solidną cegłę do tego procesu. Oczywiste jest, że lokalnie nie będziemy tych testów odpalać co chwilę (o ile w ogóle je odpalimy), natomiast przed wdrożeniem na konkretne środowisko dobrze byłoby się upewnić, że wszystko działa. I dzięki takim testom nasz pipeline wdrożeniowy właśnie się wydłuża.

Kolejnymi wadami są trudność debugowania oraz fałszywe negatywy. Zacznijmy od pierwszego. Załóżmy, że napisałeś test e2e dla funkcjonalności zakupu produktu w sklepie. Proces polegał na zalogowaniu się na konto, dodanie produktu do koszyka a następnie sfinalizowanie zakupu (dokonanie płatności). Test się wyłożył, ale gdzie dokładnie? Testy akceptacyjne nie pozwolą na szybką izolację wystąpienia problemu. Będziesz zmuszony odpalić test jeszcze raz lub samemu wykonać dany scenariusz, żeby wiedzieć co poszło nie tak. A i to sprawi, że będziesz musiał zaglądnąć w logi serwera, aby zweryfikować co dokładnie poszło nie tak.

Przechodząc do fałszywych negatywów. Ponownie załóżmy ten sam proces zakupu produktu. Twoja aplikacja działa poprawnie natomiast jeden z mikroserwisów z katalogiem produktów wyłożył się przed testami i znów test nie przeszedł. Ponownie wykorzystujesz czas na znalezienie błędu w aplikacji, którego de’facto nie ma.

Kiedy i czy warto pisać testy E2E?

Jeżeli miałbym odpowiadać na takie pytanie, to moją odpowiedzią byłoby pytanie w przeciwnym kierunku: jaki jest kluczowy scenariusz biznesowy? Czyli, jaka jest wartość biznesowa. Ile firma zarabia na danej funkcji, czy błędne działanie może spowodować istotne straty, jak często funkcja jest używana.

Szczera rozmowa z biznesem na ten temat pozwoli nam napisać mniej testów. Testy te będą jednak krytyczne i dadzą komfort psychiczny zarówno w kwesti poprawności jak i faktu, że nasz deployment nie ciągnie się godzinami. Bardzo ważne jest aby umieć zadawać dociekliwe pytania przy rozmowie z biznesem, np. co się stanie, z punktu widzenia biznesu, jeżeli ta funkcjonalność nie będzie miała testu akceptacyjnego? (jeżeli był nacisk aby taki test napisać)

Na pytanie z tego akapitu nie da się odpowiedzieć w sposób jednoznaczny. Jeżeli będziesz mieć kiedykolwiek możliwość decyzji o pisaniu takich testów, to staraj się patrzeć na to przez pryzmat wartości biznesowej. Jeżeli masz zespół testerów, który manualnie kilka scenariusze, to może faktycznie warto byłoby to zautomatyzować. Napisać kilka przykładowych scenariuszy i zobaczyć jaką wartość to przyniesie. Wtedy to testerzy mogliby zająć się utrzymywaniem testów. Na początku będzie ciężko bo trzeba nauczyć się nowych narzędzi i przyzwyczaić wszystkich do pewnych zmian, ale z czasem może (nie musi) przynieść to dużą wartość biznesową. Jaką? Jeżeli klient będzie chciał wdrożyć nową wersję produktu, to z czasem wystarczy odpalenie testów aby przetestować krytyczne ścieżki i z dużym komfortem możemy to wdrażać.

Testy E2E moim okiem

Rzeczywistość jest taka, że na ilu projektach byłem, to testów end to end nie musiałem pisać nigdy. Nie oznacza to, że ich nie pisałem. Pojawiały się próby, gdzie biznes chciał aby takie testy się pojawiły, ale zazwyczaj kończyło się to tylko na próbach.

Moim zdaniem backend developer powinien umieć napisać testy end to end. Powinien znać narzędzia, które wspomagają ten proces. A czy powinien pisać? To już zależy od klienta dla którego pracujemy. Dla krytycznych funkcjonalności, które rzadko się zmieniają a przynoszą dużą wartość powinniśmy przynajmniej rozważyć takie testy. Jednak wydaje mi się, że testy jednostkowe oraz integracyjne w dużej mierze są wystarczające a dodatkowa warstwa testów wcale nie okazuje się tak bardzo pomocna.

Pisanie testów akceptacyjnych to nie jest tylko wyklepanie pewnego scenariusza. To też umiejętność miękka. Jako osoba pisząca scenariusz muszę wejść w buty klienta (osoby, która korzysta z oprogramowania, które rozwijamy), a najlepiej jest to zrobić przez rozmowę. A sama umiejętność rozmowy oraz wyciąganie kluczowych informacji to już soft skill . Warto też pamiętać, że jeżeli będziesz umiał pisać testy e2e, to Twoja wartość rośnie. Jeżeli klient chce na projekcie takie testy to Ty, jako osoba majaca tą umiejętność będziesz bardziej atrakcyjny. To natomiast, przy odpowiedniej negocjacji przekłada się na większe pieniądze. W końcu nie pracujemy charytatywnie…

Podsumowanie

Nie da się stwierdzić jednoznacznie czy warto pisać testy e2e. Odpowiedź na to pytanie brzmi to zależy. Jest to zależne od klienta i wartości biznesowej, jaką dany test ma spełnić. Jako developerzy powinniśmy starać się ochładzać zapędy biznesowe do pisania tego rodzaju testów. Nie mówię, że całkowicie mamy ich nie pisać, ale zawsze powinniśmy przeprowadzić szczerą rozmowę z ludźmi na szczeblu, aby się dowiedzieć czy faktycznie dany scenariusz przynosi wartość.

Źródła:

• 3 typy testów, które musisz zrozumieć, by robić efektywne TDD
• Kurs SmartTesting.pl

Za tydzień

Już ostatni wpis w tym roku!! Porozmawiamy o springu i adnotacjach do wstrzykiwania zależności.

Artykuł Testy E2E Dla Backend Developera 🙄. Czy warto❓❓ pochodzi z serwisu bdabek.pl.

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
• Jak sprawdzanie wyników wpływa na wydajność testów
• Testujemy sprawdzenie odpowiedzi API
• Przetestujmy ograniczenie

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 Assertion – używana najczęściej. Pozwala na sprawdzenie między innymi odpowiedzi wiadomości, zwracane kody, nagłówki.
• Duration Assertion –prosta 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!

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:

{
    "_meta": {
        "success": false,
        "code": 401,
        "message": "Authentication failed."
    },
    "result": {
        "name": "Unauthorized",
        "message": "Your request was made with invalid credentials.",
        "code": 0,
        "status": 401
    }
}

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:

• User’s Manual – oficjalna dokumentacja JMeter
• JMETER ASSERTIONS: THE ULTIMATE GUIDE
• How to use Assertions in JMeter (Response Example) – krótko i treściwie

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 )

Artykuł JMeter. Testujemy odpowiedź serwera 👨🏾‍🚀 pochodzi z serwisu bdabek.pl.

W tym artykule skupimy się na funkcjach używanych przy testowaniu aplikacji webowych. Po przeczytaniu dzisiejszego wpisu będziesz wiedział:

• Co to Test Plan
• Czym jest Thread Group
• Do czego służą Samplers
• Jak gromadzić i czytać Metryki

A żebyś lepiej rozumiał co się dzieje przetestujemy wydajność dobrze wszystkim znanego serwisu google.com.

Nie traktuj tego wyniku jako wyznacznika – jest on zależny od kilku czynników jak np. obecne obciążenie serwera, mojej prędkości Internetu,  CPU, itd…

Co to Test Plan

Po pobraniu i uruchomieniu JMeter na swoim komputerze pojawi Ci się następujące okno

Pierwsze co rzuca się w oczy to Test Plan. Jest to po prostu root trzymający wszystkie elementy testów. Możesz go nazwać, choć ja nie spotkałem się jakoś specjalnie z tym aby plany testów były nazywane. Zazwyczaj poszczególne thread group’y dostają odpowiednią nazwę.

Wydaje mi się, że dobrą praktyką jest aby taki plan testów nie zawierał w sobie za dużo testów. No i można zapytać co to znaczy nie za dużo?? Nie umiem na to odpowiedzieć – działaj według swojego gustu. Jeżeli widzisz, że dany test będzie testował ten sam kontekst to moim zdaniem jak najbardziej możesz dołożyć do tego samego planu. Natomiast, jeżeli widzisz że zaczynasz testować inny serwis / obszar to zastanów się czy nie lepiej stworzyć osobny plan testów właśnie dla tego przypadku (i bardzo możliwe, że innych, które mogą się pojawić).

Czym jest Thread Group

Technicznie, Thread Group jest zbiorem wątków wykonujących konkretny scenariusz testowy. Swoim językiem, Thread Group jest użytkownikiem lub grupą użytkowników którzy wykonują ten sam scenariusz testowy.

W JMeter aby stworzyć nowy Thread Group wystarczy kliknąć prawy przycisk myszy na Test Plan, a później Add >> Threads (Users) >> Thread Group. Efektem będzie takie okno

To co jest dla nas interesujące, to Thread Properties:

• Number of Threads (users): reprezentuje całkowitą liczbę użytkowników, którzy będą wykonywali dany scenariusz testowy.
• Ramp-up period (seconds): informuje JMeter, jak długo trzeba czekać aby wszyscy użytkownicy wykonywali testy. Jeśli wprowadzimy 100 użytkownków i ustawimy ramp-up na 50 sekund, to JMeter będzie potrzebował 50 sekund na uruchomienie wszystkich 100 wątków. Czyli co każdą sekundę będą przybywały 2 nowe działające wątki.
  • Wzór na obliczenie ilości nowych użytkownków: Ramp-up Period / Number of Threads. Np. 120/30 = 4 – czyli co 4 sekundy dochodzi nam nowy użytkownik testujący nas scenariusz.
  • Ramp-up needs to be long enough to avoid too large a work-load at the start of a test, and short enough that the last threads start running before the first ones finish (unless one wants that to happen). – dokumentacja JMeter.
• Loop Count: liczba wykonań. Jeśli Loop Count wynosi 2, a liczba wątków 100, to test zostanie uruchomiony 200 razy. Jeśli zostanie zaznaczony checkbox Infinite, nowe wątki będą się uruchamiać do momentu zatrzymania testów.
• Same user on each iteration: pozwala na 'reużycie’ ciasteczek, jeżeli w testach użyty jest HTTP Coockie Manager.
  • Ciasteczka otrzymywane są w pierwszej odpowiedzi a później reużywalne w następnych requestach.

O pozostałych opcjach (Delay Thread creation until needed, Specify Thread lifetime) możesz doczytać googlując je sobie. Na tę chwilę nie jest Ci to potrzebne.

Do przetestowania google.com, użyjemy 100 użytkowników, którzy będą przychodzić co sekundę (ramp-up = 100) i powtórzą akcję 10 razy – czyli łącznie pojedyczny request zostanie uruchomiony 1000 razy.

Do czego służą Samplers

Samplers (próbniki??) są odpowiednikami kontrolerów – wysyłają żadania do serwera i czekają na odpowiedź. Są one przetwarzane w kolejności, w jakiej pojawiają się w drzewie struktury. Można testować wiele usług/protokołów (smtp, ftp, tcp, ldap, jdbc, …) – nas interesuje HTTP Request.

W naszym przypadku chcemy przetestować dwa żądania do usługi google – wyszukiwarkę (google.com) oraz kalendarz (google.com/calendar). Po utworzeniu nowego Sampler’a – HTTP Request – pojawia nam się okno do którego wprowadzamy adres serwera (Server Name or IP), który będziemy testować i ewentualnie ścieżkę (Path) pod jaką znajduje się usługa (w przypadku wyszukiwarki google dajemy tylko adres serwera, dla kalendarza trzeba dodać jeszcze ścieżkę – calendar – jak na screenie)

Jak gromadzić i czytać Metryki

Samo wykonanie testu niewiele nam daje jeżeli nie umiemy określić jego wyniku. Ważne jest aby przed uruchomieniem testów przemyśleć co chcemy mierzyć – pisałem o tym tydzień temu. Jak już znamy wymagania z pomocą przychodzą nam Listenery. Możemy je utworzyć na dowolnym elemencie w naszym drzewie (test plan, thread group, sampler), będą one gromadziły dane z poziomu na którym są i poniższych. Istnieje kilka różnych listenerów, ale to co jest ważne – zapisują one te same dane, różnica polega na tym w jaki sposób te dane są prezentowane.

Nie będziemy wchodzić w szczegóły każdego widoku – zobaczmy jak dla naszego testu wygląda Graph Result i Summary Report (test był wykonany na hot spocie przy słabym połączeniu).

Przy testowaniu wydajności aplikacji webowych to co może nas szczególnie interesować to:

• Throughput – przedstawia jak wydajny jest serwer. Im większa jest przepustowość tym lepiej. Przepustowość jest obliczana na podstawie ilości requestów dzielonej przez całkowity czas wykonania i jest wyrażona w KB/sec.
• Standard Deviation – odchylenie standardowe od normy wyrażane w milisekundach.
• Average – średni czas odpowiedzi, również wyrażany w milisekundach.

W naszych testach od razu rzuca się w oczy że korzystanie z kalendarza Google wymaga większych zasobów. Request zwraca więcej danych, przez co czasy odpowiedzi są dłuższe. Jeślibyśmy spojrzeli do View Result Tree (gdzie można podejrzeć szczegóły każdego z requestów), to zauważymy, że prosty GET do /calendar robi po drodze jeszcze 2 przekierowania (co oczywiście też kosztuje – w kontekście wydajności).

Bardzo ważne – w realnych testach wydajnościowych nie powinniśmy używać Graph Result Listenera:

Graph Results MUST NOT BE USED during load test as it consumes a lot of resources (memory and CPU). Use it only for either functional testing or during Test Plan debugging and Validation.

Podsumowanie

Testowanie wydajnościowe z narzędziem JMeter nie jest wcale takie trudne i straszne. Polecam Ci zacząć powoli (o ile pozwala na to Twoja sytuacja) – od bawienia się ogółami. Jak już ogarniesz podstawy to przechodź do rzeczy bardziej zaawansowanych. Informacji na ten temat jest w Internecie mnóstwo – kwestia, żebyś tylko umiał sprecyzować co chcesz osiągnąć.

Osobiście też się dopiero uczę tego narzędzia i właśnie w taki sposób podchodzę do nauki. Za jakiś czas się okaże co z tego wyjdzie

Za tydzień

Zmienimy nieco temat i porozmawiamy o metryce, ale innej, potrzebnej deweloperom czyli logach oraz ustawieniach logbacka w spring-boocie.

Btw. Jeżeli masz jakieś uwagi/sugestie co do artykułu, daj znać w komentarzu.

Artykuł JMeter – Wszystko Co Jest Ci Potrzebne Do Uruchomienia Pierwszych Testów 📌 pochodzi z serwisu bdabek.pl.