Just-in-Time Catching Test Generation at Meta (Рубрика Engineering)

Исследователи запрещенной в России Meta написали интересный whitepaper про новый класс автотестов - regression catching tests. Стандартные hardening тесты должны проходить на текущем коде и страховать от будущих регрессий. Новые catching tests специально должны упасть на конкретном входящем diff и при этом пройти на родительской версии. Идея в том, чтобы не ждать, пока баг всплывет потом, а попытаться поймать его в момент ревью или CI, до вливания кода. Интересно, что сгенерированные авторами тесты должны детектировать регрессии не на основе implicit oracle (что реагирует на очевидные проблемы типа крашей), а на основе общего оракула (general oracle), который представляет собой правильное поведение, зачастую плохо определенное и только частично известное. Авторы отдельно различают weak catch и strong catch:

• Weak catch просто тот, что падает на текущей ревизии
• Strong catch означает, что тест действительно указывает (true positive) на реальную ошибку в ожидаемом поведении (на основе general oracle)
• Strictly weak catch - это false positive, что указывает на проблему с тестовым набором Основная задача в том, чтобы научиться определять, что weak catch на самом деле является strong catch. Это интересно, так как LLM используется не как еще один генератор unit-тестов ради покрытия, а как часть системы раннего перехвата регрессий. В Meta этот контур запускается на высокорисковых diffs (аналог PRs в GitHub) и работает на системах в сотни миллионов строк кода и целится именно в тяжелые, дорогие ошибки, а не в косметические поломки.

Основные результаты статьи присустствуют прямо в абстракте (первой части любой статьи). Собственно, цель была в том, чтобы победить замедление разработки из-за false positive тестов. Авторы проанализировали 22,126 сгенерированных тестов и показали, что

• Code-change-aware методы улучшают генерацию кандидатов, ловящих проблемы в 4 раза по сравнению с обычными hardening tests и на в 20 раз по сравнению с случайно упавшими тестами
• Для борьбы с false positives авторы использовали rule-based and LLM-based ассессоры. Эти подходы уменьшают нагрузку на людей на 70%
• Inferential statistical analysis показывает, что human-accepted code changes имеют значительно больше false positives, а human-rejected changes имеют больше true positives
• Авторы сообщают о 41 candidate catches на инженере, 8 из которых true positives, а 4 из которых могли привести к значительным проблемам на проде, если бы их не поймали

При этом ложные тревоги, по словам авторов, обычно закрывались за минуты и почти не били по developer velocity. Авторы при этом не перегибают палку: они прямо пишут, что выборка пока слишком маленькая, чтобы делать слишком сильные научные выводы о доле тяжелых багов. Но они отмечают, что этот подход масштабируем, применим в индустрии и позволяет предотвращаться серьезные проблемы

Главный вывод для меня такой: это не paper про "магическую автоматизацию QA", а paper про рабочий инженерный контур. LLM + мутационное тестирование + дешевый human-in-the-loop уже дают способ спорить с incoming diff’ом и задавать автору очень полезный вопрос: "ты точно хотел изменить поведение именно так?". В следующих сериях авторы планируют добавить лучшее восстановление намерения изменения + брать более богатый контекст diff’а и прийти к более уверенному отделению weak catch от strong catch.

#AI #QA #Engineering #Whitepaper #Software #LLM #DevOps