Testy Wydajnościowe w metodykach Agile

Poprawna Implementacja testów wydajnościowych w metodologii Agile wymaga niestandardowego podejścia. Typowo przedmiotem tego typu testów jest kompletny system. W tym przypadku, celem jest ich implementacja na jak najwcześniejszym etapie oraz wykonywanie tak często jak to możliwe, powinny się również zakończyć podczas tego samego sprintu co „development”. Poza problemami spowodowanymi samymi zmianami w kodzie należy brać pod uwagę również to, że często spadek wydajności zależy od innych czynników np. infrastruktura. Może wystąpić potrzeba zastosowania elementów o większej przepustowości spowodowana wzrostem ilości przesyłanych danych, czy też konieczność rekonfiguracji reguł bezpieczeństwa. Pomocne w diagnozowaniu problemów związanych z infrastrukturą może być wykorzystanie zewnętrznych, rozproszonych farm co często pomaga ograniczyć koszty, szczególnie przy dużym obciążeniu (np. BlazeMeter). Pomocna jest również symulacja „ograniczeń” realnego środowiska zaimplementowana w narzędziach służących do symulacji obciążenia np. przepustowości czy opóźnienia sieci.

Aby wykryć problemy jak najwcześniej, rozsądne jest rozpoczęcie testów na poziomie tworzonych metod lub funkcji. Po udanych testach funkcjonalnych do zbierania metryk wydajnościowych posłużyć mogą testy JUnit oraz dodatek org.eclipse.test.performance zintegrowany ze środowiskiem IDE Eclipse.

Kolejnym etapem jest sprawdzenie czasu jaki potrzebny jest do wykonania nowo utworzonego procesu lub funkcjonalności. W zależności od zastosowanej technologii, pomocne mogą być w tym przypadku: wspomniane wcześniej testy JUnit, SoapUI lub Jmeter.

Następnie, wskazane jest sprawdzenie systemu po integracji nowych funkcjonalności z obecnym rozwiązaniem (jako całość). W zależności od dostępnego czasu, długości sprint’u, w zakresie testów uwzględnić można pełną regresję, testy kluczowych scenariuszy oraz funkcjonalności, zależnych od  zmienianego lub dodawanego kodu.

Z uwagi na czas i wykorzystanie zasobów, testy regresyjne zaleca się wykonywać poza godzinami pracy. Pomocne w tym przypadku będzie narzędzie do automatycznego uruchamiania i zbierania raportów. Dobrym przykładem jest darmowe narzędzie Jenkins. Harmonogram uruchomień dostosowywany jest w tym przypadku do czasu w jakim tworzone są nowe wersje systemu. W przypadku zastosowania aspektów metodologii BDD testy mogą być uruchamiane każdej nocy. Dodatkowym atutem narzędzia jest możliwość śledzenia trendów, zbieranie raportów oraz ustalenie bramek jakości (np. jaki procent błędnych transakcji jest dopuszczalny).

Z uwagi na fakt, że wszystkie typy testów muszą zostać wykonane podczas jednego sprintu, często złożonego z wielu cykli, istotne jest uwzględnienie testera wydajnościowego już na etapie planowania. Jest to dobry moment na dopracowanie kryteriów akceptacji.

Tworzenie danych testowych, funkcji imitujących WebService’y oraz określenie scenariuszy, należy rozpocząć na etapie tworzenia kodu. W przypadku scenariuszy, rezultaty pracy testerów funkcjonalnych mogą posłużyć za doskonałą bazę. Testy automatyczne, bez których ciężko wyobrazić sobie zapewnienie jakości w metodologii Agile, powinny zostać wykorzystane na potrzeby testów wydajnościowych.

Wymagania wydajnościowe umożliwiają wydanie rekomendacji, jednak w praktyce nie są one określone szczegółowo i często akceptowalne zachowanie systemu definiowane jest w momencie obserwacji działającego środowiska. W takim przypadku pomocne jest również bazowanie na zachowaniu już istniejącego systemu produkcyjnego. W przypadku napiętego harmonogramu,  umożliwia to również zdefiniowanie obszarów, które wymagają usprawnienia w kontekście czasu potrzebnego na wykonanie operacji, co pozwala na skoncentrowanie ograniczonych zasobów w tych właśnie miejscach.

Kolejnym aspektem, jest śledzenie trendów wydajności aplikacji. Pozwala to na wydanie rekomendacji przy jednoczesnym zaoszczędzeniu czasu potrzebnego na interpretację wyników (posiadanie wyników z poprzedniego sprintu pozwala na porównanie nie przeanalizowanych danych, w niektórych przypadkach bez konieczności ich ponownej interpretacji).

Biorąc pod uwagę fakt, że celem metodologii zwinnych jest efektywne wykorzystanie dostępnych zasobów ludzkich oraz skrócenie czasu pomiędzy zgłoszeniem zapotrzebowania a publikacją systemu, nie należy zapominać o metrykach wydajnościowych, które zbierane są zazwyczaj podczas powstawania nowego rozwiązania. Przykładem w tym przypadku jest „skalowanie” systemu pod kątem predykcji wzrostu obciążenia (jak będzie zachowywał się system w kolejnych latach jeśli ilość użytkowników będzie wzrastać o 15%/30%). Mowa tutaj również o egzekucjach o charakterze przeciążeniowym czy obciążeniowym.

Łukasz Śniadowski (Lukas Sniadowski)

Advertisements