Inżynieria Oprogramowania Laboratorium

Prezentacja na temat: "Inżynieria Oprogramowania Laboratorium"— Zapis prezentacji:

1 Inżynieria Oprogramowania Laboratorium
mgr inż. Michał Bukowski

2 Temat: Automatyzacja testów
Laboratorium nr 11 Temat: Automatyzacja testów W tej na pozór prostej sprawie panuje wiele zamętu i nieporozumień. Niektórzy twierdzą, że to automatyczne wykonywanie zadań testowych. Inni, bardziej wymagający, głoszą, że dopiero w pełni zautomatyzowane całych serii przypadków testowych, połączone z automatycznym zapisywaniem wyników, sterowaniem przebiegiem pracy w wypadku awarii itd. – zasługuje na miano automatyzacji. Jeszcze inni z kolei wskazują na to, jak wielkie korzyści może przynieść samo np. automatyczne generowanie danych testowych czy automatyczne porównywanie uzyskanych wyników z oczekiwanymi, poprawnymi.

3 Temat: Pożytki z automatyzacji
Laboratorium nr 11 Temat: Pożytki z automatyzacji Narzędzia, tak programowe jak i sprzętowe, właściwie zastosowane, umożliwiają szybsze, precyzyjniejsze, bardziej bezbłędne lub mniej pracochłonne (w porównaniu z ręcznym) wykonywanie rozmaitych z testowaniem związanych czynności. Dodatkową, na pozór trochę niepoważną korzyścią z zastosowania automatyzacji bywa wyeliminowanie nudy - tego zupełnie realnego zagrożenia przy wykonywaniu po raz kolejny tych samych testów. Nuda osłabia motywację, obniża spostrzegawczość, powoduje apatię i przepuszczanie mniej groźnych awarii na zasadzie "po co się męczyć, skoro jakoś działa". Narzędzie, które zamiast testerów wykonuje zadania najbardziej rutynowe, najczęściej powtarzane, najmniej wymagające i - nie bójmy się tego słowa! - najnudniejsze - przyczynia się w ten sposób do lepszego wykonywania testów, nawet jeśli ani ich nie przyśpiesza, ani nie czyni bardziej precyzyjnymi. Uwalniając ludzi od nudnych, rutynowych zadań, zdobywa się dla nich czas potrzebny do pracy bardziej twórczej, jaką jest np. analiza i wybór przypadków testowych. W ten sposób można upiec dwie pieczenie przy jednym ogniu: podnieść zarówno jakość wykonywania testów, jak i motywację, zadowolenie i twórcze myślenie w zespole testowym.

4 Temat: Pożytki z automatyzacji
Laboratorium nr 11 Temat: Pożytki z automatyzacji Szybkość wykonywania testów wzrasta nie tylko dlatego, że automat szybciej niż człowiek wprowadza np. dane do programu. Przede wszystkim automat potrafi pracować nieprzerwanie, 24 godziny na dobę, choćby nawet w sobotę i niedzielę, nie żądając zapłaty za nadgodziny, nie męcząc się, nie tracąc ani na chwilę czujności i staranności. Istotną cechą automatów jest także to, że się nie męczą. Porównanie wyników uzyskanych z oczekiwanymi jest równie staranne za pierwszym, co za setnym razem. Tester, wykonując po raz kolejny te same zadania, popada - świadomie lub nie - w niebezpieczna rutynę (i wspomniane już znudzenie), która nie pozwala mu kontrolować poprawności wyników równie starannie, co na początku; tymczasem nieznużony i niezrażony automat będzie równie cierpliwy i wnikliwy bez względu na ilość powtórzeń.

5 Temat: Niebezpieczeństwa automatyzacji
Laboratorium nr 11 Temat: Niebezpieczeństwa automatyzacji Niedocenianie kosztów wdrożenia automatyzacji; Pominięcie w kalkulacjach czasu potrzebnego na utrzymanie (wprowadzanie zmian) do automatycznych testów, spowodowane niestabilnością ich przedmiotu; Zamiar automatyzacji testów nie został podjęty przez projekt dostatecznie wcześnie. Jeśli architektura i założenia konstrukcyjne systemu są już gotowe, może się okazać, że nie uwzględniono potrzeb automatycznego narzędzia. Nie ma np. potrzebnych portów do komunikacji między narzędziem a testowanym systemem, brak dostatecznej ilości pamięci wewnętrznej, czy też interfejsy nie uwzględniają potrzeb automatyzacji (jak np. dopuszczenie w protokołach komunikacyjnych danych i pakietów umożliwiających pracę narzędzia.

6 Temat: Niebezpieczeństwa automatyzacji c.d.
Laboratorium nr 11 Temat: Niebezpieczeństwa automatyzacji c.d. 4. Liczebność i kwalifikacja zespołu budującego i wdrażającego automatyzację. Jeśli próbuje się to zrobić jednocześnie z testowaniem ręcznym w projekcie (projektach), to potrzebni są ludzie, którzy zaraz zaczną pracować znacznie dłużej, znacznie szybciej lub... znaczne zwiększenie liczby pracowników; 5. Zła architektura programów - jeśli działanie programu testowego polega na tym, by wielokrotnie wprowadzać rozmaite dane osobowe do bazy danych za pośrednictwem tego samego okna dialogowego, to rozwiązanie dobre polega na tym, aby kod - w tej sytuacji w formie prostej pętli - był jeden, zaś same dane (i ewentualnie oczekiwane skutki/wyniki próby ich wprowadzenia) spoczywały w osobnym pliku, skąd program by je sobie po kolei odczytywał. Natomiast rozwiązaniem złym jest napisanie kilkudziesięciu metrów bieżących kodu, gdzie każda (identyczna prócz różnicy w danych) czynność wprowadzania danych jest napisana osobno - kilka tysięcy razy

7 Temat: Niebezpieczeństwa automatyzacji c.d.
Laboratorium nr 11 Temat: Niebezpieczeństwa automatyzacji c.d. Ryzyko niewłaściwego zastosowania modnych narzędzi "zarejestruj-odtwórz". Narzędzia takie (stosowane do graficznych interfejsów typowych systemów i Internetu produkowane są dziś przez kilkuset dostawców) to w istocie dwa narzędzia połączone w jedno. Narzędzia służące do automatycznego wykonywania testów według programów sterujących ich pracą (część "odegraj") są nam bez wątpienia potrzebne - zgoda. Natomiast nie zawsze jasna jest przydatność narzędzi do automatycznego pisania tychże programów za pomocą "nagrywania" zadań testowych wykonywanych ręcznie (część "nagraj") 7. Inwazyjności narzędzi do automatycznego wykonywania testów Gdy narzędzie (do automatycznego wykonywania testów) działa na tej samej maszynie co testowany program, być może dokonuje nawet pewnej instrumentacji kodu lub środowiska tego programu, to oczywiste, że testy automatyczne odbywają się w warunkach wyraźnie innych niż przy obsłudze ręcznej przez użytkownika. Czy można tedy w pełni wierzyć wynikom tych testów? Czy nie może się zdarzyć, że to co działa, gdy używamy narzędzia, nie działa, kiedy pracujemy ręcznie - lub odwrotnie?

8 Temat: Darmowe narzędzia do testowania BUGZILLA
Laboratorium nr 11 Temat: Darmowe narzędzia do testowania BUGZILLA Narzędzie do zarządzania wymaganiami i defektami – BUGZILLA Narzędzie do śledzia błędów w oprogramowaniu z wbudowanym interfejsem sieciowym. Aplikacja napisana jest w Perl, a jej zaplecze stanowi baza danych MySQL. Bugzilla uznawana jest za standardowy system zarządzania błędami, do którego porównuje się wszystkie inne. W tym momencie, Bugzilla jest używana w bardzo wielu firmach do pomocy przy rozwoju ich własnych aplikacji. Bugzilla jest bardzo stabilną aplikacją i oferuje wiele zaawansowanych funkcji. Między innymi: Zintegrowany, oparty na produktach schemat bezpieczeństwa Zależności między błędami i możliwość tworzenia z nich grafów Zaawansowane funkcje związane z raportowaniem błędów Ogromne możliwości konfiguracji Bardzo wygodny i naturalny system rozwiązywania błędów Interfejs do , XML-a, konsoli i HTTP Możliwa integracja z automatycznymi aplikacjami konfiguracji zarządzania, takimi jak Perforce czy CVS (przez interfejs Bugzilli oraz skrypty zapisu/odczytu)

9 Temat: Darmowe narzędzia do testowania BUGZILLA
Laboratorium nr 11 Temat: Darmowe narzędzia do testowania BUGZILLA Kto używa Bugzilli? Lista jest niesamowicie długa: Linux Kernel, Gnome, Open Office, Eclipse, Red Hat, NASA, Alcatel – Lucent, AT&T, Motorola, mplayer, NATO, Siemens, Wikipedia, Yahoo itd. Oprogramowanie jest nie tylko darmowe, ale również bardzo bezpieczne i stabilne. To jak Bugzilla działa w realnym świecie można zobaczyć na przykładzie Mozilli/FireFoxa. Na stronie postawiona jest baza błędów. Można zostać użytkownikiem i samodzielnie raportować błędy. Najnowsza wersja oprogramowania jest do pobrania z: Dostępna jest również polska wersja językowa przygotowana przez Aviary.

10 Temat: Darmowe narzędzia do testowania Mantis
Laboratorium nr 11 Temat: Darmowe narzędzia do testowania Mantis Kolejne narzędzie do śledzenie ewidencjonowania błędów oprogramowania. Napisany jest w PHP z interfejsem webowym i bazą MySQL. Nie jest tak popularny jak wspomniana wyżej Bugzilla, ale ma grono zagorzałych zwolenników. Wyłączne prawa autorskie do tego dokumentu posiadają „testerzy.pl”. Rozpowszechnianie dla celów komercyjnych jak i niekomercyjnych jest dozwolone tylko pod warunkiem podania źródła. Program do pobrania z:

11 Temat: Darmowe narzędzia do testowania TestLink
Laboratorium nr 11 Temat: Darmowe narzędzia do testowania TestLink Jest to aplikacja służąca do zarządzanie i wykonywania testów. Jest niezależna od systemu operacyjnego gdyż oparta jest na interfejsie web-owym. Narzędzie wspiera tworzenie specyfikacji testowej, planowanie, raportowanie oraz zarządzanie wymaganiami. Lista najważniejszych funkcji: 1.produkt testuje się zgodnie z planem testów 2.definiowane role (np. tester, lider) 3.przypadki testowe ułożone są w menu tree 4.oparcie o kluczowe słowa dla łatwiejszego wyszukiwania błędów 5.raporty i metryki 6.export dokumentów do Word, HTML itd. 7.powiązanie z skrzynką ową 8.testowanie oparte na wymaganiach. Aplikację można pobrać z:

12 Temat: Darmowe narzędzia do testowania CVS
Laboratorium nr 11 Temat: Darmowe narzędzia do testowania CVS CVS skrót z angielskiego Concurrent Versions System jest popularnym narzędziem do kontroli wersji. Jego głównym celem jest wpieranie pracy grupowej nad kodem programów. W środowisku testerskim służy głównie do ewidencjonowania i wersjonowania źródeł. Strona, z której można pobrać CVS: Bardzo dobry artykuł o pracy z tym narzędziem znajdziesz na:

13 Temat: Darmowe narzędzia do testowania Subversion
Laboratorium nr 11 Temat: Darmowe narzędzia do testowania Subversion Subversion jest zaawansowanym systemem kontroli wersji, który jest starszym bratem CVS. Funkcjonalnie jest z nim zgodny w większości przypadków. Aplikacja jest dostępna w licencji Opensource Apache. Subversion zapisuje nie tylko zawartość pliku oraz informacje czy dany plik istnieje, ale także położenie pliku w katalogach, jego kopie, zmiany nazw. Pozwala również zapamiętywać właściwości danego pliku lub katalogu np. flagi wykonywalności itp. Zmiany w kilku plikach lub katalogach odnoszą skutek tylko wtedy, gdy każda modyfikacja została zakończona pomyślnie. W CVS możliwa była sytuacja, gdy część plików została zaktualizowana, a część nie, np. w przypadku zerwania połączenia sieciowego. Dodatkowo wprowadzono ważne funkcje takie, jak: uwierzytelnianie i autoryzację użytkowników, kompresję przesyłanych danych, oraz podstawowy dostęp do repozytorium

14 Temat: Darmowe narzędzia do testowania Subversion c.d.
Laboratorium nr 11 Temat: Darmowe narzędzia do testowania Subversion c.d. Pozostałe funkcje: 1. Własny protokół klient/serwer. 2. Protokół umożliwia przesyłanie różnic w plikach od klienta do serwera i odwrotnie. 3. Rozmiar przesyłanych danych przy zmianie pliku jest proporcjonalny do rozmiaru zmian, a nie pliku. 4. Efektywna obsługa plików binarnych. 5. Repozytorium przechowywane w bazie danych lub w systemie plików. Narzędzie do pobrania ze strony:

15 Temat: Darmowe narzędzia do testowania WAST – testowanie obciążeniowe
Laboratorium nr 11 Temat: Darmowe narzędzia do testowania WAST – testowanie obciążeniowe Skromna aplikacja wyprodukowana przez Microsoft (!) i o dziwo darmowa. WAST to skrót od Web Application Stress Tool i oznacza mniej więcej tyle, że jest to aplikacja do obciążania aplikacji w sieci. Możliwe jest tworzenie własnych skryptów oraz nagrywanie akcji użytkownika. Dostępna jest instrukcja obsługi na stronie: Samo narzędzie do pobrania z:

16 Podręcznik użytkownika dostępny na stronie:
Laboratorium nr 11 Temat: Darmowe narzędzia do testowania JMeter – testowanie obciążeniowe Kolejna aplikacja do testowania obciążenie HTTP oraz FTP. Symuluje ona rzeczywiste działania użytkowników w sieci. Podręcznik użytkownika dostępny na stronie: Istnieje również ciekawy artykuł opisujący po polsku działanie JMeter: Aplikacja do pobrania z:

17 Temat: JMeter – budowa narzędzia
Laboratorium nr 11 Temat: JMeter – budowa narzędzia Po uruchomieniu JMeter-a zobaczymy ekran startowy, na którym można wyróżnić trzy ważne elementy: a) Plan Testów (ang. Test Plan) – przechowuje aktualną konfigurację testową, czyli plan testu i umożliwia jego uruchamianie b) Brudnopis (przestrzeń robocza) – służy do tworzenia i konfigurowania testów do późniejszego wykorzystania, jeżeli praca nad testem w przestrzeni roboczej zostanie zakończona wówczas można skopiować go do węzła plan testów. c) Grupa Wątków (ang. Thread Group) – są to wirtualni użytkownicy, każdy jeden wątek symuluje działania jednego użytkownika

18 Temat: JMeter – budowa narzędzia c.d.
Laboratorium nr 11 Temat: JMeter – budowa narzędzia c.d. Używanie JMeter - a wymaga zastosowania planu testowego. Plan testów jest opisem poszczególnych kroków które musi wykonad dane narzędzie w celu sprawdzenia poprawności badanego systemu (przetestowania). W celu stworzenia takiego planu wykorzystujemy grupę wątków, każdy z wątków ma za zadanie symulowanie określonego działania użytkownika. JMeter posiada następujące rodzaje wątków, które wykonują określone interakcje w czasie odtwarzania scenariusza testowego: a) Sampler – dzięki temu elementowi JMeter może wysyłać specyficzne zapytania do serwera. Może generować między innymi żądania typu HTTP, HTTPS, FTP, SOAP, JDBC, Java i inne. Każdy rodzaj zapytań posiada odpowiednie parametry takie jak na przykład różne atrybuty, czas działania i inne. Domyślnie JMeter wysyła zapytania do serwera w kolejności, w której pojawią się one w planie testu, istnieje jednak możliwość zmiany tej kolejności poprzez użycie opcji logic controller.

19 Temat: JMeter – budowa narzędzia c.d.
Laboratorium nr 11 Temat: JMeter – budowa narzędzia c.d. b) Logic Controller – określa kolejność działania Samplersów w grupie wątków testowanej aplikacji. Obiekt typu logic controller jest stosowany wówczas kiedy generacja żądania zależy od pewnej logiki. Opisywany element może również zmieniać kolejność zapytań pochodzących z elementów podrzędnych (sub - elementów oraz potomków elementów). Swoim działaniem przypomina konstrukcje podobne do pętli znanych z języków programowania typu if-then-else, loop oraz when. c) Listener – następny element który możemy umieścić w naszym planie testu, listener pozwala na raportowanie wyników testu w postaci tabeli, wykresu graficznego, drzewa elementów lub plików typu CSV/XML. Każdy rodzaj listenera w specyficzny sposób informuje o przebiegu testów, jeżeli na przykład zależy nam na graficznym wglądzie do uzyskanych wyników testów należy skorzystać z listenera typu aggregate graph. d) Asseration – jest to warunek końcowy na odpowiedzi generowane przez serwer. Warunki te mogą dotyczyć zawartości, jak i czasu otrzymania odpowiedzi wygenerowanej przez aplikację na żądanie wirtualnego użytkownika. Opisany element pozwala określić czy JMeter zwraca oczekiwane wyniki.

20 Temat: JMeter – budowa narzędzia c.d.
Laboratorium nr 11 Temat: JMeter – budowa narzędzia c.d. e) Timer – jest to komponent dzięki któremu możemy w naszym planie testu wprowadzać przerwy o określonej długości w milisekundach. Poprzez swoje działanie timery pozwalają na dokładniejsze odzwierciedlenie działania testowanej aplikacji. Domyślnie JMeter wysyła zapytania bez przerw, stąd sami musimy pamiętać o stosowaniu Timerów wtedy kiedy jest to konieczne. Mamy możliwość doboru rodzaju opóźnienia poprzez wybór losowych lub stałych opóźnień. Opóźnienia generowane poprzez Timery są przydatne podczas wykonywania testów funkcjonalnych aplikacji. f) Config Element – ściśle współpracują z Samplerami, pozwalają na dodanie modyfikowanych zapytań, jako przykład możemy tutaj podać sytuację w której config element pozwala na taką modyfikację Samplera, aby ten wysyłał zapytania do serwera losowo. g) Pre Processor – często używany do modyfikacji ustawień Samplerów przed ich uruchomieniem lub w celu modyfikacji zmiennych wydobytych z odpowiedzi danego Samplera. h) Post Processor – jest to funkcja uruchamiana po wykonaniu zapytania przez Samplera. Dobrze jest umiejscawiać je jako element potomka Samplera w celu upewnienia się, że Sampler zostanie użyty w odpowiedniej kolejności. Element ten jest stosowany zazwyczaj jako element w procesach odpowiedzi danych w celu odnalezienia szczególnych wartości dla późniejszego użytku

21 Temat: JMeter – praktyczne testy aplikacji Web
Laboratorium nr 11 Temat: JMeter – praktyczne testy aplikacji Web Test wydajnościowy został wykonany poprzez wykorzystanie strony producenta narzędzia JMeter dostępnej pod adresem: Na poniższym rysunku została przedstawiona część testowanej w niniejszym podpunkcie strony.

22 Temat: JMeter – praktyczne testy aplikacji Web c.d.
Laboratorium nr 11 Temat: JMeter – praktyczne testy aplikacji Web c.d. W pierwszej kolejności po uruchomieniu aplikacji JMeter musimy zadbać o odpowiednie skonfigurowanie serwerów proxy. Pozwoli to na identyfikację IP z którego korzystamy jako localhost. W tym celu nasz test rozpoczynamy od dodania do naszej przestrzeni roboczej elementu odpowiadającego za ustawienie odpowiedniego serwera oraz portu – HTTP Proxy Server. Jako dane podajemy numer portu dla którego chcemy przeprowadzić test - w tym przypadku będzie to 8080. Po tej krótkiej konfiguracji wciskamy przycisk Start.

23 Temat: JMeter – praktyczne testy aplikacji Web c.d.
Laboratorium nr 11 Temat: JMeter – praktyczne testy aplikacji Web c.d. W następnym kroku należy skonfigurować odpowiednio przeglądarkę na której został wykonany test. W związku z tym, że w teście korzystamy z przeglądarki Mozilla FireFox przechodzimy do opcji tej przeglądarki, a następnie wybieramy Zaawansowane/Sieć/Ustawienia. W nowo otwartym oknie ustawimy wartość jak na rysunku.

24 Temat: JMeter – praktyczne testy aplikacji Web c.d.
Laboratorium nr 11 Temat: JMeter – praktyczne testy aplikacji Web c.d. Po odpowiedniej konfiguracji ustawień serwera proxy, przeładowujemy naszą przeglądarkę (w oknie przeglądarki musimy mieć ustawioną witrynę którą testujemy). Po kilku sekundach zauważymy, że w przestrzeni roboczej naszej przeglądarki pojawiły się nowe kroki.

25 Temat: JMeter – praktyczne testy aplikacji Web c.d.
Laboratorium nr 11 Temat: JMeter – praktyczne testy aplikacji Web c.d. Po dokładniejszym przyjrzeniu się poszczególnym elementom dodanym do przestrzeni roboczej zauważamy, że są to poszczególne elementy naszej strony, które dodatkowo zawierają wartości takie jak ścieżka (Path), nazwę serwera oraz informacje o przeglądarce. Na rysunku znajduje się przykładowy element z opisanymi parametrami.

26 Temat: JMeter – praktyczne testy aplikacji Web c.d.
Laboratorium nr 11 Temat: JMeter – praktyczne testy aplikacji Web c.d. W pierwszej kolejności do węzła plan testów dokładamy grupę wątków. Do grupy wątków musimy dołożyć elementy które będą stanowiły nasz plan testowania. W tym celu zastosujemy niektóre nagrane przez nas w poprzednich działaniach elementy. W związku z tym kopiujemy wybrane elementy witryny z przestrzeni roboczej do grupy wątków w planie testów. Po tych działaniach mamy wstępnie przygotowany plan testów, który możemy zobaczyć na poniższym rysunku:

27 Temat: JMeter – praktyczne testy aplikacji Web c.d.
Laboratorium nr 11 Temat: JMeter – praktyczne testy aplikacji Web c.d. Jak możemy zauważyć na powyższym zrzucie ekranu w naszym planie testowym zostały użyte dwa zapytania, według których w dalszej kolejności został wykonany test. W naszym planie wykorzystaliśmy opcje domyślne ustawione w grupie wątków: liczba użytkowników jest równa jeden, a cały test jest wykonywany również jednokrotnie.

28 Temat: JMeter – praktyczne testy aplikacji Web c.d.
Laboratorium nr 11 Temat: JMeter – praktyczne testy aplikacji Web c.d. Jednak przed przystąpieniem do odtwarzania naszego testu należało dodać jeszcze jeden element dzięki któremu uzyskaliśmy wgląd do wyników naszego testu. Tym elementem w przypadku niniejszego testu był listener – a dokładnie jeden z jego typów nazwany Summary Report. Aby dodać ten element do naszego planu testowego wybieramy kolejno Add/Listener/Summary_Report. Po dodaniu tego elementu nasz test jest gotowy do użycia. Ostateczna struktura naszego testu została zaprezentowana na poniższym rysunku:

29 Temat: JMeter – praktyczne testy aplikacji Web c.d.
Laboratorium nr 11 Temat: JMeter – praktyczne testy aplikacji Web c.d. Jednak przed przystąpieniem do odtwarzania naszego testu należało dodać jeszcze jeden element dzięki któremu uzyskaliśmy wgląd do wyników naszego testu. Tym elementem w przypadku niniejszego testu był listener – a dokładnie jeden z jego typów nazwany Summary Report. Aby dodać ten element do naszego planu testowego wybieramy kolejno Add/Listener/Summary_Report. Po dodaniu tego elementu nasz test jest gotowy do użycia. Ostateczna struktura naszego testu została zaprezentowana na poniższym rysunku:

30 Temat: JMeter – praktyczne testy aplikacji Web c.d.
Laboratorium nr 11 Temat: JMeter – praktyczne testy aplikacji Web c.d. W tym momencie możemy przystąpić do wykonania naszego testu, w tym celu z górnego menu wybieramy opcje Run/Start, po kilku sekundach otrzymujemy oczekiwane wyniki, które możemy zobaczyć w elemencie Summary Report:

31 Temat: JMeter – praktyczne testy aplikacji Web c.d.
Laboratorium nr 11 Temat: JMeter – praktyczne testy aplikacji Web c.d. Jak widzimy na powyższym rysunku nasz test zakończył się sukcesem. JMeter przeszedł dwa założone przez nas w planie testowym kroki skonfigurowane dla domyślnej liczby użytkowników. Kiedy uczestniczymy w rzeczywistym projekcie informatycznym dane które zostały przedstawione w powyższej tabeli podlegają dalszej analizie oraz ocenie z punktu poprawności oraz dokładności. Na podstawie wyników możemy stwierdzić, że test wykonał się poprawnie – nie zarejestrowano żadnych błędów. W raporcie możemy znaleźć również informacje dotyczące czasów dostępu: średniego, minimalnego oraz maksymalnego (czasy podane są w milisekundach). Ważnymi danymi jeżeli mówimy o testowaniu serwisów WWW jest z pewnością przepustowość łączy – w naszym raporcie również taka wartość się znajduje.

32 Temat: JMeter – praktyczne testy aplikacji Web c.d.
Laboratorium nr 11 Temat: JMeter – praktyczne testy aplikacji Web c.d. Następnie należy również wspomnieć o uzyskanych informacjach odnośnie ilości przesłanych danych –wyrażonej w bajtach oraz o szybkości ładowania poszczególnych ścieżek podanych w KB/sek. Wszystkie dane podane zostały dla poszczególnych ścieżek naszego testu, jak również ostatni wiersz stanowi zsumowanie wszystkich danych i przedstawienie wyników dla całego testu.

33 Temat: JMeter – praktyczne testy aplikacji Web c.d.
Laboratorium nr 11 Temat: JMeter – praktyczne testy aplikacji Web c.d. Strona WWW została wykonana w PHP5 z wykorzystaniem technologii takich jak JavaScript, XML, XHTML oraz CSS, jako baza danych został wykorzystany mySQL. Projekt strony został umieszczony na serwerze, w celu jego przetestowania z uwzględnieniem narzędzia JMeter. W niniejszym podpunkcie nadal korzystamy z przeglądarki FireFox w wersji Przystępując do naszego testu w oknie przeglądarki ustawiamy testowaną stronę.

34 Temat: JMeter – praktyczne testy aplikacji Web c.d.
Laboratorium nr 11 Temat: JMeter – praktyczne testy aplikacji Web c.d. Cały test dla danych zawartych w naszym teście trwa około trzydziestu minut. Po jego zakończeniu możemy zobaczyć wyniki przedstawione na elementach typu Listener. Jako pierwszy został przedstawiony element Summary Report. Na poniższym rysunku możemy zaobserwować różne wartości takie jak między innym: czas średniego, minimalnego oraz maksymalnego wczytywania się danych elementów. Z poniższych parametrów możemy wywnioskować, że czasy dostępu dla poszczególnych elementów są akceptowalne. Jednak dla dwóch wartości występują błędy: dla jednego wynosi on 0,29% a dla drugiego przypadku: 0,30%. Błędy są spowodowane tym, że te dwa elementy są stosunkowo duże w porównaniu z innymi stąd też czas dostępu do nich jest większy

35 Temat: JMeter – praktyczne testy aplikacji Web c.d.
Laboratorium nr 11 Temat: JMeter – praktyczne testy aplikacji Web c.d. Kolejnym elementem który ułatwi nam analizę wyników testu jest Graph Results. Element ten w bardzo przejrzysty i klarowny sposób pokazuje wyniki testu. Wszystkie dane pokazane są w postaci wykresu. W oknie tego elementu istniej również możliwość przefiltrowania odpowiednich wyników.