論文の概要: Specification Grounding Drives Test Effectiveness for LLM Code
- arxiv url: http://arxiv.org/abs/2607.06636v1
- Date: Tue, 07 Jul 2026 14:11:00 GMT
- ステータス: 翻訳完了
- システム内更新日: 2026-07-09 22:50:30.162803
- Title: Specification Grounding Drives Test Effectiveness for LLM Code
- Title（参考訳）: LLMコードの仕様グラウンド化によるテスト効率向上
- Abstract要約: 仕様でテストのグラウンディングを行うと、このベースラインよりも38パーセントの割合で正しいコードを生成します。
誤検出率は33%(Pythonの標準ライブラリーオラクルに対して68%)から0%に削減されている。
- 参考スコア（独自算出の注目度）: 1.8620637029128544
- License: http://creativecommons.org/licenses/by/4.0/
- Abstract: Large language models frequently generate code that appears correct on typical inputs yet fails on edge cases, invalid inputs, and other specification-defined corner conditions. A popular fix has the model write its own tests and repair until they pass, but the source of the gain is unclear: does it come from the tests merely existing, or from their grounding in a specification of what the code should do? We isolate this factor. Holding the tester, test budget, and repair loop fixed, we change a single prompt line that controls whether the tester receives the spec as a checklist of rules. The baseline is strong: it is already told to probe invalid inputs and edge cases. Grounding the tests in the spec produces correct code +38 percentage points more often than this baseline across three Claude tiers (Haiku 4.5, Sonnet 4.6, Opus 4.8), and +36 points on a held-out set. Grounding, not test quantity, is the primary driver: doubling the test budget barely helps, and combining eight independent ungrounded suites plateaus far below grounding. An ablation isolates the spec's content, not its format: given the spec as a plain paragraph the tester recovers 27 of 30 bugs, but asked to plan tests without the spec it recovers only 2 of 30. The effect survives stronger baselines: a property-based generator catches 28 of 30 bugs but invents out-of-spec requirements, and an AlphaCodium-style loop only matches the baseline. It replicates across vendors (GPT-5.3-codex +28, Gemini 3.5 Flash +19), with a task-level sign test over 18 tasks significant at p=0.002. Grounding improves both sensitivity and precision: it catches more real bugs and wrongly rejects far less correct code, cutting the false-alarm rate from 33% (68% against a Python standard-library oracle) to 0%. On well-specified algorithmic problems it neither helps nor hurts.
- Abstract（参考訳）: 大きな言語モデルは、典型的な入力では正しいように見えるコードを生成するが、エッジケース、無効な入力、その他の仕様定義のコーナー条件では失敗する。
一般的な修正では、モデルを通過するまで独自のテストと修正を書くが、利益の源は不明確である。
私たちはこの因子を分離する。
テスター、テスト予算、修正ループを固定すると、テスト担当者がルールのチェックリストとして仕様を受け取るかどうかを制御する単一のプロンプト行を変更します。
ベースラインは強く、無効な入力やエッジケースを調査するようすでに言われている。
仕様におけるテストのグラウンド化は、3つのクロード層(Haiku 4.5、Sonnet 4.6、Opus 4.8)のベースラインよりも38パーセント高い精度で正しいコードを生成する。
テスト予算を2倍にすることはほとんど役に立たないし、グラウンドよりもはるかに低い8つの独立したアングラウンドスイートを組み合わせる。
仕様がプレーンな段落であることから、テスタは30バグのうち27バグを回収するが、仕様なしでは30バグのうち2バグだけを回収するように要求する。
プロパティベースのジェネレータは、30のバグのうち28のバグをキャッチするが、仕様外要件を発明し、AlphaCodiumスタイルのループはベースラインにマッチする。
ベンダー(GPT-5.3-codex +28, Gemini 3.5 Flash +19)間で複製され、p=0.002の18タスクでタスクレベルのサインテストを行う。
グラウンディングは、感度と精度の両方を改善する: より実際のバグをキャッチし、はるかに少ない正しいコードを誤って拒否し、偽アラームレートを33%(Python標準ライブラリのオラクルに対して68%)から0%に削減する。
適切に特定されたアルゴリズム上の問題では、それは役にも立たない。
関連論文リスト
- ExecCritic: Learn to Test, Test to Improve for Coding Agents [68.42713285082912]
実行時のフィードバックは、コーディングエージェントを正しいリポジトリの修復に導くことができますが、テストが問題によって要求された振る舞いをキャプチャした場合のみです。
ExecCriticを導入し、テスト-検証-修正足場と、その中のトレーニングエージェントのためのロール固有の強化学習レシピを組み合わせる。
テストエージェントが独立してリポジトリネイティブなテストを生成し、フェイルクローズされたハーネスがそれらを調整して凍結し、リカバリエージェントがテストを変更することなく、ソースコードを実行フィードバックから修正する。
論文 参考訳（メタデータ） (2026-09-08T17:53:37Z) - Correct Tests Are Not Enough: Measuring and Training Oracle Conversion in Specification-Based Test Generation [14.44743150931186]
自然言語仕様からテストを生成するには、異常な振る舞いを公開する入力と、正しい期待出力の両方が必要である。
我々は,この相互作用を,実行可能報酬分解とスイートレベルのオラクル変換測定を通じて研究する。
生成器は1つの応答で5つの入出力試験を共同で出力する。
論文 参考訳（メタデータ） (2026-09-05T04:56:31Z) - Beyond Fail-to-Pass: Iterative Hardening of Co-Generated Bug Reproduction Tests and Fixes [55.114939648705395]
大規模言語モデル(LLM)は、現実のバグに対して、プログラムの自動修正をますます実用的にしている。
バグ再現テスト(BRT)は、バグレポートを実行可能なバグ固有の信号に変換することで、このギャップを埋めるのに役立つ。
本稿では,ループ内収束基準としてLax信号を用いるコジェネレーションフレームワークであるCoHardenを提案する。
論文 参考訳（メタデータ） (2026-07-22T07:30:07Z) - PBT-Bench: Benchmarking AI Agents on Property-Based Testing [29.035258104995204]
PBT-Benchは、40の実際のPythonライブラリにまたがる100のプロパティベースのテスト問題のベンチマークである。
各問題は1つ以上のセマンティックなバグ(総数365、平均3.65)を注入し、デフォルトのストラテジーなランダムな入力がほとんど起こらないように設計する。
PBT指導によるバグリコールは42.1%から83.4%の範囲で、オープンエンドベースラインでは31.4%から76.7%である。
論文 参考訳（メタデータ） (2026-05-13T18:01:05Z) - Breaking, Stale, or Missing? Benchmarking Coding Agents on Project-Level Test Evolution [20.606877071567958]
テスト進化のための最初のプロジェクトレベルのベンチマークであるTEBenchを紹介します。
TEBenchをDefects4Jプロジェクト上で4段階のパイプラインで構築する。
3つの産業エージェントフレームワークにまたがる7つの構成を評価する。
論文 参考訳（メタデータ） (2026-05-07T12:31:09Z) - Nexus: Execution-Grounded Multi-Agent Test Oracle Synthesis [57.40527331817245]
非回帰テストにおけるテストオラクル生成は、ソフトウェア工学における長年の課題である。
この課題に対処するための新しいマルチエージェントフレームワークであるNexusを紹介します。
論文 参考訳（メタデータ） (2025-10-30T12:20:25Z) - How Many Code and Test Cases Are Enough? Evaluating Test Cases Generation from a Binary-Matrix Perspective [51.30005925128432]
LLM(Large Language Models)が自動生成するテストケースの評価は、非常に難しい作業です。
既存のベンチマークは高い計算コスト、インフレーションのスコア、稀でクリティカルな欠陥に対する自明なバグに対するバイアスに悩まされている。
本稿では,ベンチマーク構築をバイナリコードテスト行列の最適な診断基準として定式化するフレームワークを提案する。
論文 参考訳（メタデータ） (2025-10-09T18:29:24Z) - Studying the Impact of Early Test Termination Due to Assertion Failure on Code Coverage and Spectrum-based Fault Localization [48.22524837906857]
本研究は,アサーション障害による早期検査終了に関する最初の実証的研究である。
6つのオープンソースプロジェクトの207バージョンを調査した。
以上の結果から,早期検査終了は,コードカバレッジとスペクトルに基づく障害局所化の有効性の両方を損なうことが示唆された。
論文 参考訳（メタデータ） (2025-04-06T17:14:09Z) - Learning to Generate Unit Tests for Automated Debugging [52.63217175637201]
ユニットテスト(UT)は、コードの正確性を評価するだけでなく、大きな言語モデル(LLM)にフィードバックを提供する上でも重要な役割を果たします。
提案するUTGenは,LLMに対して,予測出力とともにエラーを示す単体テスト入力を生成することを教える。
UTGen は他の LLM ベースラインを7.59% 上回っていることを示す。
論文 参考訳（メタデータ） (2025-02-03T18:51:43Z) - SBEST: Spectrum-Based Fault Localization Without Fault-Triggering Tests [17.90798133817018]
本研究は, 事故報告から得られたスタックトレースを, スペクトルベース断層定位における故障トリガー試験のプロキシとして用いる可能性について検討した。
本稿では,スタックトレース情報とテストカバレッジデータを統合する新たな手法であるSBESTを提案する。
論文 参考訳（メタデータ） (2024-05-01T15:15:52Z) - FlakyFix: Using Large Language Models for Predicting Flaky Test Fix Categories and Test Code Repair [0.5749787074942512]
不安定なテストは、テスト中の同じソフトウェアバージョンを非決定的にパスまたは失敗するため、問題となる。
本稿では、フレキネスを除去し、それに基づいてテストコードを修正するために必要な修正の種類を予測することに焦点を当てる。
1つの鍵となるアイデアは、予想される修正カテゴリの形で、テストのフレキネスに関するさらなる知識で、修復プロセスを導くことである。
論文 参考訳（メタデータ） (2023-06-21T19:34:16Z)
関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。
指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。