Prezentacja z KraQA #22, 26.10.2016

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ę.

23. FLUENTLENIUM TEST

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

71. NEW RELIC MONITORING

72. NEW RELIC MONITORING

73. NEW RELIC MONITORING

74. NEW RELIC MONITORING

75. NEW RELIC MONITORING

76. NEW RELIC MONITORING

77. NEW RELIC MONITORING

78. NEW RELIC MONITORING

79. NEW RELIC MONITORING

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

85. AWS SELENIUM GRID

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

95. KONFIGURACJA NODE’ÓW

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

116. OCADO TECHNOLOGY
➤krakowjobs@ocado.com
➤wroclawjobs@ocado.com
OcadoTechnology
OcadoTechnology.com