Знайти елемент, дочекатися можливості взаємодії, виконати дію та перевірити результат — кожна автоматизована дія складається з цих чотирьох кроків. Розуміння селекторів, динамічного завантаження, iframe і shadow DOM допомагає скриптам довше працювати стабільно.
Вебавтоматизацію часто розуміють як програму, що натискає кнопки замість вас. Але під час реальної реалізації з'ясовується, що одна дія складається з чотирьох кроків, і помилка на будь-якому з них може виглядати так, ніби взагалі нічого не сталося.
Спочатку розділимо два поняття, які легко переплутати. Вебавтоматизація має ширший зміст: це виконання програмою того, що людина зазвичай робила б на вебсторінці, включно з прямим отриманням даних через запити. Автоматизація браузера — конкретніша гілка: програма керує справжнім браузером, відкриває сторінки, виконує JavaScript та імітує кліки й введення. У сценаріях із великою кількістю динамічного контенту або складними взаємодіями зазвичай потрібен саме другий підхід.
Чотири кроки однієї дії
- Знайти елемент: Визначте ціль за допомогою id, name, class, CSS-селектора або XPath. Надавайте перевагу семантичним атрибутам, а до структури чи індексу переходьте лише за потреби.
- Дочекатися можливості взаємодії: Наявність елемента в DOM ще не означає, що його можна натиснути. Чекайте, доки він стане видимим або клікабельним, чи доки повернеться конкретний запит. Чекати треба умову, а не кількість секунд.
- Виконати дію: Клік, введення або прокручування. Власні компоненти часто вимагають відтворити послідовність дій людини: спочатку розкрити, дочекатися рендерингу списку, а потім вибрати за текстом.
- Перевірити результат: Після дії переконайтеся, що результат правильний. Перевірте, чи змінилося посилання, текст сторінки або що повернув API. Без цього кроку збій може бути прийнятий за успіх, а повторні спроби й сповіщення не матимуть надійної основи.
Із чотирьох кроків найбільше часу на налагодження зазвичай забирають другий і четвертий. Не тому, що вони складні, а тому, що часто не створюють помилки й тихо дають неправильний результат.
Стабільність селектора визначає, як довго працюватиме скрипт
Коли сторінка змінюється, жорстко заданий locator може перестати працювати. Пошук за текстом, позицією або індексом найгірше переносить зміни: одна додана кнопка чи змінена підказка можуть зрушити все.
Якщо можливо, використовуйте id, name або data-атрибути. Якщо потрібні структурні locator, тримайте їх в одному місці, щоб під час зміни виправляти один фрагмент, а не десятки рядків. Також не варто очікувати, що написаний скрипт більше не потребуватиме обслуговування: сайти регулярно оновлюються, і значна частина витрат на підтримку виникає саме тут.
Динамічне завантаження: важливіше, чого чекати, а не скільки
Сьогодні мало сторінок, де все готове одразу після завершення початкового завантаження. Дані рендеряться через асинхронні запити, тому елементи з'являються пізніше, ніж очікується.
Фіксоване очікування — поширений, але ненадійний підхід: sleep на 3 секунди може бути замалим на повільній машині й лише марнувати час на швидкій. Правильніше чекати виконання конкретної умови й діяти лише тоді, коли елемент справді став клікабельним.
Якщо елемент не знаходиться, спочатку перевірте iframe і shadow DOM
Коли елемент явно видно на сторінці, але скрипт не може його знайти, проблема часто не в селекторі, а в області пошуку.
iframe — це окремий документ. Потрібно спочатку перейти у відповідний frame, знайти елемент, а після операції вийти назад; інакше наступні пошуки виконуватимуться в неправильному контексті. Вузли всередині shadow DOM не знаходяться безпосередньо CSS-селекторами ззовні. Спочатку потрібно отримати shadow root, а потім шукати всередині нього. Ці дві ситуації часто помилково сприймають як зміну сторінки й даремно витрачають час на налагодження.
Ще дві речі, які легко пропустити
Перша — сесія. Для завдань, що потребують входу, слід продумати, як зберігати й повторно використовувати авторизований стан. Інакше під час кожного запуску доведеться входити знову, а процес може застрягнути на етапі перевірки.
Друга — середовище. Якщо всі завдання використовують одне браузерне середовище, сесії та кеші можуть впливати одне на одного. Завдання, які окремо працюють нормально, під час спільного запуску можуть почати конфліктувати. Коли завдань стає кілька, окремий шар ізоляції середовищ допомагає уникнути багатьох проблем. Інструменти на кшталт PurpleMark надають незалежний fingerprint і незалежний proxy для кожного середовища, а фреймворк автоматизації зосереджується лише на виконанні дій.
Одну межу варто перевірити до початку
Автоматизація може замінити повторювані операції, але не кроки, що потребують участі реальної людини. Якщо цільовий процес містить перевірку обличчя в реальному часі або ручну перевірку, такий процес не можна автоматизувати на 100%.
Тому спочатку перевірте все найпростішим способом: вручну пройдіть весь процес від початку до кінця, запишіть кожен крок і переконайтеся, чи немає етапу, який неможливо пройти. Лише після цього вирішуйте, скільки зусиль розробки варто вкладати. Технічна можливість і те, що дозволяють правила, — також різні питання, тому заздалегідь перегляньте умови використання цільової платформи.
