論文の概要: Android Instrumentation Testing in Continuous Integration: Practices, Patterns, and Performance

• arxiv url: http://arxiv.org/abs/2604.03438v1
• Date: Fri, 03 Apr 2026 20:24:19 GMT
• ステータス: 翻訳完了
• システム内更新日: 2026-04-07 15:49:18.579197
• Title: Android Instrumentation Testing in Continuous Integration: Practices, Patterns, and Performance
• Title（参考訳）: Android Instrumentation Testing in Continuous Integration: プラクティス、パターン、パフォーマンス
• Authors: Hamid Parsazadeh, Taher A. Ghaleb, Safwat Hassan,
• Abstract要約: オープンソースAndroidアプリが継続的インテグレーションでインスツルメンテーションテストを実行する方法について検討する。 CIでインスツルメンテーションテストを実行するのは10人に1人だけです。 テストカバレッジを拡大するために、しばしばアプローチを変更します。
• 参考スコア（独自算出の注目度）: 0.0
• License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/
• Abstract: Android instrumentation tests (end-to-end tests that run on a device or emulator) can catch problems that simpler tests miss. However, running these tests automatically in continuous integration (CI) is often difficult because emulator setup is fragile and configurations tend to drift over time. We study how open-source Android apps run instrumentation tests in CI by analyzing 4,518 repositories that use CI (snapshot: Aug. 10, 2025). We examine CI workflow files, scripts, and build configurations to identify cases where device setup is defined in Gradle (e.g., Gradle Managed Devices). Our results answer three questions about adoption, evolution, and outcomes. First, only about one in ten repositories (481/4,518; 10.6%) run instrumentation tests in CI, typically using either reusable community components or repository-specific custom scripts to set up emulators. Second, these setups usually stay the same over time; when changes happen, projects tend to move from custom scripts toward reusable community components. Third, we study why projects change their CI setup by analyzing their commits, pull requests, and issue messages. We evaluate how different setup styles perform using GitHub Actions run- and step-level metadata (e.g., outcomes, duration, reruns, and queue delay). We find that teams often change approaches to expand test coverage, and that each approach fits different needs: community-based setups are typically the most reliable and efficient for everyday checks on new code, third-party device labs suit scheduled regression testing but can be costlier and fail more often, and custom scripting provides flexibility but is associated with more reruns.
• Abstract（参考訳）: Androidインスツルメンテーションテスト(デバイスまたはエミュレータ上で実行されるエンドツーエンドテスト)は、単純なテストが見逃す問題に対処できる。 しかしながら、これらのテストを自動的に継続的インテグレーション(CI)で実行することは、エミュレータのセットアップが脆弱で、構成が時間の経過とともにドリフトする傾向があるため、しばしば難しい。 私たちは、CIを使用する4,518のリポジトリを分析することで、オープンソースのAndroidアプリがCIでインスツルメンテーションテストを実行する方法を研究します(スナップショット:8月10日、2025年8月10日)。 デバイスセットアップがGradle(Gradle Managed Devicesなど)で定義されているケースを特定するために、CIワークフローファイル、スクリプト、ビルド設定を調べます。 私たちの結果は、採用、進化、成果に関する3つの質問に答えます。 まず、10のリポジトリのうち1つ(481/4,518; 10.6%)がCIでインスツルメンテーションテストを実行している。 変更が発生すると、プロジェクトはカスタムスクリプトから再利用可能なコミュニティコンポーネントに移行する傾向があります。 第3に、コミットの分析、プルリクエスト、メッセージ発行によって、プロジェクトがCIセットアップを変更する理由を調べます。 私たちは、GitHub Actionsの実行とステップレベルのメタデータ(例えば、結果、期間、再実行、キュー遅延)を使用して、異なるセットアップスタイルがどのように機能するかを評価します。 コミュニティベースのセットアップは、新しいコードに対する日々のチェックにおいて最も信頼性が高く効率的であるのが一般的である、サードパーティのデバイスラボはスケジュールされた回帰テストに適合するが、よりコストが高く、より失敗する可能性がある、カスタムスクリプティングは柔軟性を提供するが、より多くの再実行と関連している、といったものだ。

関連論文リスト

• ImpossibleBench: Measuring LLMs' Propensity of Exploiting Test Cases [58.411135609139855]
  タスク完了のための「ショートカット」は、大規模言語モデルの信頼性評価と展開に重大なリスクをもたらす。 我々は,LLMエージェントがテストケースを利用するための正当性を測定するベンチマークフレームワークであるImpossibleBenchを紹介する。 実践的なフレームワークとして、ImpossibleBenchは単なる評価ではなく、汎用的なツールである。
  論文  参考訳（メタデータ） (2025-10-23T06:58:32Z)
• SwingArena: Competitive Programming Arena for Long-context GitHub Issue Solving [90.32201622392137]
  We present SwingArena, a competitive evaluation framework for Large Language Models (LLMs)。 従来の静的ベンチマークとは異なり、SwingArenaはLLMをイテレーションとして組み合わせて、テストケースを作成し、継続的インテグレーション(CI)パイプラインを通じてパッチを検証するパッチとレビュアーを生成することで、ソフトウェアのコラボレーションプロセスをモデル化する。
  論文  参考訳（メタデータ） (2025-05-29T18:28:02Z)
• EnvBench: A Benchmark for Automated Environment Setup [76.02998475135824]
  大規模言語モデルにより、研究者はソフトウェア工学領域における実用的なリポジトリレベルのタスクに集中できるようになった。 環境設定に関する既存の研究は革新的なエージェント戦略を導入しているが、その評価は小さなデータセットに基づいていることが多い。 このギャップに対処するため、包括的環境設定ベンチマークEnvBenchを紹介します。
  論文  参考訳（メタデータ） (2025-03-18T17:19:12Z)
• Commit0: Library Generation from Scratch [77.38414688148006]
  Commit0は、AIエージェントにスクラッチからライブラリを書くよう促すベンチマークである。 エージェントには、ライブラリのAPIを概説する仕様文書と、インタラクティブなユニットテストスイートが提供されている。 Commit0はまた、モデルが生成したコードに対して静的解析と実行フィードバックを受け取る、インタラクティブな環境も提供する。
  論文  参考訳（メタデータ） (2024-12-02T18:11:30Z)
• CI/CD Configuration Practices in Open-Source Android Apps: An Empirical Study [0.1433758865948252]
  継続的インテグレーションと継続的デリバリ(CI/CD)は、ソフトウェアシステムを自動的にビルド、テスト、パッケージ、デプロイする、十分に確立されたプラクティスです。 モバイルアプリには、さまざまなエミュレータのテストやアプリストアへのデプロイなど、CI/CDプラクティスに関する特徴がある。 一般的なCI/CDサービスを4つ採用した2,557のAndroidアプリで,CI/CDプラクティスに関する実証的研究を行っている。
  論文  参考訳（メタデータ） (2024-11-09T05:46:43Z)
• Observation-based unit test generation at Meta [52.4716552057909]
  TestGenは、アプリケーション実行中に観察された複雑なオブジェクトのシリアライズされた観察から作られたユニットテストを自動的に生成する。 TestGenは518のテストを本番環境に投入し、継続的統合で9,617,349回実行され、5,702の障害が見つかった。 評価の結果,信頼性の高い4,361のエンドツーエンドテストから,少なくとも86%のクラスでテストを生成することができた。
  論文  参考訳（メタデータ） (2024-02-09T00:34:39Z)
• Asynchronous Integration of Real-Time Simulators for HIL-based Validation of Smart Grids [0.08796261172196743]
  本稿では,実時間シミュレータを協調シミュレーション環境に統合することにより,テストの観点から開放される可能性について考察する。 スマートグリッドアプリケーションは通常、比較的多数の物理デバイス、ソフトウェアコンポーネント、通信技術を含む。
  論文  参考訳（メタデータ） (2023-09-14T11:44:21Z)
• Nirikshak: A Clustering Based Autonomous API Testing Framework [0.0]
  Nirikshakは、REST APIテストのための自立テストフレームワークである。 REST APIテスト手順の実行において、レベル2の自律性を達成する。 Nirikshakはコミュニティ向けのオープンソースソフトウェアとしてhttps://github.com/yashmahalwal/nirikshakで公開されている。
  論文  参考訳（メタデータ） (2021-12-15T18:05:27Z)

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

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