SPARC：C自動ユニットテスト生成に向けたシナリオ計画と推論

TL;DR（結論）

• Cではポインタ演算や手動メモリ管理の制約が強く、LLMに意図だけを渡してテストを書かせると、正常系に偏ったり依存関係を捏造したりして、コンパイル不能や意味の薄いアサーションになりやすいです。
• SPARCは制御フローグラフから実行パスごとのシナリオを抽出し、検証済みヘルパーに基づく操作マップで呼び出し先を制限したうえで、パス単位のテスト生成とコンパイル・実行フィードバックによる反復修復を行います。
• 59件の対象で単純なプロンプト生成より行・分岐カバレッジとミューテーションスコアが向上し、複雑な対象ではKLEEに匹敵または上回り、修復後にテストの大半が残って可読性と保守性の評価も高まりました。

なぜこの問題か

Cのユニットテスト自動生成が難しい主因は、プログラムの意図を理解する必要性と、C特有の厳格な構文・実行時制約の間に大きな隔たりがあるためです。論文では、ポインタ演算と手動メモリ管理がその隔たりを拡大すると説明されています。LLMはコード生成が得意でも、意図から直接テストコードを書かせると、プログラム構造や制約、意味への根拠づけが弱いまま出力してしまう失敗が起きやすいです。本文ではこれを「コードに飛びつく」失敗として述べ、結果としてコンパイルできないテスト、存在しない関数シグネチャの捏造、分岐カバレッジの低下、バグを捉えにくい無関係なアサーションにつながるとしています。 さらに、単純なプロンプト生成では、到達経路がいわゆる正常系に寄りやすく、境界値、ヌルポインタ、エラーハンドリング分岐といった重要な分岐が抜け落ちやすいと示されています。加えて、プロジェクト内にないヘルパーやユーティリティを参照してしまい、依存関係が不明確なままコンパイルに失敗する問題も具体例として挙げられています。もう一つの課題は、テストがブラックボックス化して追跡可能性が下がる点です。…

核心：何を提案したのか

提案手法はSPARCで、Cの自動ユニットテスト生成をシナリオベースで進める枠組みとして提示されています。論文の位置づけでは、ニューロ・シンボリックな構成により、LLMの生成能力と静的解析による構造把握を組み合わせ、意図とコードの隔たりを段階的に埋めます。重要な設計は、テスト生成を一回の出力で完結させず、まず静的解析で「高レベルのテストシナリオ」を導出し、そのシナリオを設計図としてテストを合成する二段の課題に分解する点です。これにより、特定の実行パスを狙って入力を組み立て、パスに対応する主張（アサーション）を置くという、意味的に結び付いたテストを目指します。 枠組みは4段階で説明されています。第1段階は制御フローグラフ解析で、関数の実行パスを抽出してシナリオ化します。第2段階は操作マップで、検証済みのユーティリティヘルパーに基づき、LLMが呼び出せる操作を制約して依存関係の捏造を抑えます。…

続きはログイン/プランで閲覧できます。