![KONFIGURACJA HUB’A
timeout [ms] - hub zwolni automatycznie node’a, który nie otrzyma zapytania w
zdefiniowanym czasie dla kolejnego kroku testu.
browserTimeout [ms] - maksymalny czas w ciągu, którego node może się zawiesić w
przeglądarce WWW.](https://image.slidesharecdn.com/seleniumgrid-161031104528/85/KraQA-22-Filip-Cynarski-Selenium-Grid-w-chmurze-Amazon-Web-Services-93-320.jpg)
KraQA #22, Filip Cynarski - Selenium Grid w chmurze Amazon Web Services
- 1. SELENIUM GRID on Amazon Web Services cloud
- 2. Ocado Technology Testing Chapter Lead Testuję ponad 8 lat (2008r.) Programuję ponad 18 lat (1998r.) (w tym 12 lat zawodowo) Open Source FluentLenium Filip Cynarski
- 3. AGENDA ➤ Co, to jest Selenium Grid? ➤ Opis ogólny problemu ➤ Jak było na początku w moim projekcie? ➤ Stabilizacja środowiska testowego - naprawa testów ➤ Co osiągnęliśmy? ➤ Czy, to już wszystko? ➤ Czy było warto?
- 4. INFO ➤ Informacje przedstawione podczas tej prezentacji to moje osobiste wnioski. ➤ Sama prezentacja ma charakter indywidualny - nie jest to stanowisko firmy, w której pracuję. ➤ Jej celem jest wymiana doświadczeń oraz przedstawienie, jak udało się nam rozwiązać problem, z którym wielu nie potrafiło sobie poradzić ➤ Co ważne - ta historia trwa nadal i daje nam wiele satysfakcji :)
- 5. W DROGĘ!
- 6. SELENIUM GRID ➤ Aplikacja serwerowa pozwalająca na zdalne uruchamianie testów funkcjonalnych napisanych przy użyciu biblioteki Selenium. ➤ Skalowanie poprzez uruchomienie testów na wielu maszynach i/lub wielu instancjach oraz rodzajach przeglądarek WWW. ➤ Zarządzanie wieloma środowiskami z centralnego punktu (HUB), pozostawiając tym samym HUBowi, zadanie load balancingu. ➤ Określenie wymagań środowiska podawane jest poprzez właściwości zwane DesiredCapabilities ➤ Minimalizacja nakładu pracy poświęconego na utrzymanie środowiska testowego, poprzez automatyzacje czynności takich jak timeout sesji, timeout przeglądarki oraz obsługę innych wyjątków.
- 7. SELENIUM RC, A SELENIUM WEB DRIVER Czym się różnią?
- 8. SELENIUM RC, A WEBDRIVER ➤ Selenium RC (RemoteControl) - poprzednia generacja, komunikująca się z przeglądarka poprzez warstwę pośrednią zwaną Selenium Remote Control Server, wykonującą JavaScript (JS injection) na testowanej stronie. ➤ Znacznie mniej stabilne i mniej wydajne niż w przypadku WebDriver’a. ➤ Selenium w wersji 2.0 zachowywało wsteczną kompatybilność z Selenium RC, od wersji 3.0 wsparcie dla RC zostało zarzucone.
- 9. SELENIUM REMOTE CONTROL - BEZ GRID’A
- 10. SELENIUM REMOTE CONTROL Z GRID’EM
- 11. SELENIUM WEBDRIVER ➤ Selenium WebDriver zastępuje Selenium Remote Control. Komunikacja z przeglądarką poprzez jej natywne API (IE oraz Safari były do niedawna wyjątkiem, zmieniło to pojawienie się przeglądarki EDGE dla IE, oraz Safari 10 wraz z Selenium 3.0) ➤ Selenium RC - jest oficjalnie uznane za przestarzałe (deprecated) brak wsparcia od Selenium 3.0. ➤ Aby korzystać z Selenium Grid’a wystarczy użyć paczki Selenium Server.
- 12. KILKA POWODÓW DLA KTÓRYCH WEBDRIVER JEST LEPSZY ➤ WebDriver oferuje czystsze API, do bezpośredniej komunikacji z silnikiem przeglądarki WWW. ➤ Selenium RC działa na podstawie wstrzykiwania JavaScriptu. ➤ Testy napisane przy użyciu WebDriver’a są szybsze. ➤ O wiele prościej jest rozszerzać kod napisany dla WebDriver’a w porównaniu do klas Selenium RC. ➤ WebDriver może wspierać pisanie testów dla urządzeń mobilnych takich, jak np.: iPhone, iPad, czy platforma Android.
- 13. SELENIUM GRID
- 14. OCADO CASE STUDY Jak udało się nam przestać kręcić się w kółko
- 15. WEBSHOP
- 16. NIESTABILNE TESTY ➤ Niestabilne testy, a wszystko jakoś działa - brak poważnych awarii ➤ Wzajemne testowanie feature’ów przez programistów ➤ Lokalne uruchamianie sfailowanych testów ➤ Powolne przechodzenie procedury release’owej, przeważnie trwającej do kilu dni, w skrajnych przypadkach tydzień lub dwa - konieczność weryfikacji każdego fail’ującego testu. ➤ Testy na produkcji, ale też częste rollback’i.
- 17. TESTY NA PRODUKCJI - RELEASE’Y Blue-Green deployment Beta Rules (funkcjonalność nie dla wszystkich) Inkrementalne przekierowywanie użytkowników ✦staff (not always) ✦2% + staff ✦10% ✦100% Testy manualne zredukowane do minimum
- 18. Posiadanie dwóch środowisk możliwie jak najbardziej identycznych, co do sprzętu i konfiguracji. Redukcja downtime’u. Staging: środowisko testowe dla następnego deployment’u Rollback: szybki powrót do poprzedniej wersji aplikacji Disaster recovery: rezerwowe środowisko, dostępne na wypadek awarii. BLUE-GREEN DEPLOYMENT
- 19. TAK BYŁO ➤ Rozproszenie informacji - wiele źródeł danych - słabo indeksowanych - dokumentacja (właściwie jej brak) ➤ Niestabilne środowiska testowe (CIT, SeleniumGrid, CI) ➤ Rozbieżności w konfiguracji środowiska testowego, a produkcji ➤ Scenariusze w Selenium RC przepisane na WebDriver’a przez programistów - powstaje zaawansowany framework testowy, który ciężko jest zrozumieć, ale nikt nie chce przyznać tego, że nie wie, o co chodzi w tym kodzie :) ➤ Problem z równoległym odpalaniem testów (przeładowanie konfiguracji sklepu, wspólne źródła danych, źle zaprojektowane klasy testowe)
- 20. WNIOSKI ➤ Testy czyta się łatwo i są zrozumiałe, nie chcemy BDD ➤ Sam silnik, nie jest napisany czytelnie (konieczność nadpisania wielu klas FluentLenium i ich samodzielna obsługa). ➤ Sposób organizacji kodu oraz wiele mock’owanych zależności (czasem niemock’owanych - co wiąże się z bezpośrednią integracją z bazą danych, czy też innymi aplikacjami) utrudnia debugowanie kodu. ➤ Ciężko zidentyfikować przyczynę błędu - słabe logowanie. ➤ Wprowadzenie adnotacji oraz samodzielna ich obsługa na podstawie JUnit’owych ruli wprowadza pierwiastek mistyczny :D
- 21. FLUENTLENIUM, CO TO? ➤ Framework testowy oparty zostaje o bibliotekę FluentLenium, która nie jest później aktywnie rozwijana. ➤ W Webshopie rozszerzamy oraz nadpisujemy klasy FluentLenium w rezultacie nadpisujemy prawie całą bibliotekę. ➤ Używamy jej zupełnie inaczej, niż została zaprojektowana. ➤ Co powoduje błędy w czasie wykonania i utrudnia ich identyfikację.
- 24. FLUENTLENIUM PAGE OBJECT PATTERN
- 25. WNIOSKI ➤ Nadpisywanie dobrej biblioteki jest bezsensu. ➤ Trzeba pomóc Mathilde z FluentLenium, aby spełniało nasze wymagania i szło z duchem czasu. ➤ Musimy rozdzielić część modyfikacji FluentLenium od części opisującej testy -> Wydzielenie z projektu biblioteki nazwanej E2EFramework. ➤ Nie chcemy własnej biblioteki - E2EFramework to stan przejściowy - generyczne rozwiązania można przenieść do FluentLenium, a docelowo chcemy pozbyć się wszystkich “udziwnień” -> np. obiekt komponentu.
- 26. NEXUS STATS FROM MAVEN CENTRAL
- 27. CHĘTNIE PRZYWITAMY NOWYCH KONTRYBUTORÓW!
- 28. ➤ Środowisko Selenium Grid skonfigurowane było na wirtualnych maszynach w naszej lokalnej serwerowni w Hatfield (UK) na serwerze VMware. ➤ Zainstalowane na systemie Windows Professional (jedna aktywna zdalna sesja - limit licencyjny) ➤ Opóźnienia i utrudnienia komunikacyjne - wymagana pomoc specjalistów pracujących w innej lokalizacji - brak możliwości dostępu do box’ów od strony administracyjnej. TAK BYŁO
- 29. TAK BYŁO ➤ Środowisko Selenium Grid było zarządzane ręcznie. ➤ Brak monitoringu oraz systemu ostrzegającego. ➤ Blokowanie się kont systemowych poprzez nieudane autentykacje. ➤ Niechęć i brak zaufania programistów do niestabilnego rozwiązania. ➤ Często były wątpliwości i prośby w stylu: “Jak mogę się tam zalogować i zobaczyć na czym się wywala?”
- 30. TAK BYŁO ➤ Zdarzało się pomijanie testów funkcjonalnych przed release’m ➤ Ignorowanie rzeczywistych błędów znalezionych przez te testy - ginęły w szumie generowanym przez niestabilne testy. ➤ Niestabilne wyniki testów, wiele random-failer’ów ➤ Programiści byli zmuszeni do lokalnego, selektywnego uruchamiania testów w celu weryfikacji wyników z Selenium Grid’a - często w trybie debug.
- 31. TAK BYŁO ➤ Ok 450 testów z czego 200-250 fail’i ➤ Źle zliczane fail’e -> wraz z powtórzeniami, co zaciemniało wynik i wpływało jeszcze gorzej na postrzeganie rozwiązania ➤ Początkowy brak specjalistów od automatyzacji testów, a późniejszy niedobór tych osób - framework pisali programiści nie mający doświadczenia z biblioteką Selenium - choć mieli wiele świetnych pomysłów :)
- 32. TAK BYŁO ➤ Później już nikt nie chciał zostać specjalistą od tego, co wydaje się niemożliwe do naprawy. ➤ Jedna, czy dwie osoby nie są w stanie zapanować nad nieustannie zmieniającym się środowiskiem i jeszcze je naprawić, gdy ~80 programistów zmienia co chwilę kod, a większość z nich nie uruchamia tych testów wcale przed merge’m. ➤ Kultura blame’u nie ma sensu. Nie chcemy pokazywać palcem kto zepsuł, jaką zmianą build’a. ➤ Chcemy, żeby ludzie widzieli w tych testach wartość - tylko jak ich przekonać?
- 33. TAK BYŁO ➤ Czasochłonność i wysoka złożoność projektu testowego, jak i testowanej aplikacji. ➤ Testy uruchamiane z Jenkinsa, który budował setki projektów ➤ Obciążone slave’y ➤ Słabe wydajnościowo maszyny ➤ Build (kompilacja, unit testy) wraz z deploy’em testowanego projektu (Webshop’a) trwały ponad godzinę na CI, a lokalnie 30 minut. ➤ Czasami checkout z Mercuriala trwał 20 minut! ➤ Uruchomienie testów funkcjonalnych w najgorszych momentach 4 godziny. (bez zrównoleglenia wykonania - testy trwają 9 godzin)
- 34. TAK BYŁO ➤ Za dużo tych zmiennych! ➤ Za dużo to wszystko trwa, prawie dzień, aby otrzymać feedback ze zmian, a potem jeszcze dzień lub dwa na ręczne odpalania fail’ujących Selenium’ów… ➤ Brak metryk oraz danych pozwalających rozwiązać problem. ➤ Trzeba to uprościć oraz ustalić metryki na podstawie zebranych danych, które pozwolą nam podjąć dalsze działania. ➤ Wszystko trwa za długo, feedback jest bardzo opóźniony. Nie da się tego testować metodą prób i błędów.
- 35. PODSUMOWANIE ➤ Zbiór testów funkcjonalnych napisanych w Selenium, zwany potocznie Seleniumami był koszmarem wszystkich - czasami chcieliśmy je po prostu usunąć i napisać od nowa. ➤ Ale nie mogliśmy :) Bo była i jest to dokumentacja tego jak działa nasz sklep, co więcej prócz swej uciążliwości wykrywała błędy. ➤ Nawet selektywne odpalanie testów było szybsze niż ręczne wykonywanie scenariuszy, głównie przez skomplikowany setup.
- 36. PODSUMOWANIE ➤ Pisząc coś od nowa można napisać podobnie, albo nawet gorzej. ➤ Przykład migracja z RC na WebDriver’a. Miało być ładnie i było, ale gdy zbliżał się deadline, część testów została przekopiowana, bez analizy. ➤ To, co mieliśmy nie było złe, wymagało trochę pracy.
- 37. CZAS TO ZMIENIĆ!
- 38. PIERWSZE KROKI ➤ Mierzenie nieznanego ➤ Analiza stabilności testów ➤ Brak możliwości gromadzenia wyników w środowisku CI ze względu na ograniczone zasoby, a nawet gdyby dołożyć storage - są lepsze możliwości. ➤ Początkowe użycie plugin’u (testlink jenkins plugin) JUnit -> TestLink, ale było to zbyt wolne i miało wady: ➤ nie tworzyło testów ➤ procesowało raport wyprodukowany przez JUnita. ➤ Stworzenie własnego narzędzia do zbierania wyników i zasilania nimi TestLink’a (teraz TestRail’a).
- 39. PIERWSZE KROKI ➤ Potrzebujemy zapisywać wyniki z testów w TestLinku ➤ Samodzielna próba naprawy niestabilnych testów ➤ Identyfikacja przyczyn ➤ Środowiska (CIT, SeleniumGrid) ➤ Źle napisane testy ➤ Zależności (systemy zewnętrzne: Facebook, PayPal, etc.)
- 40. PIERWSZE KROKI ➤ Automatyzacja zarządzania środowiskami Selenium Grid ➤ Mieliśmy w końcu 20 maszyn zamiast 4 gdzie można było uruchamiać testy ➤ Kto by to klikał? ➤ Ansible ➤ WinRM ➤ Eksperymenty z konfiguracją
- 41. ansible-playbook seleniumgrid.yml -i webshop
- 42. PIERWSZE KROKI ➤ Programiści tworzyli feature’y, my staraliśmy się za nimi nadążyć, ale było ciężko… ➤ Udało nam się zejść z 200 fail’i do 5, któryś z nas poszedł na urlop, drugi robił co mógł :D ➤ Po urlopie znów było 200+ fail’i :D
- 43. WNIOSKI ➤ Mamy za dużo testów do utrzymywania ➤ Jest nas za mało ➤ Jenkins gubi wyniki testów po paru build’ach ➤ Programiści powinni uruchamiać testy przed merge’m ➤ Ale nie mogą, bo: ➤ nie mają czasu czekać na siebie na wzajem (jedno uruchomienie na całą firmę) ➤ trwa to za długo ➤ później i tak są same fail’e
- 44. AKCJE ➤ Polecieliśmy do UK, zebrać informacje od biznesu jak ważne są te testy. ➤ Biznes ma trochę dość, czujemy nawet, że jak sprawa się nie rozwiąże, usuniemy te testy całkowicie, bo blokuje to development. ➤ Wybierzmy te najważniejsze testy i dbajmy o nie najbardziej (Regression test suite) ~80 scenariuszy, obecny czas wykonania 20min (wtedy było około godziny). ➤ Zatrudnijmy osoby do pomocy - więcej QA’ów ➤ Jeśli testów będzie mniej, to: będą szybsze będzie można na nich polegać programiści nauczą się je uruchamiać (będą widzieli w nich wartość)
- 45. AKCJE ➤ Napisaliśmy bibliotekę (PYRA) do przechwytywania wyników i zapisywania ich w TestLink’u, później w TestRail’u ➤ W końcu mogliśmy porównywać wyniki, i śledzić stabilność testów ➤ Nasze eksperymenty mogliśmy uruchamiać, a wyniki analizować później i obserwować ich wpływ na framework testowy ➤ Modyfikacje FluentLenium, niezwiązane z framework’iem zostały wyeksportowane od zewnętrznej biblioteki (E2EFramework) w celu ułatwienia analizy przyczyn awarii.
- 46. PYRA - PUSH YOUR REQUEST AGGREGATOR
- 47. TEST LINK
- 48. TEST LINK
- 49. TEST RAIL
- 50. TEST RAIL
- 51. CO DALEJ? ➤ Na Jenkinsie powstał nowy job -> Selenium Regression wzbudzany przez każdy push do default’a. ➤ Był nawet stabilny… Przez 2 tygodnie :D ➤ Nie byliśmy w stanie zapewnić stabilności nawet 80 testów. ➤ Dlaczego?
- 52. DLACZEGO UTRZYMANIE 80 TESTÓW NAS PRZEROSŁO ➤ Były to testy przekrojowe, więc i tak pokrywały kluczowe funkcjonalności - nie uciekliśmy od problemu, ale zmniejszyliśmy skale (to było na plus). ➤ Dbałość o testy funkcjonalne nie jest tylko obowiązkiem jednej czy dwóch osób, wszyscy powinni o nie dbać. ➤ Niestabilność środowiska, długi czas wykonania oraz oczekiwania na swoją kolej powodował niechęć do uruchamiania tych testów. ➤ Zaczęliśmy uświadamiać wszystkich zaangażowanych w proces development’u (programistów, PO, QA, management), że ignorowanie błędów w tych testach doprowadzi nas do punktu, w którym rozpoczęliśmy nasze zmagania.
- 53. CO DALEJ - USPRAWNIENIA ➤ Postanowiliśmy zrezygnować z Windowsów, czas na Linux’a ➤ Poprosiliśmy o dedykowane wirtualne maszyny w naszej infrastrukturze do testów naszego pomysłu. ➤ Powinno teraz śmigać?
- 54. SELENIUM GRID NA UNIX’SIE ➤ To byłoby za proste :D ➤ Stworzono nam za słabe maszyny ➤ Wewnętrzny dział nie potrafił dobrze zarządzać wirtualnymi serwerami ➤ Stworzone maszyny zajmowały sobie wzajemnie zasoby i doprowadzały do niestabilnego zachowania środowiska (natychmiastowe wysycenie pamięci)
- 55. OCZEKIWANIA FIRMY ➤ Szybkie w wykonaniu testy ➤ Możliwe zrównoleglenie i zwielokrotnienie ich wykonia ➤ Stabilne środowisko gdzie testy są uruchamiane (Selenium Grid, CIT, DB) ➤ Stabilne rezultaty wykonania testów ➤ Łatwy w utrzymaniu projekt testowy
- 56. ZACZNIJMY OD SELENIUM GRID
- 57. ZOSTAŁ JESZCZE AWS ➤ Kwestie bezpieczeństwa: ➤ Mamy wiele podsieci w Ocado na AWS ➤ Podsieci na AWS są odizolowane i prawie żadna nie wie o istnieniu drugiej ➤ Jest taka jedna podsieć, która widzi sieć Ocado i inne podsieci na AWS (jest dostępna tylko dla jednego zespołu) ➤ Port 22 (SSH) działa tylko w jednym kierunku Ocado -> AWS ➤ Będzie ciężko :)
- 58. ZOSTAŁ JESZCZE AWS ➤ Dostaliśmy dostęp do sieci na AWS, która jest widoczna dla wszystkich podsieci w chmurze i w Ocado. ➤ Z AWS nie widzieliśmy bazy danych, ani środowiska testowego. ➤ Konfiguracja load balancer’a dla testowych serwerów ➤ Wystawienie wewnętrznych adresów dla podsieci AWS ➤ Baza danych nie będzie dostępna z AWS ➤ EC2 AWSowe już widzą nasze testowe serwery
- 59. PLAN KOMUNIKACJI SIECIOWEJ HUB 2 - testowy HUB 1 - produkcyjny
- 60. KONFIGURACJA EC2 NA AWS’IE ➤ Napisaliśmy Ansible, które pomogą nam postawić całe środowisko. ➤ Wiemy, że odpalamy 16 równoległych wątków, wątki te uruchomią przynajmniej 16 okien przeglądarki chrome, oraz na każdej z tych maszyn działa przynajmniej jedna JVMka z Selenium Grid’em. ➤ Odpalamy testy i… Oczekujemy sukcesu… ale same błędy lecą, coś jednak jest nie tak… ➤ Wybieramy, najmocniejsze z maszyn na EC2 i nadal, TIMEOUTy, FORWARDING_TO_NODE_FAILED (po 30 minutach działania testów zaczyna być gęsto od błędów samego Grid’a, a na koniec OutOfMemory error z JVM) ➤ Nie możliwe, a jednak ;) “To chyba nie jest dobre rozwiązanie” - czy, aby na pewno?
- 61. POSZUKIWANIE PROBLEMU ➤ Wyizolowanie problemu ➤ Monitoring ➤ JMX - Java Management Extensions - (wystarczył) ➤ AWS monitoring - cały serwer bez JVM ➤ NewRelic (na sam koniec) - tego nie mieliśmy na początku ➤ JVM oraz serwer
- 62. AWS MONITORING
- 63. JMX KONFIGURACJA java -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -jar seleniumServer.jar Lokalnie nie potrzebujesz JMX, możesz podłączyć się do procesu po jego id (PID).
- 64. CZEGO DOWIEDZIELIŚMY SIĘ NA PODSTAWIE ANALIZY JMX ➤ Ustawienie Xmx and Xms na wyższe wartości niż domyślne poprawia stabilność konfiguracji w tak rozbudowanej suicie testowej. java -Xmx2048m -Xms512m -jar /home/ubuntu/seleniumagent/seleniumserver-2.53.1.jar -role hub -hubConfig /home/ubuntu/seleniumagent/hub.config java -Xmx2048m -Xms512m -jar /home/ubuntu/seleniumagent/seleniumserver-2.53.1.jar -Dwebdriver.chrome.driver=/home/ubuntu/seleniumagent/chromedriver -port 4443 -role node -nodeConfig /home/ubuntu/seleniumagent/Node.json
- 65. ANALIZA JVM PRZEZ JMX W JCONSOLE
- 66. ANALIZA JVM PRZEZ JMX W JCONSOLE
- 67. ANALIZA JVM PRZEZ JMX W JCONSOLE
- 68. ANALIZA JVM PRZEZ JMX W JCONSOLE
- 69. ZA MAŁO WĄTKÓW ➤ Jeśli zauważysz, że Twoje środowisko jest tak duże (ilość testów/node’ów) i zaczyna brakować Tobie wątków (domyślnie 256 dla jetty) org.openqa.jetty.http.SocketListener isLowOnResources INFO: LOW ON THREADS ((256-256+1)<2) on SocketListener1@0.0.0.0:80 ➤ Możesz dodać jeszcze parametr przy uruchamianiu Grida: -DPOOL_MAX=1024
- 70. NEW RELIC MONITORING ➤ Notyfikacje o awariach (Slack) ➤ Analiza wydajności rozwiązania - możliwość podjęcia decyzji na temat kosztów i infrastruktury java -javaagent:/home/ubuntu/seleniumagent/newrelic.jar -Xmx2048m -Xms512m -jar /home/ubuntu/seleniumagent/seleniumserver-2.53.1.jar -Dwebdriver.chrome.driver=/home/ubuntu/seleniumagent/chromedriver -port 4443 -role node -nodeConfig /home/ubuntu/seleniumagent/Node.json
- 80. TYPY INSTANCJI EC2 NA AMAZON ORAZ OGRANICZENIA ➤ https://aws.amazon.com/ec2/instance-types/ ➤ Dedicated bandwidth dla EBS (Elastic Block Store) Scroll the page down!
- 83. NETWORK PERFORMANCE METRIC ➤ http://www.ec2instances.info/ ➤ Network performance: ➤ Very low ➤ Low ➤ Low to Moderate ➤ Moderate ➤ High ➤ 10 Gb ➤ 20 Gb
- 84. TYPY INSTANCJI EC2 NA AMAZON ORAZ OGRANICZENIA ➤ Dostosowanie infrastruktury do wymagań ➤ Wybrać coś mocniejszego, zmierzyć ile rzeczywiście potrzebujemy ➤ Później skalować w dół w celu optymalizacji kosztów
- 86. ENVIRONMENT PROVISIONING ➤ Kiedyś ręcznie lub przez ticket’y ➤ RUNDECK - Anvil ➤ AWS tags ➤ Jak się skalujemy ➤ 6 node’ów ➤ 15 chrome’ów na każdym ➤ Bazujemy na AWS tagach dla Webshop’a
- 87. AWS TAGS
- 88. AWS TAGS
- 89. DYNAMICZNE TWORZENIE GRIDA - CZY WARTO? ➤ Nasze testy odpalają się po każdym push’u dlatego czas konieczny na postawienie środowiska (około 5-10minut) wydłużyłby czas oczekiwania na odpowiedź. ➤ Mamy w tym projekcie około 80. osób, w jednej godzinie jest kilka zmian z różnych źródeł ➤ AWS nalicza nam opłaty za każdą rozpoczętą godzinę lub start EC2
- 90. DYNAMICZNE TWORZENIE GRIDA - CZY WARTO? ➤ Można też inaczej: ➤ AWS API ➤ AWS API wrappers to scale Selenium grid: https://github.com/mhardin/SeleniumGridScaler ➤ Należy rozważyć jaka jest polityka uruchamiania testów i jaki model dla nas będzie najlepszy ➤ Jeśli decydujemy się na dynamiczne tworzenie node’ów pamiętajmy o puli adresów IP w podsieci AWS.
- 91. FORWARDING_TO_NODE_FAILED - NIGHTMARE ➤ Jak unikać ➤ Serwery w tej samej podsieci, możliwie blisko ➤ Szczególnie HUB <-> Node ➤ Wysoka przepustowość łącza na interfejsach sieciowych EC2, przy dużej ilości równoległych testów - bardzo szybko pojawiają tego rodzaju błędy.
- 92. CO ZROBIĆ, ŻEBY ZAPOMNIEĆ O PROBLEMACH Z GRIDEM ➤ Odpowiednio dobrana infrastruktura AWS ➤ Zautomatyzowany proces deployment’u i provisioning’u ➤ Zadbanie o automatyczne czyszczenie środowisk ➤ Restart Grida (nam starcza raz dziennie) ➤ HUB po kilku tysiącach testów zaczyna się destabilizować ➤ Zamykanie ghost browsers (raz dziennie, śmielej tych działających dłużej niż N minut) ➤ Odpowiednia konfiguracja HUB’a i Node’ów
- 93. KONFIGURACJA HUB’A timeout [ms] - hub zwolni automatycznie node’a, który nie otrzyma zapytania w zdefiniowanym czasie dla kolejnego kroku testu. browserTimeout [ms] - maksymalny czas w ciągu, którego node może się zawiesić w przeglądarce WWW.
- 94. KONFIGURACJA HUB’A browserTimeout powinien być większy, od: ➤ timeout’a (z doświadczenia - może być równy) ➤ socket lock timeout (45 sekund), ➤ Większy od timeout’ów WebDriver’a -> webDriver.manage().timeouts() jest to ostatnia deska ratunku dla SeleniumGrida. Źródło: https://github.com/SeleniumHQ/selenium/wiki/Grid2
- 96. MECHANIZM KOLEJKOWANIA ➤ Lepiej na nim nie polegać ➤ Kiedy test będzie za długo w kolejce - rzuci timeout exception ➤ Lepiej uruchamiać mniej testów niż mamy dostępnych slotów ➤ Czasem się przydaje, ale traktujmy to jako wyjątkową sytuację
- 97. INSTALACJA GRIDA - WEBSHOP ➤ HUB+NODE1 - na jednym serwerze ➤ NODE2…NODEn - na reszcie serwerów ➤ Korzystamy z obrazu Ubuntu ➤ Każdy z nich ma: ➤ VNC ➤ Xvfb ➤ Chrome’a ➤ Opcjonalnie Firefox ➤ Czcionki TTF ➤ Selenium HUB i/lub Node
- 98. STABILNY SELENIUM GRID ➤ Jeśli przeglądarka się z jakiegoś powodu zawiesi, miną 3 godziny zanim testy sfailują. ➤ Tyle wynosi HTTP client socket timeout, dla jednego slotu w nodzie, aby stał się ponownie dostępny. ➤ Jak to naprawić: ➤ Naprawić test, który powoduje problem, ➤ Cronjob ubijający przeglądarki działające zbyt długo.
- 99. UBIJANIE PRZEGLĄDAREK PO CZASIE WYKONANIA ➤ Można dodać do crontab’a kill -9 $(ps -eo comm,pid,etimes | awk '/^chrome / {if ($3 > 900) { print $2}}’) Nie ubijać chromedriver’a - może obsługiwać więcej niż jedną przeglądarkę: ➤ Class level driver sharing - na przykład
- 100. DRIVER SHARING
- 101. DRIVER SHARING - FLUENTLENIUM
- 102. STABILNY SELENIUM GRID ➤ Samo środowisko do uruchamiania testów nie starczy ➤ Zrównoleglenie wykonania testów w celu ich szybszego uruchomienia. ➤ Skalowanie aplikacji testowanej, by była zdolna przyjąć ruch. ➤ Pisanie testów tak, aby dało się je uruchomić równolegle / by nie blokowały środowiska. ➤ Jeśli Twoja infrastruktura pozwala odpalić wszystkie testy na raz, warto wprowadzić opóźnienia, w celu uniknięcia wysycenia zasobów na środowisku gdzie projekt testowy jest uruchamiany (warm up aplikacji przed testami).
- 103. REDUKCJA TESTÓW UI ➤ Monitorowanie trendu ilości testów na poziomie UI, ➤ Pokrycie funkcjonalności na poziomie testów integracyjnych oraz jednostkowych, ➤ Rozbicie większych scenariuszy, ➤ Test powinien być atomowy, tj. testować jedną funkcjonalność a nie ich zbiór.
- 104. KLUCZOWE KROKI, DZIĘKI KTÓRYM ODNIEŚLIŚMY SUKCES ➤ Świadomość wagi celu ➤ Zidentyfikowanie źródeł problemu ➤ Środowisko Selenium Grid ➤ Środowisko testowe ➤ Źle napisane testy szczególnie setup i clean up ➤ Zatrudnienie QA w celu wypracowania lepszego zrozumienia problemu jakości dostarczanych rozwiązań oraz przypisanie ich do zespołów w celu zwiększenia świadomości skali problemu. ➤ Specjalizacja QA w kierunku SET.
- 105. KOSZTY ➤ Rozważenie jak nasze testy będą uruchamiane ➤ Raz dziennie, dwa razy dziennie, co godzinę, częściej ➤ Nie zawsze zatrzymanie EC2 się opłaca ➤ Czym mniej testów tym lepiej -> nie zawsze wszystko trzeba testować na poziomie UI’a.
- 106. TESTY SIĘ WYKONUJĄ ➤ Grid jest stabilny, ale testy nie… ➤ Zaczynamy naprawiać testy ➤ Jest nas już więcej, mamy stabilne wyniki testów ➤ Możemy polegać na środowisku ➤ Wiemy, gdzie jest przyczyna błędu jeżeli jest raportowany przez testy ➤ Może warto coś jeszcze poprawić? ➤ O tak! Deploy trwa teraz godzinę, Jenkins jest wolny, slave’y słabo dostępne, brakuje miejsca na dysku, nie mamy nad tym kontroli
- 107. NASZE WŁASNE CI ➤ Wybraliśmy TeamCity - i to był dobry wybór ➤ Agent potrafi udostępnić artefakty innym agentom poprzez port 80, co rozwiązuje nam utrudnienia wynikające z blokowaniem portów między AWS, a siecią Ocado ➤ Synchronizacja repozytorium (VCS) do agentów - już się nie zawiesza. ➤ Możemy stworzyć własnych agentów! ➤ Najmocniejsza na AWS EC2 uruchamia testy Unit’owe i buduje Webshopa zamiast 1h w 5minut, wraz z deployem trwa do 10minut ➤ Programiści czekają więc na deploy ponad 50minut mniej.
- 108. AGENT DO BUDOWANIA WEBSHOP’A Oczywiście są jeszcze mocniejsze maszyny, ale c4.8xlarge nam wystarczył.
- 109. TEAM CITY
- 110. TEAM CITY
- 111. NIE ZAWSZE POTRZEBA TAK MOCNYCH MASZYN ➤ To jakie instancje są Tobie potrzebne powinieneś ocenić na podstawie analizy danych oraz eksperymentów z konfiguracją środowiska. ➤ Webshop i ładowane przez niego zasoby znacznie obciążają przeglądarkę - jest to witryna zawierająca wiele grafik, zaawansowanych skryptów JS oraz analitykę. ➤ Dodatkowo, mamy spory narzut na komunikację sieciową wynikającą z kwestii bezpieczeństwa i historycznych zależności. ➤ Dla mniejszych projektów starczają nam jedne ze słabszych (często darmowych) instancji.
- 112. JESZCZE MAMY SPORO DO ZROBIENIA ➤ Chcemy uruchamiać testy z AWSa (pominięcie problemu z łącznością do bazy danych) ➤ Chcemy móc tworzyć środowisko testowe w “locie” ➤ Mockować większość zależności (teraz nie wszystko mamy zamockowane) ➤ Np. PayPal i płatności (w trakcie), Facebook API, baza danych
- 113. JESZCZE MAMY SPORO DO ZROBIENIA ➤ Mieć dwie suite’y testowe: ➤ Uruchamiać więcej testów równolegle - idealnie by było, aby pełna suita trwała 5-10 minut. ➤ Szybką - testującą Webshop’a w izolacji. ➤ Wolniejszą i mniejszą (E2E) - sprawdzającą czy podstawowe przypadki (np. regresja) działają w integracji z serwisami od których aplikacja zależy - to już mamy, choć jest w niej za dużo testów na tym poziomie. ➤ Mamy jeszcze co robić w tym temacie, ale już nie kręcimy się w kółko i wiemy, dlaczego test raportuje błąd!
- 114. INNE ŹRÓDŁA YouTube: Expedia, Distributed Automation Using Selenium Grid / AWS / Autoscaling -> *Browser timeout jest w ms (Grid 2.53.1) https://www.youtube.com/watch?v=cbIfU1fvGeo