nobugteam tes

t
e
s
t
o
w
a
n
i
e
j
e
s
t
ł
a
t
w
e
testerzy.pl
Artykuł oparto na:
− Tworzenie stron WWW. Biblia. - Dawid Crowder, Rhonda Crowder; wydawnictwo Helion
− Optymalizacja serwisów internetowych. - Andrew King; wydawnictwo Helion
− Funkcjonalność stron internetowych – Mark Pearrow, wydawnictwo Helion
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
Wyłączne prawa autorskie do tego dokumentu posiadają „testerzy.pl”. Rozpowszechnianie dla celów komercyjnych jak
i niekomercyjnych jest dozwolone tylko pod warunkiem podania ich źródła.
t
−
−
e
s
t
o
w
a
n
i
e
j
e
s
t
ł
a
t
w
e
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
kodzie przekłada się na mikrosekundy opóźnienia. Tak więc z kodu należy usunąć komentarze (choć
pomijane 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ą
zoptymalizowane (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.
Wyłączne prawa autorskie do tego dokumentu posiadają „testerzy.pl”. Rozpowszechnianie dla celów komercyjnych jak
i niekomercyjnych jest dozwolone tylko pod warunkiem podania ich źródła.
t
e
s
t
o
w
a
n
i
e
j
e
s
t
ł
a
t
w
e
Wyłączne prawa autorskie do tego dokumentu posiadają „testerzy.pl”. Rozpowszechnianie dla celów komercyjnych jak
i niekomercyjnych jest dozwolone tylko pod warunkiem podania ich źródła.