Flaky тест (или нестабильный тест) — это тест, который выдаёт разные результаты — успех или провал — для одного и того же кода и одной и той же конфигурации, без каких-либо изменений в тестируемой системе.
Вот мнение, которое может вас задеть: flaky визуальный тест хуже, чем полное отсутствие теста. И это не беспричинная провокация. Отсутствующий тест ничего не стоит в повседневной работе. Он не блокирует ваш pipeline. Не потребляет время вашей команды. Не разрушает доверие к вашей инфраструктуре тестирования. Flaky тест делает всё перечисленное, каждый день, исподволь — потому что каждое ложное падение выглядит достаточно убедительно, чтобы потребовать расследования.
Данные Google о собственных системах тестирования показательны: примерно 1,5 % их тестов являются flaky в любой момент времени, но эти тесты потребляют непропорционально большую долю инженерного времени. Если компания масштаба и технической компетентности Google не устранила эту проблему — значит, она нетривиальна. А в специфической области визуального тестирования проблема усугубляется самой природой того, что сравнивается.
Почему визуальные тесты особенно уязвимы к нестабильности
Автоматизированное визуальное тестирование вводит слой недетерминизма, которого нет в модульных и функциональных тестах. Модульный тест проверяет, что функция возвращает корректное значение. Функциональный тест проверяет, что кнопка инициирует правильное действие. Эти результаты бинарны и детерминированы.
Визуальное тестирование проверяет, что рендеринг вашего интерфейса совпадает с эталонным скриншотом. А рендеринг веб-страницы — результат сложной цепочки процессов, каждый из которых вносит свою вариативность: парсинг HTML, применение CSS, выполнение JavaScript, загрузка внешних ресурсов, расчёт layout, растеризация, компоновка.
Четыре главные причины нестабильности визуальных тестов
Тайминг: проблема, которую нельзя игнорировать
Веб по своей природе асинхронен. Когда вы просите браузер сделать скриншот, действительно ли страница полностью готова? Ответ почти всегда: зависит от обстоятельств.
Загрузка страницы — не единичное событие, а каскад событий: парсинг HTML, применение CSS, выполнение скриптов, загрузка изображений, применение веб-шрифтов, возврат данных по API-запросам. Каждый этап имеет переменную длительность. Классическая стратегия ожидания «готовности» — DOMContentLoaded, событие load или network idle — не гарантирует завершённости визуального рендеринга.
Результат: ваш скриншот иногда фиксирует полностью отрисованную страницу, а иногда — страницу в процессе рендеринга.
Анимации: движение в статичном носителе
Скриншот — фиксированное изображение. Анимация — непрерывное изменение. Они фундаментально несовместимы для автоматизированного сравнения. Если на вашей странице есть 300-миллисекундная анимация, запускающаяся при загрузке, точный момент захвата относительно начала анимации варьируется от запуска к запуску.
Бесконечные анимации (спиннеры, skeleton-загрузчики) — ещё хуже: для них не существует «стабильного» момента для захвата.
Динамический контент: всё, что меняется без вашего участия
Даты, время, реклама, случайно генерируемые аватары, уведомления в реальном времени, счётчики посетителей — всё это варьируется между запусками тестов. Каждое изменение обнаруживается как визуальная разница. Каждая разница приводит к падению теста.
Сеть и инфраструктура: переменные, которые вы не контролируете
Ваш тест выполняется в среде, зависящей от внешних ресурсов: API-серверов, CDN для изображений и шрифтов, сторонних сервисов. Латентность варьируется от запуска к запуску. В pipeline CI/CD проблема усугубляется — ваш CI-runner делит ресурсы с другими задачами.
Реальная стоимость flaky тестов
Наиболее заметная статья расходов — время на классификацию. Каждое ложное падение flaky теста требует расследования: кто-то должен изучить результаты, сравнить вручную, определить, реальная ли это проблема, и при необходимости перезапустить.
Но самая разрушительная стоимость — невидимая: потеря доверия. Когда команда убеждается, что визуальные тесты «вечно» падают без причины, у неё вырабатывается рефлекс автоматического перезапуска. В тот день, когда тест упадёт из-за реального бага, рефлекс будет тем же: перезапустить. И баг попадёт в продакшен.
У этого феномена есть название: «эффект мальчика, который кричал волк». Однажды укоренившись, он очень трудно поддаётся обратному развитию.
Стратегии стабилизации, которые реально работают
Контроль среды рендеринга
Используйте headless-браузер в контролируемом контейнере с фиксированным разрешением, предустановленными шрифтами и детерминированной сетевой конфигурацией. Заморозьте версию браузера, отключите GPU-рендеринг, настройте фиксированный размер viewport.
Нейтрализация анимаций
Инжектируйте таблицу стилей, принудительно устанавливающую нулевую длительность всех анимаций и переходов. Это мгновенно «замораживает» все анимированные элементы в их финальном состоянии.
Стабилизация динамического контента
Заморозьте даты и время, отключите сторонние виджеты, замокируйте данные API, замените генерируемые аватары статическими изображениями в тестовых фикстурах. Цель — среда, в которой единственной переменной является код вашего интерфейса.
Интеллектуальное ожидание
Вместо фиксированных задержек (wait 3 seconds) применяйте стратегии ожидания на основе состояния. Ожидайте появления критических элементов, загрузки изображений, применения шрифтов, завершения сетевых запросов.
Используйте сравнение, толерантное к шуму
Пиксельное сравнение наиболее чувствительно к недетерминизму рендеринга. Перцептивные алгоритмы (SSIM, pHash) более толерантны. Структурный подход — сравнение DOM и вычисленных CSS-свойств вместо пикселей — наиболее устойчив к шуму рендеринга, поскольку он нативно игнорирует субпиксельные вариации, вызывающие большинство ложных падений.
No-code визуальное тестирование как решение проблемы поддержки
Визуальные тесты на основе кода (Playwright, Cypress, Selenium) требуют скриптов для навигации, взаимодействия и захвата. Эти скрипты сами по себе являются источником нестабильности: CSS-селектор, больше не находящий элемент; тайминг клика, промахивающийся мимо цели.
No-code инструменты, такие как Delta-QA, устраняют этот слой хрупкости. Вы не пишете скрипты — вы настраиваете тесты визуально. Инструмент берёт на себя загрузку, ожидание, стабилизацию и сравнение. Когда элемент меняет селектор, инструмент адаптируется без вашего вмешательства.
Когда стоит удалить flaky тест
Если визуальный тест падает периодически, несмотря на все попытки стабилизации, самое смелое — и зачастую самое мудрое — решение — удалить его. Flaky тест, который никто не исправляет, активно деградирует ваш pipeline. Он приучает команду игнорировать падения.
Удалите его, задокументируйте причину и замените более целенаправленной проверкой. Цель — не максимум тестов, а тесты, которым ваша команда доверяет.
FAQ
В чём разница между flaky тестом и ложным срабатыванием?
Ложное срабатывание сигнализирует о проблеме, которой не существует — достаточно единичного случая. Flaky тест выдаёт непоследовательные результаты от запуска к запуску для одного и того же кода. Flaky тест периодически производит ложные срабатывания.
Как измерить уровень нестабильности визуальных тестов?
Запустите одну и ту же визуальную тестовую сюиту несколько раз без изменения кода и подсчитайте тесты, чьи результаты меняются между запусками. Пяти последовательных прогонов достаточно для выявления наиболее нестабильных тестов.
No-code визуальные тесты менее подвержены нестабильности, чем кодовые?
Они устраняют одну категорию flakiness — хрупкость тестовых скриптов (ломающиеся селекторы, тайминг навигации, управление состоянием). Но они по-прежнему подвержены тем же ограничениям рендеринга браузера.
Стоит ли автоматически перезапускать провалившиеся визуальные тесты?
Автоматический перезапуск — пластырь, а не решение. Он маскирует проблему. Если вы вынуждены включить retry, ограничьтесь одной попыткой и помечайте тесты, потребовавшие перезапуска, для расследования.
Какой порог нестабильности допустим в CI/CD?
Стремитесь к показателю ниже 1 % от общего объёма тестовой сюиты. Выше 3 % влияние на продуктивность становится измеримым. Выше 5 % ваша команда почти наверняка вырабатывает рефлекс систематического перезапуска провалившихся pipeline.
Помогает ли Delta-QA стабилизировать визуальные тесты?
Delta-QA снижает нестабильность у источника, используя структурный подход вместо пиксельного сравнения. Субпиксельные вариации рендеринга, антиалиасинг и проблемы тайминга, вызывающие большинство периодических падений, нативно игнорируются. В сочетании с no-code подходом, устраняющим хрупкие тестовые скрипты, Delta-QA обеспечивает надёжные и воспроизводимые результаты без сложной конфигурации.
Для углубления
- Ложные срабатывания в визуальном тестировании: почему они убивают ваши тесты и как их устранить
- Визуальные Баги и SEO: Как CLS Разрушает Ваши Позиции в Google (и Как Визуальное Тестирование Это Предотвращает)
- Почему ваш сайт выглядит по-разному в разных браузерах (и как это исправить)
Визуальный тест имеет ценность только в том случае, если ваша команда ему доверяет. Нестабильные тесты разрушают это доверие день за днём. Вместо того чтобы тратить время на стабилизацию хрупких скриптов и сортировку ложных падений, выберите инструмент, изначально спроектированный для надёжности.