Testowanie wydajności stron WWW

Wydajność (ang. Performance) strony WWW jest, w dużym uproszczeniu, szybkością pracy z danym serwisem. Parametr ten jest używany do charakteryzowania jakości optymalizacji stron internetowych.
Jak ważny jest to czynnik wie każdy użytkownik z łączem wolniejszym niż 1Mb/s.


Strony niezoptymalizowane ładują się wolno i powodują frustrację. Zbyt duża ilość grafiki, animacji czy po prostu rozwlekły kod zamieniają, przyjemność zabawy czy pracę w niekończącą się przerwę. Z drugiej strony szybkość łącz może i rośnie, ale jakość nie w kręgu ludzi, których znam. Firmy informują o niesamowitej przepustowości łącza zapominając powiadomić, że jest ono współdzielone przez pół twojego osiedla.

Dlaczego warto dbać o wydajność
Pierwszą rzecz jaką mówią wszyscy użytkownicy kiedy poprosi się ich o radę mówią: “Nie każcie nam czekać”. Czy budując swoją stronę projektant/programista chce pominąć użytkowników z modemami 56,6kb/s i mniejszymi? Jeśli TAK to znaczy, że właśnie zrezygnował z 40% internautów, którym zabraknie cierpliwości. Gdy dodamy do tego, że strony mające więcej niż 40kb mają wskaźnik rezygnacji na poziomie 30% wydajność zaczyna się wydawać czynnikiem pierwszoplanowym.

Założenia
Kiedy testujemy strony internetowe pod względem wydajności warto poznać założenia
(wymagania) właściciela witryny. Mogę one idealnie posłużyć jako przypadki testowe.
Przykładowe wymaganie klienta brzmi: strona ma się ładować w ciągu 8 sekund, ale najważniejsze
elementy nawigacyjne mają być widoczne już po 2 sekundach; użytkownicy mają mieć 90%
skuteczności w znajdywaniu danych w czasie 30 sekund.
Najważniejsze z punktu widzenia testowania jest to, że można te parametry łatwo mierzyć, a co za
tym idzie prezentować wyniki.
Kiedy wymagań brak, musimy się posiłkować badaniami psychologicznymi. Odpowiedź w czasie:
- 0,1 sekundy jest postrzegana jako natychmiastowa,
- 1 sekundy daje poczucie swobodnego przemieszczania się,
- 10 sekund powoduje utratę zainteresowania użytkownika.
Optymalne wartość odpowiedzi strony to 2 sekundy a górna wartość graniczna to 8 sekund
(plus/minus dwie sekundy).
Ważne jest by pamiętać by czas odpowiedzi nie był za szybki gdyż interakcja użytkownika
(próbującego zsynchronizować się z maszyną) może prowadzić do błędów lub co gorsza do
zmęczenia i w konsekwencji utraty zainteresowania.
Do listy założeń warto dodać, iż:

- czasy odpowiedzi powinny być mniej więcej podobne, ich częsta zmiana prowadzi do wybijania z
rytmu pracy

- informacja zwrotna ze strony, typu “Strona w trakcie ładowania” lub pasek postępu pozwalają
wydłużyć czas uwagi internauty nawet do 30 sekund

- użytkownicy informowani o dłuższych opóźnieniach również podświadomie zgadzają się na
dłuższe oczekiwanie na stronę, przykładowo informacja o wielkości pliku do pobrania może
przekonać użytkownika do pogodzenia się z długim czasem trwania ściągania

- czas pobierania nie odnosi się do zaawansowanych użytkowników sieci, którzy przeglądają więcej niż jedno okno Internetu naraz.

Testujemy kod – biała skrzynka
Przypomnijmy, warto przy rozpoczynaniu testów posiadać wiedzę o wymaganiach. Jest to kluczowe w sytuacji kiedy raportujemy błąd typu: “Strona nie zwraca rezultatu w ciągu 10 pierwszych sekund od czasu rozpoczęcia ładowania, gdy środowisko pracy oparte jest na modemie 56,6kb/s”.
Bez czytelnych wymagań odpowiedź programisty może być tylko jedna “Kup sobie lepszy modem. To nie jest defekt”.
Testowanie kodu to zawsze trudne zadanie. W przypadku optymalizacji HTML-a jest to jeszcze trudniejsze gdyż każemy programiście działać wbrew temu co go uczono. Każdy nadmiarowy bajt w odzie przekłada się na mikrosekundy opóźnienia. Tak więc z kodu należy usunąć komentarze (choć omijane przez przeglądarkę są one pobierane wraz z plikiem) i tworzyć nieczytelny kod przez pominięcie końca linii. Kod wygląda po takich operacjach jak chińskie znaczki, ale jedno jest pewne - jest szybki. Podobnie jest z CSS-ami, DHTML czy Java Script. Optymalizować i jeszcze raz optymalizować! Nie będziemy tu wchodzić w szczegóły optymalizacji bo to materiał na więcej niż kilka stron. Polecam książki o optymalizacji kodu. Ważne jest aby sprawdzić programistę prostym przeglądem kodu. Przykładem testu białoskrzynkowego będzie np. sprawdzenie znaczników meta.
Czy są one używane właściwie? Czy niosą jakąś informację? Czy słowa kluczowe są optymalizowane (nadmiarowe słowa są usuwane)?
Warto także sprawdzić rozmiar grafiki i zdjęć oraz określić czy są one odpowiednio oznakowane ilością kilobajtów.

Testujemy prototyp
Zanim podjęta zostanie decyzja o publikacji portalu warto zająć się stworzeniem środowiska zbliżonego do właściwego środowiska pracy strony i rozpocząć testowanie. Kolejne elementy funkcjonalne mogą być implementowane, gdy w tym samym czasie tester powoli sprawdza funkcjonalność oraz wydajność. Takie małe kroki projektu mogą spowodować, że łatwiej dostrzeżemy ewentualne błędy. Przy tworzeniu serwera testowego, na którym testujemy aplikację należy pamiętać by:
- wszystkie czynności były zapisywane
- w jednym czasie, jeden element był testowany jedynie przez jednego testera (jedną skorelowaną grupę testerów); czynności wykonywane przez innego testera na np. w bazie danych mogą być postrzegane jako defekty przez pierwszego testera
- środowisko musi być zbliżone do rzeczywistego środowiska pracy i uwzględniać takie parametry jak zmienne obciążenia serwera w zależności od pory dnia, fluktuacje przepustowości łącza czy możliwe inne działające w tle aplikacje użytkownika.

Testujemy w rzeczywistym środowisku pracy
Do pomiarów wydajności można używać najbardziej wyszukanych metod i automatyzacji jednak nikt tak się tu nie przydaje jak zwykły stoper. Konieczne jest wielokrotne powtarzanie tych samych czynności aby na bazie średniej statystycznej określić czas odpowiedzi serwera. Na pytanie ile testów należy wykonać by otrzymać wiarygodny wynik, odpowiedź brzmi: to zależy od samej aplikacji. Czasami już 10 będzie wystarczające, czasami i 100 będzie mało. Najtrudniejsze mogą tu być elementy losowe strony, których występowanie obniża wiarygodność pomiaru.
Testowanie możemy podzielić na formalne i nieformalne. Pierwsze zazwyczaj jest drogie i wykonywane w laboratoriach, drugie prawie darmowe i wykonywane gdziekolwiek. Jest mało prawdopodobne aby czytelnik miał dostęp do skomplikowanej aparatury pomiarowej czy drogich narzędzi, dlatego też warto skoncentrować się na technikach mniej formalnych. W tym celu możemy zaprosić grupę pracowników lub znajomych, niezwiązanych z projektem, i poprosić ich o wykonanie kilku czynności na stronie. Zabawa ze stroną jest wstępem do ankiety. Pamiętaj, że jakość witryny często podświadomie łączona jest z jej szybkością tak więc nawet pytania o zadowolenie z wizualnych aspektów strony może przekładać się na postrzeganie wydajności.

 

Najbliższe terminy szkoleń

Partnerzy

Narzędzia testerskie