Testy wydajnościowe wykonywane z poziomu przeglądarki to podejście, które stosowane jest coraz śmielej w projektach IT, a przez niektórych również uważane jest jako rozwiązanie większości największych bolączek tradycyjnego testowania na poziomie protokołów (najczęściej HTTP). Ale czy, aby na pewno?

Za nowym podejście przemawia przede wszystkim fakt, iż aplikacje webowe bardzo się zmieniły, a tradycyjny styl tworzenia oraz wykonywania testów obciążeniowych stał się trudny do zastosowania w dzisiejszych, coraz bardziej złożonych aplikacjach internetowych. Rozwiązaniem tego problemu może być wykonywanie testów obciążeniowych właśnie z poziomu przeglądarki.

Jednym z częstych problemów aplikacji i serwisów internetowych jest ich niska wydajność przy zwiększonym ruchu. Objawem jest spowolnione działanie serwisu lub nawet jego niedostępność. To oczywiście może powodować straty finansowe oraz godzić w wizerunek marki, jaka stoi za serwisem internetowym.
Jedno z ostatnich badan wykazało, że prawie połowa (48%) firm zgłosiła, że ​​problemy z wydajnością bezpośrednio utrudniają prowadzenia ich biznesu.

Testy wydajnościowe na poziomie protokołu

Praktycznie od kilku dekad najpopularniejszym podejściem wykonywania testów obciążeniowych stanowi testowanie na poziomie protokołu, które polega na wysyłaniu wiadomości bezpośrednio do serwera aplikacji. Co istotne, wiadomości te, wysyłane są z pominięciem graficznego interfejsu aplikacji, a odpowiedzi otrzymywane z serwera również nie są w żaden sposób wizualizowane. „Użytkownicy” (w cudzysłowie) zdefiniowani w skryptach testowych na poziomie protokołu są w rzeczywistości wątkami, z których każdy wysyła listę komunikatów w określonych odstępach czasu, a my nazywamy ich użytkownikami wykonującymi akcje z poziomu protokołu.
W praktyce nadal dominują testy wykonywane z poziomu protokołów głównie za pomocą takich narzędzi JMeter, LoadRunner, czy też narzędzi, które pojawiły się dosyć niedawno, czyli Locust, Gatling czy też k6.

Okej, ale skąd tak duża popularność testowania na poziomie protokołu, które stosuje się do dzisiaj. Spowodowane było to zapewne kilkoma czynnikami:

• Jeszcze jakiś czas temu sprzęt, maszyny, serwery ogólnie hardware był rzadkim i drogim w utrzymaniu dobrem. Testowanie obciążeniowe z poziomu protokołu jest z kolei wyjątkowo wydajne sprzętowo. Jeszcze jakiś czas temu sprzęt, maszyny, serwery ogólnie hardware był rzadkim i drogim w utrzymaniu dobrem. Testowanie obciążeniowe z poziomu protokołu jest z kolei wyjątkowo wydajne sprzętowo.

• Z drugiej strony testy obciążeniowe były wykonywane rzadko i często przeprowadzane były przez osoby trzecie lub firmy specjalizujące się w testowaniu wydajnościowym. Po pewnym czasie testy wykonywane z poziomu protokołu stały się, po prostu standardem.

Testy na poziomie protokołu – wyzwania

Dzisiaj aplikacje webowe (i świat) bardzo się zmieniły. Testowanie obciążeniowe jednak nie tak bardzo. Tak jak już wspomniałem obecny, popularny styl tworzenia oraz wykonywania testów z poziomu protokołów powoli staje się trudny do zastosowania w dzisiejszych aplikacjach internetowych, z powodu ich rosnącej złożoności. 

Jej głównym powodem, jest JavaScript. W 2011 r. pojedyncza strona internetowa zawierała zwykle mniej niż 100 KB kodu JavaScript, co generowało około 50 lub mniej żądań HTTP. Teraz ta liczba jest podwojona: widzimy średnio 200 KB kodu JavaScript średnio na pojedynczej stronie, co generuje ponad 100 żądań.

Na przykład, tylko jedno kliknięcie na stronie Amazon.com uruchamia ponad 150 żądań HTTP przetwarzanych asynchronicznie po załadowaniu strony. Możemy znaleźć tam takie rzeczy jak dynamiczne parsowanie i wykonywanie JavaScript, cachowanie statycznych zasobów lub wywołania CDN. Co gorsza, przy kolejnym kliknięciu tego samego elementu na stronie może zostać wygenerowanych trochę więcej lub mniej żądań niż za pierwszym razem. Z każdą iteracją testu liczba wywołań może być minimalnie różna.

W momencie, kiedy zaczniemy budować symulacje danego scenariusz do testu obciążeniowego, szybko przełoży się to na dziesiątki albo i setki żądań HTTP, które należy wiernie zarejestrować, a następnie zamienić w działający skrypt. I tu sprawa się komplikuje Należy zweryfikować wszystkie żądania i odpowiedzi, przeprowadzić czyszczenie i wyodrębnić odpowiednie informacje, aby realistycznie symulować interakcje użytkowników na poziomie biznesowym. Nie myślimy w tym momencie tylko jak użytkownik, musimy także myśleć jak przeglądarka.
Przy tworzeniu testu musimy wziąć pod uwagę wszystkie funkcje, które przeglądarka automatycznie za nas obsługuje, i upewnić się, że są odzwierciedlone w skrypcie testu obciążeniowego. Obsługa sesji, zarządzanie nagłówkami plików cookie, uwierzytelnianie, buforowanie, dynamiczne analizowanie i wykonywanie skryptów, pobieranie informacji z odpowiedzi i wykorzystywanie ich w przyszłych żądaniach-wszystko to musi być ujęte w naszym teście, jeśli chcemy skutecznie generować realistyczne obciążenie. Zasadniczo stajemy się odpowiedzialni wypełnienie luki pomiędzy między sferą techniczną a biznesową. Wymaga to zarówno czasu, jak i dużego doświadczenia.

Okej. Możecie sobie pomyśleć „W porządku, użyjemy narzędzi do nagrywania i odtwarzania”. Można przecież skorzystać z serwera proxy umieszczonego pomiędzy przeglądarką a serwerem, która zarejestruje nam cały ruch i wszystkie wywołania http – taką opcję oferuje przykładowo JMeter. Niestety, nie jest to takie proste. Nawet jeśli wchodzimy w interakcję na poziomie interfejsu użytkownika, testy są nadal oparte na poziomie protokołu. Załóżmy, że analizowaliśmy ruch związany z jednym użytkownikiem wykonującym proste działanie „kliknij skrzynkę odbiorczą”. Gdy dwa razy rejestrujemy tę samą akcję dla tego samego użytkownika, istnieją dziesiątki, jeśli nie setki różnic w ciele żądania, które musielibyśmy uwzględnić.
Oczywiście możesz rozwiązać te różnice z pewnym wysiłkiem. Niestety, gdy aplikacja zmieni się ponownie, wracamy do punktu wyjścia. Im częściej aplikacja zmienia się, tym bardziej staje się to bolesne i frustrujące.

Testy wykonywane na poziomie protokołów są podatne na zmiany i czasochłonne w wykonaniu dla zwinnych zespołów. Dzisiejsi zwinni programiści i testerzy nie mają czasu (ani chęci) zmagania się ze wszystkimi szczegółami technicznymi wymaganymi do prawidłowego działania testów obciążenia i synchronizacji testów obciążenia z szybko rozwijającymi się aplikacjami.

Symulacja z poziomu interfejsu API nie zapewnia dokładnego przedstawienia rzeczywistej wydajności przeglądarki i może nie wyzwalać wszystkich składników aplikacji. Po Przechwytywane czasy odpowiedzi poszczególnych żądań nie obejmują udziału czasu odpowiedzi opartego na przeglądarce. Może zatem utracić znaczącą część czasu odpowiedzi, co czyni wyniki nie wiarygodnymi.

Ponieważ, tradycyjne narzędzia do testowania obciążenia nie używają przeglądarki, nie można określić różnicy wydajności danej aplikacji między różnymi przeglądarkami lub między różnymi wersjami przeglądarek. Wraz z przejściem coraz większej logiki do przeglądarki niewielkie różnice w sposobie, w jaki przeglądarki radzą sobie z kodem, mogą mieć duży wpływ na czas ładowania strony.

Testy obciążeniowe z poziomu przeglądarki (BLU)

Podsumowując: nowoczesne aplikacje internetowe są coraz trudniejsze do zasymulowania na poziomie protokołu. Stwierdzenie to rodzi z kolei pytanie. Dlaczego by nie przejść z testowania obciążeniowego z poziomu protokołu na poziom przeglądarki, szczególnie jeśli wrażenia odczuwane przez użytkownika dotyczące czasu ładowania danej strony za pośrednictwem przeglądarki są tym, co ostatecznie powinniśmy zmierzyć i ulepszyć?
W podejściu wykonywania testów z poziomu przeglądarki, jedna akcja biznesowa, którą chcemy zmierzyć przekłada się na jedną lub maksymalnie dwie linie kodu w skrypcie testowym w porównaniu z dziesiątkami, jeśli nie setkami żądań na poziomie protokołu. Funkcje na poziomie przeglądarki, takie jak pamięć podręczna, pliki cookie i zarządzanie uwierzytelnianiem / sesjami nie wymagają naszej obsługi. Istnieje wiele sposobów na symulację ruchu z poziomu przeglądarki: Selenium jest obecnie najbardziej popularny, ale dostępnych są też inne narzędzi do testowania w różnych przeglądarkach np. Puppeter.

Dlaczego dopiero teraz testerzy oraz deweloperzy zaczynają na poważnie rozważać użycie podejścia testowania obciążenia z poziomu przeglądarki. Ponieważ jeszcze kilkanaście lat temu nie było możliwe uruchomienie testów z poziomu przeglądarki w skali wymaganej do symulowania wysokiego obciążenia. Uruchomienie dużej ilości sesji przeglądarek z Selenium wymaga ogromnej infrastruktury, które po prostu nie była dostępna z powodu wysokich kosztów oraz długiego czasu potrzebnego na jej przygotowanie.

Dzisiaj, przy wysokiej dostępności infrastruktur chmurowych oraz konteneryzacji, koncepcja testowania obciążenia w przeglądarce jest wreszcie możliwa do zrealizowania. Nagle generowanie obciążenia na ogromnej ilości sesji przeglądarek jest o wiele bardziej osiągalne – zwłaszcza gdy chmura może zapewnić dostęp do tysięcy generatorów obciążenia, które mogą być uruchomione w ciągu kilku minut. Zamiast zmagać się z setką żądań HTTP w celu przetestowania prostej akcji użytkownika, wystarczy ją po prostu symulować w przeglądarce.

Dzięki zmniejszeniu złożoności związanej z tradycyjnym testowaniem obciążenia, testowanie obciążenia z poziomu przeglądarki daje programistom i testerom możliwość uzyskanie szybkiej informacji o tym jak zmiana kodu aplikacji wpływa na jej wydajność. Dzięki temu podejściu osoby niebędące profesjonalnymi testerami wydajności są w stanie szybko tworzyć testy obciążenia, uruchamialne w sposób ciągły w ramach procesu CI / CD.

Testy z poziomu przeglądarki – zalety

Podsumujmy sobie zatem zalety stosowania podejścia testowania obciążeniowego z poziomu przeglądarki.

• Prostsze tworzenie skryptów testowych
  Narzędzia do tworzenia testów na poziomie protokołu wymagają dogłębnej wiedzy o tym, jak działa testowana aplikacja oraz jakie konkretne żądania są wywoływane. W testach na poziomie przeglądarki nie musimy takowej wiedzy posiadać. Dla przykładu w Selenium podczas skryptowania procesu logowania wystarczy, że w skrypcie zostanie wpisana nazwa użytkownika i hasło w odpowiednich polach, a następnie kliknij przycisk “Zaloguj się”. Skrypt nie musi wiedzieć, że formularz przesyła zaszyfrowane żądanie przy użyciu interfejsu API (co na przykład trzeba wiedzieć o skrypcie na poziomie protokołu). Tworzenie skryptów testowych z przeglądarki jest więc dużo prostsze.

• Możliwość przetestowania wszystkich komponentów aplikacji z perspektywy użytkownika
  W przeciwieństwie do testowania interfejsów API nie musimy decydować o tym, który serwer chcemy konkretnie obciążyć, ani upewniać się, iż mamy wszystkie potrzebne żądania. Skrypt testowy na poziomie przeglądarki współdziała z elementami strony tak, jak robiłby to prawdziwy użytkownik, dlatego testowane są wszystkie serwery aplikacji.

• Możliwość przetestowania każdego zachowanie użytkownika
  Narzędzia do testowania obciążenia na poziomie protokołu nie radzą sobie z aplikacjami typu single-page apps, w których większość działań odbywa się po stronie klienta. W przypadku testowania obciążenia na poziomie przeglądarki nie stanowi to problemu, ponieważ sam skrypt testowy wykonywany po stornie klienta, czyli właśnie przeglądarki.

• Łatwiejsze w utrzymaniu testy
  Niższa złożoność skryptu oznacza, iż ten oparty na przeglądarce jest bardziej odporny na zmiany w przypadku pojawienia się zmian w kodzie źródłowym. Zmiana wywoływanych żądań nie będzie wymagać zmiany skryptu testowego, co czyni go idealnym do testowania regresji. Łatwiej jest także przekazać innym członkom zespołu ze względu na wysoką czytelność. Jeden krok może odpowiadać dziesiątkom żądań, które należy wykonać w przypadku testów na poziomie protokołu, co sprawia, że ​​skrypty te są trudniejsze do zrozumienia.

Testy z poziomu przeglądarki – wady

Oprócz zalet testowanie obciążeniowe w przeglądarkę posiada jedną, ale za to bardzo istotną wadę – wysokie zużycie zasobów. Narzędzia do testowania obciążenia oparte na przeglądarce zużywają dużej więcej zasobów procesora i pamięć niż narzędzia oparte na protokole. Skrypty testowe tworzone w JMeterze lub Gatlingu wysyłają wiadomości do serwera i rejestrują odpowiedzi z serwera, bez potrzeby analizowania odpowiedzi. Natomiast narzędzia oparte na przeglądarce analizują odpowiedź serwera, aby uzyskać dostęp do elementów DOM na stronie, przez co zużywają dużo więcej zasobów

Testy z poziomu przeglądarki – złoty młot?

Mimo wielu zalet i zasadniczo jednej wady związanej z wysokim zużyciem zasobów czy można byłoby uznać testowania obciążenia w przeglądarce jako remedium na wszelkie bolączki tego typu testowania.

Żadne podejście do testowania obciążenia nie rozwiąże wszystkich potrzeb we wszystkich przypadkach. Na przykład, jeśli chcielibyśmy przetestować aplikację, która nie jest dostępna w przeglądarce, podejście BLU oczywiście nie zda egzaminu.

Ponadto nadal istnieją sytuacje, w których można pominąć testowanie na poziomie przeglądarki za pomocą narzędzi takich jak JMeter, Gatling lub przypadków testowych opartych na interfejsie API. W tym przypadku nadal lepszym podejściem jest przeprowadzenie testów, które wykonywane są bezpośrednio na poziomie protokołu.

Ale czy oprócz wymienionych sytuacji powinniśmy całkowicie zapomnieć o testowaniu wydajności na poziomie protokołu i zaimplementować wszystkie testy w przeglądarce?

Nie!

Testowanie wydajności oparte na przeglądarce nie jest złotym młotem. Dlaczego?

Po pierwsze:

W wielu projektach budżet nie jest na tyle wysoki, aby umożliwić dostęp do zasobów pozwalających na wygenerowanie dostatecznego ruchu. Narzędzia na poziomie protokołu są dużo bardziej efektywne pod względem zużycia zasobów. Generowanie bardzo dużych obciążeń przy użyciu narzędzi na poziomie protokołu jest więc znacznie tańsze. Ta wydajność sprawia, że ​te ​narzędzia są dobrym wyborem do testowania obciążenia dla bardzo dużej ilości wirtualnych użytkowników lub w przypadku chęci wykonania stres testów.

Po drugie:

Jeśli chcielibyśmy testować aplikacje mobilne lub interfejsy API, narzędzia do testowania na poziomie protokołu pozwalają skupić się na trafianiu w to, co tak naprawdę chcemy przetestować i tylko tego, co chcemy przetestować. Czasami nie zależy nam na testowaniu całości składowych naszej aplikacji, np. gdy chcemy skupić się wyłącznie na zmierzeniu wydajności pojedynczej metody danego interfejsu.

Podsumowując – warto rozważyć podejście do testowania i z poziomu przeglądarki i z poziomu protokołu i w zależności od potrzeb i ograniczeń danego projektu, zdecydować się na najbardziej pasującej Wam podejście lub zdecydować się na…

Podejście hybrydowe

Podejście hybrydowe, w którym powinniśmy rozważyć wykonanie dwóch rodzajów testów:

Pierwszy to testy obciążeniowe backendu wykonywane tradycyjnym podejściem z poziomu protokołu gdzie symulujemy akcje dużej ilości rzeczywistych użytkowników w naszej aplikacji internetowej. Celem jest określenie związku między rosnącą liczbą użytkowników wirtualnych a czasem odpowiedzi / przepustowością (liczbą żądań na sekundę) oraz identyfikacja punktu nasycenia i pierwszych wąskich gardeł.

Drugi rodzaj testów to testy wydajnościowe E2E na poziomie przeglądarki, gdzie głównym celem jest zmierzenie czasu ładowania elementów aplikacji lub danego scenariusza właśnie po stronie przeglądarki na 1 instancji z punktu widzenia użytkownika końcowego. Testy tego typu pomogą nam wykryć błędy, spowolnienia oraz wąskie gardła w warstwie frontendowej.

Dobrze przeprowadzony test wydajności powinien sprawdzić więc obie składowe aplikacji. Najlepiej przeprowadzić główne obciążenie za pomocą narzędzi opartych na protokole i jednocześnie wykonać testy z poziomu prawdziwej przeglądarki, aby wykonać pomiary po stronie klienta.

Dzięki za przeczytanie tego artykułu do końca! 🙂 Już niebawem zamieszczę drugą część posta, gdzie przedstawię podejście testowania wydajnościowego w przeglądarce w praktyce z użyciem biblioteki Flood Element.

Aby nie przegapić kolejnego artykułu już teraz zapisz się do Newslettera.