論文の概要: Back to the Future! Studying Data Cleanness in Defects4J and its Impact
on Fault Localization
- arxiv url: http://arxiv.org/abs/2310.19139v1
- Date: Sun, 29 Oct 2023 20:19:06 GMT
- ステータス: 処理完了
- システム内更新日: 2023-10-31 13:56:08.326060
- Title: Back to the Future! Studying Data Cleanness in Defects4J and its Impact
on Fault Localization
- Title（参考訳）: 未来に戻れ!
欠陥4Jにおけるデータの清浄性とその故障局在への影響
- Authors: An Ran Chen, Md Nakhla Rafi, Tse-Hsun (Peter) Chen, Shaohua Wang
- Abstract要約: 我々は,Defects4Jの欠陥トリガテストについて検討し,SBFL技術に関する開発者の知識がもたらす意味を強調した。
バグの再現や回帰テストのために,障害トリガテストの55%が新たに追加されたことが分かりました。
また、バグレポートの作成後に障害トリガテストの22%が修正され、バグに関する開発者の知識が含まれています。
- 参考スコア（独自算出の注目度）: 5.9225620202281455
- 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（参考訳）: ソフトウェアテスト研究において、欠陥4jは主要なベンチマークデータセットとして注目され、有名なオープンソースシステムから実際のバグを研究するための制御された環境を提供する。
しかし、以前の調査では、Defects4Jには、バグ後レポートの追加テスト、開発者の知識の埋め込み、障害のローカライゼーションの有効性に影響する可能性がある。
本稿では,sbfl技術における開発者知識の意義を強調し,欠陥4jのフォールトトリガーテストについて検討する。
バグレポートの作成に関するこれらのテストの変更のタイムラインを調査した。
そこで本研究では,SBFL技術の有効性について検討した。
私たちはそれを見つけました
1) フォールトトリガーテストの55%が新たに追加され,バグの複製や回帰テストが行われた。
2) 障害トリガテストの22%は,バグレポート作成後に修正され,バグに関する開発者の知識が含まれている。
3) 開発者はしばしば、新しいアサーションを含むようにテストを変更したり、ソースコードの変更を反映するようにテストコードを変更する。
4) sbfl技術の性能は、開発者知識のないバグで評価した場合、著しく低下する(平均1ランクで-415%まで)。
我々は、開発者洞察のないバグのデータセットを提供し、欠陥4jにおける将来の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)
関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。
指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。