Redakcja
Strona selenium.dev ma ciekawą i rozbudowaną sekcję z dokumentacją. Znajduje się tam wiele przydatnych informacji, a jedną z nich jest właśnie „Zbiór złych praktyk w czasie automatyzowania testów”. Przyjrzyjmy się im.
CAPTCHA
Jest to skrót od Completely Automated Public Turing test to tell Computers and Humans Apart. Został on zaprojektowany w sposób uniemożliwiający automatyzację. Nie należy więc próbować automatyzować captchy! Istnieją jednak dwie podstawowe strategie obchodzenia CAPTCHA:
- Wyłączenie CAPTCHA w swoim środowisku testowym.
- Dodanie hak (ang. hook), aby umożliwić testom obejście CAPTCHA.
Uwierzytelnianie dwuetapowe
W skrócie 2FA. Jest to mechanizm autoryzacji, w którym komenda „próba uzyskania uwierzytelnienia” wymaga podania jednorazowego hasła (OTP), generowanego za pomocą aplikacji, takich jak Google Authenticator, Microsoft Authenticator itp. (lub przez SMS bądź e-mail). Stabilna automatyzacja tego procesu jest dużym wyzwaniem w Selenium. Istnieje kilka sposobów na jego zautomatyzowanie, ale będzie to kolejna warstwa w testach Selenium i nie będzie ona bezpieczna. Należy unikać automatyzacji 2FA.
Istnieje kilka opcji obejścia kontroli 2FA:
- wyłącz 2FA dla niektórych użytkowników w środowisku testowym, aby móc używać tych poświadczeń użytkownika w automatyzacji,
- wyłącz 2FA w swoim środowisku testowym,
- wyłącz 2FA, jeśli logujesz się z niektórych adresów IP.
Pobieranie plików
Chociaż rozpoczęcie pobierania plików jest łatwe (kliknięcie łącza w kontrolowanej przez Selenium przeglądarce), to interfejs API nie ujawnia postępu pobierania, co czyni go niedoskonałym narzędziem do testowania pobranych plików. Dzieje się tak, ponieważ pobieranie plików nie jest uważane za ważny aspekt emulacji interakcji użytkownika z platformą internetową. Zamiast tego, za pomocą Selenium, znajdź link oraz wymagane pliki i dodaj je do biblioteki żądań HTTP, takiej jak libcurl.
Kody odpowiedzi HTTP
W przypadku niektórych konfiguracji przeglądania w Selenium RC, Selenium działał jako proxy między przeglądarką a witryną, którą automatyzujemy. Oznacza to, że cały ruch przeglądarki przechodzący przez Selenium zostaje przechwycony lub zmanipulowany. Metoda captureNetworkTraffic () teoretycznie przechwytuje cały ruch sieciowy między przeglądarką a zautomatyzowaną witryną, w tym kody odpowiedzi HTTP.
Selenium WebDriver to zupełnie inne podejście do automatyzacji przeglądarki, stawiające bardziej na symulowanie zachowania się użytkownika. Jest to reprezentowane w sposobie pisania testów za pomocą WebDriver. W zautomatyzowanych testach funkcjonalnych, sprawdzenie kodu odpowiedzi, nie jest szczególnie ważnym aspektem potencjalnego niepowodzenia testu - ważniejsze są kroki, które ją poprzedzały.
Przeglądarka zawsze będzie prezentować kod stanu HTTP. Przykładem może być strona błędu 404 lub 500. Prostym sposobem na „szybkie niezaliczenie” testu, w przypadku napotkania jednej ze stron błędów, jest sprawdzenie tytułu lub zawartości strony (np. Tagu <h1>), po każdym jej załadowaniu. Jeśli używany jest model obiektów strony, wówczas zawartość strony można sprawdzić w konstruktorze klasy lub podobnym punkcie, w którym oczekiwane jest ładowanie strony. Czasami kod HTTP może być nawet reprezentowany na stronie błędu przeglądarki – wtedy można użyć programu WebDriver, aby to przeczytać.
Sprawdzenie zawartości strony internetowej jest zgodne z dobrymi praktykami WebDriver, polegającymi na przedstawianiu i potwierdzaniu doświadczeń użytkownika, w danej witrynie internetowej.
Jeśli zależy nam na zaawansowanych rozwiązaniach do przechwytywania kodów stanu HTTP, należy użyć Selenium RC i serwera proxy. Te narzędzia pozwolą określić, jak chcemy zareagować na kody odpowiedzi. Niestety nie każda przeglądarka udostępnia kod odpowiedzi dla WebDriver, więc decydując się na użycie proxy, możesz mieć niedziałające rozwiązanie.
Logowanie do Gmaila, poczty e-mail i Facebooka
Z wielu powodów logowanie do witryn, takich jak Gmail i Facebook, za pomocą WebDriver nie jest zalecane. Nie dość, że jest to sprzeczne z warunkami korzystania z tych witryn (z karą w postaci zamknięcia konta), to praktyka owa jest powolna i zawodna.
Idealną praktyką jest użycie interfejsów API, oferowanych przez dostawców poczty e-mail. W przypadku Facebooka warto natomiast skorzystać z usługi narzędzi programistycznych, która udostępnia interfejs do tworzenia kont testowych. Chociaż korzystanie z interfejsu API może wydawać się dodatkową pracą, to otrzymujemy zwrot w postaci szybkości, niezawodności i stabilności testów. Jest mało prawdopodobne, aby interfejs API się zmienił, podczas gdy wygląd strony internetowej i lokalizatory HTML zmieniają się często i wymagają częstej aktualizacji struktury testowej.
Zalogowanie się do witryn stron trzecich za pomocą WebDriver, w dowolnym momencie wykonania testu, zwiększa ryzyko jego niepowodzenia choćby z powodu tego, że go wydłuża. Ogólna praktyczna zasada jest taka, że im dłuższe testy, tym bardziej są one wrażliwe i zawodne.
Zależności między testami
Powszechnym, błędnym przekonaniem na temat testów automatycznych, jest określona kolejność ich wykonania. Prowadzone testy powinny być uruchamiane w dowolnej kolejności i nie powinny wymagać ukończenia pozostałych testów, aby mogły zakończyć się powodzeniem.
Test wydajności
Generalnie nie zaleca się testowania wydajności przy użyciu Selenium i WebDriver. Nie dlatego, że są do tego niezdolne, ale dlatego, że nie są zoptymalizowane do tej pracy i jest mało prawdopodobne, aby przy ich użyciu uzyskać wartościowe wyniki.
Test wydajności może wydawać się idealny w kontekście użytkownika, ale zestaw testów WebDriver podlega wielu punktom zewnętrznej i wewnętrznej wrażliwości, na które nie mamy wpływu. Na przykład szybkość uruchamiania przeglądarki, szybkość serwerów HTTP, odpowiedź serwerów stron trzecich, które obsługują JavaScript lub CSS. Różnice w tych punktach kontroli mogą powodować różnice w wynikach końcowych. Trudno jest oddzielić różnicę między wydajnością danej witryny a wydajnością zasobów zewnętrznych, a także trudno jest określić, jaki jest spadek wydajności wynikający z korzystania z WebDrivera w przeglądarce, zwłaszcza jeśli wstrzykujesz do niej skrypty.
Inną potencjalną wartością jest pozorna „oszczędność czasu”, którą potencjalnie uzyskujemy poprzez jednoczesne przeprowadzanie testów funkcjonalnych i wydajnościowych. Jednak testy funkcjonalne i wydajnościowe mają sprzeczne cele. Aby przetestować funkcjonalność, tester często musi wykazać się cierpliwością, czekając na załadowanie strony. Okres oczekiwania powoduje zaburzenie wyników testów wydajności i na odwrót.
Aby poprawić wydajność swojej witryny, musisz być w stanie przeanalizować ogólną wydajność, niezależnie od różnic w środowisku, zidentyfikować słabe praktyki kodowania, wydajność poszczególnych zasobów (np. CSS lub JavaScript), aby wiedzieć co należy poprawić. Dostępne są narzędzia do testowania wydajności, które mogą wykonać tę pracę. Dostarczają one raporty i analizy, a nawet mogą sugerować ulepszenia. Przykładowe narzędzie (open source) do użycia to: JMeter.
Badanie linków
Używanie WebDriver do badania poprawności linków nie jest zalecaną praktyką. Nie dlatego, że nie można tego zrobić, ale dlatego, że WebDriver zdecydowanie nie jest do tego odpowiednim narzędziem. WebDriver potrzebuje bowiem czasu na uruchomienie, co może zająć kilka sekund, nawet do minuty (w zależności od tego, jak napisany jest test), aby dostać się na stronę i przejść przez DOM.Zamiast używać do tego WebDrivera, można zaoszczędzić mnóstwo czasu, wykonując polecenie curl lub używając biblioteki, takiej jak BeautifulSoup. Metody te nie bazują na „tworzeniu” przeglądarki i przechodzeniu do strony. Nie używając WebDriver , oszczędzamy mnóstwo czasu, do tego zadania.
Powyższa lista jest gotowym zbiorem praktyk, których należy unikać w codziennej pracy z automatyzacją. Mają one tym większą wartość, że płyną bezpośrednio od twórców rozwiązania.
Na naszych szkoleniach z Selenium i automatyzacji nie powielamy tych błędów.
