Порой, работая инженером по тестированию, обнаруживаешь, что давно знакомая тема на деле гораздо сложнее.
Как и любому инженеру по автоматизированному тестированию, мне приходилось отлаживать и чинить разные flaky (нестабильные) тесты. Кроме того, я обратился к академической литературе о flaky-тестах, чтобы правильно разобраться с проблемой, над которой работаю. Меня удивило, что многие привычные термины имели слегка разные определения от статьи к статье, а в некоторых работах использовались сугубо академические понятия из информатики, которые редко встречаются в реальной продакшн-практике тест-инженера.
Чтобы составить список ниже, я использовал свои заметки и выделения, сделанные при чтении статей, а также исследовательский инструмент NotebookML AI, чтобы собрать больше часто встречающихся терминов из корпуса прочитанных материалов.
Причины возникновения flaky-тестов, техники снижения нестабильности и стратегии исправления, методы обнаружения и прогнозирования — вне рамок этой статьи.
Ниже перечислены самые распространённые термины и понятия, связанные с flaky-тестами, в научных публикациях по компьютерным наукам:
flaky-тест
Все тесты нестабильны (all tests are flaky — ATAF)
Матрица ошибок классификации (confusion matrix)
Детерминированный исход/результат
Недетерминированный исход/результат
Распределённые тесты
Энтропия
Длины серий отказов
Ложная тревога/оповещение
Тест, выявляющий дефект
Сбой, вызванный выявленным дефектом
Flakiness (нестабильность тестов)
Жёсткая нестабильность
Мягкая нестабильность
О��енка нестабильности
Снижение нестабильности (FR)
Потери в обнаружении дефектов (LFD)
Нестабильная сборка (flaky build)
Flaky-сбой
Доля нестабильности / частота нестабильности / уровень нестабильности / частота отказов из-за flaky-тестов
Нестабильный набор тестов
Словарь flaky-тестов
Переключение / переход (flip / transition)
Частота переключений / частота переходов
Нестабильность инфраструктуры
Негерметичные тесты
Зависимость от порядка выполнения (OD)
Вероятностная оценка нестабильности (PFS)
Карантин
Степень нестабильности
Flaky-тест, зависящий от ресурсов (RAFT)
SUT (System Under Test)
CUT (Code Under Test)
Системная нестабильность
Запахи тестов
Flaky-тест
Существует много определений flaky-теста, и все они сводятся к одной идее: это тест, который при многократном выполнении на одной и той же версии кода то проходит, то падает.
Формальное определение звучит так: flaky-тест — это тест, который даёт недетерминированный результат.
Все тесты нестабильны (ATAF)
Это предположение о том, что любой тест можно считать flaky. Единственное различие между тестами — как часто они падают (просто иногда эта частота может быть равна нулю).
Матрица ошибок классификации
Матрица ошибок классификации — это способ классификации результатов алгоритма. Её применяют для обнаружения flaky-тестов, прогнозирования, классификации и оценки качества моделей/методов.
Четыре компонента матрицы ошибок определяются в контексте классификации теста (или падения) как «flaky» (положительный класс) или «не flaky» (отрицательный класс):
Истинно положительный (TP): flaky-падение корректно распознано как нестабильность.
Ложно отрицательный (FN): flaky-падение ошибочно распознано как стабильный (или отнесено к «настоящим» падениям).
Ложно положительный (FP): стабильный тест ошибочно классифицирован как нестабильный.
Истинно отрицательный (TN): стабильные (не flaky) результаты теста корректно распознаны как стабильные; «настоящее» падение, которое не совпадает ни с одним flaky-падением.
Практики могут называть тесты из категорий FN и FP «подозрительными», потому что отладка причин падений занимает значительное время.
Детерминированный исход/результат
Это результат, который можно предсказать точно, со стопроцентной уверенностью, исходя из заданного набора входных данных и начальных условий. Это означает, что в процессе нет случайности или неопределённости.
Стабильные/надёжные тесты дают детерминированные результаты.
Недетерминированный исход/результат
Это результат, который может меняться даже при повторении одних и тех же входных данных или условий. Это означает, что результат нельзя предсказать с уверенностью — он может отличаться от запуска к запуску (то есть быть непоследовательным).
Результат теста недетерминированен, если он иногда проходит, а иногда падает.
Распределённые тесты
Это тесты, выполнение которых одновременно задействует несколько машин, окружений или SUT. В некоторых работах ставилось под вопрос влияние распределённых окружений на нестабильность, но корреляций обнаружено не было.
Например, запуск тестов параллельно на разных машинах — это распределённое тестирование; запуск тестов против SUT, развернутой на нескольких узлах, — тоже распределённое тестирование.
Энтропия
В научном смысле это мера случайности. В контексте flaky-тестов под энтропией понимают метрику, которая выявляет нестабильность по вариативности результатов теста. Энтропия измеряет случайность (или неопределённость) в истории прохождений/падений теста.
Она вычисляется по формуле:
Где:
p(i) — вероятность каждого исхода i (прохождение или падение).
В отличие от простых метрик частоты переключений, энтропия фокусируется на соотношении числа прохождений к числу падений, игнорируя порядок, в котором происходят эти исходы. Это может помочь выявлять тесты, которые непредсказуемо то проходят, то падают — а это характерный признак flaky-тестов.
Связанные термины: частота переключений / частота переходов.
Длины серий отказов
Это длина последовательностей подряд идущих падений при многократном запуске flaky-тестов; её используют, чтобы определить, сколько повторных прогонов нужно, чтобы проявилась нестабильность.
Ложная тревога/оповещение
Падение теста, вызванное flaky-тестом, при отсутствии реального дефекта или бага в тестируемом коде.
Тест, выявляющий дефект
Тест, который после повторных прогонов в рамках ��дной и той же сборки продолжает стабильно падать, тем самым выявляя регрессию.
Сбой, вызванный тестом, выявляющим дефект
Падение, вызванное тестом, выявляющим дефект: тест стабильно падает после повторных прогонов, что указывает на реальную регрессию.
Нестабильность
Нестабильность (flakiness) — это свойство теста давать непоследовательные, ненадёжные или недетерминированные результаты.
Жёсткая нестабильность
Определение нестабильности, используемое в количественном тестировании (например, в A/B-тестировании) и совпадающее с традиционной бинарной трактовкой вердикта: нестабильность фиксируется, когда при повторных запусках меняется окончательный вердикт «прошёл/упал».
Мягкая нестабильность
Определение нестабильности, специфичное для количественного тестирования (например, в A/B-тестировании): нестабильность выявляется по колебаниям количественных значений метрики качества (fitness) между повторными запусками, даже если вердикт «прошёл/упал» остаётся неизменным.
Скоринг нестабильности (flakiness scoring)
Это количественная оценка того, насколько тест нестабилен (или ненадёжен), — то есть как часто при одинаковых условиях меняется его результат (прошёл/упал). В этой оценке используются две ключевые метрики: энтропия и частота переключений, которые агрегируются во времени, чтобы получить оценку нестабильности для каждого теста.
Оценка нестабильности показывает, как нестабильность распределена по тестам, и может использоваться для мониторинга и выявления изменений в динамике нестабильности.
В Meta есть похожая внутренняя метрика: вероятностная оценка нестабильности.
Снижение флейков (Flake reduction — FR)
Это метрика оценки, используемая для измерения эффективности подхода к оценке нестабильности при фильтрации flaky-тестов.
FR определяется как доля падений flaky-тестов, удалённых фильтрацией. Она показывает, сколько «шума из-за нестабильности» удалось убрать после автоматического игнорирования тестов, чья оценка нестабильности превышает установленный порог.
Снижение нестабильности (FR)
Высокий FR = хорошо: фильтрация убрала большинство ненадёжных падений (меньше шума).
Низкий FR = плохо: многие падения flaky-тестов всё ещё остаются.
Потери в обнаружении дефектов (LFD)
Это метрика оценки, используемая для измерения эффективности подхода к оценке нестабильности при фильтрации flaky-тестов.
LFD — это доля реальных (детерминированных) дефектов, где «дефекты» определяются как детерминированные падения на конкретном коммите/версии SUT. Эта метрика измеряет нежелательный побочный эффект фильтрации flaky-тестов: сколько реальных дефектов (то есть не связанных с нестабильностью) было ошибочно отфильтровано.
Потери в обнаружении дефектов (LFD)
Низкий LFD = хорошо: мало реальных багов случайно игнорируется.
Высокий LFD = плохо: фильтрация убирает реальные, детерминированные падения.
Нестабильная сборка (flaky build)
Это сборка в CI, которая даёт недетерминированные результаты (то есть случайным образом проходит или падает). Сборка CI может завершаться неудачей из-за результата запуска набора flaky-тестов (что и означает нестабильность) или из-за нестабильности самой системы непрерывной интеграции.
Флейковое падение (flaky failure)
Падение теста, которое вызвано именно flaky-тестом.
Flaky rate / flake rate / flakiness rate / flaky-test-failure rate (частота/доля флейковости)
Эта метрика показывает, как часто тест демонстрирует flaky-поведение. Доля флейковости измеряет, какая часть выполнений теста является flaky за заданный период наблюдения.
Доля флейковости рассчитывается по формуле:
Где:
t — конкретный тест.
F(t) — число flaky-выполнений теста t.
E(t) — общее число выполнений этого теста за наблюдаемый период. Обычно здесь используют число прогонов тестов или число сборок.
Иными словами, эта метрика показывает степень нестабильности.
Для расчёта доли flaky в скользящем окне по времени или по сборкам формула принимает вид:
Где:
t — конкретный тест.
N — число последних сборок (размер окна).
Flaky(t,i) = 1, если тест t был flaky в сборке i, иначе 0.
К другим способам количественно оценить нестабильность относятся частота переключений (flip rate — измеряет, как часто тест переключается между «прошёл» и «упал») и энтропия (измеряет случайность результатов).
Набор тестов (flaky test suite)
Набор тестов считается нестабильным, если при многократном запуске на одной и той же версии кода он то проходит, то падает. При этом набор тестов также считают нестабильным, если он содержит flaky-тесты. Следовательно, flaky-набор тестов — это набор, который ведёт себя недетерминированно из-за содержащихся в нём flaky-тестов.
Словарь flaky-тестов
Это специализированный набор идентификаторов исходного кода, ключевых слов и языковых паттернов, извлечённых из исходного кода тест-кейсов, которые проявляют flaky-поведение. Такой словарь — важный признак, используемый в статическом анализе и моделях машинного обучения, чтобы предсказывать нестабильность тестов без необходимости выполнять сами тесты.
Словарь, связанный с flaky-тестами, содержит слова вроде job, table, action, wait, process, timeout, duration, thread, sleep, idle и т. п., и может зависеть от языка программирования и фреймворка автотестов.
Переключение / переход (flip / transition)
Flip, или transition, означает изменение результата теста между запусками, коммитами или версиями SUT.
Pass → Fail: тест начинает падать после изменения кода.
Fail → Pass: тест снова начинает проходить после изменения кода.
Переход (переключение результата теста) указывает на значимое изменение в поведении теста.
Частота переключений / частота переходов
Этот термин встречается в статьях о моделировании нестабильности. Частота переключений, или частота переходов, — это статистическая мера того, как часто происходят переключения (переходы). Она равна числу переключений (переходов) теста, делённому на временное окно или на количество запусков теста.
Она вычисляется по формуле:
Если тест ни разу не переключается, его частота переключений равна 0. Если тест переключился один раз из Pass → Fail за 3 запуска, частота переключений равна 1/3, или 0,33. Если тест переключился 3 раза за 3 запуска, частота переключений равна 3/3 = 1. Таким образом, частота переключений позволяет улавливать различия в поведении тестов.
Нестабильность инфраструктуры
Это такая нестабильность тестов, которая возникает из-за проблем вне кода проекта (то есть CUT), но внутри среды выполнения (например, из-за недетерминизма в тестовой инфраструктуре, виртуальных машинах (VM), Docker-контейнерах, сервисах непрерывной интеграции, sandbox-окружениях (песочницах), симуляторах, при скачивании зависимостей и т. п.).
Негерметичные тесты (non-hermetic tests)
Тесты, которые не изолированы полностью от внешних зависимостей и переменных окружения. Во время выполнения такие тесты взаимодействуют с реальными внешними системами — например, с базами данных, файловыми системами, сетями, сторонними сервисами и развёрнутыми приложениями. Из-за этого негерметичные тесты чаще оказываются нестабильными, выполняются медленнее, а разбор причин падений усложняется, поскольку результат зависит от внешних условий.
Связанные термины: неизолированные тесты, системные тесты, end-to-end тесты, распределённые тесты.
Зависимость от порядка выполнения (OD)
Зависимость от порядка выполнения тестов — это ситуация, когда результат одного теста зависит от того, в каком порядке запускаются тесты. OD — одна из ключевых причин нестабильности, и этот термин включён в список потому, что он приводит к нестабильности именно по вине самих тестов.
У OD есть собственный словарь терминов, включая victim test, polluter и state-setter и другие. Однако эти термины выходят за рамки данной статьи и рассматриваются в соответствующих публикациях.
Вероятностная оценка нестабильности (PFS)
Это статистическая метрика, которая оценивает, насколько вероятно, что конкретный тест упадёт из-за нестабильности, а не из-за реальной регрессии в коде или изменения состояния системы.
PFS измеряет вероятность нестабильности теста и может использоваться для оценки и мониторинга надёжности тестов.
В Apple есть похожая внутренняя метрика: оценка флейковости (flakiness scoring).
Карантин
Стратегия, при которой известные flaky-тесты изолируют от основного «здорового» набора тестов и выносят в отдельную зону или список — обычно для того, чтобы они не блокировали непрерывную интеграцию и чтобы позже можно было их расследовать и исправить.
Степень флейковости
Это степень выраженности (или распространённости) flaky-поведения (то есть нестабильности) для конкретного теста.
Универсальной шкалы не существует. Опираясь на независимый анализ истории результатов тестов и отчётов о дефектах, некоторые исследователи ранжируют тесты как нефлейковые (NF), слегка флейковые (SF), флейковые (F) или очень флейковые (VF).
Flaky-тест, зависящий от ресурсов (RAFT)
Тест, у которого частота падений статистически отличается при ограничении вычислительных ресурсов (например, числа ядер CPU или объёма RAM) по сравнению с запуском без таких ограничений.
SUT (System Under Test)
Любой аппаратный или программный компонент, который в данный момент тестируется. SUT может быть приложением любого типа, API, UI и т. д.
CUT (Code Under Test)
Программный код, который тест-кейс предназначен выполнять. CUT может быть скомпилированной программой, библиотекой, функцией, методом и т. д.
CUT — частный случай SUT.
Системная нестабильность
Явление, при котором flaky-тесты существуют кластерами, а их падения происходят совместно в рамках одних и тех же прогонов набора тестов, часто имея общие первопричины — например, периодические проблемы с сетью или нестабильность внешних зависимостей.
Запахи тестов
Запах тестов — это характерный признак в тестовом коде, который указывает на потенциальную проблему в дизайне или плохую практику тестирования. Запахи тестов — симптомы неудачных проектных решений в тестовом коде и отклонения от оптимального способа писать тесты, организовывать их и выстраивать их взаимодействие друг с другом.
По мнению некоторых исследователей, большинство flaky-тестов причинно связано с запахами тестов и может быть исправлено применением рефакторинга.
Если хочется перейти от словаря терминов к практическим привычкам, курс «QA Automation Engineer» собирает базу по Java-автотестам: UI/API, Selenium/Selenide, JUnit, Cucumber, Maven и работа с тестовой инфраструктурой. Отдельный упор — на паттерны PageObject/ScreenPlay и навыки, которые снижают flakiness, а не маскируют её ретраями.
Чтобы узнать больше о формате обучения и задать вопросы экспертам, приходите на бесплатные демо-уроки:
15 января, 20:00. «Mutation Testing: как я узнал, что мои тесты с 95% coverage ничего не проверяют». Записаться
21 января, 20:00. «Особенности Kotlin в UI и API тестировании». Записаться
22 января, 19:00. «Искусство интервью в QA: оценка кандидатов без ошибок». Записаться
