論文の概要: Cross-Project Flakiness: A Case Study of the OpenStack Ecosystem
- arxiv url: http://arxiv.org/abs/2602.09311v1
- Date: Tue, 10 Feb 2026 01:03:28 GMT
- ステータス: 翻訳完了
- システム内更新日: 2026-02-11 20:17:43.305902
- Title: Cross-Project Flakiness: A Case Study of the OpenStack Ecosystem
- Title（参考訳）: プロジェクト間のフレキネス - OpenStackエコシステムのケーススタディ
- Authors: Tao Xiao, Dong Wang, Shane McIntosh, Hideaki Hata, Yasutaka Kamei,
- Abstract要約: Flakinessは、テスト結果に対する開発者の信頼を損ね、計算リソースを浪費し、継続的インテグレーションの信頼性を損なう。
我々は、複数のプロジェクトに影響を与えるフレキネスと、いくつかのプロジェクトでテストがフレキネスを示すが、他のプロジェクトでは安定している不一致フレキネスに焦点を当てる。
これらの調査結果は、複雑なエコシステム間のコーディネーションの改善、CI設定の標準化、テスト分離戦略の改善の必要性を浮き彫りにしたものだ。
- 参考スコア（独自算出の注目度）: 12.704721607953433
- License: http://creativecommons.org/licenses/by/4.0/
- Abstract: Automated regression testing is a cornerstone of modern software development, often contributing directly to code review and Continuous Integration (CI). Yet some tests suffer from flakiness, where their outcomes vary non-deterministically. Flakiness erodes developer trust in test results, wastes computational resources, and undermines CI reliability. While prior research has examined test flakiness within individual projects, its broader ecosystem-wide impact remains largely unexplored. In this paper, we present an empirical study of test flakiness in the OpenStack ecosystem, which focuses on (1) cross-project flakiness, where flaky tests impact multiple projects, and (2) inconsistent flakiness, where a test exhibits flakiness in some projects but remains stable in others. By analyzing 649 OpenStack projects, we identify 1,535 cross-project flaky tests and 1,105 inconsistently flaky tests. We find that cross-project flakiness affects 55% of OpenStack projects and significantly increases both review time and computational costs. Surprisingly, 70% of unit tests exhibit cross-project flakiness, challenging the assumption that unit tests are inherently insulated from issues that span modules like integration and system-level tests. Through qualitative analysis, we observe that race conditions in CI, inconsistent build configurations, and dependency mismatches are the primary causes of inconsistent flakiness. These findings underline the need for better coordination across complex ecosystems, standardized CI configurations, and improved test isolation strategies.
- Abstract（参考訳）: 自動回帰テストは現代のソフトウェア開発の基盤であり、コードレビューや継続的インテグレーション(CI)に直接貢献することが多い。
しかし、いくつかのテストはフレキネスに悩まされ、結果が決定論的に異なる。
Flakinessは、テスト結果に対する開発者の信頼を損ね、計算リソースを浪費し、CIの信頼性を損なう。
以前の研究では、個々のプロジェクトにおけるテストのフレキネスについて検討されてきたが、エコシステム全体の影響はいまだに明らかにされていない。
本稿では,(1)プロジェクト間のフレキネス,(2)プロジェクト間のフレキネス,(2)プロジェクト間のフレキネスを示す不整合フレキネスに着目した,OpenStackエコシステムにおけるテストフレキネスに関する実証的研究を行う。
649のOpenStackプロジェクトを分析することで、1,535のクロスプロジェクトフレキテストと1,105の一貫性のないフレキテストを特定します。
プロジェクト間のフレキネスはOpenStackプロジェクトの55%に影響し、レビュー時間と計算コストの両方を大幅に増加させます。
意外なことに、ユニットテストの70%はプロジェクト間のフラキネスを示しており、統合やシステムレベルのテストといったモジュールにまたがる問題から、単体テストが本質的に絶縁されているという仮定に異議を唱えている。
質的な分析を通じて、CIにおける競合条件、一貫性のないビルド構成、依存性のミスマッチが一貫性のないフレキネスの主な原因であることを観察する。
これらの調査結果は、複雑なエコシステム間のコーディネーションの改善、CI設定の標準化、テスト分離戦略の改善の必要性を浮き彫りにしたものだ。
関連論文リスト
- Flaky Tests in a Large Industrial Database Management System: An Empirical Study of Fixed Issue Reports for SAP HANA [45.467566253448666]
不安定なテストは、同じバージョンのソースコードに対して複数回実行されると、異なる結果をもたらす。
様々な要因がテストのフレキネスを引き起こすことがある。
不安定なテストを修正するアプローチは、通常、特定の原因に対処するために調整される。
論文 参考訳（メタデータ） (2026-02-03T14:03:59Z) - Detecting Flaky Tests in Quantum Software: A Dynamic Approach [4.46640294257026]
コードや環境の変更なしに非決定的に通過または失敗する不安定なテストは、ソフトウェアの信頼性に深刻な脅威をもたらす。
本稿では,量子ソフトウェアにおけるフレキテストの大規模動的評価について述べる。
コントロールされた環境で、23リリースにまたがって1万回のQiskit Terraテストスイートを実行しました。
論文 参考訳（メタデータ） (2025-12-19T21:47:31Z) - The Ever-Evolving Science Exam [69.20851050366643]
本研究では,基礎モデルの科学的能力を確実に評価するための動的ベンチマークであるEver-Evolving Science Exam (EESE)を紹介する。
1)5つの分野と500以上のサブフィールドにまたがる専門的な科学インスタンス(問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ-問合せ)から構成される。
論文 参考訳（メタデータ） (2025-07-22T12:22:16Z) - Systemic Flakiness: An Empirical Analysis of Co-Occurring Flaky Test Failures [6.824747267214373]
不安定なテストは、コードの変更なしに一貫性のない結果をもたらす。
開発者は、毎月2250ドル(約2万5000円)の費用で、不気味なテストの修理に1.28%を費やしている。
フラキーテストは、しばしばクラスタ内に存在し、同じ根本原因を共有する共起失敗は、系統的なフレキネス(systemic flakiness)と呼ばれる。
論文 参考訳（メタデータ） (2025-04-23T14:51:23Z) - Do Test and Environmental Complexity Increase Flakiness? An Empirical Study of SAP HANA [47.29324864511411]
不安定なテストはコードの変更なしにランダムに失敗する。
テストの特徴と,テストのフレキネスに影響を与える可能性のあるテスト環境について検討する。
論文 参考訳（メタデータ） (2024-09-16T07:52:09Z) - Automating Dataset Updates Towards Reliable and Timely Evaluation of Large Language Models [81.27391252152199]
大規模言語モデル(LLM)は、さまざまな自然言語ベンチマークで素晴らしいパフォーマンスを実現している。
本稿では、データセットの自動更新と、その有効性に関する体系的な分析を提案する。
1) 類似したサンプルを生成するための戦略を模倣すること,2) 既存のサンプルをさらに拡張する戦略を拡張すること,である。
論文 参考訳（メタデータ） (2024-02-19T07:15:59Z) - FlaPy: Mining Flaky Python Tests at Scale [14.609208863749831]
FlaPyは、研究者がテストスイートを再実行することによって、与えられた、あるいは自動的にサンプルされたPythonプロジェクトの集合で、不安定なテストをマイニングするためのフレームワークである。
FlaPyはコンテナ化と新しい実行環境を使用してテスト実行を分離し、実際のCI条件をシミュレートする。
FlaPyはSLURMを使ってテスト実行の並列化をサポートしており、数千のプロジェクトをスキャンしてテストのフレキネスをスキャンすることができる。
論文 参考訳（メタデータ） (2023-05-08T15:48:57Z) - Noisy Adaptive Group Testing using Bayesian Sequential Experimental
Design [63.48989885374238]
病気の感染頻度が低い場合、Dorfman氏は80年前に、人のテストグループは個人でテストするよりも効率が良いことを示した。
本研究の目的は,ノイズの多い環境で動作可能な新しいグループテストアルゴリズムを提案することである。
論文 参考訳（メタデータ） (2020-04-26T23:41:33Z)
関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。
指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。