Dbajmy o wydajność nawet dla pojedynczych użytkowników

Zazwyczaj testy wydajnościowe planuje się mając na uwadze jak największe obciążenie aplikacji przez duże grupy użytkowników. Może się jednak zdarzyć tak, że nawet nietypowe, nieprzewidziane zachowanie tylko jednego z nich zniweczy cały nasz wysiłek.

Planując testy wydajnościowe skupiamy się przede wszystkim na funkcjach wykorzystywanych przez kilkudziesięciu lub więcej użytkowników. W mojej książce “Testowanie oprogramowania w praktyce” pisałem już, że takie podejście może narażać na ryzyko niezadowolenia z wydajności aplikacji mniej liczne grupy użytkowników. Warto przeanalizować funkcje wykorzystywane przez pojedynczych użytkowników i zastanowić się kto, kiedy i jak może chcieć je wykorzystać. Zdarzają się funkcje wykorzystywane rzadko, ale kluczowe w pewnych szczególnych przypadkach. Gdy prowadziłem ostatnio szkolenie z testowania wydajności, poznałem dwa ciekawe przykłady z jakimi mieli do czynienia kursanci i chciałbym je przytoczyć, bo dotyczą bardzo ważnego zagadnienia.

Zacznę od przykładu z książki. Testując aplikacje CMS skupiliśmy się na wydajności funkcji prezentujących treści zapisane w serwisie. Założyliśmy, że funkcje modyfikujące nie będą wykonywane częściej niż raz dziennie i z punktu widzenia wydajności nie są znaczące. To założenie było prawdziwe w czasie normalnego użytkowania. Nie zwróciliśmy jednak uwagi, że po przekazaniu systemu klient będzie chciał dodać duże ilości materiału do pustego serwisu. Nienajlepsza wydajność dla funkcji edytujących widoczna już przy niewielkiej liczbie użytkowników wydłużyła proces przygotowania serwisu. Przysporzyło nam to dużo dodatkowej pracy tuż przed wydaniem nowego systemu.

Na szkoleniu kursanci opowiadali zabawną historię o problemach z budowanym przez siebie systemem CRM. Pewnego razu duża grupa użytkowników zgłosiła problemy związane z szybkością działania tego systemu. Administrator zauważył proces zużywający duże ilości zasobów systemowych i go zakończył. Sytuacja uległa chwilowej poprawie, jednak po niedługim czasie problem się powtórzył. Ponowna analiza znów ujawniła, że za spowolnienie systemu odpowiedzialny jest tajemniczy proces. Zakończenie go rozwiązywało problem, ale po krótkiej chwili ten proces znów się uaktywniał. Dokładna analiza wykazała, że proces ten jest uruchamiany przy generowaniu raportu zleconego przez jednego z użytkowników. Użytkownik ten, widząc, że ważny i potrzebny mu raport się nie wygenerował, zlecał tą czynność ponownie blokując tym samym możliwość pracy innym osobom. Niestety po ujawnieniu tego problemu generowanie raportu stało się dozwolone tylko w czasie weekendu.

Druga historia dotyczyła oprogramowania online usprawniającego pracę tłumaczy. Oprogramowanie to dzieli tłumaczony tekst na segmenty i jeśli znajdzie segmenty podobne do już przetłumaczonych, sugeruje gotowe tłumaczenie. Do określenia podobieństwa wymagane jest dokonanie pewnych skomplikowanych tłumaczeń. Rozwiązanie to jest chwalone przez ogół użytkowników. Tym razem jednak pojawiły się problemy. Dotyczyły one końcowej fazy dużego projektu, w którym zgromadzono dużą ilość przetłumaczonych segmentów. Okazało się, że na podpowiedzi systemu trzeba czekać aż kilka sekund i szybciej było po prostu tłumaczyć tekst ręcznie. Niezadowolenie potęgował fakt, że system przestał być użyteczny pod koniec projektu czyli w najbardziej krytycznym momencie.

Jak zatem uniknąć takich problemów? Odpowiedź na to pytanie jest trudna, bo aplikacje bardzo się od siebie różnią. Myślę, że najważniejsza jest świadomość, że problemy związane z wydajnością i szybkością działania aplikacji mogą pojawić się nawet gdy z naszej aplikacji korzysta kilku użytkowników. Warto krytycznie i z wyobraźnią patrzeć na budowany przez siebie system i rozważać różne scenariusze, które mogę wydarzyć się po wydaniu. Wywiad i konsultacje z użytkownikami na pewno będą pomocne.

 

Jacek Okrojek – Tester, koordynator i kierownik testów z wieloletnim doświadczeniem w testowaniu systemów wysokiej dostępności. Jako konsultant do spraw zapewnienia jakości prowadził i uczestniczył w wielu złożonych projektach dla klientów z sektora usług medycznych, telekomunikacyjnych oraz bankowości inwestycyjnej. Pracował w obszarze testów integracyjnych, wydajnościowych oraz akceptacyjnych. Obecnie pracuje w TestArmy Group jako specjalista do spraw automatyzacji i testowania wydajności.

 

Comments are closed.