
Исследование считает, что мутации кода ИИ помогают разработчикам быстрее улавливать ошибки
4 июня 2025 г.Авторы:
(1) Бо Ван, Университет Пекин Цзиотонг, Пекин, Китай (wangbo_cs@bjtu.edu.cn);
(2) Mingda Chen, Пекинский университет Цзиотонга, Пекин, Китай (23120337@bjtu.edu.cn);
(3) Youfang Lin, Пекинский университет Цзиотонг, Пекин, Китай (yflin@bjtu.edu.cn);
(4) Майк Пападакис, Университет Люксембурга, Люксембург (michail.papadakis@uni.lu);
(5) Цзе М. Чжан, Королевский колледж Лондон, Лондон, Великобритания (jie.zhang@kcl.ac.uk).
Таблица ссылок
Аннотация и1 Введение
2 предыстория и связанная с ним работа
3 Учебный дизайн
3.1 Обзор и исследования исследований
3.2 Наборы данных
3.3 генерация мутаций через LLMS
3.4 Метрики оценки
3.5 Настройки эксперимента
4 Результаты оценки
4.1 RQ1: производительность по стоимости и юзабилити
4.2 RQ2: сходство поведения
4.3 RQ3: воздействие различных подсказок
4.4 RQ4: воздействие различных LLMS
4.5 RQ5: основные причины и типы ошибок некомпилируемых мутаций
5 Обсуждение
5.1 Чувствительность к выбранным настройкам эксперимента
5.2 Последствия
5.3 Угрозы достоверности
6 Заключение и ссылки
АБСТРАКТНЫЙ
Вопрос о том, как генерировать мутации высокопроизводительности, которые будут использоваться в целях тестирования, образует ключевую проблему в литературе по тестированию мутаций. Крупные языковые модели (LLMS) показали большой потенциал в задачах, связанных с кодом, но их полезность в тестировании на мутации остается неисследованной. С этой целью мы систематически исследуем производительность LLM в генерации эффективных мутаций W.R.T. к их удобству использования, потенциалу обнаружения неисправностей и отношениями с реальными ошибками. В частности, мы проводим крупномасштабное эмпирическое исследование с участием 4 LLM, в том числе как модели с открытым, так и с закрытым источником, и 440 настоящих ошибок на двух тестах Java. Мы обнаруживаем, что по сравнению с существующими подходами LLM генерируют более разнообразные мутации, которые поведененно ближе к реальным ошибкам, что приводит к примерно на 18% более высоким обнаружению неисправностей, чем текущие подходы (то есть 87% против 69%) в недавно собранном наборе ошибок, намеренно выбранных для оценки подходов, основанных на обучении, I.E.E., MITIG-потенциальные данные. Кроме того, мы исследуем альтернативные оперативные инженерные стратегии и коренные причины некомпилозных мутаций, производимых LLMS, и предоставляем ценную информацию для использования LLM в контексте тестирования на мутации.
1 Введение
Тестирование на мутации является одним из наиболее эффективных методов тестирования программного обеспечения [17, 18, 27, 33, 59]. Он выполняется путем создания вариантов программы путем внесения простых синтаксических изменений (то есть мутаций) в исходном коде программы происхождения (то есть мутантов). Эти варианты формируют цели тестирования, в некотором смысле, требуя тестов, чтобы вызвать различные поведения на оригинальных и мутантных программах. Мутант называется убитым или живым в зависимости от того, приводит ли выполнение теста к другой результатам программы (наблюдаемое поведение) из исходной программы или нет. Доля убитых мутантов по всему набору мутантов образует метрику адекватности теста, которая называется оценкой мутации.
Поскольку мутации являются целью тестирования, эффективность метода сильно зависит от набора мутантов, которые используется. Традиционные методы используют простые синтаксические преобразования (правила), называемые операторами мутаций, которые вводят синтаксические изменения в каждом месте кода, которое они применяют [33, 59]. Мы называем эти подходы в качестве подходов, основанных на правилах.
К сожалению, подходы, основанные на правилах, производят большое количество избыточных мутантов, то есть мутантов, которые не способствуют процессу тестирования [5, 57] и, таким образом, усугубляют вычислительные накладные расходы метода, а также человеческие усилия, связанные с изучением живых мутантов. Чтобы решить эту проблему, исследователи используют подходы к глубокому обучению для формирования операторов мутаций на основе истории проекта [62, 70, 73], с надеждой, что они будут создавать мало, но эффективные мутации. Хотя интересно, эти подходы не позволяют производить эффективные мутации [56], возможно, из -за того, что они обучаются на несколько экземпляров данных.
Тем не менее, вопрос о том, какие мутанты следует использовать при выполнении тестирования на мутации, остается открытым из -за следующих проблем: (1) формирование эффективных мутаций. Чтобы быть эффективным, мутации должны быть синтаксически правильными, что не имеет значения большинства существующих методов, основанных на обучении, и, вероятно, раскрывает ошибку [10, 80], то есть имеет хороший потенциал для соединения с реальными разломами. Хотя существующие методы эффективны, все еще существует значительное место для улучшения [15]. (2) формирование природных мутаций. Мутации должны соответствовать естественным моделям и практикам кодирования, чтобы они соответствовали ожиданиям разработчиков, то есть заставляя их чувствовать, что их стоит решить [7]. Способен гарантировать, что мутированный код не только синтаксически правильный, но и хорошо согласуется с реалистичными, общими моделями кодирования и практиками, наблюдаемыми среди разработчиков. (3) формирование разнообразных и убийственных мутаций. Определение того, является ли мутация эквивалентной, нерешительно [9], что делает трудности избегать генерации эквивалентных мутантов, что приводит к плохой масштабируемости и отходам ресурсов [58, 76, 86, 88]. В то же время мутации должны быть разнообразными и охватывать весь спектр кодового и программного поведения.
Чтобы решить эти проблемы, мы стремимся использовать модели с крупным языком (LLMS), которые были обучены большим коде и могут создавать человеческий код [11]. Следуя существующим исследованиям [26, 49, 65], мы разработали подсказку по умолчанию, которая содержит инструкции по заданиям, элемент кода, который должен быть мутирован, соответствующий код метода и несколько выстрелов, выбранных из реальных ошибок. Мы провели крупномасштабную оценку с участием 4 LLM, 2 коммерческих коммерческих и 2 с открытым исходным кодом, 440 реальных ошибок из двух контрольных показателей Java, то есть Defects4j [37] и концепции [82] и сравнивали с существующими методами и инструментами.
Наша оценка включает в себя как количественный, так и качественный анализ для мутаций, полученных LLMS, сравнивая их с существующими подходами для оценки их стоимости и эффективности. Кроме того, мы изучаем, как различные быстрые инженерные стратегии и LLMS (то есть GPT-3.5-Turbo [4], GPT-4-Turbo, Codellama-13Binstruct [64] и Starchat-16B [45]) влияют на эффективность задачи. Более того, мы анализируем основные причины и типы ошибок для некомпиляционных мутантов, генерируемых LLMS.
Наши результаты показывают, что лучшей моделью для генерации мутантов является GPT-4, поскольку она превосходит другие LLMS во всех используемых метриках, то есть, производит менее эквивалентные мутанты, мутантов с более высоким потенциалом обнаружения неисправностей, а также более высокую связь и семантическое сходство с реальными разломами. GPT-3.5 является вторым лучшим с точки зрения потенциала обнаружения неисправностей, что приводит к обнаружению 96,7% ошибок в Defects4J и 86,7% в проведениях. Из остальных методов Major является лучшим, с потенциалом выявить 91,6% ошибок в Defects4J и 68,9% в проведениях, что указывает на преимущество в размере приблизительно 18% для GPT на проводниках, которые являются вновь и невидимым набором данных.
Другое интересное открытие нашего анализа относится к разнообразию мутантов (измерено с точки зрения недавно введенных типов узлов AST). В частности, наши результаты показывают, что GPT демонстрируют наибольшее разнообразие, вновь вводя 45 различных типов узлов AST, в отличие от 2, используемых традиционными подходами, такими как основные, и подчиняются все существующие подходы, что указывает на гораздо лучшую контекстуализацию подхода на основе LLM.
Мы также проанализировали мутации, генерируемые GPT, которые не могут компилировать, общую проблему с мутациями на основе обучения, и обнаружили, что они попадают в 9 типов ошибок компиляции с использованием неизвестных методов, а типы структурных разрушений кода являются наиболее распространенными. Этот вывод указывает на то, что будущие подходы могут сосредоточиться на направлении LLMS в выборе правильных вызовов метода при мутации.
Мы завершили наш метод в инструмент мутации под названиемКумо, инструмент генерации мутаций на основе LLM для Java. Основываясь на экспериментальных данных, мы также создали набор данных, который содержит высококачественные мутанты, сгенерированные LLM, которые можно использовать не только при тестировании на мутации, но и в других приложениях для получения ошибок, таких как локализация неисправностей и прогнозирование неисправностей. Реализация Kumo и экспериментальные данные доступны для открытой науки [1].
Таким образом, наша статья вносит следующий основной вклад:
• Мы исследуем применимость LLMS в тестировании на мутации. Мы проводим обширные и подробные сравнительные эксперименты для оценки LLMS с существующими инструментами/методами. Наши результаты показывают, что модели GPT преуспевают в создании мутаций, которые внимательно имитируют реальные ошибки.
• Мы сравниваем различные подсказки и обнаруживаем это несколько выстрелов с подходящим контекстным архивами кода.
• Мы анализируем типы ошибок некомпилируемых мутаций и выясняем, что вызов метода и оценка членов с большей вероятностью приведут LLMS для генерации некомпиляционных мутаций.
• Мы строим высококачественный набор данных Java-мутаций, который включает в себя анализируемые эквивалентные мутанты вручную.
Эта статья есть
Оригинал