Testowanie wydajności – jak uratować wdrożenie i nie zwariować

UAT-y, badanie wydajności i bezpieczeństwa – tym kończą się działania projektu IT, którego celem jest wdrożenie nowego rozwiązania.

O ile dość jednoznacznie (piszę: dość, bo z praktyki projektowej – nie jest to regułą w 100% projektów) udaje się określić spełnienie kryteriów akceptacji funkcjonalnej, o tyle znalezienie odpowiedzi na pytanie: czy system/rozwiązanie jest wystarczająco wydajne – może przysporzyć trudności. Jak wobec tego się do tego zabrać?

Wymagania niefunkcjonalne, w tym wymagania dotyczące między innymi wydajności

W zależności od tego czy mamy do czynienia z nowym rozwiązaniem, czy z rozbudową istniejącego, powinniśmy odpowiedzieć sobie na pytanie:

  • jakie są oczekiwania co do czasu odpowiedzi systemu dla konkretnego przypadku, jeśli pracowałby na nim jeden użytkownik zadając żądanie o ustalonej zawartości (takich istotnych biznesowo operacji, które będą pobierać różny zakres danych z jednego albo wielu źródeł jednocześnie – może być wiele),
  • jak powinien zachować się system, jeśli takie samo żądanie wygeneruje w tym samym czasie grupa użytkowników w liczbie.. no właśnie, czy projektanci rozwiązania posiadają informację, w jakim stopniu system albo rozwiązanie będzie wykorzystywane jak tylko znajdzie się na środowisku produkcyjnym, albo np. za pół roku, kiedy będzie obsługiwało, np. inne kampanie bazujące na tym rozwiązaniu?

Odpowiedzi na te i podobne pytania powinny paść podczas etapu analizy biznesowej, a następnie projektowania, i jeśli nie posiadamy takiej informacji, należy o te kwestie uzupełnić specyfikację wymagań, czyli doprecyzować część dotyczącą wymagań niefunkcjonalnych. Dopiero zebranie danych o planowanym albo nawet szacowanym stopniu wykorzystania rozwiązania, pozwoli zaplanować weryfikację spełnienia tej części wymagań – dzięki testom wydajnościowym.

Robić – nie robić? Alternatywy

Zrezygnować z takich testów można – na pewno będzie to tańszej dla projektu, ale tylko wtedy kiedy lubimy funkcjonowanie w rzeczywistości wyzwalającej uderzenie adrenaliny w decydującym momencie?

Tak długo jak Zespół wdrożeniowo – testujący nie posiada kompetencji do wykonywania tego typu testów oraz do wnioskowania na podstawie otrzymanych wyników – rysuje się perspektywa zamówienia usługi na zewnątrz, w ramach której Projekt otrzyma:

  • dobranie narzędzia do testów, w zależności od zastosowanej technologii,
  • weryfikację scenariuszy pod kątem tego, jaką wartość dodaną wniosą one przy badaniu wydajności danego przebiegu,
  • weryfikację i skompletowanie danych testowych co do jakości, typu, a przede wszystkim oczekiwanego wolumenu (liczby rekordów, zestawów poprawnych danych, klientów itd.), bez których uruchomienie przygotowanych skryptów takich testów może się nawet nie rozpocząć,
  • wsparcie od wytycznych po skoordynowanie potrzeb lub zasobów dotyczących monitoringu od strony infrastruktury środowisk testowych lub posiadanych narzędzi monitorujących.

Pełen cykl powyżej opisanych prac (zakończonych po wyeliminowaniu znalezionych przy okazji błędów funkcjonalnych), sfinalizowany będzie przygotowaniem raportu końcowego z testów wydajnościowych, który powinien opisywać w szczególności:

  • szczegóły wprowadzonych obciążeń w podziale na poszczególne przebiegi testów,
  • wnioski z otrzymanych wyników, po odrzuceniu przyczyn zewnętrznych, leżących np. po stronie wydajności serwerów testowych,
  • rekomendacji dla poszczególnych obszarów, pochodzących z wyłaniającego się trendu otrzymanych wyników.

Jeśli projekt z różnych powodów nie może sobie pozwolić na pełny cykl testów wydajnościowych (dotyczyć to może małych i średnich projektów), warto rozważyć mniejszy, ale reprezentatywny i znaczący dla Biznesu zakres lub np. inne, częściowe podejście, np.: wygenerowanie obciążenia danego przebiegu przy pomocy narzędzi do automatyzacji testów: automat odtwarza kroki scenariusza, imitując kolejne sesje użytkowników systemu do pożądanej liczby przebiegów, a z drugiej strony prowadzona jest obserwacja logów operacji, ustawionych w tryb ‘debug’, gdzie widoczne będą czasy odpowiedzi kolejnych np. zapytań do bazy. Takie podejście ujawnić może błędy implementacji, niewykrywalne przy pojedynczych testach funkcjonalnych, ale nie zastąpi testów większych obciążeń, które dodatkowo ujawnią inne typy błędów, widoczne tylko w dużych i złożonych rozwiązaniach, np. nieadekwatnie ulokowane liczby wątków zapytań do baz danych.

Trzecia refleksja związana z podejmowaniem tematu testów wydajności w projektach to to czy po otrzymaniu rekomendacji stwierdzającej że rozwiązanie nie spełnia wymagań i ogólnie jest niewydajne – ‘Projekt’ weźmie to pod uwagę: będzie wstrzymany, przesunięty, ustalony będzie plan naprawy oraz powtórzenie testów? Jeśli nie, to jaki element wcześniej zawiódł w tej sekwencji zdarzeń?

Rozwiązania są więc dwa, oba sprowadzają się do kosztów, różni je tylko czas ich poniesienia: przed wdrożeniem lub po nim. Na przykłady kosztów poniesionych po wdrożeniu mamy wiele medialnych doniesień, a ich rozmiar i zakres bywa trudno policzalny, ale to temat na inne rozważania.