論文の概要: On the Risks of using LLM-Generated Tests for Regression Testing

• arxiv url: http://arxiv.org/abs/2610.11835v1
• Date: Thu, 08 Oct 2026 12:27:58 GMT
• ステータス: 翻訳完了
• システム内更新日: 2026-10-10 02:36:54.022495
• Title: On the Risks of using LLM-Generated Tests for Regression Testing
• Title（参考訳）: 回帰テストにおけるLCM生成試験のリスクについて
• Abstract要約: 回帰テストは実装が正しければ有益だが、コードが欠陥を含んでいる場合は問題となる。 生成されたテストは、期待された振る舞いとして欠陥の振る舞いをエンコードし、バグがソフトウェア修正全体にわたって持続し、開発者によって保守されたテストスイートを回避できることを示します。
• 参考スコア（独自算出の注目度）: 5.986952206758139
• License: http://creativecommons.org/licenses/by/4.0/
• Abstract: Software is under constant evolution: developers continuously add features, fix bugs, and refactor code, and any of these changes may break existing functionality. Regression testing guards against such effects by capturing expected behavior in test cases. LLM-based test generation aims to automate this process by generating regression tests directly from the code under test. This is beneficial when the implementation is correct, but problematic when the code contains faults: the generated tests may then encode and preserve incorrect behavior. To investigate this risk, we apply LLM-based regression test generation to pull requests merged into the main branch of software projects and study the impact of the generated tests on subsequent project evolution. We distinguish between fault-revealing tests, which assert correctly implemented behavior, and fault-enforcing tests, which assert faulty behavior. Across 145 pull requests from SciPy, Qiskit, and pandas, 8%-17% of the generated tests are fault-enforcing, while only 2.4%-4.8% reveal faults. Fault-enforcing tests persist over time: after several subsequent commits, 83%-91% of them are still relevant and pass. They also accumulate: when the faults of all pull requests are combined in one codebase, 83%-92% remain enforced at the end of the commit history, and the developer-written test suite detects only 14%-30% of them. Our results reveal a fundamental risk of LLM-generated regression tests: without manual validation, they may encode faulty behavior as expected behavior, allowing bugs to persist across software revisions and largely evade developer-maintained test suites. LLM-based regression testing can thus give rise to a new form of technical debt.
• Abstract（参考訳）: 開発者は継続的に機能を追加し、バグを修正し、コードをリファクタリングする。 回帰テストは、テストケースで期待される振る舞いをキャプチャすることで、そのような影響に対してガードする。 LLMベースのテスト生成は、テスト中のコードから直接回帰テストを生成することで、このプロセスを自動化することを目的としている。 これは実装が正しい場合に有効だが、コードが欠陥を含む場合に問題が発生する。 このリスクを調査するために、LCMベースの回帰テスト生成を用いて、ソフトウェアプロジェクトのメインブランチにマージされたリクエストをプルし、生成したテストがその後のプロジェクトの進化に与える影響を調べる。 我々は、正しく実装された動作を主張する欠陥検出テストと、欠陥のある動作を主張する欠陥強化テストとを区別する。 SciPy、Qiskit、およびパンダからの145件のプルリクエストのうち、生成したテストの8%-17%がフォールトエンテンシングであり、わずか2.4%-4.8%が障害を明らかにしている。 数回のコミットの後、その83%～91%は依然として関連性があり、パスしている。 すべてのプルリクエストの障害が1つのコードベースで結合されると、コミット履歴の最後に83%-92%が強制され、開発者が記述したテストスイートがわずか14%-30%しか検出されない。 手動による検証がなければ、予想される動作として不良動作をコード化でき、ソフトウェア修正全体にわたってバグが持続し、開発者によって維持されるテストスイートを回避できる。 LLMベースの回帰テストは、新たな技術的負債をもたらす可能性がある。

関連論文リスト

• TestJack: Should you trust the results in coding benchmarks? Agentic Coding Benchmarks Auditing via Evaluator Evolution [56.4111102268819]
  大規模言語モデル(LLM)エージェントは、ソフトウェア工学を急速に再構築している。 しかし、既存のベンチマークのほとんどすべてが、同じ数十年前の基準に依存している。 固定テストを超えてパッチを評価するスケーラブルなフレームワークであるTestJackを紹介します。
  論文  参考訳（メタデータ） (2026-10-07T07:58:04Z)
• ExecCritic: Learn to Test, Test to Improve for Coding Agents [68.42713285082912]
  実行時のフィードバックは、コーディングエージェントを正しいリポジトリの修復に導くことができますが、テストが問題によって要求された振る舞いをキャプチャした場合のみです。 ExecCriticを導入し、テスト-検証-修正足場と、その中のトレーニングエージェントのためのロール固有の強化学習レシピを組み合わせる。 テストエージェントが独立してリポジトリネイティブなテストを生成し、フェイルクローズされたハーネスがそれらを調整して凍結し、リカバリエージェントがテストを変更することなく、ソースコードを実行フィードバックから修正する。
  論文  参考訳（メタデータ） (2026-09-08T17:53:37Z)
• Evaluating and Mitigating the Misguidance Effect of Buggy Code in LLM-Generated Unit Tests [6.228248513679207]
  本稿では,その誤動作を検証するテストを生成するために,バギーコードによるLSMを誘導する現象である「誤用効果」を測定するための新しい指標を提案する。 我々は,テスト中のコードをLCM生成した仕様文書に置き換える仕様ベースの単体テスト生成パラダイムを導入し,検証する。 本研究の結果から,このパラダイムは誤操作を効果的に低減し,有効なテストを大幅に増加させ,複数ラウンドのフィードバック駆動型テスト生成パイプラインを改善し,バグやバグのないコードにも適用可能であることが示唆された。
  論文  参考訳（メタデータ） (2026-07-24T19:47:41Z)
• TTHE: Test-Time Harness Evolution [50.26245555541721]
  既存のアプローチでは、デプロイ前、トレーニング前、あるいはテスト時に凍結される固定されたエージェントワークフローの開発データを最適化する。 我々は、エージェントがテスト入力で生成するラベルのない実行トレースのみを使用して、評価自体にハーネスを最適化できるかどうかを問う。 評価中、TTHEは候補ハーネスの人口を維持し、それらの実行トレースの理由をエージェントプロジェクタを通じてそれらを洗練する。 その後、審査員は実行元プロキシ信号から改善されたハーネスをコミットし、選択したプログラムは継続してその後の入力を統治する。
  論文  参考訳（メタデータ） (2026-07-09T05:53:39Z)
• Are Benchmark Tests Strong Enough? Mutation-Guided Diagnosis and Augmentation of Regression Suites [49.16055123488827]
  十分に強力なテストスイートは、報告された成功率を膨らませながら、妥当だが意味的に正しくないパッチを認めることができる。 STINGは、意味的に変化するプログラムの変種を診断ストレス要因として利用する、ターゲットテスト拡張のためのフレームワークである。 STINGは211インスタンスにまたがる1014の検証テストを生成し、パッチリージョンラインとブランチカバレッジを10.8%、9.5%向上させた。
  論文  参考訳（メタデータ） (2026-04-02T01:13:40Z)
• Code-A1: Adversarial Evolving of Code LLM and Test LLM via Reinforcement Learning [54.95476453942411]
  コード生成のための強化学習は、単体テストのパスレートから検証可能な報酬に依存する。 最近のセルフプレイ手法は、1つのモデルでコードとテスト生成を統合する。 Code-A1は、人間のアノテーションによるテストでトレーニングされたコード生成のパフォーマンスマッチングまたはモデルを超えることを実現する。
  論文  参考訳（メタデータ） (2026-03-16T17:58:13Z)
• ATGen: Adversarial Reinforcement Learning for Test Case Generation [78.48498301767079]
  大きな言語モデル(LLM)はコード生成に優れていますが、その出力には微妙なバグが伴います。 既存のテスト生成方法は静的データセットに依存している。 我々は,対戦型強化学習を通じてテストケースジェネレータを訓練するフレームワークであるATGenを紹介する。
  論文  参考訳（メタデータ） (2025-10-16T12:49:25Z)
• TestGenEval: A Real World Unit Test Generation and Test Completion Benchmark [24.14654309612826]
  TestGenEvalは、1,210のコードから68,647のテストと、11の保守されたPythonリポジトリにまたがるテストファイルペアで構成されている。 初期テストのオーサリング、テストスイートの補完、コードカバレッジの改善をカバーしている。 パラメータは7Bから405Bまで様々である。
  論文  参考訳（メタデータ） (2024-10-01T14:47:05Z)
• TestART: Improving LLM-based Unit Testing via Co-evolution of Automated Generation and Repair Iteration [7.509927117191286]
  大規模言語モデル(LLM)は、単体テストケースを生成する際、顕著な能力を示した。 本研究では,新しい単体テスト生成法であるTestARTを提案する。 TestARTは、自動生成と修復の反復の共進化を通じて、LLMベースのユニットテストを改善している。
  論文  参考訳（メタデータ） (2024-08-06T10:52:41Z)
• Effective Test Generation Using Pre-trained Large Language Models and Mutation Testing [13.743062498008555]
  大規模言語モデル(LLM)が生成するテストケースの有効性を,バグの発見の観点から改善するための MuTAP を導入する。 MuTAPは、プログラム・アンダー・テスト(PUT)の自然言語記述がない場合に有効なテストケースを生成することができる 提案手法は, 最大28%の人書きコードスニペットを検出できることを示す。
  論文  参考訳（メタデータ） (2023-08-31T08:48:31Z)

関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。

指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。