Дайджест мутационного тестирования за июнь 2026 года.

Самые интересные июньские новости о мутационном тестировании сводятся к одному правилу: используйте мутационное тестирование как независимого судью, но не поклоняйтесь судейской оценке.

Версия на 30 секунд:

1. CDBench показал, как часто атакующие и защищающиеся большие языковые модели (LLM) ошибаются; SMART продемонстрировал, что генерацию мутантов можно улучшить, используя похожие реальные ошибки в качестве примеров и дообучая модель.
2. Масштабное исследование пробелов в поведении показало, что за многими идеальными мутационными оценками скрывается непроверенное ожидаемое поведение.
3. Появились новые инструменты мутационного тестирования для Kotlin, Julia, Ruby и Haskell, а зрелые инструменты в основном устраняли зависания и проблемы с областью анализа и совместимостью. Эффектно? Нет. Полезно? Чрезвычайно.

ИИ получил независимого судью — а оценка прошла аудит🔗

CDBench превращает мутационное тестирование в игру: одна LLM создаёт мутанта, другая пишет тест, который должен его убить. На десяти Java-классах, почти не имевших зависимостей, моделям часто засчитывали поражение за недопустимые ответы; кроме того, они создавали мутантов-дубликатов и мутантов, предположительно эквивалентных по поведению. Эквивалентность выводилась из тестов, а не доказывалась. Дополнительные рассуждения сильнее помогали защите, чем атаке.

Это небольшой бенчмарк, и защищающаяся модель видит мутанта. Но когда противник меняется, готовых ответов для заучивания становится меньше.

SMART, опубликованный 30 июня после мартовского препринта, выбрал оптимистичный путь. Подбор похожих реальных ошибок в качестве примеров, сокращение объёма показанного модели кода и дообучение повысили взвешенный показатель генерации мутаций — долю запрошенных мутаций, которые удалось успешно разобрать, — с 42,89% до 65,6%. Та же комбинация подняла взвешенную долю обнаружения реальных ошибок с 57,86% у более ранней системы LLMut до 92,61%. Для Java результат сильный, но это не всеобщий повод для триумфа: некорректные, дублирующиеся и эквивалентные мутанты — всё те же старые гремлины, только теперь с бюджетом на GPU.

Затем последовал неловкий разбор работы судьи. Авторы Beyond Coverage and Kill Scores извлекли 20 729 ожидаемых вариантов поведения из 8 922 Java-методов. По данным исследования, 17,5% из них не проверялись, а пробел оставался у 29,6% методов с идеальной мутационной оценкой.

Пробел здесь — это ожидаемое поведение, выведенное из документации и исходного кода, которое не проверяет ни один тест. Точность экстрактора составила 93,1%, поэтому ни его результат, ни идеальная мутационная оценка не являются абсолютной истиной. Июньский комментарий Наоки Тацуми точно передал новизну: покрытие требований известно давно; ново то, что LLM позволяют измерить соответствие между требованиями и тестами.

Quantum Mutant Equivalence via Transpilation борется с шумом в оценке: исходную и мутировавшую схемы одинаково компилируют, а затем сравнивают их представления в OpenQASM — текстовом формате описания квантовых схем. Метод распознал 32,1% выживших мутантов, чья эквивалентность уже была известна, без единого ложноположительного результата на исследованных данных: безопасная метла, а не волшебный пылесос.

На практике проявилась та же закономерность. QuantumVerifi сообщил о долях убитых мутантов в собственных испытаниях: 62,5% на выбранном коде веб-фреймворка Gin для Go и 85% на выбранном коде Express для JavaScript, без учёта сбоев базового прогона. Эти числа относятся к сгенерированным тестам на выбранном коде, а не к полным тестовым наборам проектов. Руководство CircleCI предлагает поручать CI-агентам разбор выживших мутантов, а «30-секундная мутационная проверка» меняет одно условие или возвращаемое значение, чтобы выяснить, заметят ли это тесты, написанные ИИ. Схема та же: сначала сгенерировать, затем проверить на прочность — модель больше не оценивает собственную работу.

В одном описанном самим практиком случае с mutmut добавление 30 тестов повысило оценку с 56,5% до 59,9%. Затем автор вручную классифицировал 218 выживших как нерелевантных, фактически эквивалентных или некорректных; в большинстве случаев менялся регистр в журналах и сообщениях об ошибках. Здесь разбор результатов оказался полезнее, чем погоня за красивой оценкой.

Новые инструменты расширили карту, зрелые — сгладили процесс🔗

В июне состоялись четыре запуска, за которыми стоит следить:

Экспериментальную часть списка открывает неофициальный LLM-мутатор для StrykerJS, который во время выполнения меняет неподдерживаемый внутренний API. К нему добавились решения для Go/CI (Cervo Mutants), наборов для оценки LLM (muteval), MoonBit (moon_mutest), оркестрации пул-реквестов (Marmorkrebs), мутационной проверки теорем Lean и доказательств на Rust, написанных для Kani. Пробовать есть что; подтверждений работы в продакшене пока мало.

Зрелые инструменты дали полезный контрапункт:

• Java-инструмент PIT 1.25.4 добавил настраиваемое число знаков после запятой в отчётах; 1.25.5 исправил обнаружение тайм-аутов в однопоточном режиме.
• .NET-инструмент Stryker 4.15.0 улучшил компиляцию, определение языка и работу с процессами; Scala-инструмент Stryker4s 0.21.0 исправил привязку к исходному коду, расстановку средств сбора покрытия и очистку при завершении работы.
• Python-инструмент mutmut 3.6.0 позволил точнее задавать область анализа и исправил ряд ошибок. Выпуски PHP-инструмента Infection 0.33.3 и 0.34.0 улучшили работу с командной строкой и diff; Rust-инструмент cargo-mutants 27.1.0 добавил поддержку TOML 1.1.

Зрелые выпуски не принесли крупных новых операторов — только меньше зависаний, запуски с более узкой областью анализа, правильные позиции в исходниках и исправления совместимости. Именно от такой менее эффектной работы зависит переход от демонстраций к широкому внедрению.

Исследования вышли за пределы обычного прикладного кода🔗

SugBreaker мутировал корректные программы на Rust так, чтобы нарушать ограничения, лежащие в основе подсказок компилятора Rust rustc, и нашёл 12 ошибок компилятора, 11 из которых подтвердили или исправили. В статье о тестировании компиляторов использовались сохраняющие поведение преобразования, машинно проверенные в системе доказательства теорем Lean: если скомпилированные варианты ведут себя по-разному на одинаковых входах, это указывает на ошибку в компиляторе или цепочке инструментов. По словам автора, этот подход уже находил ошибки в инструментах для смарт-контрактов.

Работа с безопасностью стала конкретнее. Генерация тестов для глубоких нейронных сетей улучшила мутационную оценку при одинаковом размере тестового набора в трёх сценариях, но работала медленнее, а мутационную оценку по-прежнему использовала лишь как косвенный показатель способности находить реальные дефекты модели. Работа об автономном вождении предложила кратковременные сбои в сообщениях между модулями автомобиля, выведенные из анализа безопасности; идея перспективная, но пока это шестистраничное описание без реализации. STMutants опубликовал курируемый набор из 108 мутантов, отобранных из 11 программ промышленных контроллеров, — небольшой и частично составленный вручную, но полезный для обделённой вниманием экосистемы.

Теоретические исследования тоже дали полезный результат: Minimum Complete MR Subsets показал, что выбор метаморфных отношений — правил, связывающих входы с ожидаемыми выходами, — в рамках используемой авторами модели дефектов превращается в задачу покрытия множества: нужно найти минимальную группу, покрывающую каждого релевантного мутанта.

Ещё четыре более ранних проекта в июне были официально опубликованы или представлены; сами идеи в этом месяце новыми не были: QuanForge для квантовых нейронных сетей, QuMuS для пакетной обработки квантовых мутантов, MILE для систем, обучающихся на примерах из промпта, и выборочная мутация для глубокого обучения.

Обратное мутационное тестирование на EuroSTAR меняло тесты и отмечало ослабленные варианты, которые продолжали проходить. Доказательства ограничены аннотацией доклада, но ломать тест, чтобы убедиться в его способности упасть, — восхитительно грубая проверка здравого смысла.

Тихий реестр: патенты🔗

Не удалось подтвердить ни одного июньского патента, в формуле которого мутационное тестирование было бы центральной техникой. Ближе всего оказались US20260178464A1 компании Codium/Qodo, где заявлен более широкий анализ поведения, и CN122310549A, где мутация используется при исправлении уязвимостей. В обоих документах мутация служила вспомогательной инфраструктурой, а не новой основной техникой, заявленной в формуле изобретения.

Итог🔗

Июнь уточнил рабочее правило: генерируйте разнообразные варианты, проверяйте их независимо, анализируйте выживших мутантов с учётом контекста и стремитесь к полезному следующему шагу, а не к идеальной цифре.

ИИ способен создавать более качественных мутантов и писать более качественные тесты — а ещё выдавать некорректных мутантов, бессодержательные проверки и самоуверенные оценки собственной работы. Пробелы в поведении предостерегают от ещё одной метрики тщеславия; июньские выпуски удешевляют работу с полученным сигналом.

Конечно, это менее кинематографично, чем «тестирование изменилось навсегда». Зато гораздо вероятнее переживёт встречу с настоящей кодовой базой.