Тест зелёный, но сайт «поехал»: как новый шаг ловит визуальные регрессии
Знакомая ситуация: все тесты зелёные, релиз уехал в прод, а через пару часов приходит скриншот от пользователя - блок с ценой наехал на кнопку «Купить», текст обрезан, половина карточки уехала за экран. Кнопка при этом нажимается, форма отправляется, оплата проходит. С точки зрения функционального теста - всё идеально. С точки зрения посетителя сайт сломан.
Функциональный тест проверяет, что действие выполнимо: элемент на месте, клик срабатывает, нужный текст присутствует. Но он почти никогда не видит, что страница выглядит сломанной, поехавшую вёрстку, сместившийся или пропавший блок, наехавший текст и слетевшие после правки общих стилей отступы. Один неудачный CSS-коммит или обновление шаблона и регрессия расходится по десяткам страниц, а узнаёте вы о ней последним.
Откуда мы взяли идею
Подход называется визуальным регрессионным тестированием (Visual Regression Testing, VRT): берём эталонный снимок страницы, при следующем прогоне делаем новый и сравниваем пиксели. Расходятся сильнее порога - сигналим. В мире фронтенда это давно делают для библиотек компонентов (Storybook + попиксельное сравнение скриншотов). Но там стерильные условия: изолированный компонент, фиксированные данные, один и тот же фон.
Мы тестируем живые сайты с рекламой, динамическими лентами, датами, A/B-экспериментами и просто шумом рендеринга от прогона к прогону. Поэтому «в лоб» подход с библиотек не переносится: слишком строгое сравнение завалит вас ложными срабатываниями уже на второй день. Нам нужен был VRT, устойчивый к реальному вебу.
Что мы сделали: шаг «Визуальная регрессия»
Это обычный шаг сценария - ставите его туда, где хотите зафиксировать внешний вид страницы. Например: открыть главную → дождаться загрузки → Визуальная регрессия. Дальше всё происходит само.
- Эталон собирается сам. Отдельно ничего «снимать как образец» не нужно: шаг сравнивает текущий кадр с тем, как эта же страница выглядела в нескольких последних прогонах этого же шага. При первом запуске или после изменения сценария эталон просто копится заново.
- Сравнение терпимо к шуму. Лёгкий шум рендеринга и сглаживание шрифтов игнорируются, а правило «совпал хотя бы с одним из последних кадров» гасит мелкую динамику вроде меняющейся рекламы. Порог расхождения настраивается - по умолчанию 2% площади (для живых сайтов это золотая середина).
- Понятный вердикт, а не «0,4% пикселей». Если расхождение всё-таки превысило порог - кадр уходит в AI-зрение, и в отчёте вы видите человеческое объяснение: «сместился блок цены, текст кнопки обрезан», а не сухую цифру.
Почему это дешевле, чем кажется
Сначала отрабатывает быстрое и бесплатное попиксельное сравнение. AI подключается только когда что-то реально изменилось, то есть на подавляющем большинстве прогонов, где всё в порядке, никакие AI-токены не тратятся вообще. Получается честный размен: дешёвый фильтр отсекает 99% «зелёных» кадров, а умный и платный разбор включается ровно там, где есть что объяснять. Расход токенов при этом виден и по конкретному шагу и за тестом в целом - никаких сюрпризов в биллинге.
Что это ловит на практике
- поехавшую после правки общих стилей вёрстку - сразу на всех страницах, где стоит шаг;
- сместившийся, обрезанный или пропавший текст и элементы;
- сломавшиеся отступы, размеры, цвета;
- «пустые» места, где не подтянулся блок или картинка.
И всё это до того, как увидит пользователь, а не по его жалобе.
Как включить
Добавьте в сценарий шаг «Визуальная регрессия» в нужном месте (обычно сразу после перехода на страницу и её загрузки) и при желании поправьте порог. Дайте тесту пару прогонов, чтобы сформировался эталон, дальше шаг сам начнёт сторожить внешний вид страницы и поднимать тревогу, когда дизайн «поедет». Результат и наглядное пояснение видно прямо на странице отчёта прогона.
Функциональные тесты отвечают на вопрос «работает ли». Шаг «Визуальная регрессия» добавляет второй, не менее важный: «а выглядит ли так, как задумано». Вместе они закрывают и логику и внешний вид и вы перестаёте узнавать о сломанной вёрстке от клиентов.