Репутація українського ІТ. Пройти опитування Асоціації IT Ukraine
×Закрыть

Скорочуємо час виконання UI-тестів з використанням Selenium Grid у Minikube-кластері

Привіт. Я Євгеній Овчаренко, працюю QA Automation Lead у Master of Code Global. Маю 4 роки досвіду як мануального, так і автоматизованого тестування. Зараз займаюся розробкою автоматизованих тестів з використанням різних платформ і фреймворків Java (Selenide, Selenium, REST Assured, JUnit) і Node.js (Jest).

У статті, спираючись на власний досвід, я розповім про проблему великої тривалості виконання UI-тестів, поділюся інформацією про Selenium Grid і Minikube та як з їхньою допомогою можна вирішити проблему, перевагами і недоліками запропонованого підходу.

Матеріал буде корисним:

  • QA Automation-інженерам (для скорочення часу виконання тестів);
  • розробникам (для самостійної реалізації цього процесу, за відсутності QA-інженера в команді);
  • менеджерам проєктів і продакт-оунерам — для розуміння того, як цей підхід може заощадити час і кошти).

Selenium Grid cluster

Дослідження теми я почав, коли зіткнувся з тим, що послідовне виконання тестів в одному потоці для одного браузера займає в середньому 40 хвилин. А під час крос-браузерного тестування кожен додатковий браузер потребує такої самої кількості часу. Шукаючи шляхи оптимізації цього процесу, я зупинився на Selenium Grid-кластері.

Selenium Grid-кластер має два основні компоненти: hub i nodes.

Hub — сервер, який приймає запити на доступ від клієнта WebDriver і направляє тестові команди JSON на віддалені диски на nodes. Він проводить одночасне виконання тестів на декількох машинах, централізовано керуючи різними браузерами, що полегшує аналіз і порівняння результатів.

Node — віддалений пристрій, який складається з рідної ОС та віддаленого WebDriver. Він отримує запити від Hub у вигляді тестових команд JSON і виконує їх за допомогою WebDriver.

Архітектура Selenium Grid

Пропоную розглянути результати виконання smoke-тестів, використовуючи підхід Selenium Grid:

  • Виконання тестів в одному потоці для одного браузера почергово займає в мене 9 хвилин 25 секунд, а на двох — 18 хвилин 55 секунд.
  • Для пришвидшення виконання тестів запускаю їх у двох браузерах паралельно, використовуючи Selenium Grid підхід (тобто на виконання двох потоків іде 9:25 хвилин 25 секунд, а не 18 хвилин 55 секунд, як у попередньому варіанті).

Утім, проблема із виконанням тестів в одному потоці для кожного браузера лишилася, і я шукав способи її розв’язання.

Minikube cluster

Найважливішим в ухваленні рішення на користь Selenium Grid у Minikube-кластері стало те, що він зручний у налаштуванні, не потребує додаткової підтримки, безплатний.

Він має два типи ресурсів: Master i Node.

Master управляє кластером: запуском застосунків, їхнім плануванням, підтримкою й оновленнями. Master містить такі типи ресурсів:

  • Controller manager — стежить за загальним станом кластера через API server і вносить зміни, щоб перевести поточний стан у необхідний.
  • Scheduler — це частина платформи Kubernetes, що спостерігає за новоствореними подами, яким не призначено node. Він відповідальний за пошук найкращого вузла, на якому буде запущений pod.
  • API server.

Node — це віртуальна машина, або фізичний комп’ютер, що виконує функцію робочої станції в кластері Kubernetes. Вона має утиліту Kubelet — агента управління нодою та спілкування з Kubernetes-майстром через API server, а також Docker-інструменти обробки операцій з контейнерами:

  • Kubernetes Pod — група контейнерів, розгорнутих на одному хості.
  • ServiceProxy — сервер для доступу до hub.
  • Kubelet — відповідає за підтримку pods і працює з PodSpec.
  • PodSpec — це специфікація, що описує поведінку pod в YAML- або JSON-файлах.

Архітектура Minikube

Результати виконання тестів

Розуміючи, що таке Minikube, розглянемо результати виконання тестів з використанням Selenium Grid у Minikube-кластері.

З підходом Selenium Grid у Minikube-кластері запускаю тест у три потоки для одного пулу з’єднань браузера Firefox, масштабованого до трьох у Minikube-кластері. Таку саму конфігурацію застосовую до Chrome. З таким підходом виконання сотні тест-кейсів на обох браузерах (по п’ятдесят на кожен) займає 5 хвилин 28 секунд. Цим ми скоротили час виконання тестів на 14 хвилин.

Щоб більше мінімізувати час, можна збільшити потоки виконання тестів і масштабувати браузери. Але важливо враховувати ресурси вашої локальної машини.

Тож використання підходу Selenium Grid у Minikube-кластері заощадило 72% часу. Якщо треба запустити більшу кількість тестів, ресурси, витрачені на налаштування інфраструктури й написання коду, компенсуються. Справа за часом: на проєктах з активною фазою розробки й постійними деплоями це відбудеться швидше, а в інших — повільніше, залежно від кількості запуску тестів.

Плюси та мінуси

Для мене перевагами підходу є:

  • Відсутність додаткових витрат та обслуговування.
  • Легке встановлення на локальну машину, швидке налаштування й оновлення.
  • Наявність змістовної бази інструкцій.
  • Можливість легко мігрувати на Kubernetes-кластер до хмарних обчислень у разі браку ресурсів локальної машини.
  • Зручний Dashboard для моніторингу й перегляду логів і масштабування браузерів.
  • Self-healing-підтримка, що дає змогу автоматично перезапускати контейнери, якщо вони з якоїсь причини стали недоступні.
  • Усунення проблем із затримкою передачі інформації між сервісами в кластері завдяки тому, що сервіси перебувають в одній мережі.
  • Масштабоване рішення.

Серед недоліків можу виокремити:

  • Відмовостійкість. Якщо локальна машина, на якій запущено Minikube з налаштованим Selenium Grid, недоступна, то доступу не буде й до всього кластера.
  • Hub доступний лише в одному екземплярі й не масштабується. Тому якщо він стане тимчасово недоступним, тести, відправлені клієнтом, і тести, запущені на інших вузлах, будуть фейлитися. Та завдяки self-healing capability за певний час доступ до хаба може відновитися.
  • Відсутність можливості встановлення балансувальника запитів і створення кількох Selenium Grid кластерів. Адже вся інформація про Browser Nodes і сесії зберігається в пам’яті конкретної Node й не поширюється між ними.

Як налаштувати Selenium Grid у Minikube-кластері

Щоб почати використання Selenium Grid у Minikube-кластері, треба встановити Minikube й VirtualBox, завантажити деплойменти і YAML-файли, а далі за кроками:

0. Перед стартом Minikube-кластера необхідно збільшити ресурси VirtualBox.

Це важливо, адже Minikube запускається із використанням конфігурації за замовчуванням: Creating VirtualBox VM (CPUs = 2, Memory = 2048 MB, Disk = 20 000 MB). Якщо ресурси не збільшити, виникнуть проблеми з масштабуванням браузерів і запуском тестів на них у потрібній кількості. Тести не запустяться на жодному з вузлів, адже виділеної пам’яті бракує для запуску всіх масштабованих вузлів.

Конфігурація віртуальної машини, на якій я запускаю Minikube-кластер

1. Minikube start.

2. Необхідно створити деплойменти сервісів. У цьому разі ми створимо деплойменти hub, proxy-service, firefox-node й chrome-node браузерів, виконуючи такі команди:

kubectl create --filename=<path>/selenium-hub-deployment.yaml
kubectl create --filename=<path>/selenium-hub-svc.yaml
kubectl create --filename=<path>/selenium-node-chrome-deployment.yaml
kubectl create --filename=<path>/selenium/selenium-node-firefox-deployment.yaml

3. Після того як ми створимо деплойменти, нам потрібно надати доступ до hub через наш розгорнутий proxy-service, виконуючи команду:

kubectl expose deployment selenium-hub --type=NodePort

4. Далі, залежно від тих ресурсів, що було виділено для Minikube-кластера, ми масштабуємо браузери в кластері (у цьому разі це по 5 реплік):

kubectl scale deployment selenium-node-chrome --replicas=5
kubectl scale deployment selenium-node-firefox --replicas=5

5. Наступною командою отримуємо UrlHub для надсилання інформації про тест з клієнта

minikube service selenium-hub --url

6. Виконавши команду Minikube Dashboard, автоматично відкриється Kubernetes Dashboard, на якому можна подивитися статус усіх pods і кількість розгорнутих деплойментів.

7. Minikube dashboard:

8. Готово до використання.

Після того як ми налаштували Selenium Grid у Minikube, зробили відповідні масштабування браузерів і написали код, можемо запускати тести. У цілому, це залежить від того, де ви запускатимете код: це може бути як локально, так і через Jenkins.

Наприклад, цей підхід я запускав за допомогою Jenkins, бо він має інтеграцію з Maven, а проєкт з тестами написано на Java з використанням Maven. Відповідно, усе, що мені потрібно було зробити, — встановити Maven Integration-плагін у Jenkins і налаштувати Jenkins Job для запуску тестів з GitHub.

Підхід з використанням платформи Node.js для цієї платформи я не застосовував. Проте думаю, що проблем з його налаштуванням не виникне.

І наостанок посилання, яке раджу вам переглянути перед запуском цього підходу:

  • Kubernetes.io — офіційний ресурс для кращого розуміння концепцій і детальнішого ознайомлення із сервісами.
  • Рецепти Selenium Grid (з YAML-файлами й докладним описом Readme.md).
LinkedIn

21 комментарий

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Гарна стаття, все зрозуміло, але не бачу конфігурації під safari browser. Як автоматизуєте тести для iOS/Mac OS Safari?

Привіт. Такої вимоги в мене не було підтримувати safari browser. Але можу сказати те що це і неможливо так як відсутня інсталяція safari для Docker

Дякую за статтю! Цікаво) хоч на колишньому проекті, коли виникла необіхдність, я використовував Selenoid.

Привіт, будь ласка) радий що було цікаво

Можна ще потицяти Zalenium — такий собі недо-селеноїд, який також можна розгорнути через кубік.

Привіт, так чув також за Zalenium, але не доводилось використовувати поки що. Дякую

Зачем эти все свистопляски если есть Selenoid? Он с огромным перевесом перекрывает все плюсы и минусы Selenium Grid.

Привіт, дав відповідь нижче

Selenoid не является полным аналогом Selenium Grid — для этого есть платный Moon от аерокуба.
github.com/aerokube/moon

Локально 10-20 браузеров под виртуалкой, на разных ОС, запустить — не представляется возможным.

С мобильными устройствами ещё сложнее — там встречаются вендорбаги и нужно тестировать прямо на физических устройствах.

«Selenoid не является полным аналогом Selenium Grid — для этого есть платный Moon от аерокуба» — шо ????

речення своє почитайте — не вяжеться взагалі)

tldr; Selenium Grid на кубі запустить можна, а Selenoid — ні.

чому не розглядали варіант з Selenoid ? в нього немає ряду недоліків і проблем, які є в Selenium Grid

Привіт, варіант з Selenoid не розглядав по тій причині, що він не підтримує жодну з систем оркестрації. Тож було обрано таке рішення використовувати Selenium Grid в Minikube для локального запуску тестів, з можливістю швидкої міграції в Kubernetes cluster в будь якому з клауд провайдерів.

К тому же масштабирование будет сильно ограничено хабом, который обычно начинает загибаться после 10-20 нод

А какая выгода здесь от kubernetes? Ферма ведь получилась статичной. Я бы рекомендовал если хочется уменьшить расходы на кластер — посмотреть на Aerokube Moon. Он уже заточен под автоскейлинг, и намного стабильней чем обычный селениум грид

Привіт. погоджуюсь з тобою з приводу Aerokube moon, але першочергово мені треба було вирішити задачу як розгорнути локально кластер без будь яких витрат, + в майбутньому мати можливість міграції в систему оркестрації, тому було обране таке рішення.

ну витрати зажди є) Ти просто в це інвестував свій час, мабуть десь за 2 тижні розібрався та все полетіло, рахуємо що твії 2 тижні роботи коштували 2к$. А плюс інфраструктура, міні куб не легка штука
Тому тут потрібно грати в довгу, щоб випрадало часові витрати
Дякую за статтю та за труди, але я краще піду в мун, ібо після мене людям троха легше буде то підтримувати, мабуть)

Привіт. Дякую і тобі за твій відгук.

Зарепостив на мою сторінку QA Club Lviv)

Подписаться на комментарии