LLM-Powered Test Case Generation for Detecting Bugs in Plausible Programs

生成日: 2026-05-24 02:20

# LLM-Powered Test Case Generation for Detecting Bugs in Plausible Programs

- 既存のテストスイートを通るが、なおバグを含む plausible program を対象に、バグを露出するテストケースを生成する研究である。
- TrickCatcher は、LLM にプログラム修正版の候補と入力生成器を作らせ、それらを用いた differential testing により期待出力を構成する。
- TrickyBugs と EvalPlus で評価され、既存手法に対して recall、precision、F1 をそれぞれ最大 1.80 倍、2.65 倍、1.66 倍に改善した。

## Abstract（日本語訳）

既存のテストスイートを通過するにもかかわらずバグを含む plausible program において、見つけにくいバグを検出することは、ソフトウェアテストにおける重要な課題である。この問題に対処するため、本論文では、plausible program のバグを明らかにするテストケースを生成する LLM ベースの手法 TrickCatcher を提案する。TrickCatcher は三つの段階で動作する。第一に、プログラム under test（PUT）とその仕様に基づき、LLM を用いてプログラムの variant を生成する。第二に、仕様からテスト入力を生成するための入力生成器を LLM に構築させる。最後に、これらの入力を PUT とプログラム variant の双方で実行し、出力の不一致を検出する。TrickCatcher は、366 件の人手で書かれた plausible program と 151 件の AI 生成 plausible program を含む二つのデータセット、TrickyBugs と EvalPlus で評価された。TrickCatcher は、recall、precision、F1 において、それぞれ state-of-the-art のベースラインの 1.80 倍、2.65 倍、1.66 倍のスコアを達成した。使用したコードとデータは https://github.com/RinCloud/TrickCatcher/ で公開されている。

## 論文の面白いところ

この論文の焦点は、コードが「見かけ上は正しい」状況に置かれている。通常のテスト生成では、カバレッジを広げることや、単体テストを増やすことが目的になりやすい。しかし、この論文で扱う plausible program は、すでに与えられたテストをすべて通過しているため、単に入力を増やすだけでは有効な検査になりにくい。著者らは、LLM に正解プログラムを一つ作らせるのではなく、PUT に近い複数の program variant を作らせ、それらの出力差を利用する。ここで興味深いのは、多数決を素直に採用しない点である。variant の多くが PUT と同じ誤りを継承する場合があるため、PUT と異なる出力を出した variant にむしろ注目する。さらに、入力そのものを LLM に直接列挙させず、入力制約を満たす Python の入力生成器を書かせることで、無効な入力による false positive を抑えている。LLM の不安定さを前提にしながら、その不安定さを differential testing の材料に変えている点に、この研究の実用上の含意がある。

## 問題設定

対象は、仕様、プログラム under test（PUT）、既存のテストスイートが与えられた状況である。PUT が既存テストをすべて通過する場合、論文ではそれを plausible program と呼ぶ。ただし、plausible であることは正しいことを意味しない。たとえばオンラインジャッジでは、用意されたテストを通る提出でも、境界条件や例外的な入力で誤ることがある。この論文では、そのようなバグを tricky bug と呼び、それを露出する入力と期待出力の組を生成することを目標にする。テストケースが有効であるためには、入力が仕様の制約内にあり、期待出力も仕様に照らして正しくなければならない。入力が無効であったり、期待出力が誤っていたりすると、正しいプログラムを誤ってバグありと判定する false positive になりうる。したがって、このタスクでは単に失敗するテストを作るだけでなく、開発者が確認する価値のあるテストを作ることが重要になる。

## 提案手法

提案手法 TrickCatcher は、PUT に基づく program variant 生成、入力生成器による test input 生成、diversity-driven differential testing の三段階から成る。第一段階では、LLM に仕様と PUT の両方を与え、PUT にバグがあるかを考えさせ、必要に応じて修正版のプログラムを生成させる。仕様だけからプログラムを作らせるよりも、既存テストを通る PUT を足場にした方が、意味のある variant を得やすい。生成された variant は、既存のテストスイートを通らないものが除かれる。第二段階では、LLM にテスト入力を直接出させるのではなく、仕様の入力制約を満たす入力生成器を書かせる。実験では Python script と CYaRon ライブラリを用いており、これにより複雑な入力制約をコードとして扱える。第三段階では、生成した入力を PUT と複数の variant に実行し、PUT と異なる出力が出た場合に、その出力を期待出力候補として採用する。複数の異なる出力がある場合は、その中で最頻のものを oracle とする。この設計は、多数決で最も多い出力を正解とみなす通常の differential testing とは異なる。

## 結果

評価には、人手で書かれた plausible program を含む TrickyBugs と、AI 生成コードを含む EvalPlus が用いられた。TrickyBugs には C++ 251 件と Python 115 件、EvalPlus には Python の 151 件の buggy plausible program が含まれる。比較対象は、LLM に直接テストケースを作らせる DirectChat、Differential Prompting を plausible program 向けに調整した Differential Prompting Plus（DPP）、自動プログラム修正に基づく APR である。TrickCatcher は TrickyBugs（C++）で F1 41.31%、TrickyBugs（Python）で F1 42.35%、EvalPlus で F1 51.34% を得た。対応する最良ベースラインの F1 は、それぞれ 24.95%、36.20%、35.76% であった。正しいプログラムに対する false positive も調べられており、EvalPlus では DPP や DirectChat より最大 16 倍少なかった。特に、入力生成器を使う方式では invalid input による false positive が発生しなかったと報告されている。ablation study では、PUT-guided program generation、generator-based input generation、diversity-driven differential testing の各構成要素が性能に寄与することが示された。さらに deepseek-v3 を用いた追加実験でも EvalPlus の F1 が 59% 台となり、基盤となる LLM が強くなるほど性能が上がる傾向が確認されている。

## 具体例

三つの整数 A、B、C が与えられ、それらが 5、7、5 の並べ替えであるかを判定する問題を考える。正しいプログラムは、入力を並べ替えて `[5, 5, 7]` と一致するかを調べる。ところが、既存テストに `5 5 7` や `7 5 5` だけが含まれていると、三つの数の合計が 17 かどうかだけを見る誤ったプログラムも通ってしまう。この PUT に対して TrickCatcher は、まず LLM に仕様と PUT を渡し、並べ替えで比較する variant などを生成させる。次に、1 から 10 までの整数を三つ出す入力生成器を作らせ、そこから `5 4 8` のような入力を得る。この入力では合計が 17 なので、誤った PUT は Yes を返しやすい。しかし仕様上は 5、7、5 の並べ替えではないため、期待される出力は No である。variant の一部が No を返し、PUT が Yes を返すなら、TrickCatcher はこの差を手掛かりにバグを示すテストケースとして扱う。間違えやすい点は、単純な多数決では PUT と同じ誤りをもつ variant が多い場合に Yes が正しいと見なされかねないことである。TrickCatcher は PUT と異なる出力に注目するため、この種の隠れた条件漏れを検出しやすくなる。

LLM-Powered Test Case Generation for Detecting Bugs in Plausible Programs

既存のテストスイートを通るが、なおバグを含む plausible program を対象に、バグを露出するテストケースを生成する研究である。
TrickCatcher は、LLM にプログラム修正版の候補と入力生成器を作らせ、それらを用いた differential testing により期待出力を構成する。
TrickyBugs と EvalPlus で評価され、既存手法に対して recall、precision、F1 をそれぞれ最大 1.80 倍、2.65 倍、1.66 倍に改善した。

Abstract（日本語訳）

既存のテストスイートを通過するにもかかわらずバグを含む plausible program において、見つけにくいバグを検出することは、ソフトウェアテストにおける重要な課題である。この問題に対処するため、本論文では、plausible program のバグを明らかにするテストケースを生成する LLM ベースの手法 TrickCatcher を提案する。TrickCatcher は三つの段階で動作する。第一に、プログラム under test（PUT）とその仕様に基づき、LLM を用いてプログラムの variant を生成する。第二に、仕様からテスト入力を生成するための入力生成器を LLM に構築させる。最後に、これらの入力を PUT とプログラム variant の双方で実行し、出力の不一致を検出する。TrickCatcher は、366 件の人手で書かれた plausible program と 151 件の AI 生成 plausible program を含む二つのデータセット、TrickyBugs と EvalPlus で評価された。TrickCatcher は、recall、precision、F1 において、それぞれ state-of-the-art のベースラインの 1.80 倍、2.65 倍、1.66 倍のスコアを達成した。使用したコードとデータは https://github.com/RinCloud/TrickCatcher/ で公開されている。

論文の面白いところ

この論文の焦点は、コードが「見かけ上は正しい」状況に置かれている。通常のテスト生成では、カバレッジを広げることや、単体テストを増やすことが目的になりやすい。しかし、この論文で扱う plausible program は、すでに与えられたテストをすべて通過しているため、単に入力を増やすだけでは有効な検査になりにくい。著者らは、LLM に正解プログラムを一つ作らせるのではなく、PUT に近い複数の program variant を作らせ、それらの出力差を利用する。ここで興味深いのは、多数決を素直に採用しない点である。variant の多くが PUT と同じ誤りを継承する場合があるため、PUT と異なる出力を出した variant にむしろ注目する。さらに、入力そのものを LLM に直接列挙させず、入力制約を満たす Python の入力生成器を書かせることで、無効な入力による false positive を抑えている。LLM の不安定さを前提にしながら、その不安定さを differential testing の材料に変えている点に、この研究の実用上の含意がある。

問題設定

対象は、仕様、プログラム under test（PUT）、既存のテストスイートが与えられた状況である。PUT が既存テストをすべて通過する場合、論文ではそれを plausible program と呼ぶ。ただし、plausible であることは正しいことを意味しない。たとえばオンラインジャッジでは、用意されたテストを通る提出でも、境界条件や例外的な入力で誤ることがある。この論文では、そのようなバグを tricky bug と呼び、それを露出する入力と期待出力の組を生成することを目標にする。テストケースが有効であるためには、入力が仕様の制約内にあり、期待出力も仕様に照らして正しくなければならない。入力が無効であったり、期待出力が誤っていたりすると、正しいプログラムを誤ってバグありと判定する false positive になりうる。したがって、このタスクでは単に失敗するテストを作るだけでなく、開発者が確認する価値のあるテストを作ることが重要になる。

提案手法

提案手法 TrickCatcher は、PUT に基づく program variant 生成、入力生成器による test input 生成、diversity-driven differential testing の三段階から成る。第一段階では、LLM に仕様と PUT の両方を与え、PUT にバグがあるかを考えさせ、必要に応じて修正版のプログラムを生成させる。仕様だけからプログラムを作らせるよりも、既存テストを通る PUT を足場にした方が、意味のある variant を得やすい。生成された variant は、既存のテストスイートを通らないものが除かれる。第二段階では、LLM にテスト入力を直接出させるのではなく、仕様の入力制約を満たす入力生成器を書かせる。実験では Python script と CYaRon ライブラリを用いており、これにより複雑な入力制約をコードとして扱える。第三段階では、生成した入力を PUT と複数の variant に実行し、PUT と異なる出力が出た場合に、その出力を期待出力候補として採用する。複数の異なる出力がある場合は、その中で最頻のものを oracle とする。この設計は、多数決で最も多い出力を正解とみなす通常の differential testing とは異なる。

結果

評価には、人手で書かれた plausible program を含む TrickyBugs と、AI 生成コードを含む EvalPlus が用いられた。TrickyBugs には C++ 251 件と Python 115 件、EvalPlus には Python の 151 件の buggy plausible program が含まれる。比較対象は、LLM に直接テストケースを作らせる DirectChat、Differential Prompting を plausible program 向けに調整した Differential Prompting Plus（DPP）、自動プログラム修正に基づく APR である。TrickCatcher は TrickyBugs（C++）で F1 41.31%、TrickyBugs（Python）で F1 42.35%、EvalPlus で F1 51.34% を得た。対応する最良ベースラインの F1 は、それぞれ 24.95%、36.20%、35.76% であった。正しいプログラムに対する false positive も調べられており、EvalPlus では DPP や DirectChat より最大 16 倍少なかった。特に、入力生成器を使う方式では invalid input による false positive が発生しなかったと報告されている。ablation study では、PUT-guided program generation、generator-based input generation、diversity-driven differential testing の各構成要素が性能に寄与することが示された。さらに deepseek-v3 を用いた追加実験でも EvalPlus の F1 が 59% 台となり、基盤となる LLM が強くなるほど性能が上がる傾向が確認されている。

具体例

三つの整数 A、B、C が与えられ、それらが 5、7、5 の並べ替えであるかを判定する問題を考える。正しいプログラムは、入力を並べ替えて [5, 5, 7] と一致するかを調べる。ところが、既存テストに 5 5 7 や 7 5 5 だけが含まれていると、三つの数の合計が 17 かどうかだけを見る誤ったプログラムも通ってしまう。この PUT に対して TrickCatcher は、まず LLM に仕様と PUT を渡し、並べ替えで比較する variant などを生成させる。次に、1 から 10 までの整数を三つ出す入力生成器を作らせ、そこから 5 4 8 のような入力を得る。この入力では合計が 17 なので、誤った PUT は Yes を返しやすい。しかし仕様上は 5、7、5 の並べ替えではないため、期待される出力は No である。variant の一部が No を返し、PUT が Yes を返すなら、TrickCatcher はこの差を手掛かりにバグを示すテストケースとして扱う。間違えやすい点は、単純な多数決では PUT と同じ誤りをもつ variant が多い場合に Yes が正しいと見なされかねないことである。TrickCatcher は PUT と異なる出力に注目するため、この種の隠れた条件漏れを検出しやすくなる。