Testowanie wydajności API w środowisku rozproszonym. Część 4. Opracowanie wyników

Testy zostaną uruchomione w następujących konfiguracjach:

1. Dla 10 użytkowników (testy linii podstawowej).
2. Dla 30 użytkowników jednocześnie (testy obciążeniowe).
3. Dla 100 użytkowników jednocześnie (testy przeciążeniowe).

Zebrane wyniki testów będą zawierały informacje:

1. Czas odpowiedzi serwera dla wszystkich rodzajów przeprowadzonych testów.
2. Średni czas odpowiedzi serwera.
3. Wyniki zaplanowanych testów – z informacją o sukcesie lub błędzie.
4. Sumaryczna liczba przetworzonych żądań.
5. Informacje o zużyciu zasobów sprzętowych.

Wyniki zostały wygenerowane automatycznie i zapisane we wskazanej ścieżce w narzędziu JMeter w formacie strony html. Następnie zebrane dane zostały przedstawione w formie tabelarycznej i omówione w kolejnej części pracy. 

Testy linii podstawowej

Dla 10 użytkowników

Testy linii podstawowej zgodnie z założeniami wynikającymi z planu testów wykonano dla 10 użytkowników z następującymi parametrami:

• Liczba jednoczesnych wątków: 10.
• Czas trwania: 7 minut.

W tab. 7 zaprezentowano wyniki z przeprowadzonych testów linii podstawowej. Wszystkie zaplanowane przypadki testowe zakończyły się poprawnie i bez błędów funkcjonalnych. Czasy odpowiedzi zgodnie z założeniem z planu testów są na akceptowalnie niskim poziomie i średnio nie przekraczają 22 ms.  

Wskaźnik APDEX na poziomie 1 oznacza najwyższą wydajność i nie przekroczenie założonych wcześniej progów tolerancji na poziomie 500 ms. 

W szczytowych momentach trwania testów zużycie procesora wyniosło 21% co widać na rys. 9. Wynik ten również spełnia przyjęte kryteria jakości.  

Rys. 9 Przypadek Testowy 4 – zaktualizuj rezerwację – zużycie procesora wyrażone w procentach (oś Y) w czasie trwania testów (oś X) dla 10 użytkowników

Testy obciążeniowe

Dla 30 użytkowników

Testy obciążeniowe zgodnie z założeniami wynikającymi z planu testów wykonano dla 30 użytkowników z następującymi parametrami:

• Liczba jednoczesnych wątków: 30.
• Czas trwania: 7 minut.

Wyniki testów obciążeniowych pokazane w tab. 8 pokazują pierwsze problemy z wydajnością. Przy zasymulowanym 30 jednoczesnych użytkownikach czasy odpowiedzi serwera na żądania wydłużyły się znacząco dla pierwszego (rys. 10), trzeciego (rys. 11) i czwartego (rys.12) przypadku testowego i nie spełniają założonych kryteriów jakości. Z powodu przekroczenia wskaźników progu tolerancji na czas odpowiedzi na wysyłane żądania, który wynosi 500 ms również ogólna ocena wydajności APDEX spadła poniżej 1 dla wymienionych trzech z czterech przypadków testowych. Na tym etapie można zauważyć i zidentyfikować wąskie gardła, które określają najwolniej działające komponenty aplikacji. Zalecana jest analiza tych komponentów i dodatkowy przegląd kodu celem ustalenia przyczyn obniżonej wydajności systemu.

Rys. 10 Przypadek Testowy 1 - Wyszukaj rezerwację – uśrednione czasy odpowiedzi żądań do serwera w czasie trwania testów dla 30 użytkowników

Rys. 11 Przypadek Testowy 3 – Usuń rezerwację – uśrednione czasy odpowiedzi żądań do serwera w czasie trwania testów dla 30 użytkowników

Rys. 12 Przypadek Testowy 4 – Aktualizuj rezerwację – uśrednione czasy odpowiedzi żądań do serwera w czasie trwania testów dla 30 użytkowników

Podczas tej rundy testów największymi czasami odpowiedzi, a zarazem najgorszą wydajnością wykazała się funkcjonalność aktualizacji danych z systemu, która była testowana w trakcie uruchomienia czwartego przypadku testowego – zaktualizuj rezerwację. 

W tym miejscu należy zauważyć, iż podczas wykonywania pierwszego przypadku testowego jakim jest wyszukanie rezerwacji w systemie, zużycie procesora wzrosło w szczytowym momencie do 50% co można zaobserwować na rys. 13. Zdefiniowanym założeniem testów obciążeniowych dla 30 jednoczesnych użytkowników jeśli chodzi o utylizację CPU było nie przekroczenie progu 80%, 
a więc to założenie zostało spełnione. Niemniej jednak w tej sytuacji rekomenduje się przeprowadzenie analizy testowanego komponentu, czyli wyszukiwania rezerwacji.

Rys. 13 Przypadek Testowy 1 – wyszukaj rezerwację – zużycie procesora wyrażone w procentach (oś Y) w czasie trwania testów (oś X) dla 30 użytkowników

Testy przeciążeniowe

Dla 100 użytkowników

Testy przeciążeniowe zgodnie z założeniami wynikającymi z planu testów wykonano dla 100 użytkowników z następującymi parametrami:

• Liczba jednoczesnych wątków: 100.
• Czas trwania: 7 minut.

Na podstawie danych z tab. 9 prezentujących wyniki testów przeciążeniowych zaobserwowano poważne problemy z wydajnością i działaniem aplikacji „restful-booker”. Wszystkie testy zakończyły się bez błędu, natomiast czasy odpowiedzi na żądania podczas trwania testów były na nieakceptowalnie niskim poziomie. 

Dla przypadków testowych numer jeden (rys. 14), trzy (rys. 15) i cztery (rys. 16) wskaźnik ogólnej wydajności spadł znacząco. Progi frustracji ustalone na 1500 ms zostały przekroczone, co przełożyło się na bardzo niską ocenę według kryterium APDEX. 
Z powyższych wyników można jednoznacznie wywnioskować, że badana aplikacja nie poradzi sobie z jednocześnie pracującymi 100 użytkownikami, zwalniając swoje działanie do stopnia nieużywalności. 

Rys. 14 Przypadek Testowy 1 – Wyszukaj rezerwacje – uśrednione czasy odpowiedzi żądań do serwera w czasie trwania testów dla 100 użytkowników

Rys. 15 Przypadek Testowy 3 – Usuń rezerwację – uśrednione czasy odpowiedzi żądań do serwera w czasie trwania testów dla 100 użytkowników

Rys. 16 Przypadek Testowy 4 – Zaktualizuj rezerwację – uśrednione czasy odpowiedzi żądań do serwera w czasie trwania testów dla 100 użytkowników

W szczytowym momencie dla przypadku testowego numer trzy, czyli usuwania rezerwacji, zużycie procesora wyniosło 81% - widoczne na rys. 17. Oznacza to, że oprócz słabej wydajności aplikacji również zasoby sprzętowe są wykorzystywane w znacznym stopniu.

Rys. 17 Przypadek Testowy 3 – Usuń rezerwację – zużycie procesora wyrażone w procentach (oś Y) w czasie trwania testów (oś X) dla 100 użytkowników

Jeśli w systemie w warunkach produkcyjnym doszłoby do skoku jednocześnie pracujących użytkowników wynoszącym 100, to aplikacja przestałaby spełniać swoje kryteria jakościowe, a potencjalni użytkownicy mogliby zrezygnować z dalszego jej używania.

Wnioski końcowe

Wszystkie przeprowadzone testy zostały wykonane zgodnie z planem testów. 

Z wyników można wywnioskować, że testowana aplikacja "restful-booker" spełnia założone wymagania wydajności jedynie dla 10 jednocześnie pracujących użytkowników. Dalsze testy obciążeniowe i przeciążeniowe wykazały problemy z czasami odpowiedzi serwera oraz zwiększonym zużyciem procesora serwera wraz ze wzrostem liczby wątków działających w tym samym czasie. Powodami obniżonej wydajności może być nieoptymalnie napisany kod aplikacji lub zbyt małe zasoby sprzętowe serwera. 

Wydajność aplikacji internetowych ma ogromne znaczenie w dzisiejszym świecie. W kontekście biznesowym, to jak szybko aplikacja reaguje na kliknięcia użytkownika i jego zapytania do serwera determinuje sukces komercyjny oprogramowania. Przedsiębiorstwa, które nie sprawdzają wydajności swoich systemów przed publikacją produktu mogą stracić reputacje i pieniądze jeśli nie testują swoich aplikacji pod kątem wydajności. W procesie wytwarzania oprogramowania zapewnienie jakości dostarczanego produktu jest bardzo istotne, a sama wydajność oprogramowania staje się obecnie kluczowa. Przeciętny konsument i użytkownik Internetu w przypadku, gdy przykładowa aplikacja nie spełnia jego oczekiwań np. poprzez długie ładowanie się strony wybierze inne oprogramowanie do zaspokojenia swoich potrzeb. 

Istnieje wiele różnych metod testowania wydajności aplikacji. W pracy inżynierskiej pokazano przykłady jak posługiwać się narzędziem do weryfikacji wydajności na podstawie przykładowej aplikacji typu REST API, które realnie pokazują jak sprawdzać tę niezwykle istotną charakterystykę oprogramowania. Optymalizacja oprogramowania pod kątem zużywanych zasobów serwera również pozostaje nie bez znaczenia. Usługi hostingowe i przechowywanie danych w chmurze generują koszty. Podczas gdy aplikacja nad którą trwają prace nie jest odpowiednio zoptymalizowana zużyje tych zasobów więcej, a co za tym idzie wzrosną wydatki firmowe na utrzymanie środowiska produkcyjnego.

Część trzecią pracy znajdziesz tutaj.

Całą pracę znajdziesz poniżej:

*) Od autora pracy: 
"Z niniejszej publikacji usunięto wstęp związany ściśle z zagadnieniem samego testowania oprogramowania. Nacisk tej publikacji skierowany jest na testy wydajności wraz ze sprawozdaniem z przebiegu wykonania tych prac. Pomysł na temat obrony dyplomu i publikacji tego artykułu był prosty – ja jako autor chciałem nauczyć się nowej umiejętności w moim testerskim przyborniku, a z wami czytelnikami chciałem podzielić się efektem mojej kilkumiesięcznej pracy, na którą złożyła się nauka testowania wydajności od zupełnych podstaw, przez implementację rozwiązania w JMeter, a także stworzenie raportu. Cel został osiągnięty poprzez znalezienie wielu źródeł w postaci teorii testowania wydajności, a przede wszystkim znalezieniu informacji na temat dobrych praktyk i przykładów jak zaplanować i wykonać tego typu testy. Puentą jest to, jak to w projekcie informatycznym, czyli dostarczenie pewnej wartości w postaci przeprowadzenia i wykonaniem testów wydajności wraz z raportem i wnioskami. Z perspektywy czasu wiele rzeczy bym zmienił, natomiast myślę, że ten artykuł może komuś jeszcze posłuży."

*) Publikacja ta jest skróconą wersją pracy dyplomowej.
Autor: Michał Zacharuk
Tytuł pracy: "Testowanie wydajności API w środowisku rozproszonym"
Uczelnia: Politechnika Łódzka, Wydział Elektrotechniki, Elektroniki, Informatyki i Automatyki
Instytut Informatyki Stosowanej
Opis: Przedstawienie i rozwiązanie problemu testowania wydajności aplikacji internetowej opartej na REST API w środowisku rozproszonym. Skrócona wersja pracy dyplomowej.

Bibliografia:
Adam Roman, "Testowanie i jakość oprogramowania Modele, techniki, narzędzia", Wydawnictwo Naukowe PWN SA, Warszawa 2018.
ISTQB Certyfikowany Tester - Poziom Podstawowy 2018 – Sylabus, International Software Testing Qualifications Board, 2018
Myers G., "Projektowanie niezawodnego oprogramowania", Wydawnictwa Naukowo-Techniczne, Warszawa 1980.
Myers G., "The Art Of Software Testing", Wiley, New York 1979.
Hetzel W.C., "The Complete Guide to Software Testing", John Wiley & Sons, 1988
Miller E., "Introduction to Software Testing Technology" w: Tutorial: Software Testing & Validation, IEEE Catalog No. EHO 180-0
IEEE 610 IEEE Standard Glossary of Software Engineering Technology Terminology, The Institue of Electrical and Electronics Engineers, New York, 1990
IEEE 829 Standard for Software and System Test Documentation, IEEE Computer Society, 2008
Apache License, Version 2.0, https://www.apache.org/licenses/LICENSE-2.0
ISTQB Moduł Specjalistyczny Poziomu Podstawowego - Tester Wydajności, International Software Testing Qualifications Board, 2020
Mark Winteringham, "Restful Booker" https://restful-booker.herokuapp.com/
Paweł Marek, "Weryfikacja i automatyzacja procesu testowania oprogramowania", Core Magazine No 6, Lipiec 2011
https://testerzy.pl/baza-wiedzy/artykuly/ocena-jakosci-oprogramowania, 2020
https://testerzy.pl/baza-wiedzy/testowanie-oprogramowania, 2017
https://testerzy.pl/baza-wiedzy/piramida-potrzeb-uzytkownika-produkt-o-minimalnej-koniecznej-funkcjonalnosci, 2015
Radosław Smilgin, "Praktyka testowania", Wydawnictwo Naukowe PWN, Warszawa 2020