Selenium часто вже керує важливими наскрізними та міжбраузерними сценаріями. Знімок у правильній точці додає візуальний доказ, не замінюючи функціональних перевірок. Складність не в самому виклику screenshot. Треба відтворити однаковий стан на локальній машині, вузлах браузерної ферми й у CI, а потім дати рецензенту достатньо доказів для рішення.
У цьому посібнику прикладом буде підсумок замовлення. Розберемо явні очікування, можливості браузера, назви еталонів, межі порівняння та артефакти. Також проведемо практичну межу між знімками всередині набору Selenium і бойовими сторінками, які простіше регулярно переглядати в RenderLog.
Додавайте візуальну перевірку лише до відомого функціонального стану
Доведіть кошик до іменованого стану, а тоді перевірте деталі, які надають йому сенсу: товар, кількість, суму та активну кнопку покупки. Знімок має зафіксувати стан, який функціональний тест уже розпізнав. Якщо перехід не вдався або підсумок не з'явився, повідомте цю причину прямо. Порівняння напівзавантаженої сторінки дає великий diff, але приховує кориснішу помилку.
Обирайте область знімка за ризиком. Для стабільного підсумку часто краще знімати один елемент, виключивши навігацію й чат. Знімок вікна потрібен, коли важливе взаємне розташування форми, підсумку та кнопки. Повносторінкове склеювання може створювати власні розбіжності, тому застосовуйте його, лише якщо розміщення нижче першого екрана справді перевіряється.
- Перевіряйте бізнес-стан до знімка.
- Знімайте елемент, коли інші ділянки лише додають шум.
- Знімайте вікно, коли важлива композиція сторінки.
- Відокремлюйте помилки переходу й готовності від візуальної різниці.
Замініть фіксовані паузи явними очікуваннями
Документація Selenium називає перегони в часі одним із головних джерел нестабільності. Чекайте, доки підсумок стане видимим, індикатор завантаження зникне, а потрібний текст чи стан кнопки з'явиться. Двосекундна пауза зайва для швидкого запуску й водночас замала для завантаженого вузла. Явне очікування завершується помилкою з умовою, яку легко зрозуміти.
Не поєднуйте великі неявні очікування з явними. Їхня спільна поведінка дає непередбачувану тривалість і ускладнює пошук причини. Тримайте умову готовності поруч з об'єктом сторінки або сценарієм, який розуміє цей стан. Допоміжна функція знімка має отримувати вже готовий елемент чи драйвер, а не самостійно спати, прокручувати й здогадуватися.
- Чекайте видимості, тексту, стану кнопки або зникнення завантаження.
- Розміщуйте умову біля поведінки сторінки, яку вона описує.
- Не змішуйте неявні та явні очікування.
- Зупиняйте запуск до порівняння, якщо сторінка не готова.
Зафіксуйте можливості браузера й умови відтворення
Записуйте назву й версію браузера, розмір вікна, масштаб пристрою, якщо доступний, образ операційної системи, мову, часовий пояс, тему та встановлені шрифти. Віддалена ферма може направити два запуски на вузли з різними шрифтами чи дисплеями. Це різні середовища відтворення, навіть коли назва тесту однакова, тому їм не слід ділити один безіменний еталон.
Будуйте шлях еталона зі стану та середовища, а не з випадкового номера. Наприклад, додайте назву підсумку, Chrome, розмір вікна й мову. Фіксуйте тестові дані, коли вони не є предметом перегляду, вимикайте анімацію через налаштування продукту чи браузера. Для міжбраузерного покриття схвалюйте окремий еталон кожного браузера, а не змушуйте Firefox збігатися з Chrome.
- Версіонуйте еталони за браузером і важливим розміром вікна.
- Використовуйте однакові шрифти та образи системи.
- Явно задавайте мову, часовий пояс і тему.
- Не використовуйте один еталон для браузерів, які відтворюють сторінку по-різному.
Розділіть отримання знімка, порівняння та схвалення
WebDriver повертає байти зображення. Бібліотека може порівняти їх зі збереженим файлом, а зовнішній сервіс додати керування еталонами та перегляд. Залишайте ці шари видимими в реалізації. Невелика функція отримання знімка не повинна сама вирішувати, що змінений стан продукту прийнятний. Це рішення належить рецензенту, запиту на зміни або окремому правилу схвалення.
Обирайте спосіб порівняння під дефект, який треба помітити. Піксельний метод чутливий і прозорий, але показує шум відтворення. Перцептивний може терпимо ставитися до дрібних відмінностей, але теж потребує перевірених прикладів і записаних меж. Незалежно від методу зберігайте вихідні зображення й diff. Самої оцінки без зорового доказу недостатньо для рішення про випуск.
- Нехай Selenium створює керований стан і робить знімок.
- Нехай окремий шар створює вимірюваний результат порівняння.
- Нехай новий еталон схвалює визначена людина або правило.
- Зберігайте вихідні зображення навіть за наявності числової оцінки.
Підготуйте артефакти для розподіленої браузерної ферми
Невдала робота на фермі має зберегти еталон, поточний знімок, diff, можливості браузера, адресу сторінки, журнал тесту й доречні дані консолі або мережі. Шляхи мають бути безпечними для паралельного виконання, адже кілька браузерів можуть знімати той самий стан. Результат повинен пережити закриття віддаленого сеансу. Файл лише на вузлі фактично втрачений.
Відділяйте несправність інфраструктури від завершеного порівняння. Розірване з'єднання, застарілий елемент чи завершення очікування не є візуальною регресією. Завершений знімок зі зміненим підсумком є. Рахуйте ці категорії окремо, щоб розуміти, чи потрібна робота над надійністю, чи перевірка продукту. Сліпі повтори можуть стерти несталу помилку й створити хибне відчуття здорового набору.
- Завантажуйте докази до закриття віддаленого сеансу.
- Додавайте можливості браузера й назву стану до метаданих.
- Використовуйте унікальні шляхи для паралельних робіт.
- Не перетворюйте помилки ферми або готовності на оновлення еталона.
Використовуйте RenderLog, коли головним об'єктом є сторінка
Selenium залишається правильним власником приватного кошика, якому потрібні вхід до системи, підготовлені дані й функціональні перевірки. Публічна партнерська сторінка, тарифи чи документація можуть потребувати лише повторних знімків, історії та рецензента поза тестовою командою. У RenderLog можна зберегти адресу, запускати перевірку за розкладом або API й бачити еталон, результат та diff разом.
Розділяйте роботу за результатом, а не за уподобанням інструмента. Залишайте сценарії, що блокують випуск, у Selenium. Стеження за бойовою сторінкою перенесіть у спільну систему, коли воно має тривати незалежно від змін репозиторію. Після розгортання можна викликати збережений запуск RenderLog, не відмовляючись від покриття до випуску. Кожна перевірка повинна мати власника й визначену реакцію.
- Залишайте приватні сценарії з даними в Selenium.
- Регулярно перевіряйте публічні сторінки, що змінюються поза випусками.
- За потреби запускайте збережену перевірку RenderLog після розгортання.
- Не дублюйте перевірки з тим самим власником і тією самою дією.
Бібліотека для Selenium, API знімків чи RenderLog?
Вирішальна межа проходить між власником стану та власником перегляду. Selenium сильний, коли знімок є частиною браузерного сценарію, а спільний сервіс, коли сама сторінка потребує постійного нагляду.
| Рішення | Порівняння в Selenium | API знімків | RenderLog |
|---|---|---|---|
| Найкраще застосування | Наявний браузерний сценарій або ферма | Програмне отримання без перегляду | Збережені перевірки бойових сторінок та історія |
| Керування станом | WebDriver, фікстури й об'єкти сторінок | Параметри запиту та логіка клієнта | Сценарії, розклад і запуски через API |
| Порівняння | Бібліотека або зовнішній візуальний сервіс | Реалізує сам клієнт | Еталон, поточний знімок і diff в одному результаті |
| Типовий власник | Автоматизація якості й розробка | Команда застосунку-клієнта | Якість, продукт, операції, агенція або клієнт |
Мінімальний процес візуальних доказів у Selenium
Приклади окремо показують очікування готовності, отримання знімка, порівняння та необов'язкове спільне стеження. Бібліотеку зображень і сховище оберіть відповідно до мови та середовища CI.
tests/pricing-visual.mjs
import { writeFile } from "node:fs/promises";
import { Builder, By, until } from "selenium-webdriver";
const driver = await new Builder().forBrowser("chrome").build();
try {
await driver.manage().window().setRect({ width: 1366, height: 900 });
await driver.get("https://example.com/pricing");
const heading = await driver.findElement(By.css("h1"));
await driver.wait(until.elementTextIs(heading, "Pricing"), 10_000);
const image = await driver.takeScreenshot();
await writeFile("artifacts/pricing-current.png", image, "base64");
} finally {
await driver.quit();
}Comparison boundary
const result = await comparePngFiles({
baseline: "baselines/pricing-chrome-1366.png",
current: "artifacts/pricing-current.png",
diff: "artifacts/pricing-diff.png"
});
if (result.changedPixelRatio > 0.001) {
throw new Error("Visual difference needs review");
}Saved-page handoff
curl -X POST https://renderlog.com/api/check-suites/suite_01J/runs \
-H "Authorization: Bearer rl_live_xxx" \
-H "Content-Type: application/json" \
-d '{"format":"png","labels":{"source":"selenium","commit":"8f4a7f2"}}'Першоджерела для цього посібника
Актуальну поведінку WebDriver та параметри браузера перевіряйте в документації Selenium. Тут головна увага на відтворюваному стані, зрозумілих доказах і відповідальності за перегляд.
Продовжте з відповідним процесом
Посібник із візуального регресійного тестування
Оберіть відтворювані стани, доречні пороги й власника еталонів.
Візуальне тестування в Cypress
Порівняйте ті самі рішення в процесі на основі Cypress.
Візуальне тестування в Playwright
Застосуйте вбудовані перевірки знімків і надійні докази з CI.
API знімків вебсторінок
Створюйте разові або збережені запуски та отримуйте артефакти.
Порівняння засобів візуального тестування
Зіставте рішення для репозиторію, компонентів і спільного перегляду.
Призначте власника для однієї бойової сторінки
Залиште браузерні сценарії в Selenium, а одну публічну сторінку збережіть у RenderLog, коли іншому рецензенту потрібні регулярні знімки, видима різниця та зрозуміла історія еталонів.
Створити робочий простір RenderLog