Визуальный регрессионный тест сравнивает текущий скриншот страницы с утверждённым эталоном и показывает, где интерфейс изменился. Он полезен после релиза, обновления темы или правки CSS, но только если оба снимка сделаны в одинаковых условиях.
Чтобы тест не срабатывал на случайный шум, сначала зафиксируйте браузер, размер окна, шрифты, данные и состояние страницы. Лишь затем подбирайте допустимое отличие: большой порог не лечит нестабильный тест, а прячет реальные дефекты.
Что именно проверяет визуальный тест
Обычный функциональный тест отвечает, существует ли кнопка и можно ли её нажать. Визуальный тест замечает другое: кнопку перекрыл баннер, текст вышел за границы, карточки разъехались, а мобильное меню оказалось за пределами экрана.
Проверять весь сайт одним длинным снимком обычно неудобно. Выберите несколько критичных состояний:
- первый экран главной или посадочной страницы;
- форма до заполнения, с ошибкой и после успешной проверки;
- карточка товара или услуги с длинным заголовком;
- меню, модальное окно и уведомление;
- отдельные варианты для узкого и широкого экрана.
Так сбой проще связать с конкретным компонентом, а отличие быстрее разобрать.
Как настроить сравнение скриншотов
1. Опишите проверяемое состояние
Перед снимком тест должен открыть точный адрес, дождаться нужного элемента и привести страницу к известному состоянию. Для формы задайте безопасные тестовые значения, для списка — фиксированный набор записей, для личного кабинета — отдельного тестового пользователя без реальных данных.
Плохой критерий готовности — «подождать несколько секунд». Надёжнее ждать появления заголовка, исчезновения индикатора загрузки или завершения известного запроса.
2. Зафиксируйте среду
Эталон и новый снимок должны создаваться в одном браузере и при одинаковых параметрах:
- ширина и высота окна;
- масштаб и плотность пикселей;
- набор и способ загрузки шрифтов;
- язык, часовой пояс и цветовая схема;
- версия браузера и системное окружение;
- тестовые данные и права пользователя.
Если эталон сделан на одном компьютере, а проверка запускается на другом, отличаться могут сглаживание текста, переносы и размеры элементов. Проще выполнять обе операции в одинаковом контейнере или в одном закреплённом CI-окружении.
3. Уберите контролируемую динамику
Дата, часы, случайные рекомендации, реклама, мигающий курсор и анимация создают отличия без дефекта. Подмените время и ответы тестового API, отключите переходы и анимации, дождитесь загрузки шрифтов и изображений.
Динамический блок можно замаскировать, только если его содержание не относится к цели проверки. Не закрывайте маской всю шапку из-за часов: так тест перестанет видеть сломанное меню.
4. Создайте осмысленный эталон
Первый скриншот становится эталоном не автоматически. Просмотрите его при нужных размерах экрана и убедитесь, что нет заглушек, обрезанного текста, незагруженных картинок и открытых отладочных панелей.
Храните эталон рядом с версией теста. Изменение эталона должно быть отдельным осознанным решением, чтобы случайный дефект не закрепился как новая норма.
5. Сохраняйте три артефакта
При несовпадении нужны эталон, текущий снимок и изображение разницы. Без этой тройки сообщение «проценты не совпали» почти ничего не объясняет.
Добавьте к артефактам адрес страницы, размер окна, версию сборки и имя сценария. Секреты, Cookie и персональные данные в отчёт попадать не должны.
Откуда берётся шум и что делать
| Признак | Вероятная причина | Что проверить | |---|---|---| | Отличается только текст | Другой шрифт, язык или тестовые данные | Дождаться шрифта, закрепить локаль и фикстуру | | Сдвинулся весь экран | Иной viewport, полоса прокрутки или масштаб | Сверить размеры окна и плотность пикселей | | Разница появляется в одном месте | Дата, баннер, анимация или карусель | Зафиксировать состояние либо точечно маскировать | | Часть изображения пустая | Lazy loading или незавершённая загрузка | Прокрутить к блоку и ждать явного признака готовности | | Контуры текста слегка отличаются | Другое окружение рендеринга | Сравнивать в одинаковом браузерном окружении |
Повторный запуск полезен для диагностики: если отличие исчезает без изменения кода, сценарий нестабилен. Но автоматически перезапускать тест до зелёного результата опасно — реальный дефект тоже может стать случайно незаметным.
Как выбрать допустимое отличие
Начните со строгого сравнения в стабильной среде. Если остаются объяснимые различия рендеринга, задавайте допуск локально: для конкретного компонента или типа снимка, а не для всей страницы.
Перед увеличением допуска ответьте на три вопроса:
- Какие пиксели меняются и почему?
- Может ли в ту же область попасть реальный дефект?
- Увидит ли команда небольшое смещение текста, кнопки или цены после нового порога?
Чем больше скрываемая область и допуск, тем слабее сигнал теста. Иногда надёжнее сравнить отдельный компонент и дополнить проверку утверждениями о тексте, размере или доступности элемента.
Как разбирать падение теста
Сначала посмотрите на форму отличия.
- Геометрия изменилась по всей странице — проверьте viewport, шрифты и базовые стили.
- Один компонент сдвинул соседние — найдите изменение его размера, контента или загрузки.
- Поменялся только текст — сравните тестовые данные, локаль и состояние пользователя.
- Исчезло изображение или иконка — проверьте загрузку ресурса, путь и момент снимка.
- Отличие воспроизводится только иногда — ищите гонку загрузки, анимацию или случайные данные.
Если изменение задумано, сначала подтвердите макет и поведение, затем обновите эталон. Если нет — исправьте интерфейс и оставьте прежний снимок. Не принимайте новый эталон только ради зелёной сборки.
Что визуальный тест не заменяет
Скриншот не доказывает, что форма действительно отправляет заявку, платёж завершён, API возвращает правильные данные, а страница доступна из внешней сети. Визуальная проверка должна дополнять функциональные сценарии, проверку API и smoke-тест после релиза.
Если цель — разобраться с прыжками элементов во время загрузки, полезен отдельный разбор причин CLS: финальный скриншот может выглядеть правильно и не показать движение, которое уже увидел посетитель.
Практический следующий шаг
Выберите одну критичную страницу и два размера экрана, стабилизируйте данные и окружение, затем добейтесь повторяемого результата без широких масок и завышенного допуска. После этого добавляйте следующие состояния по одному.
Чтобы отдельно контролировать доступность критичного URL между релизами, добавьте его в Web-Puls: сервис будет регулярно проверять ответ сайта и сообщит о сбое. Это не замена сравнению скриншотов, а второй независимый уровень контроля.