Wprowadzenie do testów wydajnościowych: Load i Stress Testing

Jakub Sagan

Jakub

QA Engineer

Wstęp

Każdy tester spotkał się w swojej pracy, a przynajmniej powinien, z pojęciem testów wydajnościowych albo też stress testów. Może nawet zostało mu zlecone ich wykonanie i czyta ten artykuł, aby odpowiedzieć sobie na pytanie: czym one są i co je wyróżnia? W niniejszym tekście postaram się przybliżyć pewne pojęcia i rodzaje testów, które wchodzą w zakres szeroko pojętego performance testingu.

W artykule przeczytasz:

Performance testing

Podczas testowania wydajnościowego sprawdzana jest jakość aplikacji w różnych okolicznościach, bowiem inżynier testów doprowadza do obciążenia bazy danych, serwera i przeprowadzania wiele akcji jednocześnie w tej samej aplikacji. Działania te mogą być skutkiem realnego obciążenia, kiedy w roli testera stawia się wielu użytkowników korzystających z aplikacji lub też potencjalnego, kiedy tworzymy wirtualnych użytkowników, którzy symulują zachowanie prawdziwych użytkowników - podobnie jak Threads w jMeterze.

Tego rodzaju testy niefunkcjonalne są przeprowadzane nie tylko w optymalnych warunkach zgodnie z wymaganiami klienta, ale również w obliczu symulacji skrajnych obciążeń tak, aby sprawdzić, co się stanie, kiedy wielu użytkowników będzie wykonywało tę samą czynność np. zamawia produkt albo generuje fakturę. Pozwala to zapewnić satysfakcjonujące działanie nawet w przypadku krytycznych obciążeń.

Na podstawie tego uważa się, że celem testowania wydajnościowego jest ustalenie wzorcowego zachowania systemu, spełnienie kryteriów wydajności, stałe monitorowanie stanu aplikacji pod tym kątem oraz w razie konieczności optymalizacja. Temu ostatniemu warto poświęcić trochę danych marketingowych.

Optymalizacja jest niezwykle istotna, nawet podstawowe testy pozwalają znaleźć przyczynę problemów związanych z długim czasem ładowania aplikacji. Niekiedy wystarczy skompresować rozmiar użytych grafik, zoptymalizować kod lub wprowadzić cache’owanie powtarzalnych elementów na stronie, aby odczuć większy komfort korzystania z aplikacji.

Tej tematyce były poświęcone liczne badania, z których dowiadujemy się między innymi, że 53% użytkowników rezygnuje z dalszego eksplorowania portalu internetowego, jeśli jego czas ładowania wynosi więcej niż 3 sekundy. Do podobnych wniosków w swoich badaniach dociera Harris (2013, 2015). Dowiódł on, że 46% użytkowników robiących zakupy przez internet nie wróci już na wolnoładującą się stronę. 67% korzystających z mobilnych urządzeń wychodzi z takich stron, natomiast 22% użytkowników decyduje się z tegoż powodu na ostateczny zakup u konkurencji. Wniosek? Testować i optymalizować!

Load testing

Testowanie obciążenia, jak sama nazwa wskazuje, ma na celu w sposób ciągły i proporcjonalny zwiększać obciążenie serwerów, aplikacji lub bazy danych aż do osiągnięcia wcześniej postawionego kryterium testowego. Istotne jest monitorowanie przyrostu użytkowników i analiza raportu, aby ustalić, w jakich miejscach oraz pod jakim obciążeniem, doszło do spowolnienia działania serwisu (o ile takowe się pojawi). Jako kryterium często ustala się rzeczywiste i bardzo prawdopodobne obciążenie wytworzone przez realnych użytkowników aplikacji. Aktualnie istnieją liczne narzędzia, które umożliwiają efektywne wdrożenie Load testów na niemalże każdy projekt webowy, są to m.in. jMeter, LoadRunner, BlazeMeter (jako aplikacja webowa lub wtyczka do Chrome) lub NeoLoad.

Aplikacje z długim czasem odpowiedzi ze strony serwera i niską wydajnością mogą zostać szybko zdiagnozowane przez load testy już nawet na wczesnych fazach developmentu – głównie za sprawą wykrycia bottleneck’ów, które obniżają wydajność aplikacji. Pozwala to zapobiec sytuacji, w której wydajemy mało efektywną aplikację końcowemu użytkownikowi. Dodatkowo im wcześniej zostanie rozpoznany problem, tym mniejszy będzie koszt jego naprawy na tym etapie projektu.

Stress testing

Stress testy (czasami nazywane torture testingiem) są przykładami niefunkcjonalnego I negatywnego testowania aplikacji. Wykorzystywane są one do sprawdzania stabilności i niezawodności produktu w sytuacji skrajnego obciążenia. Przeprowadzenie odpowiednich stress testów nie jest łatwym zadaniem dla testera, ponieważ wymaga to od niego poświęcenia szczególnej uwagi maksymalnej liczbie użytkowników oraz ich aktywności, gdzie aplikacja jeszcze pozostaje stabilna. W momencie, kiedy aplikacja przestaje odpowiadać, zawsze powinien pojawić się stosowny komunikat, który poinformuje o aktualnym stanie aplikacji.

Ważnym elementem jest stworzenie raportu z zachowania aplikacji i upewnienie się, czy wywołane przez nas obciążenie nie doprowadziło na przykład do naruszenia bezpieczeństwa danych. Za połowiczny sukces możemy uznać sytuację, w której aplikacja samoczynnie „wraca do świata żywych” i nie wymaga zewnętrznej ingerencji administratora np. manualnego restartu serwera. Niezbędne jest, aby po powrocie systemu do normalności wszystkie komponenty oraz dane pozostały nienaruszone. Taki rodzaj testów możemy wykorzystywać na przykład na stronach związanych z popularnym wydarzeniem np. festiwal filmowy, mistrzostwa e-sportowe albo też w przypadku dużych wyprzedaży online np. podczas Black Friday lub Cyber Monday. Do wykonania stress testów możemy wykorzystywać te same narzędzia, które zostały przytoczone w przypadku Load Testów.

PODSUMOWANIE:

Load Testing

  • Load Testing polega na testowaniu aplikacji zgodnie z wymaganiami, jest to przykład testowania pozytywnego.
  • Tester stopniowo obciąża aplikację, aby sprawdzić jej zachowanie w "naturalnych" warunkach.
  • Skutkiem udanego Load Testingu nie jest crash lub popsucie aplikacji.

Stress Testing

  • Stress Testing polega na testowaniu aplikacji ponad wymagania, staramy się zepsuć aplikację, a więc jest to testowanie negatywne.
  • Tester stopniowo wychodzi ponad "naturalne" warunki, aby sprawdzić limit przepustowości.
  • Często kończy się crashem serwera, sprawdza się, co się stanie po osiągnięciu limitów aplikacji.

Udostępnij w social mediach

Wybierz sposób realizacji i wspólnie zacznijmy realizować Twój projekt

Wycena projektu
Cofnij