Дизайн эксперимента и метрики для тестирования на мутации с LLMS

Таблица ссылок

Аннотация и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 Заключение и ссылки

3.4 Метрики оценки

Чтобы оценить полезность мутаций, генерируемых LLM, мы должны определить набор метриков, которые их всесторонне оценивают. Поэтому мы разработали несколько категорий метрик, захватывающих разные

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

Чтобы лучше понять метрики, мы сначала иллюстрируем категории мутаций. Пусть все сгенерированные мутации были набором 𝐴, где LLMS может генерировать синтаксически неверные мутации, которые не могут пройти компиляцию. Таким образом, мы обозначаем компилируемые мутации как набор 𝐶. Обратите внимание, что набор 𝐶 содержит два типа мутаций, которые следует удалить, бесполезные мутации (обозначенные как 𝑈) и эквивалентные мутации (обозначаемые как 𝐸). Бесполезные мутации относятся к тем, которые идентичны исходному коду или другим мутациям. При тестировании на мутации идеальным набором мутаций для использования является из набора (𝐶 - 𝐸 - 𝑈), исключая эквивалентные мутации, которые не вносят вклад в обнаружение слабости тестов. Однако определение набора эквивалентных мутаций 𝐸 является неразрешимым, поэтому мы следуем общей практике и используем набор (𝐶 - 𝑈) в качестве практического приближения для проведения тестирования на мутации [21, 70, 89].

3.4.1 Метрики стоимости.Показатели затрат указывают время и экономические затраты в генерации мутаций, которые содержат следующие два показателя.

Среднее время поколения:Средняя продолжительность, необходимая для получения каждой мутации, измеряя эффективность подхода.

Стоимость за 1K Мутации:Средняя стоимость денег в долларах США для создания 1K -мутаций. Для GPT-3.5 и GPT-4 мы рассчитываем среднюю стоимость по использованию API, в то время как для моделей с открытым исходным кодом мы используем затраты на аренду облачных серверов.

3.4.2 Метрики удобства использования.Показатели юзабилити служат ключевыми показателями практической полезности генерируемых мутаций.

Скорость комбинации:Доля мутаций, которые успешно скомпилируются, рассчитанные как: | 𝐶 |/| 𝐴 |. Поскольку LLM не может гарантировать генерацию совершенно правильного кода, и процесс компиляции может быть трудоемким, мы предпочитаем подход с более высокой скоростью сопоставимости.

Бесполезная скорость мутации:Доля бесполезных мутаций, рассчитанных как: | 𝑈 |/| 𝐴 |. LLM иногда генерируют дублирующиеся мутации или мутации, которые точно такие же, как исходный код. В то время как традиционные подходы редко генерируют бесполезные мутации, LLM страдают от проблем недоразумения и повторения, что приводит к созданию этих бесполезных мутаций.

Эквивалентная скорость мутации:Доля эквивалентной мутации, рассчитанная как: | 𝐸 |/| 𝐴 |. Эквивалентные мутации семантически эквивалентны исходной программе, которая влияет на точность оценки мутации. Из -за неразрешимой природы определения того, является ли мутация эквивалентной, мы выбираем значительные части всех мутаций и судим их вручную. Более конкретно, учитывая, что популяция является набором 𝐴, мы установили уровень доверия на 95%, а погрешность - 5%, чтобы получить подмножество мутаций, которые будут вручную проверить.

Разнообразие узлов AST:Поэтому мы предпочитаем набор мутаций с разнообразными формами, мы анализируем код до и после мутации и проверяем разнообразие недавно введенных узлов AST. Подход с большим разнообразием типов узлов AST считается превосходным.

3.4.3 Сходство поведения с реальными ошибками.Сходство поведения относится к степени сходства в функциональности и выполнении между мутацией и соответствующей реальной ошибкой. Поскольку захват всех программ поведения является неразрешимым после существующих исследований, мы, таким образом, используем следующие показатели в качестве прокси для измерения сходства поведения [42, 55, 61].

Настоящая обнаружение ошибок:Учитывая местоположение реальной ошибки (которая может занимать несколько строк), пусть подход генерации мутаций генерирует набор мутаций, если тесты, которые убивают эти мутации, также могут убить эту реальную ошибку, мы говорим, что подход генерации мутаций может «обнаружить» эту реальную ошибку. Учитывая набор реальных ошибок и подход к генерации мутаций, реальная обнаружаемость ошибок определяет количество ошибок, обнаруженных этим подходом мутации.

Скорость связи:Тестирование на мутации основано на эффекте связи разлома, то есть мутациями, хотя и являются простыми синтаксическими изменениями, в сочетании с более сложными ошибками [53]. Чтобы описать степень, в которой мутация объединяется с соответствующей реальной ошибкой, мы принимаем скорость связи после существующего исследования [38]. Учитывая реальную ошибку и соответствующий мутант, сгенерированный в том же месте, мутант считается связанным мутантом, если набор тестовых случаев, убивающих перекрытие мутанта с набором тестовых случаев, вызывающих ошибки. Скорость связи относится к доле связанных мутантов внутри (𝐶 - 𝑈).

3.5 Настройки эксперимента

3.5.1 Настройки для генерации мутаций.Одной из основных целей нашего исследования является изучение сходства между LLM-генерируемыми мутациями и реальными ошибками. Поэтому мы генерируем мутации в контексте реальных ошибок, чтобы обеспечить такое сравнение. Чтобы определить количество мутаций, полученных в подсказке, мы принимаем настройку ямы [12]. Мы используем сгенерированные пит-мутации с полным набором операторов и обнаруживаем, что яма генерирует 1,15 мутации на строку кода. Поэтому, основываясь на данном контексте кода, мы генерируем одну мутацию на строку. Мы исследуем влияние длины контекста на генерацию мутаций в разделе 5.

3.5.2 Настройки для RQ1-RQ2.В первой части нашего исследования мы намерены качественно и сравнительно оценить возможности LLM в генерации мутаций. Мы принимаем настройки по умолчанию, которые содержат две модели (то есть GPT-3.5-Turbo и Codellama) и используем шаблон приглашения по умолчанию, генерируя мутации в универсальном наборе 405 ошибок в разделе 3.2.

Чтобы понять производительность LLM, мы принимаем Leam [70], 𝜇bert [15], Pit [12] и Major [39] в качестве базовых. Среди этих подходов Leam является современным подходом к созданию мутаций, в которой используется модель, обученная 13 миллионами реальных ошибок Java. В то время как 𝜇bert основан на BERT [20], предварительно обученная языковая модель замаскированной, которая не может разговорной реагирование на человеческий текст и код. PIT [12], а основные [39] являются популярными традиционными инструментами тестирования мутации с представленными человеческими операторами простых мутаций. Обратите внимание, что для ямы и майора мы используем всех операторов мутаций.

3.5.3 Настройки для RQ3-RQ4.Во второй части нашего исследования мы намерены изучить, как разные подсказки и разные модели влияют на производительность генерации мутаций. Из -за ограничений бюджета мы выбираем подмножество из 105 ошибок из нашего набора данных, который состоит из 10 ошибок выборки из каждого проекта Defects4j и всех проводящих ошибок.

В RQ3 для исследования подсказок мы используем модель GPT-3.5-Turbo и переключаем различные шаблоны подсказки. Более конкретно, мы изменяем шаблон приглашения по умолчанию, добавляя и удаляя различные источники информации в контексте, и мы наконец -то получаем 4 типа подсказок, показанные следующим образом:

(1)Подсказка 1 (P1): Подсказка по умолчанию.P1 - это подсказка по умолчанию, показанная как рисунок 1.

(2)Подсказка 2 (P2):P1 без нескольких примеров.P2 основан на P1, удаляя все примеры.

(3)Подсказка 3 (P3): P2 без целого метода Java.P3 основан на P2, удаляя окружающий код метода Java, только удерживая элемент целевого кода для мутирования.

(4)Приглашение 4 (P4): P1 с модульными тестами.На основе подсказки по умолчанию P1 P4 дополнительно добавляет исходный код соответствующих модульных тестов целевого метода в контекст.

В RQ4 для исследования LLMS мы используем подсказку по умолчанию и исследуем производительность GPT-3.5-Turbo, GPT-4-Turbo, Codellama-13b-Instruct и Starchat-𝛽-16b.

3.5.4 Настройки для RQ5.Генерация некомпилируемых мутаций несет дополнительные бессмысленные затраты, поэтому в третьей части нашего исследования мы изучаем основные причины, лежащие в основе некомпиляционных мутаций LLM. В частности, мы выбираем 384 некомпилируемые мутации каждого подхода к генерации мутаций и анализируем их разум, отвергнутую компилятором Java, и особенности их контекста окружающего кода.