Автоматизація браузера пройшла три покоління. Кожне усувало вузьке місце попереднього та водночас переносило наступне обмеження в іншу частину системи. Розуміти невирішені проблеми корисніше, ніж запам’ятовувати назви інструментів.
Автоматизація браузера існує вже понад двадцять років і за цей час пройшла три основні етапи. Цікаво, що кожне покоління розв’язує інший клас проблем, а після цього вузьке місце знову переміщується в іншу частину системи.
Перше покоління: на рівні операційної системи вдавати, що мишею керує людина
Найперші методи автоматизації фактично працювали не всередині браузера, а на рівні операційної системи. Скрипт рухав мишею та натискав клавіші, а браузер лише пасивно приймав ці дії.
Перевагою була універсальність: скрипт міг взаємодіяти з усім, що було видно на екрані — вебсторінкою, клієнтською програмою або старим настільним ПЗ, — і браузеру не потрібно було надавати жодного інтерфейсу. Ціна була не менш очевидною. Скрипт орієнтувався на координати екрана, тож зміна роздільної здатності, системного масштабування або положення вікна могла призвести до кліку не в те місце. Він також не знав, чи сторінка вже повністю завантажилася, тому доводилося покладатися на фіксовані затримки. Ще складнішою була паралельність: одна машина має одну мишу й клавіатуру, отже для десяти середовищ були потрібні десять машин.
Проблема, яку залишило це покоління, була простою: воно не бачило сторінку.
Друге покоління: обійти екран і спілкуватися з браузером безпосередньо
Поява WebDriver перевела автоматизацію з рівня пікселів на рівень елементів: замість позиції 800-го пікселя на екрані шукався конкретний елемент сторінки. Один і той самий код міг керувати різними браузерами та бути написаний різними мовами, що також стало однією з причин перетворення WebDriver на стандарт у тестуванні.
Пізніше рішення на основі протоколів налагодження браузера значно розвинули цей напрям. Puppeteer і Playwright безпосередньо взаємодіють із рушієм браузера та можуть отримувати внутрішній стан сторінки: автоматично чекати готовності елементів, перехоплювати й змінювати запити, підключатися до вже відкритого екземпляра браузера, працювати без графічного інтерфейсу та запускати кілька контекстів паралельно. Більшість можливостей, які сьогодні здаються звичними, сформувалися саме на цьому етапі.
Це розв’язало питання керування та стабільності, але залишило дві інші проблеми. По-перше, скрипти й далі жорстко задавали люди. Якщо структура сторінки змінювалася або селектор переставав працювати, потрібно було редагувати код, а вартість супроводу зростала разом із масштабом проєкту. По-друге, залишалася фундаментальніша проблема: підхід визначає, як виконувати дії, але не те, як виглядає їхній виконавець. Пряме керування через протокол робить дії точнішими, однак зміна способу зв’язку сама по собі не прибирає сліди автоматизації. Навіть дуже стабільний скрипт може все одно виглядати як скрипт.
Третє покоління: людям більше не потрібно описувати кожен крок, і проблема знову переміщується
У третьому поколінні змінюється не спосіб керування, а спосіб прийняття рішень. У перших двох люди мали явно описувати кожен крок: яку кнопку натиснути, яке поле заповнити та в якій послідовності. У поколінні, керованому моделями, задається мета, модель сама планує шлях і може знайти нову точку входу після зміни дизайну сторінки.
Через це старі дрібні труднощі — як написати селектор або скільки чекати — поступово стають менш критичними. Проте одразу з’являються нові проблеми.
Ключовий момент у тому, що сама модель не звертається до вебсторінки. Сторінку все ще відкриває браузер, він же завантажує ресурси та підтримує стан входу. Тому, коли завдання починає працювати нестабільно, причина часто не в неправильному рішенні моделі, а в середовищі виконання під нею: кілька завдань використовують один браузер і забруднюють одне одному cookies та кеш; характеристики fingerprint дуже схожі, тому платформа бачить ці завдання як такі, що надходять з однієї машини; облікові записи використовуються між завданнями, і одна аномалія може зачепити багато інших; середовища потрібно тимчасово створювати й звільняти після використання, але єдиного планування немає. Модель розв’язує питання як виконати роботу, а питання де її виконувати стає новим вузьким місцем.
Додатковий шар в архітектурі
Якщо подивитися на всі три покоління разом, різниця не зводиться до того, яке з них прогресивніше. Кожне мусить підхопити те, чого не вирішило попереднє. У перших двох поколіннях середовище майже не було проблемою, бо автоматизація працювала у браузері на власній машині. На етапі Agent завдання стають масовими, паралельними й автономними, тому середовищем потрібно керувати явно: кожне завдання працює в ізольованому середовищі, fingerprint і сесії не змішуються; стан входу зберігається між завданнями, щоб не авторизуватися щоразу; IP, часовий пояс і мова узгоджуються як єдиний набір; середовища створюються та звільняються на вимогу як обчислювальні ресурси.
PurpleMark працює саме на цьому рівні, перетворюючи браузерні середовища на ресурси, якими можна керувати, щоб Agent зосереджувався на логіці завдання.
Так легше й визначити потрібний підхід. Корпоративні тестові стеки та наявні скрипти можуть залишатися на поточному шляху; складні вебзастосунки, яким потрібен контроль на рівні запитів, відповідають поколінню з протокольним керуванням; а для завдань, які планує модель і які мають стабільно працювати тривалий час, технології перших двох поколінь усе ще можна використовувати, але шар середовища потрібно вирішувати окремо. Якщо сценарій вимагає, щоб дії виглядали так, ніби їх виконує реальний користувач, сам framework автоматизації не може цього забезпечити незалежно від покоління.
Поза технічним шляхом існує ще одна межа: автоматизовані дії мають відповідати правилам цільової платформи та місцевому законодавству. Те, що щось технічно працює, не означає автоматично, що це підходить для бізнесу.
