Сравнение тестовых запусков: как понять, это регрессия, flaky-тест или изменение набора
Перед релизом команда получает два похожих результата: в контрольном запуске — 1 000 тестов, в новом — тоже 1 000. Успешных стало меньше. В чате уже пишут: «Нашли регрессию».
Однако сравнение показывает другую картину. В обоих запусках есть только 982 общих теста. Ещё 18 остались только в контрольном, а 18 других появились только в новом. Среди общих тестов статус изменился у 12. Теперь у команды не один вопрос «почему стало больше падений?», а три проверяемых вопроса: что изменилось в составе, какие общие тесты сменили статус и чем вызвана эта смена.
Короткий ответ: подобное сравнение даёт представление о том, как поменялись результаты одних и тех же тестов и состав набора. Переход общего теста из «Успешного» в «Неуспешный» — кандидат в регрессию, но не доказательство. Отсутствие теста в одном запуске говорит об изменении состава. Чередование статусов — признак возможной нестабильности, который проверяют по истории, повторным попыткам, окружению, логам и артефактам.
Что именно показывает сравнение тестовых запусков
Тестовый запуск фиксирует результаты и контекст проверки: окружение, связанные задачи, время, джобы и другие метаданные. Подробнее модель разобрана в статье «Тестовые запуски: создание, статусы, результаты, CI/CD и анализ прогонов».
Сравнение запусков в ТестОпс устроено так: столбцы соответствуют запускам, строки — тестам, ячейки — результатам выполнения. По ID теста открывается связанный тест-кейс, по названию — детальное сравнение, по ID запуска — его карточка. С точки зрения QA это не только способ найти регрессию, но и возможность отделить смену статусов от изменения набора тестов или признаков нестабильности.
Так сравнение двух тестовых запусков в ТестОпс локализует изменение, но не определяет причину автоматически. Анализ результатов тестирования продолжается проверкой контекста, шага падения, ошибки, логов, артефактов, версии продукта и инфраструктуры.
Как выбрать корректный контрольный запуск
Контрольный, или базовый, запуск — аналитическая точка отсчёта, а не автоматически назначаемый статус. Несопоставимая база может привести к ложному выводу о регрессии или скрыть проблему.
Перед сравнением следует проверить 5 условий:
- Одинаковая цель. Полный регресс сравниваем с полным регрессом, smoke-набор — со smoke-набором.
- Стабильная точка. Результаты должны быть полностью загружены и разобраны: незавершённый запуск меняется во время анализа.
- Сопоставимый код. Фиксируем сборку, ветку, коммит и ожидаемые изменения продукта.
- Сопоставимые условия. Учитываем браузер и его версию, ОС, устройство, стенд, данные и конфигурацию. Если окружения различаются, результаты не следует безоговорочно объединять в одну метрику: сначала нужно проверить, не связано ли изменение статуса именно с окружением. В ТестОпс окружение входит в контекст результата теста.
- Сопоставимый отбор. Проверяем тест-план, теги, suite, фильтры, версию тестового кода и discovery. Одинаковое количество тестов не гарантирует одинаковый набор.
Важно исключить известный массовый сбой CI, стенда или внешнего сервиса. Если идеальной базы нет, нужны два-три соседних стабильных запуска с указанием ограничения анализа.
Какие режимы сравнения есть в ТестОпс
Режимы отвечают на разные диагностические вопросы:
Фильтры по владельцу и кастомным полям помогают сузить список до компонента, уровня тестирования или команды.
Практический порядок анализа такой:
- Открываем «Различия» и проверяем состав.
- Переходим к «Пересечениям», чтобы выделить общую часть.
- На сопоставимой части включаем «Только изменения статуса».
- Сужаем список фильтрами по владельцу и кастомным полям.
- Открываем детали изменившихся результатов и сопоставляем ошибки, шаги и артефакты.
В нашем примере «Различия» находят по 18 тестов только в каждой точке: проверяем план, теги, переименование, маппинг и discovery. «Пересечения» оставляют 982 общих теста. Только внутри этой части 12 смен статуса становятся корректным входом в диагностику.
Как отличить регрессию, flaky-тест и проблему инфраструктуры
По официальной документации ТестОпс, у упавших тестов: есть несколько статусов:
- «Неуспешный» фиксирует неожиданный результат при корректно выполненном тесте;
- «Сломанный» показывает, что сам тест не довёл проверку до конца, и здесь возможны две трактовки: проблема в тесте или действительно в продукте; поэтому такой статус нельзя автоматически считать дефектом приложения;
- «Пропущенный» означает, что тест был в плане, но не был выполнен;
- «Неизвестный» чаще всего говорит о том, что результат не был классифицирован, например из-за сбоя адаптера Allure, но это не единственное возможное объяснение.
Однако сам по себе ни один статус не заменяет расследование. Наблюдение следует использовать как начальную гипотезу:
Когда смена статуса похожа на регрессию
Сильный кандидат в регрессию — общий тест, который стабильно проходил, после изменения продукта стал «Неуспешным» в том же окружении и воспроизводится с тем же отклонением. Связь с коммитом, одинаковый шаг падения и подтверждение на повторе усиливают гипотезу.
В TMS ТестОпс важно проверить и альтернативы: не изменились ли тестовые данные, версии зависимостей или конфиги окружения; не устарели ли ассерты; не является ли падение следствием массового инфраструктурного сбоя. До подтверждения дефекта следует помечать его именно как «кандидат в регрессию».
Когда это напоминает flaky-поведение
Flaky-тест, или нестабильный автотест, при одинаковых условиях получает то успешный, то неуспешный результат. Чередование статусов между запусками — сигнал, но не диагноз: условия могли отличаться, а ошибка — быть инфраструктурной.
При этом не стоит смешивать оба механизма. Сравнение тестовых запусков в ТестОпс отражает изменения между прогонами, но само по себе не определяет их причину. Если после перезапусков в рамках одного запуска тест получил разные статусы, появляется отметка «Флаки?», а подтверждённая нестабильность обозначается как «Флаки».
Аналогичная смена результатов между независимыми запусками может быть связана с flaky-поведением, однако альтернативными объяснениями остаются изменения тестовых данных, конфигурации, зависимостей, стенда или CI-инфраструктуры. Подробнее — в документации и статье о карантине и retry policy.
Когда сначала нужно проверить инфраструктуру
Инфраструктурный сбой часто затрагивает несвязанные тесты в одно время. Ищите общую ноду, стенд, сетевой тайм-аут, внешний сервис, setup или стектрейс. Массовость лишь задаёт первую проверку. «Сломанный» нельзя автоматически переводить в «инфраструктура»: тест просто не выполнил задуманную проверку.
Как превратить сравнение в воспроизводимый регламент
Закрепляем короткий регламент, чтобы разбор не зависел от конкретного инженера:
- Записываем ID запусков, цель, сборку, ветку и окружение; проверьте полноту результатов и инциденты CI.
- Фиксируем общее количество, пересечение и различия в обе стороны.
- Разбераем смены статусов на общем ядре и классифицируйте гипотезы.
- Прикладываем результат, ошибку, лог, артефакт, коммит или дефект.
- Назначаем владельца, действие и срок; отметьте влияние на релиз.
Минимальный отчёт о регрессе можно собрать в одной таблице:
Так красный счётчик превращается в воспроизводимый отчёт: видно, какой набор проверяли, что изменилось и на чём основано решение.
Когда нужен перезапуск упавших автотестов
Если CI/CD-пайплайн умеет запускать только весь набор, ради 10 упавших тестов приходится снова выполнять все 1 000 и ждать полный прогон.
ТестОпс позволяет выбрать отдельные неуспешные автотесты и отправить их на выборочный перезапуск в CI-системе., не выполняя весь набор заново. Результаты перезапуска учитываются в текущей статистике, а исходные попытки остаются доступными для сравнения. Повторный сбой усиливает гипотезу о проблеме, тогда как успешный повтор может указывать не только на исправление, но и на нестабильность теста или внешние условия. В виджете «Перезапуски тестов» доступны прошлый и текущий статусы — история проверки не теряется.
Перезапуск не определяет первопричину, но даёт новое наблюдение в том же контексте. Как выбрать падения, что происходит между ТестОпс и CI/CD и как читать повторную попытку — тема следующего материала.
Главное
Сравнение тестовых запусков — не кнопка «найти регрессию». Оно отделяет изменения состава, изменения результатов общих тестов и гипотезы, которые требуют проверки по окружению, истории, логам и артефактам.
Начинайте с сопоставимой контрольной точки, затем проверяйте «Различия», выделяйте «Пересечения» и разбирайте изменения статусов. Так команда переходит от агрегата к проверяемой гипотезе и обоснованному решению о релизе.
