Android持续集成中的仪器测试：实践、模式与性能
Android Instrumentation Testing in Continuous Integration: Practices, Patterns, and Performance
AI总结：
研究Android持续集成中仪器测试的实践、模式及性能，发现仅10.6%的仓库使用仪器测试，常用社区组件或自定义脚本设置模拟器，不同设置方式在可靠性、效率和成本上有差异。
摘要：
Android仪器测试（端到端测试，运行在设备或模拟器上）能发现简单测试无法捕捉的问题。然而，在持续集成（CI）中自动运行这些测试往往困难，因为模拟器设置脆弱且配置易漂移。我们通过分析4,518个使用CI的开源Android应用仓库（快照：2025年8月10日），研究CI工作流文件、脚本和构建配置，识别设备设置在Gradle中定义的情况（例如Gradle管理的设备）。我们的结果回答了关于采用、演变和结果的三个问题。首先，仅约10%的仓库（481/4,518；10.6%）在CI中运行仪器测试，通常使用可重用的社区组件或仓库特定的自定义脚本设置模拟器。其次，这些设置通常随时间保持不变；当变化发生时，项目倾向于从自定义脚本转向可重用的社区组件。第三，我们通过分析提交、拉取请求和问题消息，研究项目为何改变CI设置。我们使用GitHub Actions运行和步骤级元数据（如结果、持续时间、重跑和队列延迟）评估不同设置方式的性能。我们发现团队经常改变方法以扩展测试覆盖范围，每种方法适合不同需求：基于社区的设置通常是最可靠和高效的日常检查，第三方设备实验室适合计划的回归测试但成本更高且失败更多，自定义脚本提供灵活性但与更多重跑相关。
英文摘要：
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.
机构、总结、中文摘要均由AI分析而来，可能存在错误，请以论文正文为准。
