iOS
Android
此页面提供了问题排查帮助，以及有关使用 Firebase Test Lab 运行测试的常见问题解答。此页面中还记录了已知问题。如果您找不到所需内容或者需要其他帮助，请加入 Firebase Slack 上的 #test-lab 频道 ，或与 Firebase 支持团队 联系。
问题排查
为什么我的测试需要很长时间才能完成运行？
如果您在 Test Lab 目录中选择容量级别为“高”的设备，您的测试可能会较快开始；但如果所选设备的容量级别为“低”，则测试可能需要更长时间才能开始运行。此外，如果调用的测试数量远远超过所选设备的容量，则测试可能需要更长时间才能完成。
不过，在以下因素的影响下，在任意设备容量级别运行的测试都可能需要更长时间来完成：
流量（会影响设备可用性和测试速度）。
设备或基础架构故障（可能随时发生）。如需查看 Test Lab 是否有基础架构报错，请参阅 Firebase 状态信息中心 。
如需详细了解 Test Lab 中的设备容量，请相应参阅 Android 平台和 iOS 平台对应的设备容量信息。
为什么我会收到不确定的测试结果？
出现不确定测试结果的原因通常是因为测试运行被取消或者基础架构存在错误。
基础架构错误是由内部 Test Lab 问题（例如网络连接错误或意外设备行为）导致的。在报告不确定结果之前，Test Lab 会在内部多次重试产生基础架构错误的测试运行；不过，您可以使用 failFast 停用这些重试。
如需确定错误的原因，请按以下步骤操作：
在 Firebase 状态信息中心 检查是否存在已知的服务中断故障。
在 Test Lab 中重试测试，以验证能否重现错误。
注意 ：Test Lab 不会针对基础架构错误向您收费。 尝试在其他设备或设备类型上运行测试（如果适用）。
如果问题仍然存在，请在 Firebase Slack 上的 #test-lab 频道 中与 Test Lab 团队联系。
为什么启用分片后测试的运行时间延长？
如果您指定的分片数量超过 Test Lab 中可用的设备数量，分片就可能会导致测试的运行时间延长。为避免这种情况，您可尝试切换到其他设备。如需详细了解如何选择其他设备，请参阅设备容量 。
为什么我的测试需要很长时间才能启动？
在您提交测试请求后，系统会先对应用完成验证、重新签名等操作，为在设备上运行测试做好准备。通常，此过程会在几秒钟内完成，但可能会受到应用大小等因素的影响。
应用准备就绪之后，系统会安排测试作业并将其放入队列，直到有设备准备好运行测试。无论测试作业是正在队列中还是正在运行，在所有测试作业都完成运行之前，矩阵状态都将是“待处理”。
注意 ：测试等待可用设备的这段时间不会计入您的结算时间。
为什么我的测试需要很长时间才能完成？
测试作业完成后，系统会从设备下载测试工件、进行处理并将其上传到 Cloud Storage。此步骤的时长可能会受工件数量和大小的影响。
应用没有返回数据，无法找到屏幕截图
测试作业工件（例如，屏幕截图和日志文件）存储在 Google Cloud Storage 中，并直接呈现到 Firebase 控制台中。如果测试作业在过去 90 天内执行，请确认您已分配项目级层角色（Project Owner、Project Editor 或 Project Viewer）。另请确保您的项目或组织未启用 Cloud Audit Logging。
如果测试作业在 90 天之前执行，系统很可能已经自动删除测试工件。您可以点击 Test Lab 信息中心内的测试结果 标签页来查看结果存储桶配置。默认结果存储桶配置为保留对象 90 天。
如需将测试工件保留更长时间，请运行带有 --results-bucket 标志的 gcloud firebase test android run 命令，并传入结果存储桶的名称。如需了解详情，请访问 gcloud firebase test android run 参考文档
为什么我会收到部分插桩测试用例结果，或者收不到任何结果？
运行插桩测试时，您可能会看到表明仅收到部分结果的测试错误，此类错误会包含类似 Test run failed to complete. Expected
x tests, received y 这样的消息（其中 y 小于 x）。如果出现此错误，则表示 Test Lab 无法对通常由 AndroidJUnitRunner 生成的测试用例开始或结束标记进行 logcat 解析。
以下是导致此问题的常见原因：
问题说明
可能的解决方案
由于超时导致测试用例未能运行。如果测试的总时长超过您指定的超时设置或超过特定超时上限 ，Test Lab 便会取消未完成的剩余测试用例。
请增大矩阵的超时设置，确保所有测试都能完成。
如果未启用分片，请对测试进行分片，以便每个分片运行一部分测试，并在更短的时间内完成。
如果已启用分片，请增加分片数量。
由于过早退出或卡住，测试用例未能完成。测试用例可能会因某个未捕获到的异常或断言错误而过早退出。测试用例可能会陷入无限循环，或者无法继续完成，例如，由于应用未能显示正确的视图而导致测试用例无法在相应的界面中执行所需的操作。
请检查相关视频和 logcat，调查测试停止在哪个位置。
某个自定义测试运行程序（包括扩展的 AndroidJUnitRunner）意外崩溃或向 logcat 写入了意外的测试用例开始或结束标记。
检查测试运行程序代码。
写入 logcat 的日志过多，导致缓冲区过载或导致 logcat 进程崩溃。
减少对 logcat 执行的写入操作。
被测应用崩溃。
调试应用。
常见问题解答
Test Lab 的免费配额是多少？配额用完后，该怎么做？
Firebase Test Lab 提供了用于在设备上运行测试和使用 Cloud API 的免费配额。请注意，测试配额使用标准的 Firebase 定价方案，而 Cloud API 配额不使用此方案。
测试配额
测试配额的大小取决于用于运行测试的设备数量。Firebase Spark 方案为用户提供免费的固定测试配额。而对于 Blaze 方案，如果您的 Google Cloud 用量随时间增加，您的配额可能也会增加。如果您已达到测试配额，请等到次日再继续测试或升级为 Blaze 方案（如果您目前采用的是 Spark 方案）。如果您已采用 Blaze 方案，则可以申请增加配额。如需了解详情，请参阅测试配额 。
您可以在 Google Cloud 控制台 中监控测试配额用量。
Cloud Testing API 配额
Cloud Testing API 有两个配额限制：每个项目每天的请求数和每个项目每 100 秒的请求数。您可以在 Google Cloud 控制台 中监控您的使用情况。
Cloud Tool Results API 配额
Cloud Tool Results API 有两个配额限制：每个项目每天的查询数，以及每个项目每 100 秒的查询数。您可以在 Google Cloud 控制台 中监控您的使用情况。
如需详细了解 API 限制，请参阅 Test Lab 的 Cloud API 配额 。如果您已达到 API 配额，请按以下步骤操作：
如何确定到达后端的流量是否来自 Test Lab？
您可以在后端对照我们的 IP 范围 检查源 IP 地址，从而确定流量是否来自 Firebase 托管的测试设备。
Test Lab 是否支持 VPC-SC？
Test Lab 不支持 VPC-SC，后者会阻止在 Test Lab 的内部存储空间与用户的结果存储桶之间复制应用和其他测试工件。
如何在 Test Lab 中检测不稳定的测试？
如需在测试中检测不稳定行为，建议您使用
--num-flaky-test-attempts
选项。若为解决稳定性问题而重新运行作业，会计入相关费用或每日配额，就与正常的测试作业一样。
请注意以下几点：
系统在检测到失败时会重新运行整个测试作业。不支持仅重试失败的测试用例。
为解决稳定性问题而重试的运行作业亦会安排在同时运行，但不保证会并行运行，例如在流量超出可用设备数量或其他情况下。
注意 ：基础架构错误与稳定功能无关，亦不会为解决稳定性问题而触发重新运行作业。
Test Lab 是否支持穿戴式设备？
是的！Test Lab 支持 Google Pixel Watch。您现在可以在 Google Pixel Watch 上的独立 Wear 应用中运行测试。如需详细了解 Test Lab 设备，请参阅在可用设备上进行测试 。
Test Lab 是否支持最新的 Google 设备？
是的！Test Lab 支持 Google Pixel Tablet 和 Google Pixel Fold。您可以在独立实体设备上运行测试。如需详细了解 Test Lab 设备，请参阅在可用设备上进行测试 。
如何在 Test Lab 中检测正在运行的测试？
如果您正在 Firebase 中测试应用，或者在 Play 管理中心运行测试以获取发布前测试报告 ，可以通过检查 MainActivity 文件中的系统属性 firebase.test.lab 来检测某测试是否正在 Firebase 托管的设备上运行。然后，您就可以基于 testLabSetting 的布尔值执行其他语句。有关详细信息，请参阅修改的测试行为 。
Test Lab 是否支持对经过混淆处理的应用（例如，使用 ProGuard 或 R8 进行过混淆处理）执行测试？
Test Lab 未明确表明支持混淆处理或去混淆处理。虽然应用可能会正常运行，但任何经过混淆处理的应用数据（如堆栈轨迹）在日志中都会被记录为经过混淆处理的内容。
在 Test Lab 中进行测试时，我可以在不同的可折叠状态和姿势下使用可折叠设备吗？
是的！您可以在可折叠状态和姿势 下测试可折叠设备。
可折叠设备可能会处于各种折叠状态，例如 FLATHALF_OPENED
另一方面，姿势包括特定的设备屏幕方向和可折叠状态，例如桌面姿势（在水平屏幕方向下为 HALF_OPENED 状态）或图书姿势（在垂直屏幕方向下为 HALF_OPENED 状态）。
如果您运行插桩测试，可以使用 Jetpack WindowManager 库并按照在可折叠设备上测试应用 文档测试不同的状态和姿势。
或者，可用状态因设备而异，并且可以使用 adb
shell command cmd device_state 与之交互。
如需列出当前状态，请运行 adb shell cmd device_state state。
如需设置或替换当前状态，请运行 adb shell cmd device_state state <IDENTIFIER>。
如需重置状态，请运行 adb shell cmd device_state state reset。
如需检查可用状态，请在可折叠设备上运行 adb shell cmd device_state print-states 命令。
Google Pixel Fold（型号 ID felix）
$ adb shell cmd device_state print-states
Supported states: [
DeviceState{identifier=0, name='CLOSED', app_accessible=true},
DeviceState{identifier=1, name='HALF_OPENED', app_accessible=true},
DeviceState{identifier=2, name='OPENED', app_accessible=true},
DeviceState{identifier=3, name='REAR_DISPLAY_STATE', app_accessible=true},
]
Samsung Galaxy Z Fold4（型号 ID q4q）
$ adb shell cmd device_state print-states
Supported states: [
DeviceState{identifier=0, name='CLOSE', app_accessible=true},
DeviceState{identifier=1, name='TENT', app_accessible=true},
DeviceState{identifier=2, name='HALF_FOLDED', app_accessible=true},
DeviceState{identifier=3, name='OPEN', app_accessible=true},
]
哪些设备最适合进行屏幕截图差异测试？
*.arm) 模拟器设备。Arm 模拟器设备使用与 Android Studio“通用”模拟器高度相似或相同的映像。
我们还建议您调查测试库，这些库有助于在存在预期变更时提高屏幕截图测试的可靠性。
如何启用覆盖率报告？
如需启用覆盖率报告，请将 coverage=true 添加到 environmentVariables 字段
--environment-variables coverage=true,coverageFilePath=/sdcard/Download/
如果您没有使用 Orchestrator，则可以指定一个文件路径，如下所示：
--environment-variables coverage=true,coverageFile=/sdcard/Download/coverage.ec
在哪里可以找到设备详细信息，例如分辨率、支持的 ABI 等？
详细的设备信息可通过 API 获取，并且可以通过 gcloud 客户端使用 describe 命令 进行访问：
gcloud firebase test android models describe MODEL
已知问题
登录人机识别系统
如果用户在登录屏幕上除了输入登录凭据之外还需要执行额外操作（例如完成人机识别系统验证），则 Robo 测试将无法绕过登录屏幕。
界面框架支持
Robo 测试非常适合使用 Android 界面框架中的界面元素（包括 View、ViewGroup 和 WebView 对象）的应用。如果您对使用其他界面框架的应用（包括使用 Unity 游戏引擎的应用）执行 Robo 测试，可能会导致立即退出测试；也就是说，除了首屏，测试不会探索其他任何部分。
