Selenium

Дванадцять маршрутів магазину в Selenium на одному екрані — і хто що забезпечує

Selenium робить менше, ніж два інші інструменти на цьому сайті, і робить так свідомо. Він керує браузером — і на цьому все. Тож корисне питання — хто робить решту. Нижче — дванадцять маршрутів зі сторінки «Наскрізне тестування», той самий інтернет-магазин, — так, як магазин написав би їх на Selenium. Четверта колонка каже як. Пʼята каже, хто це забезпечує: WebDriver — стандарт, який реалізує кожен вендор браузера; WebDriver BiDi — його новіший двосторонній канал; мова, якою написано тести; або тестове середовище.

Таблиця відповідає, чи може Selenium пройти маршрути магазину. Може, усі дванадцять. Друга половина цього екрана відповідає на питання, на яке може відповісти лише Selenium: чи працюють маршрути в браузерах, які клієнти справді встановили? Playwright запускає власні збірки — його WebKitWebKitрушій браузера SafariРушій браузера з відкритим кодом, на якому працює Safari. Сторінка, що працює в Chrome, може зламатися у WebKit, тому набори тестів проганяють браузерні маршрути й у ньому — Playwright для цього має власну збірку WebKit.Усі терміни не є Safari, — тому сторінка про Playwright лишає маршрут 2 у випущеному Safari людині з iPhone перед кожним релізом. Запуск нижче закриває цю прогалину. Це чотири маршрути в пʼяти браузерах на одному grid щоночі, записані як рішення магазину й пронумеровані, щоб наступні розділи могли посилатися на «рядок 2.3».

1. 1.Що запускається

   1. 1.1Маршрути 1, 2, 5 і 11 — ті чотири, результат яких залежить від того, як сам браузер поводиться з cookiecookieдані, які браузер надсилає назадНевеликий фрагмент даних, який сайт просить браузер зберегти й надсилати назад із кожним запитом до цього сайту, — так сервер пам’ятає, що ви увійшли. Оскільки браузер додає його автоматично, навіть до запиту, який спровокував інший сайт, cookie сесії потребує правильних прапорців і перевірки проти підробки запитів на сервері.Усі терміни, фреймами й іншими доменами. Решта вісім ідуть лише в Playwright.
   2. 1.2Щоночі й перед кожним релізом, після того як набір Playwright для мерджу зелений. Червона ніч ніколи не блокує мердж — вона відкриває тікет.
   3. 1.3У брендових Chrome, Edge і Firefox, які встановлюють клієнти, у Safari на macOS — і маршрут 2 ще й на iPhone.

2. 2.Де він працює

   1. 2.1Один grid усередині мережі магазину. Маршрутизатор має імʼя користувача й пароль, і жоден його порт не досяжний з інтернету.
   2. 2.2Два Linux-вузли з Docker-образів проєкту, з Chrome, Edge і Firefox, по чотири сесії на кожному.
   3. 2.3Mac mini з одним слотом Safari, бо Safari дозволяє одну сесію водночас, і iPhone, підʼєднаний до нього, — довірений, розблокований, з увімкненою Remote Automation. iPhone ділить цей самий слот.

3. 3.Як створюють сесію і як у ній чекають

   1. 3.1Нова сесія для кожного маршруту. Жодну сесію ніколи не ділять двоє.
   2. 3.2Жодного неявного очікування. Кожне очікування явне: 10 секунд, опитування кожні 250 мс і повідомлення, що називає умову.
   3. 3.3Елементи шукають спершу за data-testid, потім за коротким CSS-селектором. Жодного XPathXPathзапит до елементів за шляхомМова запитів, що вибирає частини XML- чи HTML-документа за шляхом крізь нього: цей елемент, усередині того, третій такого типу. У браузерному тесті довгий XPath записує, де елемент стоїть, а не чим він є, тож ламається, щойно змінюється розмітка.Усі терміни, скопійованого з інструментів браузера.

4. 4.Версії — і коли один падає

   1. 4.1Selenium закріплено на точній версії й оновлюють окремою зміною. Драйвери підбирає Selenium Manager; Linux-вузли закріплюють browserVersion і пересувають його свідомо.
   2. 4.2Падіння зберігає скриншот і код сторінки, а в Chrome, Edge і Firefox — ще й журнал консолі через BiDi. Safari дає перші два й власний журнал драйвера.
   3. 4.3Червоний маршрут читають поруч із результатом Playwright для того самого маршруту. Зелений там і червоний тут означає браузер, а не магазин, і тікет називає версію браузера.

Протокол із трьома власниками — і один похід туди й назад на кожну команду

Розуміння Selenium починається з того, що це не одна програма. Ваш тест кличе привʼязку — клієнтську бібліотеку вашою мовою. Привʼязка надсилає кожну команду звичайним HTTP-запитом із JSONJSONJavaScript Object Notation — текстовий формат данихТекстовий формат для передавання даних: пари «ключ — значення», списки, числа й рядки. Він народився в JavaScript, але сьогодні його читає будь-яка мова — і саме тому ним відповідає більшість API, а не чимось потужнішим.Усі терміни: щоб знайти кнопку оплати — POST на /session/{id}/element з {"using": "css selector", "value": "[data-testid=pay]"}. Драйвер — програма, яку написав вендор браузера, — отримує його, змушує браузер це зробити й відповідає. Кожна команда — похід туди й назад, і нічого не повертається, якщо тест про це не спитав.

Середина цього ланцюжка — стандарт W3C: WebDriver став Рекомендацією 5 червня 2018 року, а його наступний рівень — робочий проєкт, востаннє оновлений 2 липня 2026 року. Тож ланцюжок має трьох власників. Тест належить вам. Привʼязки, grid і Selenium Manager — інструмент, що завантажує драйвери, — належать проєкту Selenium. Драйвери й браузери належать вендорам браузерів. Оскільки формат на дроті публічний, будь-який кінець можна замінити, і власна сторінка Apple каже саме це: тести можна писати на Python, Java, PHP, JavaScript і будь-якій іншій мові, бібліотека якої сумісна з протоколом W3C WebDriver.

Те, що драйвер належить вендорові, — найважливіший факт. Playwright керує Firefox і WebKit через збірки, які пропатчив сам; драйвер WebDriver керує браузером таким, яким його випускає вендор. Таблиця показує, що це означає для кожного браузера.

Очікування пишете ви: що WebDriver перевіряє один раз і чого не перевіряє ніколи

Люди, що прийшли з Playwright, очікують, що клік зачекає, доки клікати матиме сенс. Клік WebDriver цього не робить. Element Click у стандарті прокручує елемент у видиму область і перевіряє дві речі, один раз. Якщо елемент досі поза видимою областю, відповідь — element not interactable. Якщо щось інше його закриває, відповідь — element click intercepted. В обох випадках помилка повертається одразу; ніщо не повторюється. Навігація чекає лише, доки readyState документа стане «complete», а на застосунок, що рендериться після цього, — тобто майже будь-який сучасний магазин, — не чекає взагалі.

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

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

Друга звичка, що вирішує, чи добре старітиме набір, — як шукають елементи. By у Selenium — локатор у повному сенсі: рецепт, який розвʼязують щоразу, коли ним користуються. А те, що повертає findElement, — ні. Це посилання на один вузол, і коли сторінка перерендерюється, цього вузла вже немає, — застаріла сума маршруту 4. Тож page objectpage objectклас на кожен екран у наборі тестівПатерн проєктування браузерних тестів: кожна сторінка чи компонент отримує клас, що знає, як знайти її елементи й виконати її дії, тож тести читаються як кроки, а редизайн виправляють в одному місці. Сам клас нічого не має перевіряти — перевірка результату лишається в тесті.Усі терміни тримає значення By і шукає на вимогу. Щодо того, який рецепт обрати, документація радить id там, де id унікальні й стабільні, потім добре написаний CSS-селектор, і попереджає, що XPath-селектори зазвичай не тестують на швидкодію вендори браузерів і вони бувають досить повільні. Магазин додає атрибут для тестів (рядок 3.3): шукайте елемент за тим, для чого він, а не за тим, де він стоїть.

Сесія — це браузер: ізоляція, паралельні запуски й доріжка, яку задає один Mac

У Selenium немає одиниці ізоляції, меншої за сесію, а сесія — це процес браузера зі свіжим профілем. Магазин відкриває нову для кожного маршруту (рядок 3.1). Тому маршрут 11 нічого не коштує: нова сесія не бачить того, що лишив маршрут 10. Кожен маршрут платить запуском браузера — близько двох секунд у Chrome на вузлах магазину, чотирьох у Safari, двадцяти на iPhone.

Тож друга особа — це другий браузер. Маршрут 12 відкриває його для агента, і збереженого стану сховища, з яким такий браузер можна запустити, немає. Зате є cookie. Агент входить через APIAPIApplication Programming Interface — контракт між програмамиПравила, за якими одна програма звертається до іншої: які запити можна надіслати, у якому вигляді й що прийде у відповідь. Для того, хто звертається, це контракт — усе, що за ним, лишається чорною скринькою, і саме тому другий бік можна переписати, не зламавши вас.Докладніше в статті →Усі терміни, тест відкриває невелику сторінку на домені бек-офісу й додає cookie сесії — і відтоді агент у системі. Порядок важить: cookie для домену, на якому браузер не перебуває, WebDriver не прийме. З BiDi storage.setCookie ставить cookie без цього обходу — у Chrome, Edge і Firefox.

Паралельний запуск тестів — теж не робота Selenium. Це робить раннер тестів — JUnit, TestNG, pytest із плагіном для паралельності, NUnit, — і кожен тест відкриває власну сесію на grid. Скільки їх іде водночас, вирішує grid через слоти: один на процесорне ядро для браузерів родини Chrome і Firefox на вузлі, а для Safari, каже документація, створюється лише один слот. Це одне речення і є формою ночі магазину.

WebDriver BiDi: канал, якого протоколу завжди бракувало, — і браузер, що ним не говорить

Класичний WebDriver — це запит і відповідь, тож браузер ніколи не може заговорити першим. Він не може сказати, що запит упав, що скрипт кинув помилку чи що консоль щось надрукувала. Роками обхідним шляхом був Chrome DevTools ProtocolChrome DevTools Protocolяк інструменти керують ChromeПротокол, яким інструменти розробника Chrome оглядають браузер і керують ним; до нього може підʼєднатися будь-яка програма. Інструменти тестування, як-от Playwright і Puppeteer, керують через нього Chromium, тож бачать стан браузера напряму, а не крізь сторінку.Усі терміни, яким добре говорять лише браузери родини Chrome. WebDriver BiDi — стандартна відповідь. Він додає до сесії WebSocketWebSocketпостійний двосторонній звʼязокЗʼєднання, що лишається відкритим в обидва боки: на відміну від HTTP, сервер може надіслати повідомлення сам, не чекаючи запиту. На ньому тримаються чати й живі стрічки — і більшість того, що виглядає як сторінка, що оновлюється сама.Усі терміни, яким браузер надсилає події тоді, коли вони стаються, і додає команди, яких класичний протокол не мав. Документація Selenium описує його як протокол, створений проєктом Selenium разом із вендорами браузерів, і як кросбраузерну заміну Chrome DevTools Protocol. Це робочий проєкт W3C, востаннє оновлений 8 жовтня 2026 року, а тест вмикає його можливістю webSocketUrl.

Усі пʼять працюють у Chrome і Edge з версії 126 — emulation з 137 — і у Firefox. Саме це план мусить врахувати, бо на цьому перелік закінчується. За даними сумісності MDN на 15 жовтня 2026 року Safari не підтримує жодної частини WebDriver BiDi — запити на попередньо завантажені скрипти й команди для cookie відкриті у трекері WebKit. Браузер, через який передусім і варто тримати цей grid, — єдиний браузер на ньому, де нових можливостей немає. Усе на доріжці Safari користується класичним WebDriver: скриншоти, код сторінки й власний журнал драйвера.

В інших браузерах перехід уже стався. Mozilla оголосила застарілою свою підтримку протоколу DevTools з Firefox 129, у травні 2024 року закликавши переходити на BiDi, а Selenium прибрав підтримку DevTools для Firefox у версії 4.29 у лютому 2025 року.

Grid: той самий протокол із маршрутизатором попереду — і двері, відчинені за замовчуванням

Selenium Grid ставить маршрутизатор перед тим самим протоколом. У тесті змінюється одне — адреса, до якої він підʼєднується, а grid вирішує, яка машина запустить сесію. Він має шість частин, і з Grid 4 кожна може працювати окремим процесом.

Усі шість можуть працювати одним процесом (standalone), як хаб із вузлами або повністю розподілено, і проєкт публікує Docker-образи для кожного варіанта. Чого жоден із цих режимів не змінює — першого речення історії про безпеку.

Це речення належить самому Selenium: Selenium Grid за замовчуванням не має жодної автентифікації, бо завжди передбачалося, що ви поставите його за захищеною мережею. 25 липня 2024 року Wiz Research опублікувала, що буває, коли цього не зробили. Кампанія, яку там назвали SeleniumGreed, відкривала сесії на grid, відкритих в інтернет, і в параметрах Chrome цієї сесії задавала як бінарний файл браузера Python, а як його аргументи — скрипт. Вузол запускав Python замість Chrome, скрипт відкривав зворотну оболонку, і машина майнила криптовалюту. Wiz нарахувала понад 30 000 відкритих grid — половину на старій 3.141.59, половину новіших, переважно на типовому порту 4444 — і підтвердила, що прийом працює й на версії 4. Нічого не зламали у звичному сенсі. Grid запускає ту програму, яку просить його клієнт, — це його робота.

Пʼять змін під робочими наборами

Набір Selenium залежить від трьох сторін водночас: проєкту, драйверів і браузерів. Кожну з цих змін заздалегідь оголосили ті, хто її зробив, і кожна відділила набори, що доручили драйвери проєкту й закріплювали версії свідомо, від тих, що завантажували бінарні файли вручну.

Де він не допомагає і як порівнюється

Selenium відповідає на вужче питання, ніж колись. Для нового набору, який ніщо не штовхає в інший бік, Playwright дає більше за менші зусилля, і його сторінка це каже. Сказати це тут — і є те, що надає змісту випадкам, де Selenium виграє.

• Він дає вам браузер — і нічого більше. Раннер, звіт, повтори, запис запуску, що впав, — команда обирає й підʼєднує кожне сама.
• Очікування — це код, який пишете ви, і в успадкованому наборі його зазвичай написано неправильно.
• Safari під автоматизацією починає з чистого аркуша, як приватне вікно, за скляною панеллю. Це близько до першого візиту, а не до клієнта з річною історією, а на iPhone екранна клавіатура не показується взагалі.
• Нові можливості закінчуються там, де починається найсильніший аргумент цієї сторінки: Safari не говорить BiDi.
• Він не тестує нативні застосунки — це робить Appium тим самим протоколом — і не є інструментом навантажувального тестування.

Антипатерни, які варто назвати

• Глобальне неявне очікування разом із явними — документація сама попереджає, що це дає непередбачуваний час очікування.
• Абсолютний XPath, скопійований з інструментів браузера: ламається на наступному редизайні й нічого при цьому не пояснює.
• Перевірки всередині page object. Документація: самі page object ніколи не мають робити перевірок чи тверджень.
• Одна сесія на кілька тестів заради часу запуску: повертається рівно та залежність від порядку, яку сесія мала прибрати.
• Grid на публічному порту. Див. SeleniumGreed.
• Код, який написав агент для програмування на основі десятиліття старих дописів. Власний блог Selenium 29 вересня 2026 року перелічує, що такий агент видає: обʼєкт DesiredCapabilities, якого не існує вже багато років, абсолютний XPath, скопійований з DevTools, і sleep(5), — і додає, що описуватиме він Selenium 3.

Коли це застосовувати

Пов’язані сторінки

• QAPlaywrightPlaywright — відкрита бібліотека автоматизації браузера й раннер тестів від Microsoft, що керує Chromium, Firefox і WebKit ззовні браузера. Сторінка починається з дванадцяти маршрутів зі сторінки «Наскрізне тестування», написаних на Playwright, — механізму, на який спирається кожен, і конфігурації, що проганяє їх приблизно за чотири хвилини, — далі одне зʼєднання, з якого випливає все, браузери, які він насправді запускає, автоочікування, контексти й воркери, чого тест може дістати, крім сторінки, траси й повтори, чотири зміни під робочими наборами і де він не допомагає.
• QACypressCypress — відкритий раннер тестів для вебзастосунків, що виконує тест усередині браузера, у тій самій вкладці й event loop, що й застосунок. Сторінка починається з дванадцяти маршрутів зі сторінки «Наскрізне тестування» так, як магазин написав би їх на Cypress, — сім нативних, пʼять з обхідним шляхом і те одне, що спільне для всіх пʼяти, — далі вкладка й чотири компроміси, які Cypress називає постійними, черга команд, повторність у тому вигляді, в якому вона працює з Cypress 12, ізоляція й бік Node, паралельність за файлами специфікацій, чотири зміни під робочими наборами і де він не допомагає.
• QAНаскрізне тестування (E2E)Наскрізне тестування проводить бізнес-процес через зібрану систему від початку до кінця, як це зробив би клієнт, в умовах, близьких до продакшну. Сторінка починається з повного набору одного магазину — дванадцять маршрутів, шов, який доводить лише кожен із них, і що в ньому справжнє, а що підмінене, — далі що не доведе жоден нижчий рівень, яких форм набуває набір тестів, чого коштує червоний маршрут, як обирати маршрути й тримати їх надійними, і три збої, де тест зупинився за крок до кінця.