Нестабильный сетевой тест: трасса, повтор и честный диагноз
Повтор может подтвердить нестабильность, но не исправляет её. Первый отказ нужно сохранить как отдельный результат с сетевыми событиями и состоянием страницы.
Главное за минуту
- Статус flaky — сигнал для расследования, а не успешный тест.
- Повтор должен начинаться в изолированном worker и с контролируемым состоянием.
- Успешный повтор не стирает доказательства первого отказа.
- Необратимый шаг повторяют только после идемпотентности и сверки.
Доказательства первого отказа
Сохраните код, URL без токенов, этап, длительность и трассу. Не перезаписывайте их данными успешного повтора.
Первый сбой связывайте с run ID, test ID, route ID и безопасным идентификатором аренды. Сохраните последовательность запросов, коды и тайминги до запуска повтора. Trace, screenshot и console могут содержать персональные данные или токены, поэтому применяйте фильтрацию до выгрузки и ограниченный срок хранения. Успешный retry добавляется рядом, но не заменяет исходный артефакт.
Ограниченный retry
Назначьте небольшое число попыток и отдельно считайте flaky. Бесконечный retry увеличивает нагрузку и маскирует регрессию.
Обычно достаточно одного или двух повторов с одинаковой конфигурацией и контролируемой паузой. Считайте отдельно passed, failed и flaky, а также вероятность нестабильности по истории. Не используйте retry для платежей и иных необратимых шагов без идемпотентного ключа и postcheck. Рост flaky-rate выше базовой линии должен блокировать релиз или создавать обязательную задачу расследования.
Изоляция состояния
Playwright перезапускает worker после падения. Тестовые данные и внешние операции должны быть готовы к новому процессу и не зависеть от незавершённого шага.
Каждый retry получает новый browser context и очищенные тестовые данные, но сохраняет общий correlation ID. Внешний объект создавайте идемпотентно либо выдавайте уникальное имя и cleanup с проверкой результата. Если предыдущий шаг имеет неизвестный исход, новый процесс не повторяет его вслепую: сначала выполняется сверка фактического состояния, иначе тест сам создаст дубликат.
Классификация причины
Разделяйте отказ клиента, прокси, мобильного канала, DNS, TLS и целевого сервиса. Только подтверждённый слой получает исправление или алерт.
Используйте короткое дерево решений: ошибка воспроизводится без прокси, только на одном маршруте, на всех целях или на одном endpoint. Сравните DNS, connect, TLS, статус и содержимое. Назначайте причину только после независимого подтверждения; до этого используйте unknown, а не обвиняйте оператора или приложение. Отчёт должен содержать доказательство и следующий безопасный диагностический шаг.
Практический чек-лист
- 1Сохраните первый trace.
- 2Ограничьте retries.
- 3Отчитывайтесь о flaky отдельно.
- 4Считайте flaky-rate отдельно по маршрутам.
- 5Добавьте decision tree в шаблон отчёта.
Источники и документы
Материал подготовлен по первичным, официальным и техническим источникам. Формулировки статьи являются самостоятельным изложением.