ШІ-візуальне регресійне тестування: порівняння скриншотів із ШІ

Чому візуальне регресійне тестування ламається на релізах

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

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

Далі підключається людський фактор. Ручна звірка екранів на десятках роздільностей і станів розтягується на дні, а результат залежить від того, хто дивиться: втомлений інженер на чотирьохсотому рядку звіту пропускає реальну розбіжність, зате впевнено підтверджує десяток уявних.

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

Ціна цієї втрати проявляється на релізі. Пропущений дефект верстки — кнопка, що виїхала за край екрана, перекритий текст, форма, що роз'їхалася на мобільному — доходить до користувачів і знаходиться за зверненнями до підтримки, вже без контексту останньої зміни.

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

Що дає автоматична перевірка інтерфейсу: ефект і метрики

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

На старті порівняння «по пікселях» шумить на кожній зміні шрифту або анімації — команда витрачає на розбір знімків більше часу, ніж на саму розробку, і звикає ігнорувати червоні збірки.

Порівняння на основі моделей зору (як у Applitools та аналогічних платформах) цей шум прибирає: модель відрізняє реальний зсув блоку від перемальовування згладжування.

Далі робота йде не з порогом «на око», а з налаштуваннями — маски динамічних зон (дати, лічильники, аватари, каруселі), пороги чутливості за регіонами, стабілізація тестових даних.

Що звіряємо до і після впровадження:

• Частка хибних спрацювань: з 40–70% на сирих попіксельних порівняннях до 5–10% після налаштування масок і порогів.
• Час розбору звіту: з півгодини ручного зіставлення до 5–10 хвилин — видно, який блок виїхав, на якому екрані та в якому стані.
• Дефекти оформлення в користувача: одиниці замість десятків, бо перевірка йде на кожній зміні, а не перед випуском.
• Швидкість випуску релізу: узгодження візуальної частини вкладається в години, а не розтягується на дні.
• Покриття станів: не лише основні сторінки, а й модальні вікна, помилки, порожні списки, локалі, довгі тексти.
• Трудовитрати на супровід еталонів: нові екрани додаються без переписування набору перевірок вручну.

Без вимірювання цих чисел «стало краще» залишається думкою — тому метрики знімаємо на одному й тому самому наборі сценаріїв до і після.

Підходи до порівняння знімків: попіксельний, структурний, на моделі ШІ

Будь-яке порівняння знімків екрана починається однаково: еталон і поточний кадр приводяться до одного розміру, вирівнюються за опорними точками, і далі шукаються розбіжності.

Різниця лише в тому, що вважати розбіжністю — конкретний піксель, блок інтерфейсу чи смислову зміну на екрані.

Попіксельне порівняння фіксує будь-яке відхилення кольору і тому дає повну відтворюваність: один і той самий прогін дає один і той самий звіт.

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

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

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

Підходи не взаємовиключні: критичні екрани — оплату, форми, звіти — тримають на попіксельному порівнянні з масками, решту інтерфейсу віддають структурному або ШІ-порівнянню.

Поріг чутливості підбирають за першими прогонами на реальному стенді, а не за значенням за замовчуванням: занадто строгий повертає шум, занадто м'який — пропускає зламану верстку.

Етапи впровадження: від аудиту інтерфейсу до передачі регламентів

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

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

1. Аудит інтерфейсу та інвентаризація екранів. Збираємо карту сторінок, модальних вікон, станів завантаження й помилок, окремо позначаємо динамічні зони — банери, лічильники, аватари, — які не можна порівнювати напряму.
2. Схема перевірок. Фіксуємо, на яких типах пристроїв і в яких браузерах знімаємо еталони та які кроки проходимо перед знімком, щоб екран опинився в потрібному стані.
3. Налаштування чутливості. Підбираємо поріг чутливості порівняння та області маскування: занадто строгий поріг дає шум на кожному релізі, занадто м'який пропускає реальні дефекти.
4. Зняття еталонів і ручне рев'ю. Перший прогін майже завжди показує розбіжності — їх переглядають і підтверджують як нову норму.
5. Вбудовування в конвеєр збірки. Перевірка запускається на кожній зміні та блокує злиття, якщо розбіжність перевищує заданий поріг.
6. Перевірка на реальних змінах. Навмисно ламаємо верстку в тестовій гілці: дивимося, чи впіймає система дефект і чи не підніме хибну тривогу.
7. Передача регламентів. Віддаємо документацію: як додавати нові екрани, як оновлювати еталони і хто має право змінювати поріг.

Що ви отримуєте: конфігурації, еталони, правила й документація

Усе, що з'являється в процесі, залишається у вашому репозиторії поруч із кодом — не в листуванні і не на чиємусь ноутбуці.

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

• Конфігурації порівняння: пороги чутливості для гілок, карти масок для динамічних зон (курсори, анімації, живі годинники), набір правил виключення під кожен тестований екран.
• Набір еталонних знімків у контролі версій: стани інтерфейсу, розміри вікна, теми, мови — еталон прив'язаний до конкретного коміту, а не до локальної машини.
• Правила оновлення еталонів: оновлення допускається лише окремим комітом із зазначенням причини, старий знімок залишається в історії — відкат на попередній еталон займає одну команду.
• Регламент розбору падінь: як відрізнити хибне спрацювання від реальної регресії, хто і в який термін дивиться звіт, у яких випадках правлять поріг, а в яких — верстку.
• Звіти з підсвічуванням відмінностей і посиланням на коміт, гілку та середовище — падіння відтворюється локально однією командою без перезбирання стенда.
• Документація на перевірки інтерфейсу: які сценарії та стани покриті, що усвідомлено не покрито, як додати новий екран і не зламати старі еталони.
• Інструкція для команди: запуск на локальній машині, в конвеєрі збірки та на нічному прогоні, з розшифруванням типових повідомлень про помилку.

Кейс: як скоротили хибні спрацювання та час перевірки

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

На один цикл ішло кілька годин, частина дефектів усе одно доходила до користувачів — увага не безмежна.

Що було до впровадження

Знімки порівнювалися попіксельно, і помилкою вважалося будь-яке розходження. Динамічні блоки — лічильники, курси, час, банери — давали до двох третин хибних спрацювань: з десяти «падінь» сім виявлялися шумом. Звіту перестали довіряти і все одно переглядали його очима, тобто перевірка не економила часу.

Що змінили

Зафіксували еталонні знімки за ключовими сценаріями, а порівняння віддали сервісу візуального аналізу на базі ШІ — Applitools. Налаштували зони ігнорування для динаміки, окремі пороги для ролей і мовних версій, затримку до зупинки анімацій.

Порівняння стало семантичним: підсвічування показувало реально зламаний блок, а не зсунутий на пару точок текст.

Що стало

Хибні спрацювання впали приблизно з 65% до 10%, перевірка інтерфейсу скоротилася з трьох-чотирьох годин до півгодини, покриття зросло з п'яти вибіркових екранів до сорока основних. Дефекти верстки стали знаходити на етапі збірки, а не після релізу.

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

Що робити, якщо інтерфейс уже покритий функціональними перевірками?

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

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

Порівняння зображень ловить те, що не описується правилами: зсув макета після правки стилів, перекриття елементів, зниклий фон, роз'їхалася сітка на вузькому екрані. Різниця між підходами до перевірок — в об'єкті: поведінка проти відрендереного результату.

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

Щоб покриття інтерфейсу перевірками не перетворилося на шум, еталони фіксують для стабільних екранів, динаміку закривають масками, а поріг відмінностей налаштовують під згладжування шрифтів.

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

Сумніви та обмеження регресійних перевірок інтерфейсу

Візуальна регресія впевнено ловить зсуви верстки й обрізані підписи, але впирається в чотири місця: динаміку на сторінці, старіння еталонів, підтримку після передачі та межі самої звірки. Це ті сумніви, які варто закрити до старту робіт.

Еталони доведеться перезатверджувати після кожного релізу?

Тільки коли інтерфейс змінювався усвідомлено. Базові знімки лежать поруч із кодом і прив'язані до гілки: планова правка проходить рев'ю разом зі зміною, а непояснене розходження розбирають окремо. Історія еталонів зберігається, відкат залишається доступним.

Що залишиться команді замовника після передачі?

Конфігурації масок і порогів, набір сценаріїв, регламент оновлення еталонів і запуск перевірок у загальній збірці. Проводимо розбір: де дивитися звіт, як додати екран, як відрізнити шум від регресії. Далі перевірки працюють без нас.

Що автоматична звірка не впіймає?

Змістові: неправильний текст, кривий переклад, недоступну кнопку, помилку в розрахунку. Звірка відповідає на питання «чи змінилося зображення», а не «чи правильне воно». Візуальні перевірки доповнюємо функціональними.

Обговоримо задачу і повернемося з оцінкою та планом робіт

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

Після обговорення задачі повертаємося з такими матеріалами:

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

Опишіть поточний процес перевірок та інтерфейс — повернемося з оцінкою робіт, схемою впровадження та термінами.