Ciężkie czasy nastały… Każą nam siedzieć w domach i nigdzie się nie ruszać. W naszej branży to jeszcze nie jest tak źle, możemy, a nawet musimy pracować z domu. Nie będę się tutaj rozpisywał, jak sobie ułożyć pracę w domu, aby nie zwariować. Pewnie obejrzałeś/-aś bądź przeczytałeś/-aś wiele branżowych materiałów na ten temat. Ja chcę spojrzeć na obecną sytuację od drugiej strony. Czy Twój proces testowania oprogramowania sprostał koronawirusowi? Czy jest on tak samo efektywny, jak był jeszcze 2 miesiące temu?
Jeżeli Twoje rozwiązanie opiera się głównie o testy manualne, to na płynność ich wykonywania, może teraz mieć negatywny wpływ ogólne obciążenie sieci internetowej. Wiadomo, teraz prawie cały świat, o ile może, to pracuje z domu. Nawet platformy wideo ograniczają maksymalną rozdzielczość dostarczanych materiałów. Pracując z domu, łącząc się do serwera testowanej aplikacji, korzystając z połączenia VPN, możesz nie mieć takiej samej przepustowości jak w biurze. A to wydłuża czas wykonywania testów, jak i zwiększa Twoją frustrację. Może to dobry moment, aby w końcu zacząć wdrażać automatyzację?
W przypadku testów automatycznych najważniejszą zasadą jest: nie uruchamiaj testów ze swojego komputera. To jest Twoja maszyna do tworzenia testów, a nie do ich uruchamiania. Tak samo jak w przypadku oprogramowania, które testujesz. Nie zgadzasz się przecież testować go na maszynie programisty, tylko jest ono wrzucane na środowisko testowe. Ten sam reżim powinieneś/-aś wprowadzić dla testów automatycznych.
Dzięki takiemu podejściu zapewniasz swoim testom dodatkową stabilność i powtarzalność. Nie są już one zależne od lokalizacji twojego komputera i jego obciążenia. Jednym słowem, nieważne gdzie jesteś i skąd uruchamiasz testy, wykonują się one zawsze w zbliżonych warunkach, a co najważniejsze, mogą się one ograniczyć do firmowego intranetu, więc obecnie panujące warunki nie powinny mieć na nie żadnego wpływu.
Build serwer / CI
źródło: https://pixabay.com/illustrations/devops-business-process-improvement-3148393/
Skoro nie powinieneś/-aś uruchamiać testów na swoim komputerze, to uruchamiaj je na zewnętrznym serwerze, na build serwerze. Najczęściej używane obecnie produkty to Jenkins lub TeamCity.
Pamiętaj, że na początek to nie musi być od razu pełny proces CI, gdzie testy są automatycznie odpalane po każdej kompilacji i po każdym nowym deploymencie aplikacji. Jeżeli to jest Twoje pierwsze podejście do integracji testów automatycznych z build serwerem, warto zacząć od najprostszego rozwiązania: testy uruchamiane ręcznie na serwerze. To i tak jest dużo, dużo lepsze rozwiązanie, niż testowanie z własnej maszyny, i od tego radzę zacząć. Na większą automatyzację przyjdzie jeszcze czas…
Jeżeli Twoje testy automatyczne są oparte o jeden z wielu języków programowania (Python, Java, C# itp. itd.) wraz z dedykowaną biblioteką, ułatwiającą pisanie testów (np. RestAssured dla Javy) to nie powinieneś/-aś mieć problemu z uruchomieniem tych testów na systemie CI. Wszakże, uruchomienie takich testów praktycznie nie różni się od budowania aplikacji, którą trzeba przetestować. Upewnij się tylko, że serwer CI ma dostęp do testowanej usługi. Wykorzystaj tą samą komendę, którą uruchamiasz testy ze swojej maszyny.
Postman
Jeżeli Twoje rozwiązanie testów automatycznych jest oparte o Postman’a, tutaj jest trochę komplikacji, ale co najważniejsze, nadal jest to możliwe. W tym przypadku na pomoc rusza narzędzie zwane Newman. Jest to narzędzie, które pozwala na uruchamianie kolekcji Postman’owych z poziomu lini poleceń z pominięciem samego Postman’a. Musisz teraz wyeksportować swoją kolekcje testów, a następnie:
1newman run <plik_collections>
Oczywiście zamiast <plik_collections> podstaw nazwę pliku z Twoimi testami. Jeżeli korzystasz ze zmiennych środowiskowych, jak również, z predefiniowanych zmiennych globalnych, newman również pozwala na ich użycie, dodaj do komendy opcje:
1--globals <plik_globals> --environment <plik_environments>
Newman obsługuje również plik z zestawem danych do testów parametryzowanych. W przeciwieństwie do Postmana wspiera tylko format CSV, więc jeżeli do tej pory korzystałeś z danych w postaci plików JSON, to czeka Cię konwersja do odpowiedniego formatu. Potem już tylko pozostaje ci rozszerzyć komendę o dodatkową opcję:
1--iteration-data <plik_danych>
Podsumowywując, Newman daje Ci możliwość uruchamiania testów Postmanowych, wykorzystując wszystkie potrzebne funkcjonalności zaszyte w oryginale. Dzięki temu nie powinieneś mieć już problemu z uruchamianiem takich testów z poziomu serwera CI.
Testy Web UI
źródło: https://pixabay.com/illustrations/software-testing-service-762486/
Jeżeli do testów automatycznych potrzebujesz przeglądarki, nadal możesz wykonanie takich testów zlecić serwerowi CI. Musisz tylko rozwiązać problem Jak dostarczyć przeglądarkę do serwera? Tutaj masz dostępne dwa podstawowe rozwiązania.
1. Tryb headless
Firefox oraz Chrome pozwalają na uruchomienie się w tzw. trybie “headless”. Jest to tryb, w którym przeglądarka nie wyświetla swojego okna, wszystko się dzieje w pamięci operacyjnej systemu. Poza tą drobną różnicą, że wszystkie pozostałe funkcjonalności pozostają bez zmian, Działa również robienie zrzutów ekranu, o ile korzystasz z funkcji wbudowanych w Web Driver’a, a nie korzystasz z wywołań systemowych.
Jeżeli zdecydujesz się na korzystanie z tego podejścia, wystarczy, że na serwerze, na którym stoi system CI, zainstalujesz potrzebną Ci przeglądarkę, a w testach odpalisz ją w trybie “headless”. Więcej informacji dla Firefox’a znajdziesz tutaj, a dla Chrome’a tutaj.
2. Selenium Grid
Powyższe rozwiązanie ma jedną wadę: obciąża dodatkowo serwer CI, co zazwyczaj nie jest akceptowalne. Jeżeli z tego serwera korzysta wiele projektów, ich budowanie oraz uruchamianie testów jednostkowych może się znacznie wydłużyć, co nie jest pożądane. Na ratunek przychodzi Selenium Grid, czyli dedykowany serwer, którego udostępnianą usługą są przeglądarki (w większości przypadków uruchamiane w trybie headless).
Jak już zdecydujesz się na to rozwiązanie, lub chcesz tylko spróbować, to radzę skorzystać z jednego z gotowych rozwiązań. Największą zaletą z takiego podejścia jest prostota uruchomienia takiego serwisu, w dobie wszędobylskiego Docker’a jest to jedna komenda i serwer działa, i można z niego korzystać. Drugą zaletą są dodatkowe funkcjonalności takie jak rozszerzone raportowanie, czy nagrywanie okna przeglądarki w trakcie wykonywania testu, aby można było sobie potem takie nagranie odtworzyć i sprawdzić co dokładnie poszło nie tak.
Z mojej strony mogę zarekomendować dwa takie gotowce Selenium Grid: Selenoid oraz Zalenium. Sprawdź sam i przekonaj się jakie to proste.
Podsumowanie
Jeżeli efektywność Twoich testów w dobie koronawirusa jest taka sama jak przed, brawa dla Ciebie! Masz dobrze wszystko przemyślane i Twój projekt przechodzi test koronawirusa. Jeżeli jednak tak nie jest, może to dobry moment, aby sprawdzić, co można poprawić, aby w przyszłości nie miało znaczenia, skąd przeprowadzasz swoje testy. A jak już to poprawisz, to może będzie dobra okazja, aby kupić kampera i ruszyć w trasę, oczywiście ciągle pracując z miejsc, gdzie akurat się zatrzymałeś.
