Блог

Сравнение тестовых запусков в TMS| ТестОпс

2026-08-14 14:00

Сравнение тестовых запусков: как понять, это регрессия, flaky-тест или изменение набора

Перед релизом команда получает два похожих результата: в контрольном запуске — 1 000 тестов, в новом — тоже 1 000. Успешных стало меньше. В чате уже пишут: «Нашли регрессию».
Однако сравнение показывает другую картину. В обоих запусках есть только 982 общих теста. Ещё 18 остались только в контрольном, а 18 других появились только в новом. Среди общих тестов статус изменился у 12. Теперь у команды не один вопрос «почему стало больше падений?», а три проверяемых вопроса: что изменилось в составе, какие общие тесты сменили статус и чем вызвана эта смена.
Короткий ответ: подобное сравнение даёт представление о том, как поменялись результаты одних и тех же тестов и состав набора. Переход общего теста из «Успешного» в «Неуспешный» — кандидат в регрессию, но не доказательство. Отсутствие теста в одном запуске говорит об изменении состава. Чередование статусов — признак возможной нестабильности, который проверяют по истории, повторным попыткам, окружению, логам и артефактам.

Что именно показывает сравнение тестовых запусков

Тестовый запуск фиксирует результаты и контекст проверки: окружение, связанные задачи, время, джобы и другие метаданные. Подробнее модель разобрана в статье «Тестовые запуски: создание, статусы, результаты, CI/CD и анализ прогонов».
Сравнение запусков в ТестОпс устроено так: столбцы соответствуют запускам, строки — тестам, ячейки — результатам выполнения. По ID теста открывается связанный тест-кейс, по названию — детальное сравнение, по ID запуска — его карточка. С точки зрения QA это не только способ найти регрессию, но и возможность отделить смену статусов от изменения набора тестов или признаков нестабильности.
Так сравнение двух тестовых запусков в ТестОпс локализует изменение, но не определяет причину автоматически. Анализ результатов тестирования продолжается проверкой контекста, шага падения, ошибки, логов, артефактов, версии продукта и инфраструктуры.

Как выбрать корректный контрольный запуск

Контрольный, или базовый, запуск — аналитическая точка отсчёта, а не автоматически назначаемый статус. Несопоставимая база может привести к ложному выводу о регрессии или скрыть проблему.
Перед сравнением следует проверить 5 условий:
  1. Одинаковая цель. Полный регресс сравниваем с полным регрессом, smoke-набор — со smoke-набором.
  2. Стабильная точка. Результаты должны быть полностью загружены и разобраны: незавершённый запуск меняется во время анализа.
  3. Сопоставимый код. Фиксируем сборку, ветку, коммит и ожидаемые изменения продукта.
  4. Сопоставимые условия. Учитываем браузер и его версию, ОС, устройство, стенд, данные и конфигурацию. Если окружения различаются, результаты не следует безоговорочно объединять в одну метрику: сначала нужно проверить, не связано ли изменение статуса именно с окружением. В ТестОпс окружение входит в контекст результата теста.
  5. Сопоставимый отбор. Проверяем тест-план, теги, suite, фильтры, версию тестового кода и discovery. Одинаковое количество тестов не гарантирует одинаковый набор.
Важно исключить известный массовый сбой CI, стенда или внешнего сервиса. Если идеальной базы нет, нужны два-три соседних стабильных запуска с указанием ограничения анализа.

Какие режимы сравнения есть в ТестОпс

Режимы отвечают на разные диагностические вопросы:
Режим
Что показывает
На какой вопрос отвечает
Все
Тесты из выбранных запусков
Как выглядит общая картина сравнения?
Различия
Тесты, присутствующие не во всех выбранных запусках
Изменился ли состав тестов?
Пересечения
Тесты, присутствующие во всех выбранных запусках
Какие тесты образуют общий сопоставимый набор?
Только изменения статуса
Тесты, у которых различаются статусы результатов в выбранных запусках
У каких тестов изменился результат выполнения?
Фильтры по владельцу и кастомным полям помогают сузить список до компонента, уровня тестирования или команды.
Практический порядок анализа такой:
  1. Открываем «Различия» и проверяем состав.
  2. Переходим к «Пересечениям», чтобы выделить общую часть.
  3. На сопоставимой части включаем «Только изменения статуса».
  4. Сужаем список фильтрами по владельцу и кастомным полям.
  5. Открываем детали изменившихся результатов и сопоставляем ошибки, шаги и артефакты.
В нашем примере «Различия» находят по 18 тестов только в каждой точке: проверяем план, теги, переименование, маппинг и discovery. «Пересечения» оставляют 982 общих теста. Только внутри этой части 12 смен статуса становятся корректным входом в диагностику.

Как отличить регрессию, flaky-тест и проблему инфраструктуры

По официальной документации ТестОпс, у упавших тестов: есть несколько статусов:
  1. «Неуспешный» фиксирует неожиданный результат при корректно выполненном тесте;
  2. «Сломанный» показывает, что сам тест не довёл проверку до конца, и здесь возможны две трактовки: проблема в тесте или действительно в продукте; поэтому такой статус нельзя автоматически считать дефектом приложения;
  3. «Пропущенный» означает, что тест был в плане, но не был выполнен;
  4. «Неизвестный» чаще всего говорит о том, что результат не был классифицирован, например из-за сбоя адаптера Allure, но это не единственное возможное объяснение.
Однако сам по себе ни один статус не заменяет расследование. Наблюдение следует использовать как начальную гипотезу:
Что видно при сравнении
Рабочая гипотеза
Что проверить до вывода
Общий тест: «Успешный» → «Неуспешный»
Возможная регрессия
Изменение продукта, одинаковые условия, шаг падения, логи, артефакты, воспроизводимость
Тест отсутствует в одном из запусков
Изменение состава
Историю, повторные попытки, тайминги, тестовые данные, зависимости и состояние окружения
Одновременно падают несвязанные тесты
Общая проблема инфраструктуры или окружения
Тест-план, теги, suite, фильтры, discovery, исключения, переименование и маппинг
«Неуспешный» → «Успешный»
Исправление или невоспроизведённый симптом
CI-джобу, ноду, сеть, стенд, внешний сервис, время и общий текст ошибки
«Сломанный» → «Неуспешный»
Изменилась природа сбоя
Код теста, адаптер, данные и момент, до которого теперь доходит сценарий
Количество тестов одинаковое, но «Различия» не пусты
Подмена части набора
Какие тесты ушли и пришли, почему сохранился общий счётчик
Появились «Неизвестные» результаты
Результат передан или завершён некорректно
Адаптер, формат результатов, закрытие запуска и логи CI

Когда смена статуса похожа на регрессию

Сильный кандидат в регрессию — общий тест, который стабильно проходил, после изменения продукта стал «Неуспешным» в том же окружении и воспроизводится с тем же отклонением. Связь с коммитом, одинаковый шаг падения и подтверждение на повторе усиливают гипотезу.
В TMS ТестОпс важно проверить и альтернативы: не изменились ли тестовые данные, версии зависимостей или конфиги окружения; не устарели ли ассерты; не является ли падение следствием массового инфраструктурного сбоя. До подтверждения дефекта следует помечать его именно как «кандидат в регрессию».

Когда это напоминает flaky-поведение

Flaky-тест, или нестабильный автотест, при одинаковых условиях получает то успешный, то неуспешный результат. Чередование статусов между запусками — сигнал, но не диагноз: условия могли отличаться, а ошибка — быть инфраструктурной.
При этом не стоит смешивать оба механизма. Сравнение тестовых запусков в ТестОпс отражает изменения между прогонами, но само по себе не определяет их причину. Если после перезапусков в рамках одного запуска тест получил разные статусы, появляется отметка «Флаки?», а подтверждённая нестабильность обозначается как «Флаки».
Аналогичная смена результатов между независимыми запусками может быть связана с flaky-поведением, однако альтернативными объяснениями остаются изменения тестовых данных, конфигурации, зависимостей, стенда или CI-инфраструктуры. Подробнее — в документации и статье о карантине и retry policy.

Когда сначала нужно проверить инфраструктуру

Инфраструктурный сбой часто затрагивает несвязанные тесты в одно время. Ищите общую ноду, стенд, сетевой тайм-аут, внешний сервис, setup или стектрейс. Массовость лишь задаёт первую проверку. «Сломанный» нельзя автоматически переводить в «инфраструктура»: тест просто не выполнил задуманную проверку.

Как превратить сравнение в воспроизводимый регламент

Закрепляем короткий регламент, чтобы разбор не зависел от конкретного инженера:
  1. Записываем ID запусков, цель, сборку, ветку и окружение; проверьте полноту результатов и инциденты CI.
  2. Фиксируем общее количество, пересечение и различия в обе стороны.
  3. Разбераем смены статусов на общем ядре и классифицируйте гипотезы.
  4. Прикладываем результат, ошибку, лог, артефакт, коммит или дефект.
  5. Назначаем владельца, действие и срок; отметьте влияние на релиз.
Минимальный отчёт о регрессе можно собрать в одной таблице:
Блок
Что зафиксировать
Контекст
ID запусков, сборка, ветка, окружение, цель
Состав
Общее количество, пересечение, тесты только в каждой точке
Динамика
Переходы статусов общих тестов
Диагностика
Гипотеза, доказательства, недостающие данные
Действие
Владелец, следующий шаг, срок, влияние на релиз
Так красный счётчик превращается в воспроизводимый отчёт: видно, какой набор проверяли, что изменилось и на чём основано решение.

Когда нужен перезапуск упавших автотестов

Если CI/CD-пайплайн умеет запускать только весь набор, ради 10 упавших тестов приходится снова выполнять все 1 000 и ждать полный прогон.
ТестОпс позволяет выбрать отдельные неуспешные автотесты и отправить их на выборочный перезапуск в CI-системе., не выполняя весь набор заново. Результаты перезапуска учитываются в текущей статистике, а исходные попытки остаются доступными для сравнения. Повторный сбой усиливает гипотезу о проблеме, тогда как успешный повтор может указывать не только на исправление, но и на нестабильность теста или внешние условия. В виджете «Перезапуски тестов» доступны прошлый и текущий статусы — история проверки не теряется.
Перезапуск не определяет первопричину, но даёт новое наблюдение в том же контексте. Как выбрать падения, что происходит между ТестОпс и CI/CD и как читать повторную попытку — тема следующего материала.

Главное

Сравнение тестовых запусков — не кнопка «найти регрессию». Оно отделяет изменения состава, изменения результатов общих тестов и гипотезы, которые требуют проверки по окружению, истории, логам и артефактам.
Начинайте с сопоставимой контрольной точки, затем проверяйте «Различия», выделяйте «Пересечения» и разбирайте изменения статусов. Так команда переходит от агрегата к проверяемой гипотезе и обоснованному решению о релизе.