論文の概要: Back to the Future! Studying Data Cleanness in Defects4J and its Impact on Fault Localization

• arxiv url: http://arxiv.org/abs/2310.19139v3
• Date: Thu, 8 Aug 2024 00:41:11 GMT
• ステータス: 処理完了
• システム内更新日: 2024-08-09 20:59:13.804655
• Title: Back to the Future! Studying Data Cleanness in Defects4J and its Impact on Fault Localization
• Title（参考訳）: バック・トゥ・ザ・フューチャー! 欠陥4Jにおけるデータの清浄性の研究と異常局在への影響
• Authors: Md Nakhla Rafi, An Ran Chen, Tse-Hsun Chen, Shaohua Wang,
• Abstract要約: 我々は,Defects4Jの欠陥トリガテストについて検討し,SBFL技術に関する開発者の知識がもたらす意味を強調した。 バグの再現や回帰テストのために,障害トリガテストの55%が新たに追加されたことが分かりました。 また、バグレポートの作成後に障害トリガテストの22%が修正され、バグに関する開発者の知識が含まれています。
• 参考スコア（独自算出の注目度）: 3.8040257966829802
• License: http://creativecommons.org/licenses/by/4.0/
• Abstract: For software testing research, Defects4J stands out as the primary benchmark dataset, offering a controlled environment to study real bugs from prominent open-source systems. However, prior research indicates that Defects4J might include tests added post-bug report, embedding developer knowledge and affecting fault localization efficacy. In this paper, we examine Defects4J's fault-triggering tests, emphasizing the implications of developer knowledge of SBFL techniques. We study the timelines of changes made to these tests concerning bug report creation. Then, we study the effectiveness of SBFL techniques without developer knowledge in the tests. We found that 1) 55% of the fault-triggering tests were newly added to replicate the bug or to test for regression; 2) 22% of the fault-triggering tests were modified after the bug reports were created, containing developer knowledge of the bug; 3) developers often modify the tests to include new assertions or change the test code to reflect the changes in the source code; and 4) the performance of SBFL techniques degrades significantly (up to --415% for Mean First Rank) when evaluated on the bugs without developer knowledge. We provide a dataset of bugs without developer insights, aiding future SBFL evaluations in Defects4J and informing considerations for future bug benchmarks.
• Abstract（参考訳）: ソフトウェアテストの研究において、Defects4Jは主要なベンチマークデータセットとして際立っている。 しかし、以前の調査では、Defects4Jには、バグ後のレポートを追加したテスト、開発者の知識を埋め込んだり、障害のローカライゼーションの有効性に影響する可能性がある。 本稿では,Defects4Jの欠陥追跡テストについて検討し,SBFL技術に関する開発者の知識がもたらす意味を強調した。 バグレポート作成に関するこれらのテストに対する変更のタイムラインについて検討する。 そこで本研究では,SBFL技術の有効性について検討した。 私たちはそれを発見しました 1) 障害追跡テストの55%は、バグの再現や回帰テストのために新たに追加されました。 2) 障害トリガテストの22%は,バグレポート作成後に修正され,バグに関する開発者の知識が含まれている。 3) 開発者はしばしば、新しいアサーションを含むようにテストを変更したり、ソースコードの変更を反映するようにテストコードを変更したりする。 4)SBFL技術のパフォーマンスは、開発者知識のないバグを評価すると、著しく低下する(平均一等級は-415%まで)。 開発者の洞察なしにバグのデータセットを提供し、Defects4Jにおける将来のSBFL評価を支援し、将来のバグベンチマークについて検討する。

関連論文リスト

• Understanding Code Understandability Improvements in Code Reviews [79.16476505761582]
  GitHub上のJavaオープンソースプロジェクトからの2,401のコードレビューコメントを分析した。 改善提案の83.9%が承認され、統合され、1%未満が後に復活した。
  論文  参考訳（メタデータ） (2024-10-29T12:21:23Z)
• Rethinking the Influence of Source Code on Test Case Generation [22.168699378889148]
  大規模言語モデル(LLM)は、コンテキストとして提供されるテスト対象のソースコードでテスト生成を支援するために広く応用されている。 テスト中のソースコードが間違っていれば、LLMはテストの生成時に誤用されるだろうか? 評価結果から, 誤りコードは, 正しい, 高いカバレッジ, バグ修正テストを生成する際に, LLMを著しく誤解させる可能性が示唆された。
  論文  参考訳（メタデータ） (2024-09-14T15:17:34Z)
• Leveraging Large Language Models for Efficient Failure Analysis in Game Development [47.618236610219554]
  本稿では,テストの失敗の原因となるコードの変更を自動的に識別する手法を提案する。 このメソッドは、LLM(Large Language Models)を利用して、エラーメッセージと対応するコード変更を関連付ける。 当社のアプローチは新たに作成したデータセットで71%の精度に達しています。
  論文  参考訳（メタデータ） (2024-06-11T09:21:50Z)
• Leveraging Stack Traces for Spectrum-based Fault Localization in the Absence of Failing Tests [44.13331329339185]
  我々は,スタックトレースデータをテストカバレッジと統合し,障害局所化を強化する新しいアプローチであるSBESTを導入する。 提案手法では,平均精度(MAP)が32.22%向上し,平均相互ランク(MRR)が17.43%向上した。
  論文  参考訳（メタデータ） (2024-05-01T15:15:52Z)
• DebugBench: Evaluating Debugging Capability of Large Language Models [80.73121177868357]
  DebugBench - LLM(Large Language Models)のベンチマーク。 C++、Java、Pythonの4つの主要なバグカテゴリと18のマイナータイプをカバーする。 ゼロショットシナリオで2つの商用および4つのオープンソースモデルを評価する。
  論文  参考訳（メタデータ） (2024-01-09T15:46:38Z)
• An Analysis of Bugs In Persistent Memory Application [0.0]
  我々は,NVMレベルのハッシュPMアプリケーションをテストするために,オープンソースの自動バグ検出ツール(AGAMOTTO)を評価した。 私たちの忠実な検証ツールは、PMDKライブラリで65の新しいNVMレベルのハッシュバグを発見しました。 本稿では,PM-Aware 探索アルゴリズムを用いたディープQ学習探索アルゴリズムを提案する。
  論文  参考訳（メタデータ） (2023-07-19T23:12:01Z)
• What Happens When We Fuzz? Investigating OSS-Fuzz Bug History [0.9772968596463595]
  我々は2022年3月12日までにOSS-Fuzzが公表した44,102件の問題を分析した。 コードを含むバグの発生時期を推定するために,バグ貢献のコミットを特定し,検出から修正までのタイムラインを測定した。
  論文  参考訳（メタデータ） (2023-05-19T05:15:36Z)
• Large Language Models are Few-shot Testers: Exploring LLM-based General Bug Reproduction [14.444294152595429]
  問題によりオープンソースリポジトリに追加されたテストの数は、対応するプロジェクトテストスイートサイズの約28%であった。 本稿では,Large Language Models (LLMs) を用いたLIBROを提案する。 LIBROの評価は、広く研究されているDefects4Jベンチマークにおいて、全ての研究ケースの33%で障害再現テストケースを生成することができることを示している。
  論文  参考訳（メタデータ） (2022-09-23T10:50:47Z)
• SUPERNOVA: Automating Test Selection and Defect Prevention in AAA Video Games Using Risk Based Testing and Machine Learning [62.997667081978825]
  従来の手法では、成長するソフトウェアシステムではスケールできないため、ビデオゲームのテストはますます難しいタスクになります。 自動化ハブとして機能しながら,テスト選択と欠陥防止を行うシステム SUPERNOVA を提案する。 この直接的な影響は、未公表のスポーツゲームタイトルの55%以上のテスト時間を減らすことが観察されている。
  論文  参考訳（メタデータ） (2022-03-10T00:47:46Z)
• TACRED Revisited: A Thorough Evaluation of the TACRED Relation Extraction Task [80.38130122127882]
  TACREDはリレーショナル抽出(RE)において最も大きく、最も広く使われているクラウドソースデータセットの1つである パフォーマンスの天井に到達したのか、改善の余地はあるのか? ラベルエラーは絶対F1テストエラーの8%を占めており、例の50%以上を可逆化する必要がある。
  論文  参考訳（メタデータ） (2020-04-30T15:07:37Z)

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

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