Jednym z problemów, z którym często borykają się dostawcy oprogramowania wieloproduktowego, jest powielanie kompetencji inżynierów – programistów, testerów i administratorów infrastruktury – w niemal każdym zespole. Dotyczy to również kosztownych inżynierów – specjalistów w dziedzinie testów obciążeniowych.
Zamiast wykonywać swoje bezpośrednie obowiązki i wykorzystywać swoje unikalne doświadczenie do budowania procesu testowania obciążenia, wybierania metodologii, optymalnych metryk i pisania autotestów zgodnie z profilami obciążeń, inżynierowie często muszą wdrażać infrastrukturę testową od podstaw, konfigurować narzędzia do ładowania i osadzać je się w systemach IK, zakładają monitoring i publikację raportów.
Rozwiązania niektórych problemów organizacyjnych można znaleźć w testach, które stosujemy w Positive Technologies w . W tym omówię możliwość zintegrowania testów obciążeniowych ze wspólnym potokiem CI przy użyciu koncepcji „testowania obciążenia jako usługi” (testowanie obciążenia jako usługa). Dowiesz się, jak i które obrazy dokerów źródeł ładowania można wykorzystać w potoku CI; jak podłączyć źródła ładowania do projektu CI za pomocą szablonu kompilacji; jak wygląda potok demonstracyjny do uruchamiania testów obciążenia i publikowania wyników. Artykuł może być przydatny dla inżynierów testów oprogramowania i automatyków w CI, którzy zastanawiają się nad architekturą swojego systemu ładowania.
Istota koncepcji
Koncepcja testowania obciążenia jako usługi implikuje możliwość integracji narzędzi ładowania Apache JMeter, Yandex.Tank i własnych frameworków w dowolny system ciągłej integracji. Demo będzie dla GitLab CI, ale zasady są wspólne dla wszystkich systemów CI.
Testowanie obciążenia jako usługa to scentralizowana usługa do testowania obciążenia. Testy obciążeniowe przeprowadzane są w dedykowanych pulach agentów, wyniki są automatycznie publikowane w GitLab Pages, Influx DB i Grafana lub w systemach raportowania testów (TestRail, ReportPortal itp.). Automatyzacja i skalowanie realizowane są w jak najprostszy sposób – poprzez dodanie i parametryzację zwykłego szablonu gitlab-ci.yml w projekcie GitLab CI.
Zaletą tego podejścia jest to, że cała infrastruktura CI, agenty ładowania, obrazy dokerów źródeł ładowania, potoki testowe i publikowanie raportów są utrzymywane przez scentralizowany dział automatyzacji (inżynierowie DevOps), podczas gdy inżynierowie testów obciążeniowych mogą skoncentrować swoje wysiłki na rozwoju testów i analiza ich wyników, bez zajmowania się kwestiami infrastruktury.
Dla uproszczenia opisu założymy, że docelowa aplikacja lub testowany serwer zostały już wcześniej wdrożone i skonfigurowane (można do tego wykorzystać automatyczne skrypty w Pythonie, SaltStack, Ansible itp.). Wtedy cała koncepcja testowania obciążenia jako usługi mieści się w trzech etapach: przygotowywanie, testowanie, publikacja raportów. Więcej szczegółów na schemacie (wszystkie zdjęcia są klikalne):
Podstawowe pojęcia i definicje w testowaniu obciążenia
Podczas przeprowadzania testów obciążeniowych staramy się przestrzegać , użyj odpowiedniej terminologii i zalecanych wskaźników. Podam krótką listę głównych pojęć i definicji w testowaniu obciążenia.
Załaduj agenta - maszyna wirtualna, na której aplikacja zostanie uruchomiona - źródło ładowania (Apache JMeter, Yandex.Tank lub samodzielnie napisany moduł ładowania).
Cel testu (cel) - serwer lub aplikacja zainstalowana na serwerze, która będzie podlegała obciążeniu.
Scenariusz testowy (przypadek testowy) - zestaw sparametryzowanych kroków: akcje użytkownika i oczekiwane reakcje na te akcje, z ustalonymi żądaniami i odpowiedziami sieciowymi, w zależności od określonych parametrów.
Profil lub plan obciążenia (profil) - w (Rozdział 4.2.4, s. 43) profile obciążenia definiują metryki, które są krytyczne dla danego testu oraz opcje zmiany parametrów obciążenia podczas testu. Możesz zobaczyć przykłady profili na rysunku.
Test — skrypt z zadanym zestawem parametrów.
Plan testów (plan testów) - zestaw testów i profil obciążenia.
Testowanie (przebieg testowy) - jedna iteracja uruchomienia jednego testu z w pełni wykonanym scenariuszem obciążenia i otrzymanym raportem.
Żądanie sieci (żądanie) — Żądanie HTTP wysłane przez agenta do celu.
Odpowiedź sieci (odpowiedź) — Odpowiedź HTTP wysłana z celu do agenta.
Kod odpowiedzi HTTP (stan odpowiedzi HTTP) - standardowy kod odpowiedzi z serwera aplikacji.
Transakcja to pełny cykl żądanie-odpowiedź. Transakcja liczona jest od momentu wysłania żądania (zapytania) do zakończenia otrzymania odpowiedzi (odpowiedzi).
Stan transakcji - czy udało się pomyślnie zakończyć cykl żądanie-odpowiedź. Jeśli w tym cyklu wystąpił błąd, cała transakcja jest uważana za nieudaną.
Czas odpowiedzi (opóźnienie) - czas od zakończenia wysłania żądania (zapytania) do początku otrzymania odpowiedzi (odpowiedzi).
Załaduj metryki — charakterystyki załadowanej usługi i agenta obciążenia wyznaczone w procesie testowania obciążenia.
Podstawowe metryki do pomiaru parametrów obciążenia
Niektóre z najczęściej używanych i zalecanych w metodologii (s. 36, 52) metryki przedstawiono w tabeli poniżej. Podobne metryki dla agenta i celu są wymienione w tym samym wierszu.
Metryki dla agenta ładowania
Metryki docelowego systemu lub aplikacji testowanej pod obciążeniem
Liczba procesor wirtualny i pamięć RAM,
Dysk - „żelazne” właściwości środka obciążającego
CPU, Pamięć, użycie dysku - dynamika obciążenia procesora, pamięci i dysku
w trakcie testowania. Zwykle mierzone jako procent
maksymalne dostępne wartości
Przepustowość sieci (na agenta ładowania) - przepustowość
interfejs sieciowy na serwerze,
gdzie jest zainstalowany agent ładowania.
Zwykle mierzone w bajtach na sekundę (bps)
Przepustowość sieci(on target) - przepustowość interfejsu sieciowego
na serwerze docelowym. Zwykle mierzone w bajtach na sekundę (bps)
Użytkownicy wirtualni- ilość wirtualnych użytkowników,
wdrażanie scenariuszy obciążeń i
imitowanie rzeczywistych działań użytkownika
Stan użytkowników wirtualnych, Passed/Failed/Total — liczba udanych i
nieudane statusy użytkowników wirtualnych
dla scenariuszy obciążeń, a także ich łączną liczbę.
Ogólnie oczekuje się, że wszyscy użytkownicy byli w stanie ukończyć
wszystkie zadania określone w profilu obciążenia.
Każdy błąd będzie oznaczał, że prawdziwy użytkownik nie będzie w stanie tego zrobić
rozwiązać swój problem podczas pracy z systemem
Żądania na sekundę (minuty)- liczba żądań sieciowych na sekundę (lub minutę).
Ważną cechą agenta ładowania jest liczba żądań, które może wygenerować.
W rzeczywistości jest to imitacja dostępu do aplikacji przez użytkowników wirtualnych
Odpowiedzi na sekundę (minuty)
- liczba odpowiedzi sieci na sekundę (lub minutę).
Ważna cecha docelowej usługi: ile
generować i wysyłać odpowiedzi na zapytania za pomocą
środek ładujący
Stan odpowiedzi HTTP— liczba różnych kodów odpowiedzi
z serwera aplikacji odebranego przez agenta ładowania.
Na przykład 200 OK oznacza udane połączenie,
i 404 - że zasób nie został znaleziony
Utajenie (czas odpowiedzi) - czas od końca
wysłanie żądania (zapytania) przed rozpoczęciem otrzymywania odpowiedzi (odpowiedzi).
Zwykle mierzone w milisekundach (ms)
Czas reakcji transakcji— czas jednej pełnej transakcji,
zakończenie cyklu żądanie-odpowiedź.
Jest to czas od rozpoczęcia wysyłania żądania (zapytania)
do czasu zakończenia otrzymania odpowiedzi (odpowiedzi).
Czas transakcji można mierzyć w sekundach (lub minutach)
na kilka sposobów: rozważ minimum,
maksimum, średnia i na przykład 90. percentyl.
Odczyty minimalne i maksymalne są ekstremalne
stan wydajności systemu.
Dziewięćdziesiąty percentyl jest najczęściej używany,
jak pokazuje większość użytkowników,
komfortową pracę na progu wydajności systemu
Transakcje na sekundę (minuty) - liczba kompletna
transakcji na sekundę (minutę),
czyli ile aplikacja była w stanie zaakceptować i
przetwarzać żądania i wydawać odpowiedzi.
W rzeczywistości jest to przepustowość systemu
Stan transakcji , Zdane / Nieudane / Suma - liczba
udane, nieudane i łączna liczba transakcji.
Dla prawdziwych użytkowników nieudane
transakcja faktycznie będzie oznaczać
niemożność pracy z systemem pod obciążeniem
Schemat testowania obciążenia
Koncepcja testów obciążeniowych jest bardzo prosta i składa się z trzech głównych etapów, o których już wspomniałem: Przygotuj raport z testu, czyli przygotowanie celów testów i ustawienie parametrów dla źródeł obciążenia, następnie wykonanie testów obciążenia, a na koniec wygenerowanie i opublikowanie raportu z testu.
Uwagi schematyczne:
- QA.Tester jest ekspertem w testach obciążeniowych,
- Cel to aplikacja docelowa, dla której chcesz poznać jej zachowanie pod obciążeniem.
Klasyfikator podmiotów, etapów i kroków na diagramie
Etapy i kroki
Co się dzieje
Co jest przy wejściu
Jaki jest wynik
Przygotowanie: etap przygotowania do testów
Załaduj parametry
Ustawienie i inicjalizacja
użytkownik
parametry obciążenia,
wybór metryk i
przygotowanie planu testów
(ładowanie profilu)
Niestandardowe opcje dla
inicjalizacja agenta ładowania
Plan testów
Cel testowania
VM
Wdrożenie w chmurze
maszyna wirtualna z
wymagane cechy
Ustawienia maszyny wirtualnej dla agenta ładowania
Skrypty automatyzacji dla
Tworzenie maszyny wirtualnej
Maszyna wirtualna skonfigurowana w
Chmura
Środowisko
Konfiguracja i przygotowanie systemu operacyjnego
środowisko dla
praca agenta obciążenia
Ustawienia środowiska dla
agent obciążenia
Skrypty automatyzacji dla
ustawienia środowiska
Przygotowane środowisko:
System operacyjny, usługi i aplikacje,
niezbędne do pracy
agent obciążenia
Załaduj agentów
Instalacja, konfiguracja i parametryzacja
środek ładujący.
Lub pobieranie obrazu dokera z
wstępnie skonfigurowane źródło ładowania
Załaduj źródłowy obraz dokera
(YAT, JM lub samodzielnie napisany framework)
Ustawienia
agent obciążenia
Ustaw i gotowe
do agenta obciążenia pracą
Test: etap wykonywania testów obciążeniowych. Źródłami są agenty ładowania wdrożone w dedykowanych pulach agentów dla GitLab CI
Załadować
Uruchamianie agenta ładowania
z wybranym planem testów
i parametry obciążenia
Opcje użytkownika
do inicjalizacji
agent obciążenia
Plan testów
Cel testowania
Dzienniki wykonania
testy obciążeniowe
Logi systemowe
Dynamika zmian metryk celu i agenta obciążenia
Uruchom agentów
Wykonanie agenta
mnóstwo skryptów testowych
zgodnie z
ładowanie profilu
Załaduj interakcję agenta
w celu przetestowania
Plan testów
Cel testowania
Dzienniki
Zbiór „surowych” dzienników
podczas testów obciążeniowych:
rekordy aktywności agenta ładowania,
stan obiektu testowego
oraz maszynę wirtualną, na której działa agent
Dzienniki wykonania
testy obciążeniowe
Logi systemowe
Metryka
Zbieranie „surowych” metryk podczas testowania
Dynamika zmian metryk celu
i agent obciążenia
Raport: etap przygotowania raportu z badań
generator
Przetwarzanie zebrane
układ ładowania i
system monitoringu "surowy"
metryki i dzienniki
Tworzenie raportu w
formie czytelnej dla człowieka
możliwe z elementami
analitycy
Dzienniki wykonania
testy obciążeniowe
Logi systemowe
Dynamika zmian metryk
agent docelowy i ładujący
Przetworzone „surowe” logi
w formacie odpowiednim dla
przesyła do pamięci zewnętrznej
Raport obciążenia statycznego,
czytelny dla człowieka
Publikować
Publikacja raportu
o obciążeniu
testowanie w zewn
usługa
Przetworzone „surowe”
dzienniki w odpowiednim formacie
do rozładunku na zewnątrz
repozytoria
Zapisane w zewnętrznym
raporty dotyczące przechowywania
ładunek, odpowiedni
do analizy ludzkiej
Łączenie źródeł ładowania w szablonie CI
Przejdźmy do części praktycznej. Chcę pokazać jak na niektórych projektach w firmie wdrożyliśmy koncepcję testów obciążeniowych jako usługi.
Najpierw z pomocą naszych inżynierów DevOps stworzyliśmy dedykowaną pulę agentów w GitLab CI do przeprowadzania testów obciążeniowych. Aby nie pomylić ich w szablonach z innymi, takimi jak asembler pools, dodaliśmy do tych agentów tagi, : obciążenie. Możesz użyć innych zrozumiałych tagów. Pytają Biegacze GitLab CI.
Jak znaleźć wymaganą moc sprzętową? Charakterystykę agentów ładowania - wystarczającą ilość vCPU, RAM i Disk - można obliczyć na podstawie faktu, że na agencie powinny działać Docker, Python (dla Yandex.Tank), agent CI GitLab, Java (dla Apache JMeter) . W przypadku Javy pod JMeter zaleca się również użycie co najmniej 512 MB pamięci RAM, a jako górny limit: .
W związku z tym, bazując na naszym doświadczeniu, zalecamy użycie co najmniej 4 vCPU, 4 GB RAM, 60 GB SSD dla agentów ładowania. Przepustowość karty sieciowej jest określana na podstawie wymagań profilu obciążenia.
Używamy głównie dwóch źródeł ładowania - obrazów dokerów Apache JMeter i Yandex.Tank.
to narzędzie typu open source firmy Yandex do testowania obciążenia. Jego modułowa architektura jest oparta na wysokowydajnym, asynchronicznym generatorze żądań HTTP opartym na trafieniach firmy Phantom. Tank posiada wbudowany monitoring zasobów testowanego serwera poprzez protokół SSH, może automatycznie zatrzymać test w określonych warunkach, może wyświetlać wyniki zarówno w konsoli jak i w postaci wykresów, można podłączyć swoje moduły do niego, aby rozszerzyć funkcjonalność. Nawiasem mówiąc, używaliśmy czołgu, kiedy nie był jeszcze głównym nurtem. W artykule "» możesz przeczytać historię, jak przeprowadziliśmy z nim testy obciążeniowe w 2013 roku jest jednym z produktów naszej firmy.
to narzędzie do testowania obciążenia typu open source firmy Apache. Równie dobrze może być używany do testowania zarówno statycznych, jak i dynamicznych aplikacji internetowych. JMeter obsługuje ogromną liczbę protokołów i sposobów interakcji z aplikacjami: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET itp.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) i IMAP(S), bazy danych za pośrednictwem JDBC, mogą wykonywać polecenia powłoki i pracować z obiektami Java. JMeter ma IDE do tworzenia, debugowania i wykonywania planów testów. Istnieje również CLI do obsługi wiersza poleceń w dowolnym systemie operacyjnym zgodnym z Javą (Linux, Windows, Mac OS X). Narzędzie może dynamicznie generować raport z testu HTML.
Dla ułatwienia użytkowania wewnątrz naszej firmy, aby sami testerzy mogli zmieniać i dodawać środowisko, wykonaliśmy buildy obrazów docker źródeł ładowania na GitLab CI z publikacją do wewnętrznego . Ułatwia to i przyspiesza łączenie ich w potoki do testów obciążenia. Jak zrobić docker push do rejestru przez GitLab CI - zobacz .
Wzięliśmy ten podstawowy plik dokera dla Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]A dla Apache JMeter ten:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Możesz przeczytać jak działa nasz system ciągłej integracji w artykule "".
Szablon i potok
W projekcie dostępny jest przykładowy szablon do przeprowadzania testów obciążeniowych , Możesz przeczytać instrukcje dotyczące korzystania z szablonu. W samym szablonie (plik ) znajdują się uwagi o tym, za co odpowiada każdy krok.
Szablon jest bardzo prosty i przedstawia trzy etapy testowania obciążenia opisane na powyższym diagramie: przygotowywanie, testowanie i publikowanie raportów. Odpowiedzialny za to : Przygotuj, przetestuj i zgłoś.
- Etap należy użyć do wstępnej konfiguracji celów testowych lub sprawdzenia ich dostępności. Środowisko dla źródeł ładowania nie musi być konfigurowane, są one wstępnie zbudowane jako obrazy dokerów i umieszczane w rejestrze dokerów: wystarczy określić żądaną wersję na etapie Test. Ale możesz je odbudować i stworzyć własne zmodyfikowane obrazy.
- Etap służy do określania źródła ładowania, uruchamiania testów i przechowywania artefaktów testowych. Możesz wybrać dowolne źródło ładowania: Yandex.Tank, Apache JMeter, własne lub wszystkie razem. Aby wyłączyć niepotrzebne źródła, po prostu skomentuj lub usuń zadanie. Punkty wejścia dla źródeł obciążenia:
- Parametry uruchamiania dla Yandex.Tank są określone w pliku .,
- Parametry uruchamiania Apache JMeter są określone w pliku .
Uwaga: Szablon konfiguracji zestawu służy do ustawienia interakcji z systemem CI i nie implikuje umieszczenia w nim logiki testowej. Na potrzeby testów określany jest punkt wejścia, w którym znajduje się kontrolny skrypt bash. Sposób przeprowadzania testów, generowania raportów oraz same skrypty testowe muszą być zaimplementowane przez inżynierów QA. W wersji demonstracyjnej, dla obu źródeł ładowania, żądanie strony głównej Yandex jest używane jako najprostszy test. Skrypty i parametry testowe znajdują się w katalogu .
- Na scenie musisz opisać, w jaki sposób opublikować wyniki testów uzyskane na etapie Test do zewnętrznych magazynów, np. do GitLab Pages lub specjalnych systemów raportowania. GitLab Pages wymaga, aby po zakończeniu testów katalog ./public nie był pusty i zawierał co najmniej plik index.html. Możesz przeczytać o niuansach usługi GitLab Pages. .
Przykłady eksportu danych:
- z JMeter do ,
- z Yandex.Tank do .
Publikowanie instrukcji konfiguracji:
- Statyka HTML w ,
- do InfluxDB, a następnie do .
W przykładzie demonstracyjnym potok z testami obciążenia i dwoma źródłami ładowania (można wyłączyć niepotrzebne) wygląda tak:
Apache JMeter potrafi sam wygenerować raport HTML, więc bardziej opłaca się go zapisać w GitLab Pages przy użyciu standardowych narzędzi. Tak wygląda raport Apache JMeter:
W przykładzie demonstracyjnym dla Yandex.Tank zobaczysz tylko w sekcji GitLab Pages. Podczas testowania Tank może zapisać wyniki do bazy InfluxDB, a stamtąd można je wyświetlić np. w Grafanie (konfiguracja odbywa się w pliku ). Tak wygląda relacja Tanka w Grafanie:
Streszczenie
W artykule mówiłem o koncepcji „testowania obciążenia jako usługi” (testowania obciążenia jako usługi). Główną ideą jest wykorzystanie infrastruktury prekonfigurowanych pul agentów ładowania, obrazów dokerów źródeł ładowania, systemów raportowania oraz łączącego je potoku w GitLab CI w oparciu o prosty szablon .gitlab-ci.yml (przykład ). Wszystko to wspierane jest przez niewielki zespół inżynierów automatyków i powielane na zlecenie zespołów produktowych. Mam nadzieję, że pomoże to Państwu w przygotowaniu i wdrożeniu podobnego schematu w Państwa firmie. Dziękuję za uwagę!
PS Chciałbym bardzo podziękować moim współpracownikom, Siergiejowi Kurbanowowi i Nikołajowi Jusiewowi, za pomoc techniczną przy wdrażaniu koncepcji testów obciążeniowych jako usługi w naszej firmie.
autor: - Zastępca Szef Technologii i Procesów Rozwojowych (DevOps) w Positive Technologies
Źródło: www.habr.com