7 Pomysłów Na To, Jak Przyspieszyć Testy Automatyczne UI Dla Stron WWW

Jak Przyspieszyć testy automatyczne? –  Często pojawia się ten temat, gdy rozmawiam z osobami z branży lub czasami widzę dyskusję w internecie na ten temat.

Wiem, że duża ilość osób ma problem, że ich testy są wolne, że muszą czekać kilka godzin, a nawet dni na zakończenie ich egzekucji i to w sytuacji, w której nie mają dużej ilości tych testów. Często wynika to z tego, że nie korzystają np. z uruchamiania współbieżnego testów lub mają tych testów za dużo, bo po głębszej analizie wychodzi na to, że niektóre scenariusze są pokryte po kilkadziesiąt razy.

Również skracanie czasu egzekucji testów automatycznych jest jednym z wyzwań, przed którym stoi wiele zespołów. Dziś chce przedstawić kilka pomysłów na to, jak do tego możemy się zabrać.

Czemu chcemy przyspieszyć testy automatyczne? – Aby szybciej dostarczać.

To jest jeden z celów automatyzacji testów im szybciej wiemy, w jakim stanie znajduje się nasza aplikacja, tym szybciej możemy reagować. Zespół ma feedback po każdej wprowadzonej zmianie.

Dziś chce przedstawić kilka pomysłów na to, jak testy automatyczne możemy przyspieszyć.

1. Selenium Grid – Zalenium / Selenoid + parallel – testy automatyczne cross browser

Jednym z dobrych pomysłów na zmniejszenie czasu wykonywania testów jest skorzystanie z Selenium Grida.

Czym jest Selenium Grid?

Selenium Grid jest narzędziem, które pozwala uruchamiać testy na różnych przeglądarkach w sposób współbieżny. Oczywiście musimy pamiętać, że testy, jeżeli chcemy uruchamiać je współbieżnie, muszą być do tego dostosowane:

Nasz framework, z którego korzystamy do uruchamiania testów musi mieć taką opcję-większość obecnych runnerów, z których korzystamy w testach automatycznych taką opcje ma np. NUnit, XUnit, JUnit, TestNG, PyTest.

Testy nie mogą od siebie zależeć i być w „izolacji” – mam tu na myśli tworzenie w każdym teście nowych danych testowych, dzięki temu mamy za każdym razem test, który ma korzystać z przewidywalnych danych testowych.

Zalenium / Selenoid – Selenium Grid na sterydach

Polecam korzystać z Selenium Grida na sterydach np. Zalenium lub Selenoida. Pisałem o nich  tu i tu. Są to ulepszone wersje standardowego Selenium Grida.

Selenoid i Zalenium realizują praktycznie te same zadania. Nie ma między nimi dużej różnicy.  Najlepiej spróbować obu i wybrać to narzędzie, które lepiej nam się sprawdza.

W skrócie:
Zalenium – Selenium Grid rozwijany przez programistów z firmy Zalando. Pozwala mieć dostęp do:
VNC podczas testów, dzięki temu widzimy, jak nasze testy działają – dzięki temu możemy je debugować poprzez uruchamianie ich lokalnie i obserwowanie wyniku w przeglądarce.
Skalowalność – tutaj właśnie jest miejsce na nasze przyspieszenie testów. Dzięki temu, że Zalenium korzysta z dockera możemy w łatwy sposób skalować ile przeglądarek potrzebujemy w danym momencie. Oczywiście zależy to również od zasobów serwerowych, którymi dysponujemy.

Jak silną maszynę potrzebujemy?

Według założeń z dokumentacji, jak również moich empirycznych testów jedna przeglądarka potrzebuje około 1 vCPU i 512 mb ramu, więc żeby testy uruchomić na 10 wątkach, potrzebujemy 6GB ramu i 10 wirtualnych procesorów. Pozwala nam to na znaczne zredukowanie czasu uruchomienia testów, jeżeli porównamy to uruchomienie testów do domyślnego sekwencyjnego uruchomienia (na jednym wątku).

Przyjmując, że mamy 300 testów:
Na jednym wątku jeden test w naszym przypadku uruchamia się około 40 sekund to daje nam 12000 sekund (300 x 40sek) – czyli 3,33 h dla wszystkich 300 testów.

Gdy uruchomimy ten sam zestaw testów na 10 wątkach to czas, który będzie nam potrzebny zmniejszy się do około 33 minut, nawet jeżeli czas zaokrąglimy w górę to maksymalnie będzie to 40 min (współbieżność nie dzieli dokładnie czasu na 10, bo również musimy zwrócić uwagę na obciążenie maszyny). Jest to znacznie lepszy wynik, który pozwala nam zaoszczędzić dużą ilość czasu.
Reasumując, jest to dość łatwy sposób na zmniejszenie czasu egzekucji testów.

2. Amazon Lambda

Amazon Lambda wykorzystywany do testów pisanych w Selenium jest dość nowatorskim pomysłem. Polecam prezentację na ten temat, która była na Selenium Conf.

Jest tam dobrze pokazane, jak również link do githuba dzięki temu sami możemy tego rozwiązania spróbować. W skrócie Amazon Lambda pozwala tworzyć funkcje, które mogą się dowolnie skalować i dzięki temu możemy współbieżnie uruchomić dużą ilość testów współbieżnie. Rozwiązanie te jest jeszcze nowatorskie i ma swoje ograniczenia, jednak warto spróbować samemu i zobaczyć jak testy mogą się szybko wykonywać. Oczywiście przy założeniu, że są dobrze napisane i nie zależą od siebie.

3. Dom Testing

Jest jednym z ciekawszych podejść do i testy automatyczne UI mogą być wykonywane szybciej. Podejście, że testy są wykonywane warstwę niżej niż testy w Selenium WebDriver. Dzięki temu nasze testy wykonują się szybciej. Polecam prezentację Aslaka Hellesøy ( twórca Cucumbera), który pokazuje przykład, w którym testy wykonują się znacznie szybciej niż podobne testy wykonane w Selenium WebDriver.

Co polecam?
Polecam prezentacje Aslaka, który gdzie pokazuje jak korzysta z biblioteki browser monkey.

Drugą popularną biblioteką tego typu jest DOM Testing – ma aktywne community i jest bardziej aktualizowane.

4. Przejrzeć przypadki testowe

Metoda, która powinna być dość często stosowana, a nie jest. Czasem trzeba zrobić krok w tył i popatrzeć na nasze testy krytycznie i zastanowić się, czy naprawdę tego przypadku potrzebujemy? Może się okazać, że określony obszar aplikacji mamy sprawdzany w kilku testach i to wydłuża nam czas egzekucji testów lub mamy kilkadziesiąt innych podobnych przypadków, więc musimy dokonać selekcji.
Co polecam?
Mieć stały kontakt z osobami w naszym zespole, które mają wiedzę biznesową, które elementy z obecnych scenariuszy z automatyzowanych są najważniejsze, oraz implementowanie tych, które mają sens biznesowy i są ważne. Dobrze jest samemu mieć taką wiedzę i znać na tyle produkt. Nie pisać testów dla samego pisania tylko starać się przed implementacją zapytać siebie i zespół, czy na pewno potrzebujemy tego testu? Może łatwiej (szybciej) będzie zaimplementować kilka testów jednostkowych przez programistę lub napisanie testów korzystając z API?

5. Tworzenie danych testowych przez REST API

Jeżeli korzystam z testów akceptacyjnych UI to dane testowe, które tworzymy do naszych testów powinny być tworzone za każdym razem i nie wyklikiwane z interfejsu użytkownika.

Dlaczego?
Jeżeli jeden test korzysta z danych testowych w różnych miejscach to lepiej jest, to zrobić za każdym razem tworząc dane poprzez API / bazę (jeżeli nie mamy możliwości przez API) dlatego, że mamy test w izolacji i za każdym razem mamy dane, których potrzebujemy, więc nasze testy mogą działać współbieżnie, bo nie zależą od siebie. Tworzenie danych poprzez wyklikiwanie ich danych też jest złym pomysłem, bo wydłuża czas egzekucji testów.

Dzięki temu testy automatyczne są znacznie bardziej stabilne.

6. Testy na niższych warstwach

To, co zalecam w automatyzacji testów to wdrażać i skupiać się na niższych warstwach piramidy testów. Dlaczego? Dlatego, że czas egzekucji testu jednostkowego jest znacznie mniejszy niż uruchomienie testu UI. Poza tym testy jednostkowe mogą być świetną dokumentacją aktualnego stanu aplikacji znacznie lepszą niż komentarze w kodzie. Również wiele testów funkcjonalnych może być szybciej realizowanych przez API i tutaj bym nakładał większy nacisk niż tworzenie dużej ilości testów UI. 

Co polecam?

Zachęcić programistów do zajmowania się również testami jednostkowymi. Świadomość w branży jest coraz większa, ale warto też przekonywać biznes, że warto tego typu testy tworzyć, bo znacznie szybciej je tworzy się niż testy UI, więc ich ilość powinna być większa. My jako programiści testów możemy skupiać się na testach funkcjonalnych realizowanych przez API.

7. Monitorowanie czasu uruchomienia testów

Jest to punkt, który widzę po organizacjach jest często pomijany, skupiamy się często na dokładaniu nowego kodu w postaci nowych zautomatyzowanych testów. Jednak nie widzimy tego, jak często naszego czasu zaczyna rosnąć. Może wynikać to z tego, że test jest źle napisany i daną operację robi zbyt długo.

Co polecam?

Allure Report (o, którym pisałem tutaj) ma opcje, która pozwala śledzić trendy, jak również czasu uruchomienia testów.

Jedną z zalet jest też skorzystanie ze slidera, który również pozwala pokazywać, który test np. jest najdłużej uruchamianym testem.

Jeżeli będziemy robić to regularnie to będziemy wiedzieć, który test uruchamia się najdłużej i możemy dojść do wniosku, że powinniśmy w jakiś sposób spróbować przyspieszyć go np. tworząc więcej danych za pomocą API, czy np. przejść bezpośrednio do strony na, której wykonujemy daną akcję, zamiast przechodzenia przez długie menu.

Testy automatyczne dodatkowo dzięki Allure Report są znacznie bardziej przejrzyste do analizy.

Innym pomysłem jest skorzystanie z Grafany (polecam artykuł ) – możemy skonfigurować Grafanę, której będziemy wysyłać informacje o tym ile czasu test się wykonuje. Użycie Grafany (lub innego narzędzia tego typu) ma jeszcze jedną zaletę, pozwala nam to na łatwiejsze znajdywanie tzw. flaky testów, czyli testów, które czasem przechodzą pozytywnie, a czasem kończą się błędem nie koniecznie z winy aplikacji. Gdy mamy statystyki, które prezentują poszczególne wyniki testów, to możemy znaleźć testy, które wymagają reakcji i może poprawy, lub testy pokazują nam jakiś ukryty problem aplikacji, który nie występuję zawsze.

Podsumowanie

W dzisiejszym wpisie pokazałem kilka pomysłów na to, jak przyspieszyć testy automatyczne. Polecam śledzić trendy, bo oprócz pisania testów automatycznych, które są stabilne musimy zwracać uwagę na to by wynik z ich uruchomienia był jak najszybciej dostarczony do nas, żeby testy mogły służyć całemu zespołowi w jak najkrótszym czasie — dzięki temu możemy dostarczać oprogramowanie jeszcze szybciej.