Что такое flaky-тесты и как с ними бороться?

Auto QA Middle Автоматизация / CI-CD обновлено 15.11.2025

Краткий ответ

Flaky-тесты — это нестабильные автотесты, которые иногда проходят успешно, а иногда падают без изменения кода. Они мешают CI/CD и снижают доверие к автоматизации.

Причины: задержки, нестабильные данные, асинхронность, внешние сервисы.
Как бороться:

  • Убрать зависимости от окружения,
  • Добавить ожидания (wait), retry, mock,
  • Изолировать данные теста,
  • Анализировать логи и метрики стабильности.

Пример:

UI-тест на кнопку “Оплатить” иногда падает из-за того, что страница не успевает прогрузиться.
Решение — добавить waitForElement() или стабилизировать API-ответ.

Полный ответ

Что такое flaky-тест

Flaky (от англ. flaky — “ломкий”, “ненадёжный”) тест — это автоматизированный тест, который даёт разные результаты при одинаковых условиях:

  • то проходит,

  • то падает,

  • хотя код системы и теста не менялся.

Такие тесты создают “шум” в отчётах, затрудняют анализ CI и снижают доверие к автотестам.

Пример flaky-теста

def test_payment_success(api_client):
    response = api_client.post("/payment", data={"sum": 100})
assert response.status_code == 200

Иногда падает с ошибкой 504 Gateway Timeout.
Почему? → сервис оплаты отвечает дольше из-за задержки сети.
Тест “флаки”, потому что ошибка не в логике, а во внешнем факторе.

Основные причины флаки-тестов

Категория: Асинхронность / тайминги
Пример: Элемент UI не успел отрисоваться
Решение: Добавить явные ожидания (wait, retry)

Категория: Нестабильные данные
Пример: Тест использует общие данные в БД
Решение: Изолировать или создавать данные заново

Категория: Зависимость от окружения
Пример: API-тест зависит от стороннего сервиса
Решение: Использовать mock / stub

Категория: Параллельное выполнение
Пример: Несколько тестов меняют одни данные
Решение: Изолировать тестовые данные

Категория: Порядок выполнения тестов
Пример: Один тест влияет на другой
Решение: Делать независимыми (stateless)

Категория: Нагрузка на CI
Пример: Тест падает при нехватке ресурсов
Решение: Настроить стабильные агенты и окружение

Категория: Недетерминированный код
Пример: Рандом, кэш, время
Решение: Фиксировать seed, стабилизировать clock()

Как бороться с flaky-тестами

Изоляция тестов

  • Каждый тест должен работать независимо.

  • Создавать / удалять данные внутри теста.

  • Использовать фикстуры и teardown.

Контроль времени и ожиданий

  • Добавить явные ожидания (waitForElement, assertEventually).

  • Задать максимальные таймауты и polling-интервалы.

  • Избегать “жёстких sleep()” — они не гарантируют стабильность.

Использовать mock / stub

  • Подменить внешние API и сервисы тестовыми версиями.

  • Пример: вместо реального /payment — mock-сервис, возвращающий стабильный ответ.

Перезапуск flaky-тестов

  • Настроить auto-rerun при падении (в Jenkins, TestOps).

  • Если тест падает 1 раз из 5 — пометить его как flaky и вынести из основного набора.

Мониторинг стабильности

  • Вести статистику успешности каждого теста (% pass rate).

  • Автоматически детектить flaky по истории запусков (например, Allure TestOps, Jenkins Flaky Plugin).

Рефакторинг теста или системы

  • Проверить: может, проблема не в тесте, а в коде приложения (медленные API, race condition).

Пример анализа flaky-теста

Признак: Ошибка “Element not found”.
Обнаружено: UI-тест на Chrome падает иногда
Решение: Добавлен waitForElement()

Признак: Ошибка 504.
Обнаружено: API зависает при нагрузке
Решение: Подменили сервис mock-ответом

Признак: Нестабильный результат при параллельных тестах.
Обнаружено: Данные общие для всех
Решение: Сделали уникальные user_id

После фиксов стабильность выросла с 80% → 98%.

Как внедрить борьбу системно

  1. Завести метрику “Flakiness rate” (% нестабильных тестов).

  2. Порог допуска: <5% flaky = OK, >10% = сигнал тревоги.

  3. Регулярно анализировать отчёты.

  4. Выносить flaky-тесты в карантин до исправления.

Пример инструмента

Allure TestOps → умеет:

  • автоматически определять flaky по истории;

  • помечать нестабильные тесты;

  • считать стабильность по проектам.

Jenkins Flaky Test Handler → перезапускает только упавшие тесты.

Итог

Flaky-тесты — это нестабильные тесты, которые падают без причины. Они появляются из-за асинхронности, зависимостей и нестабильных данных.

Чтобы с ними бороться:

  • Делай тесты изолированными и детерминированными,

  • Используй ожидания и mock-и,

  • Анализируй статистику стабильности,

  • Автоматизируй rerun и контроль качества.

Оцените ответ
0 / 5 · 0

Related Questions