Zautomatyzowane testy funkcjonalności

    Zautomatyzowane testy aplikacji pozwalają na szybkie przetestowanie, czy napisane do tej pory mechanizmy działają poprawnie. Pomimo że utworzenie takich testów może zająć trochę czasu, korzyści widoczne są przy wprowadzaniu do aplikacji nowych funkcjonalności. Dzięki takim testom jest możliwość natychmiastowego sprawdzenia, czy po dopisaniu i zmodyfikowaniu kodu programu, serwer nadal działa poprawnie.

    Do testów zautomatyzowanych wykorzystane zostały wspomniane wcześniej: program Imprimatur, oraz własne oprogramowanie.

Testy podstawowe

    Najbardziej podstawowym testem jest wysłanie prostych zapytań GET i POST do serwera HTTP i sprawdzenie ze wzorcem czy otrzymano oczekiwaną odpowiedź. Należy tutaj przetestować wszystkie wersje protokołu HTTP najlepiej od razu dla statusów 200 OK i 404 Not Found. Można w ten sposób sprawdzić przy okazji, czy serwer poprawnie rozpoznaje przekazane do niego adresy do zasobów.

If-Modified-Since, oraz If-Unmodified-Since

    Testy te pozwolą sprawdzić, jak serwer radzi sobie z zapytaniami warunkowymi, zawierającymi w nagłówku jeden z wierszy: „If-Modified-Since” lub „If-Unmodified-Since”, oraz z odczytywaniem daty modyfikacji pliku i parsowaniem różnych formatów daty przekazanej do serwera. W przypadku „If-Modified-Since” gdy plik został zmodyfikowany powinien zostać zwrócony status 200 OK, a jeżeli plik nie uległ zmianie status 304 Not Modified. Dla wiersza „If-Unmodified-Since” w przypadku, gdy zasób został zmodyfikowany powinien być zwrócony status 412 Precondition Failed, a jeżeli nie uległ zmianie: 200 OK.

Testy tagów

    W skład tych testów wchodzą testy dla zapytań zawierających w nagłówku wiersz
„If-Match” lub „If-None-Match”. Nagłówki te jako wartość przyjmują pojedynczy tag (wygenerowany przez serwer identyfikator zasobu) lub listę tagów wśród których serwer wyszukuje pasujący do żądanego zasobu tag. Testy powinny więc obejmować zapytania zawierające oraz niezawierające zgodnego tagu do zasobu, jak również tagi wysyłane powinny być jako pojedynczy element, lub w formie listy elementów, w której serwer będzie musiał znaleźć trafienie. Trzeba również przetestować, traktowanie tagu „*”, który odpowiada dowolnemu tagowi, oraz zapytania dla metody POST, gdzie w przypadku wiersza „If-None-Match” i znalezienia zasobu po tagu, serwer powinien zwrócić status 412 Precondition Failed, a dla metody GET status 304 Not Modified.

Pobieranie fragmentu zasobu

    Pobieranie fragmentów zasobu opiera się na manipulowaniu wartościami wiersza „Range”. Przyjmować on może pojedyncze wartości, jak i ich listę. Należy tutaj sprawdzić, czy serwer poprawnie oblicza przedziały (np. przedział „0-500” ma długość 501 bajtów,
a „0-0” ma długość 1 bajtu), czy poprawnie obsługuje różne formaty zapisów przedziałów („-1” pobierze tylko ostatni bajt, „500-” pobierze wszystkie bajty powyżej 499 bajtu). Na liście wartości warto przy testowaniu umieszczać różne formaty zapisów przedziałów i do niektórych zapytań dodać nieprawidłowy format, sprawdzając czy serwer zwróci komunikat o błędzie 416 – Requested Range Not Satisfiable i czy przypadkiem nie doprowadzi to do wyrzucenia jakiegoś krytycznego wyjątku po stronie serwera. Poprawność odpowiedzi można sprawdzać na podstawie długości otrzymanego zasobu, jak i pod kontem wyszukiwania określonych wartości w otrzymanym zasobie.

If-Range

    Wiersz „If-Range” w nagłówku zapytania informuje serwer o tym, że klient posiada fragment pobranego zasobu i chciałby sprawdzić, czy posiadany przez niego fragment jest nadal aktualny (aby np. kontynuować jego pobieranie). Nagłówek ten może wysyłać do serwera zarówno datę, jak i tag zasobu, tak więc przy testach należy wziąć pod uwagę oba te warianty. Wiersz ten powinien być dołączany tylko z wierszem „Range” i jeżeli taki nie został przesłany w zapytaniu serwer powinien ignorować nagłówek „If-Range”. W testach należy sprawdzić, czy serwer zwraca status 206 – Partial Content, w przypadku spełnienia warunku w „If-Range”, lub status 200 – OK, jeżeli nie spełnia (w takim wypadku serwer powinien wysłać do klienta cały dokument).

Wartości wiersza nagłówka w wielu liniach

    Serwer powinien sobie również poradzić z sytuacjami, gdy wartość wiersza nagłówka zapisana jest w kilku liniach:

Naglowek-pierwszy: wartosc1
          ,
       wartosc2
Naglowek-drugi: wartosc 3

    Wiersz nagłówka nie może rozpoczynać się od białego znaku, więc wszystkie linie w nagłówku, które zaczynają się w ten sposób są kontynuacją nagłówka wcześniejszego. W ten sposób wartość „Nagłówka-pierwszego” z powyższego przykładu to: „wartosc1 , wartosc2”. Właściwość tę najlepiej testować na nagłówkach, które mogą przesyłać listę wartości, podając wartości w kolejnych liniach i sprawdzając, czy wynik jest identyczny jak w przypadku listy wartości napisanej w pojedynczej linii.

Kompresja przesyłanego zasobu

    Preferencje odnośnie kompresji klient wysyła do serwera za pomocą wiersza
„Accept-Encoding”. O tym, czy zasób zostanie skompresowany decyduje serwer. Przy testowaniu tej funkcjonalności należy sprawdzić, czy serwer odeśle skompresowany zasób algorytmem gzip gdy tego zażądano, czy odeśle nieskompresowany zasób, gdy zaznaczy się, że klient nie chce kompresji, lecz zasób w oryginalnej postaci (gzip;q=0, identity). Należy również sprawdzić, czy serwer wyśle status 406 – Not Acceptable, jeżeli serwerowi nie odpowiada żadna z opcji preferowanych przez klienta.

Pliki indeksujące zawartość katalogu

    Sam test jest podobny do testów podstawowych dla serwera HTTP wspomnianych w podrozdziale 4.4.1. Jego zadaniem jest sprawdzenie, czy serwer zwróci plik index.html (lub inny określony w pliku konfiguracyjnym), jeżeli taki istnieje i następuje odwołanie do katalogu zamiast do konkretnego zasobu, czy wyświetli status o błędzie 404 – Not Found. Status taki nie powinien być zwrócony, zamiast niego serwer powinien dynamicznie wygenerować stronę HTML zawierającą odnośniki do plików znajdujących się w katalogu.

Autoryzacja

    Test właściwie składa się z trzech zapytań. Pierwsze z nich ma sprawdzić odpowiedź serwera, jeżeli klient chce się odwołać do zasobu zabezpieczonego hasłem, nie podając informacji o nazwie użytkownika i haśle. Drugi test polega na wysłaniu błędnej nazwy użytkownika i hasła. W obydwóch przypadkach serwer powinien zwrócić status 401 Unauthorized. Ostatnie zapytanie ma zawierać poprawne dane do autoryzacji, a powinien zwrócić klientowi odpowiedź ze statusem 200 OK.

Testy komunikatów o błędach

    Jest to kilka również bardzo prostych testów, których celem jest sprawdzenie czy generowane są poprawne informacje o błędach. Zaliczyć można do nich testy statusów
501 Not Implemented, gdy klient odwołuje się do nieistniejącej metody, czy 400 Bad Request, gdy w zapytaniu dla protokołu HTTP/1.1 nie dodano wiersza nagłówka z nazwą hosta.

Testy CGI

    Celem tych testów jest zbadanie poprawności działania mechanizmu CGI. Do przeprowadzenia tych testów są potrzebne skrypty PHP, Perla, lub inne aplikacje korzystające z tego interfejsu. Sprawdzić tutaj można standardowe zapytania GET i POST, jak również obsługę wysyłania formularzy metodą POST, czy wgrywanie plików na serwer. W przypadku plików binarnych testy jest łatwiej przeprowadzić przez przeglądarkę, niż za pomocą używanych tutaj aplikacji testujących, gdyż kopiując zawartość pliku binarnego do aplikacji testującej może spowodować jego uszkodzenie (zastosowanie innego kodowania znaków dla plików tekstowych).