Периодически один автотест падает на одном и том же коммите, но повторный запуск иногда проходит. Как в CI подтвердить, что это нестабильность теста, а не дефект продукта?
Запустите тест многократно на неизменном коммите и в контролируемом окружении, сохраняя каждый результат и диагностические артефакты. Если при одинаковых исходных условиях тест дает разные результаты без изменения продукта или входных данных, это сильный признак flaky-теста; его нужно расследовать отдельно, а не скрывать повторами.
Нестабильные тесты стали распространенной проблемой с ростом асинхронных интерфейсов, распределенных систем и параллельного выполнения проверок. Один и тот же сценарий начал зависеть не только от кода продукта, но и от времени, порядка выполнения, ресурсов окружения или внешних сервисов.
Обычный отчет «прошел или упал» не позволяет отличить дефект продукта от случайной ошибки самого теста. Поэтому в CI появились накопление истории запусков, повторные проверки на фиксированной версии и анализ причин сбоев.
Если тест падает только иногда, автоматический повтор может превратить реальный дефект в зеленую сборку. Если же такой тест всегда блокирует слияние, команда начинает игнорировать сигнал и снижает доверие ко всему набору.
Одного успешного повторного запуска недостаточно: продуктовый дефект тоже может проявляться редко. Нужны неизменный коммит, одинаковые входные данные, сопоставимое окружение и данные о каждом запуске, включая длительность, логи, скриншоты, трассировки и состояние зависимостей.
Сначала зафиксируйте версию продукта, тестов, окружения и набора данных. Затем выполните один и тот же тест или небольшой набор тестов много раз, желательно в нескольких независимых заданиях CI, не меняя код между запусками.
Собирайте для каждой попытки статус, время начала, длительность, номер повторения, идентификатор окружения и диагностические материалы. Полезно сопоставлять сбои с нагрузкой, параллельными заданиями, временем ожидания, сетевыми ошибками и изменениями состояния стенда.
Тест считают подозрительно нестабильным, если при одинаковых условиях он чередует успешные и неуспешные результаты. Это не математическое доказательство отсутствия дефекта продукта: редкий дефект может случайно совпасть с теми же наблюдениями. Вывод повышает надежность, если результаты воспроизводятся на нескольких независимых запусках и причина связана с тестом или окружением.
Повторы допустимы как диагностический инструмент, но не как способ сделать сборку зеленой. После подтверждения нестабильности тест следует пометить, назначить владельца, сохранить его в отдельном контролируемом наборе и отслеживать метрики: долю нестабильных запусков, возраст проблемы и время исправления.
Важно разделять нестабильность теста и нестабильность системы. Если меняется состояние общего стенда или внешнего сервиса, тест может быть детерминированным, а окружение — нет; тогда исправлять нужно границу зависимости, а не только сам тест.
После каждого коммита API-тест иногда не находил созданную сущность. Команда рассматривала три варианта: увеличить число повторов, полностью отключить тест или провести серию запусков на одном коммите с сохранением логов и идентификаторов запросов.
Повторы быстро уменьшали число красных сборок, но скрывали редкие ошибки. Отключение устраняло шум, однако убирало проверку важного сценария. Выбрали третий вариант: серия контролируемых запусков показала, что тест обращался к данным сразу после записи, а тестовый стенд асинхронно обновлял индекс.
Исправили ожидание готовности данных на уровне тестовой границы и оставили мониторинг нестабильности. После этого результаты стали воспроизводимыми, а диагностические материалы позволили отдельно проверить, что задержка индексации не создает продуктовую ошибку.
Нет. Один успешный повтор показывает лишь, что сбой не воспроизвелся сразу. Нужна серия запусков на фиксированной версии с сопоставимыми условиями; чем реже сбой, тем больше наблюдений требуется для обоснованного вывода.
Последовательные запуски могут наследовать состояние браузера, базы данных, кэша или внешнего сервиса. Кроме того, одинаковый узел CI может иметь одну и ту же неисправность. Поэтому полезны очистка состояния, независимые задания и сравнение артефактов, а не только итоговых статусов.
Когда продукт действительно имеет вероятностное или времязависимое поведение: например, гонку, потерю события или нарушение согласованности. Если повторяемость сбоя зависит от конкретной последовательности действий, нагрузки или состояния системы, нельзя автоматически списывать его на тест; нужно воспроизвести условия на уровне продукта и проверить его наблюдаемыми сигналами.