本文档整理了在 Fuchsia 上与测试片交互的最佳实践。
背景：什么是不稳定测试？
不稳定的测试是指在使用完全相同的代码修订版本运行时，有时会通过，有时会失败的测试。
不稳定的测试是不好的，因为它们：
- 我们的提交队列 (CQ) 基础架构可能会导致实际 bug 被遗漏。
- 降低其他有用的测试的值。
- 提高 CQ 的失败率，从而增加修改代码的延迟时间。
本文档适用于测试片，但不适用于基础架构片。
要求：不稳定的测试的目标
- 应尽快从 CQ 的关键路径中移除抖动。
- 由于 flake 本身为失败测试，因此从 CQ 中取出后，不应忽略 flake 问题。它们代表了需要解决的真实问题。
- 测试随时都有可能出现波动，因此，这些 bug 的观察者可能不是最有能力修复 bug 的人。报告 bug 的过程必须快速、简单，并且与诊断和修补分离。
政策
下面提供了薄片的预期和建议的生命周期：
- CI 或 CQ 中的测试不稳定。
- 识别：测试被自动识别为不稳定的测试。
- 跟踪：系统会自动针对 Flake 组件下已确定的 Flake 提交问题。
- 移除：立即从 CQ 中移除该测试。
- 修正：违规测试已离线修复并重新启用。
辨识
我们目前正在使用岩石提取工具识别绝大多数碎片。
该工具会在 CQ 中查找失败的测试，其中同一测试在同一组的补丁上重试时同一测试会成功。
移除
应该优先考虑从提交队列中删除该测试。这可以通过以下方式实现：
- 如果最近的补丁已提示该漏洞：提交触发此漏洞的补丁的还原。
- 停用测试。
建议采用上述机制，因为它们可以消除不稳定的测试，并防止提交队列变得不可靠。最好使用第一个选项（还原代码），但它不像第二个选项（停用测试）那么简单，这会降低测试覆盖率。重要的是，这些选项都无法阻止对问题诊断和修复，但允许离线处理。
不建议在未先从 CQ 中移除测试的情况下尝试修复测试。这会导致 CQ 对于所有其他贡献者而言不可靠，从而使得其他不稳定问题在代码库中复合存在。
修正
此时，您可以接受提交的问题，在本地重新启用测试，然后重现失败问题。这样他们就能找到根本原因，并解决问题。问题解决后，您可以关闭 bug，并重新启用测试。如果任何还原的补丁需要重新登陆，可以安全地重新登陆。
修复不稳定问题时，通过测试 CQ 中的不稳定来验证修复。