論文の概要: 230,439 Test Failures Later: An Empirical Evaluation of Flaky Failure
Classifiers
- arxiv url: http://arxiv.org/abs/2401.15788v1
- Date: Sun, 28 Jan 2024 22:36:30 GMT
- ステータス: 処理完了
- システム内更新日: 2024-01-30 16:39:44.922055
- Title: 230,439 Test Failures Later: An Empirical Evaluation of Flaky Failure
Classifiers
- Title(参考訳): 230,439 テスト障害後:flaky障害分類器の実証評価
- Authors: Abdulrahman Alshammari, Paul Ammann, Michael Hilton, Jonathan Bell
- Abstract要約: 不安定なテストは、コードの変更がなくても、決定論的にパスまたはフェールできるテストである。
欠陥が原因でテストが失敗したのか、それともバグを検知したのか、どうやって簡単に判断できるのか?
- 参考スコア(独自算出の注目度): 9.45325012281881
- License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/
- Abstract: Flaky tests are tests that can non-deterministically pass or fail, even in
the absence of code changes.Despite being a source of false alarms, flaky tests
often remain in test suites once they are detected, as they also may be relied
upon to detect true failures. Hence, a key open problem in flaky test research
is: How to quickly determine if a test failed due to flakiness, or if it
detected a bug? The state-of-the-practice is for developers to re-run failing
tests: if a test fails and then passes, it is flaky by definition; if the test
persistently fails, it is likely a true failure. However, this approach can be
both ineffective and inefficient. An alternate approach that developers may
already use for triaging test failures is failure de-duplication, which matches
newly discovered test failures to previously witnessed flaky and true failures.
However, because flaky test failure symptoms might resemble those of true
failures, there is a risk of missclassifying a true test failure as a flaky
failure to be ignored. Using a dataset of 498 flaky tests from 22 open-source
Java projects, we collect a large dataset of 230,439 failure messages (both
flaky and not), allowing us to empirically investigate the efficacy of failure
de-duplication. We find that for some projects, this approach is extremely
effective (with 100\% specificity), while for other projects, the approach is
entirely ineffective. By analyzing the characteristics of these flaky and
non-flaky failures, we provide useful guidance on how developers should rely on
this approach.
- Abstract(参考訳): フレーキーテスト(Fraky test)は、コードの変更がなくても、決定論的にパスまたはフェールできるテストである。誤ったアラームのソースであるにもかかわらず、フレーキーテストは検出された後にテストスイートに留まることが多い。
したがって、フレキテスト研究における重要なオープンな問題は、フレキネスによってテストが失敗したのか、バグを検出したのかを素早く判断する方法である。
テストが失敗すると、それが定義によって不安定になります。もしテストが永続的に失敗すると、おそらく本当の失敗になります。
しかし、このアプローチは非効率かつ非効率である。
開発者がすでにテストの失敗をトリアージするために使用している別のアプローチは、新しく発見されたテストの失敗と、以前目撃した不安定で真の失敗にマッチする、障害の重複解消である。
しかし、フレキなテスト失敗の症状は真の失敗の症状と似ているため、本当のテスト失敗を無視されるフレキな失敗として誤分類するリスクがある。
22のオープンソースjavaプロジェクトの498のflakyテストのデータセットを使用して、230,439件の障害メッセージ(flakyとnotの両方)の大規模なデータセットを収集し、障害の重複排除の有効性を実証的に調査しました。
プロジェクトによっては、このアプローチが極めて効果的である(100\%の特異性を持つ)ことが分かっていますが、他のプロジェクトでは、アプローチは完全に非効率です。
これらの不安定で非脆弱な障害の特徴を分析することで、開発者はこのアプローチにどう依存すべきか、有用なガイダンスを提供します。
関連論文リスト
- Do Test and Environmental Complexity Increase Flakiness? An Empirical Study of SAP HANA [47.29324864511411]
不安定なテストはコードの変更なしにランダムに失敗する。
テストの特徴と,テストのフレキネスに影響を与える可能性のあるテスト環境について検討する。
論文 参考訳(メタデータ) (2024-09-16T07:52:09Z) - GPT-HateCheck: Can LLMs Write Better Functional Tests for Hate Speech Detection? [50.53312866647302]
HateCheckは、合成データに対してきめ細かいモデル機能をテストするスイートである。
GPT-HateCheckは,スクラッチからより多彩で現実的な機能テストを生成するフレームワークである。
クラウドソースのアノテーションは、生成されたテストケースが高品質であることを示しています。
論文 参考訳(メタデータ) (2024-02-23T10:02:01Z) - Taming Timeout Flakiness: An Empirical Study of SAP HANA [47.29324864511411]
不安定なテストは回帰テストに悪影響を及ぼします。
テストタイムアウトは、このような不安定なテストの失敗に寄与する要因のひとつです。
テストのフレキネス率は、繰り返しテストの実行回数によって49%から70%の範囲である。
論文 参考訳(メタデータ) (2024-02-07T20:01:41Z) - The Effects of Computational Resources on Flaky Tests [9.694460778355925]
不安定なテストは、不確定にパスし、変更のないコードで失敗するテストである。
リソースに影響されたFraky Testsは、テストの実行時に利用可能なリソースを調整することで、かなりの数のFraky-test障害を回避することができることを示している。
論文 参考訳(メタデータ) (2023-10-18T17:42:58Z) - Just-in-Time Flaky Test Detection via Abstracted Failure Symptom
Matching [11.677067576981075]
大規模な産業用ソフトウェアシステムであるSAPの継続的インテグレーションパイプラインにおいて、障害症状を使用して、不安定なテスト障害を特定します。
本法では, 再発性難聴の診断に障害症状を用いることで, 少なくとも96%の精度を達成できる可能性が示唆された。
論文 参考訳(メタデータ) (2023-10-10T04:15:45Z) - Do Automatic Test Generation Tools Generate Flaky Tests? [12.813573907094074]
テスト生成ツールが生成するフレキなテストの頻度と性質はほとんど不明である。
EvoSuite(Java)とPynguin(Python)を使ってテストを生成し、各テストは200回実行します。
この結果から, フレキネスは開発者の手書きテストと同様, 生成テストでも一般的であることが判明した。
論文 参考訳(メタデータ) (2023-10-08T16:44:27Z) - Perfect is the enemy of test oracle [1.457696018869121]
テストのオーラクルは、テストが失敗する(バグを検出する)か通過するかを判断するために、正しい動作とバギーな動作を区別できる地平線に依存しています。
本稿では,テストアサーションが存在しない場合には,テスト対象のメソッド(MUT)で単体テストが通過するか失敗するかを判定できる,学習に基づくSEERを提案する。
さまざまなオープンソースのJavaプロジェクトから5K以上のユニットテストにSEERを適用する実験は、生成したオラクルがフェールやパスラベルを予測するのに有効であることを示している。
論文 参考訳(メタデータ) (2023-02-03T01:49:33Z) - On the use of test smells for prediction of flaky tests [0.0]
不安定な検査は 検査結果の評価を妨げ コストを増大させる
既存のテストケース語彙の使用に基づくアプローチは、文脈に敏感であり、過度に適合する傾向がある。
フレキな検査の予測因子として, 試験臭の使用について検討した。
論文 参考訳(メタデータ) (2021-08-26T13:21:55Z) - Double Perturbation: On the Robustness of Robustness and Counterfactual
Bias Evaluation [109.06060143938052]
テストデータセットを超えたモデル弱点を明らかにするための"ダブル摂動"フレームワークを提案する。
この枠組みを,モデルの頑健さと英語における反事実バイアスの分析に使用される2つの摂動に基づくアプローチに応用する。
論文 参考訳(メタデータ) (2021-04-12T06:57:36Z) - Understanding Classifier Mistakes with Generative Models [88.20470690631372]
ディープニューラルネットワークは教師付き学習タスクに有効であるが、脆弱であることが示されている。
本稿では、生成モデルを利用して、分類器が一般化に失敗するインスタンスを特定し、特徴付ける。
我々のアプローチは、トレーニングセットのクラスラベルに依存しないため、半教師付きでトレーニングされたモデルに適用できる。
論文 参考訳(メタデータ) (2020-10-05T22:13:21Z) - Cross-validation Confidence Intervals for Test Error [83.67415139421448]
この研究は、クロスバリデーションのための中心極限定理と、学習アルゴリズムの弱い安定性条件下での分散の一貫した推定器を開発する。
結果は、一般的な1対1のクロスバリデーションの選択にとって、初めてのものだ。
論文 参考訳(メタデータ) (2020-07-24T17:40:06Z)
関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。
指定された論文の情報です。
本サイトの運営者は本サイト(すべての情報・翻訳含む)の品質を保証せず、本サイト(すべての情報・翻訳含む)を使用して発生したあらゆる結果について一切の責任を負いません。