测试是 Fuchsia 贡献者为保持质量和速度而实践的持续集成流程的核心。好的测试会成为团队的财富，而糟糕的测试则会成为负担。
本文档回顾了与 Fuchsia 测试相关的主题，并提供了指向其他资源的参考链接。本文档假定您熟悉一般的软件测试概念。
Fuchsia 平台测试应服务于项目目标，并符合 Fuchsia 的架构原则：
- 简单：简单的测试比复杂的测试更好。单元测试优于集成测试、系统测试或手动测试。Fuchsia 上的测试解决方案应使用生产环境中存在的相同机制。
- 安全：测试受适用于生产软件的相同安全性、隔离和密封机制的约束。测试会利用这些相同的机制来获益。系统的安全属性是可测试的。
- 可更新：务必测试稳定版 Fuchsia 系统接口的组件和其他部分之间的稳定接口。如果被测组件发生更改或被完全替换，那么仅测试组件之间接口的测试应继续正常运行。Fuchsia 树之外的测试不应假设平台组件的实现细节。
- 高性能：Fuchsia 上的测试应快速、可靠且灵活。测试运行速度快，可更轻松地进行迭代，并减少资源消耗。测试不应不稳定，也不应挑剔在 Fuchsia 上的运行方式。在模拟器上运行测试比在真实硬件上运行测试更简单。
Fuchsia 上的测试有何不同？
操作系统是复杂的程序
软件开发和测试的每个领域都面临着独特的挑战。测试操作系统有其特殊的问题和解决方案，就像测试移动应用、服务器软件或航天器一样。
例如，Zircon 内核的测试在特殊的运行时环境中运行，该环境尽可能少地假设内核是正常运行的，并且可以检测低级内核代码中的错误。与此形成对比的是典型的应用测试，其中测试在假设为正常运行的某个操作系统上运行。
隔离和密封性
组件框架通过在组件清单中严格定义的沙盒环境中运行每个组件，来促进 Fuchsia 实现安全目标。然后，它通过仅允许组件使用那些类型为可更新合约的组件功能进行互连，来推进 Fuchsia 的可更新性目标。
测试还可以使用这些相同的隔离和密封机制作为一种依赖项注入形式。例如，受测组件可以通过测试框架获得其所依赖的功能的测试替身，从而更轻松地进行合约测试。
多个代码库
Fuchsia 是一个大型项目，具有许多外部依赖项，并且针对数百个其他源代码库进行构建。多代码库开发给测试带来了独特的挑战。一位参与 WebRTC 项目的贡献者发布了一篇博文，详细介绍了开发 Fuchsia 时遇到的许多问题和解决方案。