Testy Wydajno┼Ťciowe ­čŤá. Podstawy ­čöŹ

Hej.

Ten wpis jest pierwszym z artyku┼é├│w o testach wydajno┼Ťciowych. Je┼╝eli dopiero zaczynasz w tym temacie to bardzo dobrze trafi┼ée┼Ť. W trakcie tej serii poznasz podstawy i razem ze mn─ů napiszesz pierwsze zautomatyzowane testy sprawdzaj─ůce wydajno┼Ť─ç twojej aplikacji.


W dzisiejszym wpisie dowiesz si─Ö:

Ôťů czym s─ů testy wydajno┼Ťci
Ôťů po co testowa─ç wydajno┼Ť─ç
Ôťů jakie s─ů rodzaje test├│w wydajno┼Ťci
Ôťů jak wygl─ůda flow pisania takich test├│w
Ôťů jakie metryki mo┼╝na zbiera─ç
Ôťů przyk┼éadowe przypadki testowe

 

Zaczynajmy… ­čöą­čöą­čöą


Czym s─ů testy wydajno┼Ťci

znak-zapytania

Celem test├│w wydajno┼Ťci jest – tak jak w ka┼╝dym innym rodzaju test├│w – sprawdzenie czy nasz program dzia┼éa zgodnie z oczekiwaniami. Natomiast w tego rodzaju testach weryfikujemy nieco inne metryki. Do takich metryk mog─ů nale┼╝e─ç np. szybko┼Ť─ç, czas odpowiedzi, niezawodno┼Ť─ç, wykorzystanie zasob├│w czy te┼╝ skalowalno┼Ť─ç programu przy oczekiwanym obci─ů┼╝eniu.

Testuj─ůc okre┼Ťlon─ů metryk─Ö zawsze robimy jakie┼Ť za┼éo┼╝enie. We┼║my na przyk┼éad testowanie niezawodno┼Ťci aplikacji. Chcemy zweryfikowa─ç, ┼╝e nasza aplikacja zachowuje si─Ö odpowiednio przy okre┼Ťlonej ilo┼Ťci ┼╝─ůda┼ä do naszego serwera (zak┼éadamy ┼╝e to aplikacja webowa). Obecnie do naszego serwera trafia oko┼éo 100 request├│w / min. Mo┼╝emy zrobi─ç za┼éo┼╝enie ok.. a co si─Ö stanie jak zaczniemy dostawa─ç 400 req/min? Czy nasza aplikacja dalej b─Ödzie stabilna?

Inny przyk┼éad – testowanie skalowalno┼Ťci. Nasz ┼Ťredni ruch na stronie wynosi 50 unikalnych u┼╝ytkownik├│w / min. Biznes zak┼éada, ┼╝e w najbli┼╝szych miesi─ůcach ruch na stronie mo┼╝e zwi─Ökszy─ç si─Ö nawet 10-krotnie. Co teraz?

Na oba powy┼╝sze przypadki nie mo┼╝emy jednoznacznie odpowiedzie─ç, ┼╝e wszystko b─Ödzie dobrze bo u koleg├│w kt├│rzy maj─ů podobn─ů aplikacj─Ö dzia┼éa. Musimy to jako┼Ť zweryfikowa─ç i w┼éa┼Ťnie do tego przydadz─ů nam si─Ö testy wydajno┼Ťciowe.

Poda┼éem tutaj przyk┼éady typowo webowe. Ale testowanie wydajno┼Ťci to nie tylko web – mo┼╝emy tak┼╝e testowa─ç bazy danych, sie─ç czy te┼╝ zasoby systemu operacyjnego. Co jest wa┼╝ne i kluczowe do zapami─Ötania – celem test├│w wydajno┼Ťciowych nie jest znalezienie usterek funkcjonalnych ale wyeliminowanie w─ůskich garde┼é w naszym oprogramowaniu.


Po co testowa─ç wydajno┼Ť─ç

Performance Testing

Wi─Ökszo┼Ť─ç aplikacji na rynku komercyjnym ma lub b─Ödzie mie─ç klient├│w. Wi─Öksza czy mniejsza skala – nie wa┼╝ne – wa┼╝ne, ┼╝e kto┼Ť polega na naszym produkcie, czymkolwiek to jest. Aplikacje biznesowe powstaj─ů dla biznesu – chyba nie musz─Ö Ci─Ö o tym przekonywa─ç?

Skoro aplikacje jakie tworzymy s─ů lub maj─ů by─ç sprzedawane to naszym obowi─ůzkiem jest zapewnienie, aby dzia┼éa┼éy prawid┼éowo. Maj─ůc testy wydajno┼Ťciowe w naszych aplikacjach jeste┼Ťmy w stanie zweryfikowa─ç ich dzia┼éanie. Dzi─Öki testom mo┼╝emy tak┼╝e zakomunikowa─ç biznesowi potencjalne problemy. B─Ödziemy te┼╝ umieli odpowiedzie─ç na pytania z jakimi ludzie od biznesu mog─ů do nas przyj┼Ť─ç, np. czy mo┼╝e sta─ç si─Ö co┼Ť z┼éego je┼╝eli wypu┼Ťcimy nasze oprogramowanie w 3 kolejnych pa┼ästwach? Bez test├│w wydajno┼Ťci ci─Ö┼╝ko nam b─Ödzie na to odpowiedzie─ç – a na pewno nie damy sobie za to r─Öki uci─ů─ç (cho─ç dobrze radz─Ö, nawet jak mamy takie testy to i tak nie dawajmy tej r─Öki).

Badanie wydajno┼Ťci aplikacji okre┼Ťli czy nasze oprogramowanie spe┼énia wymagania dotycz─ůce pr─Ödko┼Ťci, skalowalno┼Ťci czy te┼╝ stabilno┼Ťci przy spodziewanym obci─ů┼╝eniu. Nale┼╝y pami─Öta─ç, ┼╝e produkt cechuj─ůcy si─Ö nisk─ů wydajno┼Ťci─ů zyskuje z┼é─ů reputacj─Ö – a ten parametr cie┼╝ko jest odbudowa─ç w dzisiejszym ┼Ťwiecie, gdzie konkurencja jest ogromna.

Ostatnim wa┼╝nym aspektem s─ů jeszcze pieni─ůdze. Cho─ç mam nadziej─Ö, ┼╝e zrozumia┼ée┼Ť przes┼éank─Ö z biznesem o kt├│rej wspomina┼éem wy┼╝ej – to mimo wszystko pami─Ötajmy, ┼╝e ka┼╝dy produkt pracuje i w jaki┼Ť spos├│b ma zarabia─ç pieni─ůdze. Niedost─Öpno┼Ť─ç aplikacji tylko dlatego, ┼╝e ┼║le ustawili┼Ťmy jaki┼Ť parametr i na nasz─ů stron─Ö mo┼╝e wej┼Ť─ç maksymalnie 10 u┼╝ytkownik├│w jednocze┼Ťnie mo┼╝e sporo kosztowa─ç. A co by tu du┼╝o gada─ç – jak w wi─Ökszo┼Ťci sytuacji wygl─ůdaj─ů testy manualne naszych aplikacji? Kilku tester├│w i deweloper├│w nie oddaj─ů tego co si─Ö dzieje na produkcji (cho─ç czasami mo┼╝e i tak).


Rodzaje test├│w wydajno┼Ťci

rodzaje testow wydajnosci

Testowanie obci─ů┼╝enia – sprawdza zdolno┼Ť─ç aplikacji do dzia┼éania przy przewidywanym obci─ů┼╝eniu u┼╝ytkownik├│w. Celem jest zidentyfikowanie w─ůskich garde┼é wydajno┼Ťciowych zanim aplikacja zostanie uruchomiona.

Stress testy – polegaj─ů na testowaniu aplikacji przy ekstremalnym obci─ů┼╝eniu, aby sprawdzi─ç, jak radzi sobie z du┼╝ym ruchem lub przetwarzaniem danych. Celem jest zidentyfikowanie punktu przerwania pracy aplikacji.

Testy wytrzyma┼éo┼Ťciowe (endurance tests) – s─ů wykonywane w celu upewnienia si─Ö, ┼╝e oprogramowanie jest w stanie obs┼éu┼╝y─ç oczekiwane obci─ů┼╝enie przez d┼éugi okres czasu.

Spike testy – testuje reakcj─Ö oprogramowania na nag┼ée du┼╝e skoki obci─ů┼╝enia generowanego przez u┼╝ytkownik├│w.

Volume testy – testuj─ů zachowanie aplikacji kiedy aplikacja posiada ogromn─ů ilo┼Ť─ç zgromadzonych danych (np. w bazie danych). Monitorowane jest og├│lne zachowanie systemu. Celem badania jest sprawdzenie wydajno┼Ťci aplikacji pod r├│┼╝nym ÔÇÜobci─ů┼╝eniemÔÇÖ danych.

Testowanie skalowalno┼Ťci – celem testowania skalowalno┼Ťci jest okre┼Ťlenie w jakim stopniu „skalowalna” jest aplikacja w przypadku wzrostu obci─ů┼╝enia przez u┼╝ytkownik├│w..


Flow pisania test├│w wydajno┼Ťciowych

flow test├│w wydajno┼Ťci

  1. Zidentyfikuj ┼Ťrodowisko testowe – okre┼Ťl swoje fizyczne ┼Ťrodowisko na kt├│rym b─Ödziesz odpala─ç testy. ┼Ürodowisko powinno by─ç maksymalnie zbli┼╝one do produkcyjnego (z punktu widzenia test├│w najlepiej gdyby to by┼éa produkcja – ale tak raczej nigdy nie b─Ödzie). Dobrze by by┼éo gdyby┼Ť pozna┼é szczeg├│┼éy dotycz─ůce konfiguracji ┼Ťrodowiska na jakim stoi twoja aplikacja. Pomo┼╝e to tworzy─ç bardziej wydajne testy. Mo┼╝e to r├│wnie┼╝ pom├│c zidentyfikowa─ç i rozwi─ůza─ç mo┼╝liwe wyzwania i problemy kt├│re mo┼╝na napotka─ç podczas pisania test├│w.
  2. Okre┼Ťl kryteria akceptacji – jakie dok┼éadnie s─ů cele i ograniczenia. Przyk┼éadem mo┼╝e by─ç metryka czasu odpowedzi – aplikacja ma odpowiada─ç zawsze w przeci─ůgu 0.2 sekundy. Im szybciej tym lepiej ale je┼╝eli czasy odpowiedzi przekraczaj─ů 0.2 sekundy to nasze kryterium nie jest spe┼énione a wi─Öc trzeba co┼Ť poprawi─ç.
  3. Zaplanuj i zaprojektuj testy – okre┼Ťl jak u┼╝ycie aplikacji mo┼╝e si─Ö r├│┼╝ni─ç pomi─Ödzy ko┼äcowymi u┼╝ytkownikami i na tej podstawie u┼é├│┼╝ kluczowe scenariusze testowe. Konieczne jest przeprowadzenie symulacji r├│┼╝nych u┼╝ytkownik├│w ko┼äcowych, zaplanowanie danych jakie b─Öd─ů wykorzystywane podczas test├│w wydajno┼Ťciowych oraz okre┼Ťlenie jakie metryki zostan─ů zebrane.
  4. Skonfiguruj ┼Ťrodowisko testowe┬á– przygotuj ┼Ťrodowisko testowe przed wykonaniem test├│w. Dodatkowo, nale┼╝y r├│wnie┼╝ przygotowa─ç narz─Ödzia wspomagaj─ůce testy i inne przydatne zasoby (pliki z konfiguracjami).
  5. Napisz testy┬á– stw├│rz testy zgodnie z planem test├│w.
  6. Przeprowad┼║ testy – poza samym przeprowadzeniem pami─Ötaj o monitorowaniu test├│w.
  7. Analizuj, dostrajajaj i testuj ponownie – analizuj wyniki test├│w (warto tak┼╝e dzieli─ç si─Ö t─ů informacj─ů z zespo┼éem co by wiedzieli jak si─Ö sprawy maj─ů). Nast─Öpnie dostrajaj aplikacj─Ö i testuj ponownie aby sprawdzi─ç czy nast─ůpi┼éa poprawa czy spadek wydajno┼Ťci. Poniewa┼╝ ulepszenia na og├│┼é malej─ů wraz z ka┼╝dym ponownym testem, zatrzymaj si─Ö, gdy w─ůskie gard┼éo jest spowodowane przez CPU. Wtedy mo┼╝esz rozwa┼╝a─ç zwi─Ökszenie mocy serwer├│w.

Jakie metryki mo┼╝na zbiera─ç

jakie metryki zbiera─ç

  • Zu┼╝ycie procesora – ilo┼Ť─ç czasu, jak─ů procesor po┼Ťwi─Öca na wykonywanie w─ůtk├│w.
  • Zu┼╝ycie pami─Öci – ilo┼Ť─ç pami─Öci fizycznej dost─Öpnej dla proces├│w na komputerze.
  • Czas na dysku (disk time) – ilo┼Ť─ç czasu, przez jaki dysk jest zaj─Öty wykonywaniem ┼╝─ůdania odczytu lub zapisu.
  • Przepustowo┼Ť─ç – bity na sekund─Ö u┼╝ywane przez interfejs sieciowy.
  • Przerwania CPU na sekund─Ö – ┼Ťrednia liczba sprz─Ötowych przerwa┼ä, kt├│re procesor odbiera i przetwarza co sekund─Ö.
  • Czas odpowiedzi – czas od momentu wprowadzenia ┼╝─ůdania przez u┼╝ytkownika do otrzymania pierwszego znaku odpowiedzi.
  • Wydajno┼Ť─ç – szybko┼Ť─ç, z jak─ů komputer lub sie─ç odbiera ┼╝─ůdania w ci─ůgu sekundy.
  • Wielko┼Ť─ç puli po┼é─ůcze┼ä – im wi─Öcej ┼╝─ůda┼ä zostanie zrealizowanych przez po┼é─ůczenia w puli, tym lepsza b─Ödzie wydajno┼Ť─ç.
  • Maksymalna liczba aktywnych sesji – maksymalna liczba sesji, kt├│re mog─ů by─ç aktywne na raz.
  • Liczba wywo┼éa┼ä na sekund─Ö (hits per second) – liczba uderze┼ä na serwerze WWW podczas ka┼╝dej sekundy testu obci─ů┼╝eniowego.
  • Nadj┼éu┼╝sze czasy oczekiwania – s─ů monitorowane w celu okre┼Ťlenia, jakie czasy oczekiwania mog─ů by─ç skr├│cone.
  • Liczenie w─ůtk├│w – stan aplikacji mo┼╝e by─ç mierzony na podstawie liczby dzia┼éaj─ůcych i aktualnie aktywnych w─ůtk├│w.
  • GC (garbage collection) – ma to zwi─ůzek z przywracaniem niewykorzystanej pami─Öci z powrotem do systemu. GC musi by─ç monitorowany pod k─ůtem wydajno┼Ťci.

Przykładowe przypadki testowe

  • Sprawdzenie czy czas reakcji nie przekracza 2 sekund gdy 3000 u┼╝ytkownik├│w jednocze┼Ťnie u┼╝ywa aplikacji.
  • Zweryfikowanie maksymalnej liczby u┼╝ytkownik├│w kt├│rych aplikacja mo┼╝e obs┼éu┼╝y─ç zanim si─Ö wy┼éo┼╝y.
  • Jak zachowuje si─Ö nasza baza danych, gdy jednocze┼Ťnie odczytywanych/zapisywanych jest 1000 rekord├│w.
  • Sprawdzenie zu┼╝ycia procesora i pami─Öci aplikacji oraz serwera bazy danych w warunkach szczytowego obci─ů┼╝enia.
  • Zmierzenie czas├│w reakcji aplikacji w warunkach niskiego, ┼Ťredniego i du┼╝ego obci─ů┼╝enia.

Podczas rzeczywistego wykonywania test├│w wydajno┼Ťci, niejasne stwierdzenia jak np. du┼╝e obci─ů┼╝enie, jak zachowuje si─Ö xxx, itp. s─ů zast─Öpowane przez konkretne liczby. Osoba wykonuj─ůca testy powinna ustawi─ç te liczby zgodnie z wymaganiami biznesowymi i mo┼╝liwo┼Ťciami technicznymi aplikacji.


Podsumowanie

Przed wprowadzeniem na rynek jakiegokolwiek produktu oprogramowania konieczne zalecane jest przeprowadzenie test├│w wydajno┼Ťci. Zapewnia to satysfakcj─Ö klienta i chroni biznes przed awari─ů produktu. Koszty testowania wydajno┼Ťci s─ů wysokie– bo nale┼╝y zatrudni─ç do tego ekspert├│w, posiada─ç i dostroi─ç odpowiednio ┼Ťrodowisko, zaanga┼╝owa─ç biznes oraz deweloper├│w do wymiany wiedzy. Mimo wszystko, poniesione koszty s─ů zazwyczaj nadrobione dzi─Öki poprawie zadowolenia klienta. A je┼╝eli klient jest zadowolony to mo┼╝e do nas wr├│ci─ç lub nas poleci─ç.


Za tydzień

Skoro ju┼╝ wiemy czym s─ů testy wydajno┼Ťciowe, dlaczego warto je pisa─ç i jakie metryki zbiera─ç, za tydzie┼ä ogarniemy narz─Ödzie JMeter. Opisz─Ö jego najwa┼╝niejsze funkcjonalno┼Ťci i jak si─Ö nim pos┼éugiwa─ç. Standardowo w sobot─Ö o 12.

Ps. je┼╝eli doszed┼ée┼Ť do tego miejsca – daj zna─ç w komentarzu czy na swoich projektach piszesz testy wydajno┼Ťciowe? Jak tak – to jakich narz─Ödzi u┼╝ywacie. A jak nie – to mo┼╝esz napisa─ç ┼╝e czekasz na kontynuacj─Ö bo chcesz to ogarn─ů─ç i zwi─Ökszy─ç swoj─ů wiedz─Ö. Dzi─Öki ­čÖé

0 0 vote
Article Rating
Subscribe
Powiadom o
guest
0 komentarzy
Inline Feedbacks
View all comments