W Polkomtelu są wykonywane także testy ze stałym obciążeniem. Nie oddają one sytuacji rzeczywistych, w praktyce bowiem liczba użytkowników i intensywność ich pracy zmieniają się dynamicznie. Zwykle wykonuje się je w celach demonstracyjnych, np. gdy kierownik działu chce się przekonać, czy upgrade polepszy komfort pracy użytkowników, lub też, co zdarza się rzadko, w celu zdiagnozowania nietypowych problemów, np. gdy aplikacja ulega awarii lub jej wydajność spada znacząco bez wyraźnej przyczyny.

Standardy i niuanse

Skrypty uruchamiane przez aplikacje testujące muszą odzwierciedlać rzeczywiste warunki działania aplikacji. Wykorzystywane w Polkomtelu narzędzia pozwalają odzwierciedlić naturalną "przypadkowość" przez przypisanie czynnościom symulowanym przez skrypty testujące współczynników czasowych, które są wykorzystywane przez zawarte w systemach algorytmy pseudolosowe.

Przygotowanie i przeprowadzenie testów wydajnościowych nie ogranicza się tylko do obsługi gotowych narzędzi. Wiele praktycznych problemów trzeba rozwiązać samodzielnie. Jednym z poważniejszych wyzwań dla testerów jest radzenie sobie z aplikacjami, w których ścieżki wykonania programu się rozgałęziają. Przykładowo, program może przewidywać, że użytkownik ma do klienta wysłać wiadomość e-mail lub faks albo list tradycyjny. Dla każdej opcji następująca sekwencja zdarzeń będzie nieco inna, choć prawdopodobnie w wielu punktach - identyczna. "W takiej sytuacji nie można posłużyć się jednym skryptem. Każdą ścieżkę wykonania programu trzeba zbadać oddzielnie. W praktyce wymaga to umiejętnego podzielenia testu na wiele skryptów cząstkowych, które dla każdego scenariusza składa się w odpowiedniej kolejności" - mówi Tomasz Wodziński.

Zaprojektowanie testu to połowa sukcesu. W praktyce sztuką jest także zebranie danych, ich wstępna obróbka, interpretacja i forma prezentacji. Pliki log z wynikami testów są zwykle zapisywane na stacjach roboczych, które biorą udział w teście. Ponieważ test może trwać kilkanaście godzin, a pojedyncza stacja symuluje kilkudziesięciu użytkowników, danych jest dużo - nawet kilkanaście gigabajtów na pojedynczej stacji. Po konsolidacji dane trzeba poddać analizie statystycznej. Według specjalistów z Polkomtela miary średnie - średnie arytmetyczne czy geometryczne nie nadają się do analizy wydajności. Znacznie więcej informacji niosą miary pozycyjne, takie jak mediana czy kwartyle.

Pakiety testujące zawierają narzędzia analityczne i raportujące, w tym nawet do budowy raportów wielowymiarowych. Użyteczność tych ostatnich jest w praktyce niewielka. "Większa liczba szczegółowych dwuwymiarowych raportów niesie więcej informacji niż jeden wielki raport wielowymiarowy. Znacznie łatwiejsze do wykonania i interpretacji są także tworzone na ich podstawie proste wykresy" - podkreśla Tomasz Wodziński.

Więcej niż wydajność

Testy wydajnościowe to z pewnością najlepszy sposób na określanie bezpiecznych granic obciążania aplikacji. Niejako przy okazji testy wydajnościowe mogą być także użytecznym narzędziem do przewidywania kosztów związanym z rozbudową sprzętu. Na tym ich rola jednak się nie kończy. Podczas testowania wydajności aplikacji można wykrywać nie tylko błędy związane z jej architekturą, ale także te, które uszły uwagi testerów mających dostęp do kodu. "Testy wydajnościowe, poddając aplikację "stresowi", niejednokrotnie ujawniają jej ukryte wady, np. pojawianie się nie dokończonych transakcji czy nie domkniętych połączeń z bazą danych itp. Przy ich użyciu można też wykryć błędy przypisywane, często niesłusznie, systemom operacyjnym, np. tzw. wycieki pamięci" - mówi Adam Suskiewicz.