Недавно прочитала исследование про flaky тесты, и оно оказалось интереснее, чем я ожидала. Вопрос у авторов был довольно простой. Можно ли показать модели только код теста и попросить определить, flaky он или нет?
На уровне интуиции идея звучит вполне нормально. У flaky тестов и правда часто бывают заметные признаки. Где‑то тест завязан на порядок элементов, где‑то есть сомнительные ожидания, где‑то всплывает работа со временем, случайностью или состоянием. Кажется, что модель вполне могла бы научиться такие вещи замечать. Но чем дальше читаешь статью, тем яснее становится, что проблема тут глубже. И дело не только в качестве самих моделей.
Почему подход выглядел многообещающим
Интерес к такой задаче понятен. Flaky тесты всем портят жизнь. Они шумят в CI, ломают доверие к автотестам, заставляют тратить время на падения, которые потом могут просто не повториться. Перезапускать тесты много раз можно, но это дорого и не всегда удобно. Поэтому идея заранее понимать, что тест подозрительный, выглядит очень заманчиво.
Flaky‑тесты действительно часто оставляют следы в коде. Например, тест может полагаться на неупорядоченные коллекции, строковое сравнение сериализованного JSON, sleep, хрупкие проверки, завязку на время, shared state и прочие конструкции, которые давно воспринимаются как рискованные. Ранние работы по этой теме как раз строились на предположении, что у flaky‑тестов есть характерный словарь и что по нему можно обучить классификатор.
Тем более что раньше на эту тему уже были работы с довольно красивыми результатами. В одном из ранних исследований на DeFlaker‑бенчмарке даже сообщался MCC 0.9, то есть картинка выглядела очень обнадёживающей. Отсюда и ощущение, что направление перспективное. Но в этой новой статье как раз хорошо показано, почему к таким цифрам стоит относиться осторожно. Модель может не понимать flaky поведение как явление, а просто цепляться за слова, шаблоны и особенности конкретного датасета. Если так, то на знакомых примерах метрики будут выглядеть хорошо, а в реальной жизни всё быстро развалится.
И авторы это не просто предполагают, а довольно убедительно показывают. Они разбирают предыдущие подходы и обращают внимание на неприятную вещь. В некоторых наборах данных можно получить очень приличные метрики, даже если модель по сути учится не распознавать flaky тесты, а узнавать локальные паттерны исправлений. То есть она ловит не проблему, а след от того, как эту проблему когда‑то уже чинили. Для практики это, конечно, совсем не то, что хотелось бы получить.
Что показало само исследование
Авторы взяли три LLM, два датасета и несколько вариантов промтов. Проверка была вполне добросовестная. Не было такого, что модели дали один кривой промпт, а потом объявили идею неработающей. Им пробовали и обычный zero shot, и вариант с рассуждением, и few shot с примерами. Но общая картина всё равно вышла слабой. Модели местами показывали результаты чуть лучше случайного угадывания, но до чего‑то действительно надёжного там очень далеко. На одном из датасетов ни один подход даже не смог обойти совсем грубые примеры, в которых все тесты просто считаются flaky. Это уже само по себе много о чём говорит.
Но самое важное в статье, по‑моему, не эти цифры сами по себе. Авторы сделали ещё одну полезную вещь. Они вручную посмотрели часть примеров и попытались ответить на более неприятный вопрос. А можно ли вообще уверенно решать такую задачу, если перед тобой только код теста?
И вот здесь начинается самое интересное. Иногда ответ да. Бывают случаи, где источник проблемы действительно лежит на поверхности. Например, тест ожидает фиксированный порядок там, где порядок не гарантирован. Или сравнивает строковое представление JSON так, будто сериализация обязана всегда выдавать одинаковый порядок полей. Такие вещи можно увидеть глазами, и модель теоретически тоже могла бы их подхватывать, почему нет?
Но очень часто причина flaky поведения находится не в самом тесте. Она может жить во вспомогательной функции, в настройках, в скрытом состоянии, в коде под тестом, в сайд‑эффекте, который вообще не виден из тела тестового метода. И вот в таких ситуациях задача резко меняется, потому что дело не в ошибке модели, ей просто неоткуда взять ключевую информацию. По сути, она начинает гадать. И человек в похожей ситуации тоже не выглядит всемогущим. В статье это хорошо видно по ручной оценке. Даже люди не всегда способны определить, что по одному тесту можно уверенно понять, flaky он или нет.
Также авторы отдельно посмотрели, насколько стабильно модели отвечают при повторных прогонах. С этим тоже не всё хорошо, на одинаковом входе результаты заметно плавают во многих случаях.
Какие здесь могут быть выводы, кроме того что LLM опять чего‑то не могут?
Мне эта статья понравилась не потому, что она в очередной раз говорит, что LLM чего‑то не могут. Это уже само по себе давно не новость. Она интересна другим. Она очень хорошо показывает границы задачи.
В некоторых случаях идея искать моргающие тесты только по коду может сработать, если проблема в тесте торчит наружу, но в большом количестве случаев она слишком узкая. И это, на мой взгляд, самый полезный вывод. Потому что проблема, по сути, не в модели, а в отсутствии информации, и здесь уже нельзя рассказать очередную историю про то, что нужно взять модель побольше.
Если и строить подобные инструменты, то, наверное, вокруг более широкого контекста. И передавать в модель историю изменений, хелперы, результаты дополнительного поиска релевантных фрагментов. Об этом, кстати, авторы тоже говорят и упоминают RAG и агентные подходы как более реалистичное продолжение работы.
Если после разбора flaky‑тестов хочется посмотреть на ИИ в тестировании с более практической стороны, обратите внимание на два открытых урока OTUS:
-
21 мая, 20:00 — «ИИ как ассистент QA: пишем API‑тесты с нуля». Записаться
Разберем, как использовать ИИ при подготовке API‑тестов: от первых сценариев до более осмысленной автоматизации. -
16 июня, 20:00 — «ИИ в автотестах: помощник или угроза?». Записаться
Поговорим о том, где ИИ действительно помогает в автоматизированном тестировании, какие риски создаёт и почему слепо доверять модели в тестах опасно.
Оба урока бесплатные и проходят в рамках онлайн‑курсов. Их ведут преподаватели‑практики, поэтому можно будет задать вопросы, обсудить реальные кейсы и посмотреть, как тема ИИ в тестировании выглядит не в теории, а в инженерной работе.
📌 А чтобы не пропускать новые разборы, исследования и практические материалы по тестированию, разработке и ИИ в IT — подписывайтесь на блог.
Автор: SiYa_renko
