W przypadku każdego projektu dużą rolę odgrywają testy. Niekiedy nawet kluczową, jak np. w modelu Extreme Programming.
Testy obejmują:
testy funkcjonalne
testy obciążeniowe
JMeter zapewnia kompleksową obsługę tych drugich, pozwalając symulować realny ruch użytkowników na wiele sposobów.
JMeter jest napisany w całości w Javie.
Tego nigdy za wiele. Prawdopodobnie zawsze znajdzie się na tyle skomplikowany system, że skorzystanie z gotowej platformy do testowania będzie niewygodne. W tym celu korzysta się ze skryptów w:
zawsze działa
bardzo szybki
nieprzenośny
mało bibliotek - gotowców
przenośny
szybkie i proste tworzenie skryptów
bogate biblioteki, istnieje też biblioteka Benchmark
podobno Benchmark daje niezbyt wiarygodne wyniki
problematyczne wątki
obsługa sieci i wielu protokołów wyższego poziomu out-of-the-box.
przenośna
prosto obsługuje wątki
wymagania systemowe duże
nieskryptowa
większość zalet Javy
skryptowy, niskie wymagania systemowe
Po pierwsze, jest trochę rozwiązań komercyjnych, które są duże, fajne i drogie. Z tego ostatniego powodu nie będę ich opisywał, tu Google jest przyjacielem.
Z pozostałych warte wspomnienia:
tester serwerów HTTP. Dość prosty, z command line, dostarczany z serwerem Apache. Do zastosowań, które nie wymagają wiele więcej poza kilkoma zapytaniami GET i POST.
biblioteka stworzona do współpracy z JUnit, zastępująca przeglądarkę (pozwala tym samym na pracę bez GUI). Ponieważ jest to biblioteka, a nie gotowy soft, jest najbardziej użyteczna jako komponent do testowania
wygodny interfejs użytkownika. Główna wada to fakt, że projekt się dalej nie rozwija.
o tym dalej.
JMeter to środowisko do tworzenia testów, które:
jest darmowe
jest przenośne
ma funkcjonalne GUI
ale można odpalać testy bez niego
umożliwia tworzenie skomplikowanych scenariuszy testowania
które można odpalać zdalnie z wielu maszyn jednocześnie
ma spore możliwości gromadzenia i analizy statystyk
jest to abstarkcyjny system do testów, który ma komponenty do testowania obciążeniowego HTTP, FTP, LDAP, JMS, JNDI i wielu innych
można też rozszerzać JMeter o własne komponenty do testów
używanie asercji pozwala nawet na ograniczone wykrywanie błędów w kodzie
Wady:
GUI i Java daje narzut na szybkość działania, przez co wyniki mogą być zaburzone
spore wymagania pamięciowe
stabilność zależna od stabilności implementacji Javy na lokalnym systemie.
Pierwszy problem można ograniczyć przez stosowanie testowania wsadowego i zdalnego.
Strona domowa projektu:
http://jakarta.apache.org/jmeter/
Podręcznik:
http://jakarta.apache.org/jmeter/usermanual/
Download:
http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi
Binarka przychodzi pod postacią pliku .tar.gz. Należy go rozpakować
w wybranym katalogu. W podkatalogu bin/ są skrypty uruchamiające JMeter
pod różnymi systemami: jmeter.bat i jmeter-server.bat pod Windows,
jmeter i jmeter-server pod Linuksem.
Plan testu zawiera listę kroków, które będą wykonane podczas testu. Pozwala równiez na przechowywanie zmiennych statycznych do których będą zapisywane wartości wyekstrahowane z odpowiedzi na zapytania.
Jest on hierarchiczny i do jego budowania są dostępne następujące składniki:
Każdy plan testu musi zawierać przynajmniej jedną grupę wątków. Grupy wątków są punktami startowymi testu - składniki wykonują się w ramach grupy wątków. Pozwala ona ustalić ilość wątków, czas tworzenia wątków (ramp-up period), ilość powtórzeń części testu.
W Jmeter są dwa rodzaje kontrolerów:
Samplers - pozwalają na generowanie zapytań (np. HTTPSampler - generuje zapytanie HTTP)
Logic controllers - pozwalają sterować przepływem (np. IfControler - pozwala na wykonanie zapytania jeśli warunek jest spełniony).
Wszystkie one są szczegółowo opisane na stronie http://jakarta.apache.org/jmeter/usermanual/component_reference.html.
Samplery wykonują żądania łącząc się z serverem WWW czy FTP. W Jmeter dostępne są m.in.:
FTP Request
HTTP Request
JDBC Request - wysyla zapytanie SQL do bazy danych
Java object request - pozwala wywołac obiekt implementujący interfejs JavaSamplerClient.
JMS Point to Point - pozwala wrzucać/pobierać wiadomości z/do kolejek JMS'owych.
Pozwalają sterować przepływem wykonania składników potomnych planu (wykonanie warunkowe, pętle, wykonanie w przypadkowej kolejności). Kontrolery logiki można zagnieżdżać. Kilka przykładowych:
zawartość tego kontrolera będzie wykonana tylko w pierwszej iteracji testu. Przydatne np. do obsługi logowania.
zawartośc kontrolera będzie wykonana tylko gdy warunek jest spełniony. Warunki są fragmentami kodu w Javascript.
Asercje pozwalają zweryfikować czy odpowiedź na zapytanie zawiera określone wyrażenie regularne. Można też zastosować asercje XPath, które pozwalają zwalidować odpowiedź na zapytanie przy użyciu DTD, lub wpisać zapytanie XPath i jeśli wynik jest niepusty przyjąć, że asercja jest prawdziwa.
Składniki pozwalające opóżnić lub zsynchronizować poszczególne operacje. Domyślnie JMeter wysyła zapytania bez przerwy, co może prowadzić do jego przeładowania. W JMeter dostępne są m.in:
timer powodujący odczekanie stałą ilość czasu pomięcy zapytaniami.
timer powodujący odczekanie zmienna ilość czasu obliczoną tak, żeby throughput byl stały.
Składniki pozwalające uprościć tworzenie planu poprzez zgrupowanie ustawień konfiguracyjnych. Np. adres ip dla wszystkich zapytań servera HTTP może być taki sam. Wtedy zamiast każdemu elementowi HTTPRequest konfigurować adres ip servera wystarczy dodać do kontenera nadrzędnego HTTPRequestDefaults, gdzie będzie skonfigurowany adres ip serwera. Pozwala również na obsługe ciasteczek czy autentykacje przy użyciu HTTP Basic .
Składniki pozwalające zbierać wyniki np wyświetlić wykres (Graph Results) czy sprawdzić czy asercje są spełnione (Assertion Results). Może równiez być użyty w celu zapisania odpowiedzi na zapytania.
Składniki pozwalające wykonać jakąś akcję przed wykonaniem zapytania. Użyteczne np. w przypadku gdy sesja jest zawarta w URL.
Analogicznie jak Pre-Processor Elements - pozwalają wykonać akcję po wykonaniu zapytania. Użyteczne do esktrahowania wartości z tekstu odpowiedzi.
Tworzenie nowej ThreadGroup.
Domyślna konfiguracja HTTP
CookieManager
Pierwszy request: strona główna Google
Drugi request: wyszukanie hasła "kretyn"
GraphListener
element ProxyController
włączenie serwera proxy
nagrywanie
pobrać i zainstalować JMeter
uruchomić jmeter-server
podać prowadzącym (nam) swój adres IP
My wykonamy:
uruchomienie JMeter z opcją -J sygnalizującą adresy IP zdalnych hostów
załadowanie testu: zdalny.jmx
testowanie z wielu komputerów
Otwórz plan JMS-Point-to-Point.jmx.
W planie zdefiniowana jest asercja. Dodaj element, który pozwoli śledzić czy jest ona spełniona.
Dodaj wykres obrazujący throughput testu.
Dodaj raport agregujący i ustawiając ilość wątków na dość dużą ilośc (np. 100) oraz ilość powtórzeń na 10. Poeksperymentuj z wartościami timera oraz czasu oczekiwania na odpowiedź tak aby nie było błędów.
Uwaga. Najpierw należy ustawić brokerURL na swoj adres ip, odpalić activeQueue oraz odpalić programik JMSEcho, który będzie odpowiadał na wiadomości. Odpala się go poprzez run tcp://host:port example.Q.REQ example.Q.RPL. Kolejki są zdefiniowane w JNDI (dla JMetera).
Przeprowadź test porównawczy obciążenia kilku serwerów FTP: ftp.{$kraj}.debian.org, dla wartości {$kraj}: pl, us, de, cz, se, przez zalogowanie się na nie anonimowo po FTP i ściągnięcie jednego pliku. Wykorzystaj kontroler ForEach oraz zmienne do iteracji po kolejnych serwerach. Wykorzystaj AggregateGraph Listener do obserwacji wyników.