| RFC-0221：用于树外系统测试的 Python | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 批准 Python 用于树外系统测试。 |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2023-04-27 |
| 审核日期（年-月-日） | 2023-06-13 |
摘要
批准 Python 用于树外 (OOT) 系统测试。
设计初衷
众所周知，Fuchsia 需要改进面向最终开发者的系统测试支持。随着驱动程序开发转向树外 (OOT)，通过 SDK 交付标准化系统测试解决方案以支持硬件资格认证的需求变得迫切。
在开始这项工作之前，需要先选择用于构建解决方案的编程语言。本文档通过提出评估标准并为每种语言提供数据点，考虑了各种用于 OOT 系统测试的编程语言。评估练习的结果将用于就 Fuchsia 应使用哪种编程语言来满足当今的 OOT 系统测试需求提出明智的建议。
利益相关方
辅导员：
- David Moore (davemoore@google.com)
待定
审核者：
- abarth@google.com
- cpu@google.com
- jamesr@google.com
- keir@google.com
- rlb@google.com
已咨询：
- amituttam@google.com
- crjohns@google.com
- dannyrosen@google.com
- dworsham@google.com
- fmeawad@google.com
- guptaritu@google.com
- jeremymanson@google.com
共同化：
OOT 系统测试评估标准以及对考虑的每种编程语言的评估结果已在 Google 文档中与 FEC、测试架构团队、测试基础设施团队和工具团队的成员进行了讨论。
定义
- 系统测试通常称为 E2E 或 CUJ 测试，是对完整组装的系统进行的测试，用于验证系统是否满足特定要求。如需了解全面的定义，请参阅什么是系统测试？。
商品要求
产品动机和要求的摘要，旨在支持针对 Fuchsia 的下一代 OOT 系统测试。
主要用户：测试 Fuchsia 平台和产品的开发者和系统集成商。
环境：树内，以及 SDK 交付到的所有环境和 petal。
策略
- 将使用情形范围限定为涉及一个或多个目标设备的端到端设备测试。
- 提供将现有 SL4F 测试和用户迁移到新框架的途径。
- 解决 SL4F 现有的痛点，重点在于以易于使用的语言编写测试的人体工程学。
- 确保与 Google 的端到端测试框架轻松集成。
- 投资开发 Fuchsia 用户要求的其他功能，以满足平台测试需求（例如，性能监控、内存用量等）。
选择编程语言的重要性
测试框架的采用在很大程度上取决于语言选择。一种易于使用的语言，已广泛应用于此系统测试用例，这对于将用户群扩展到核心 SWE 之外，并纳入测试工程师和系统集成商非常有益。
评估准则
每种语言（TypeScript 和 JavaScript 除外）的总体优缺点已在 Fuchsia 编程语言政策 (FPLP) 中详细记录。本文档中使用的指标涵盖了与 OOT 系统测试特别相关的语言方面。
评估标准（排名不分先后）：
生态系统采用情况：OOT 系统测试空间中的语言普及程度
- 一种主流且广泛使用的系统测试语言有利于 OOT 的采用。
- 优先选择已在 OOT 客户代码库中用于系统测试的语言。
人体工程学：语言对常见系统测试使用模式的支持程度
- 一种常见的系统测试模式是协调主机-设备互动，例如在受测 Fuchsia 设备 (DUT) 上触发 API 并断言行为。与传统的 Fuchsia 平台开发相比，这种使用方式受益于一组不同的语言功能；以下是一些主要区别：
- 优先考虑开发敏捷性而非性能。
- 首选自动内存管理和垃圾回收。
- 主机上的测试性能通常是一个次要考虑因素。
- 偏好使用交互模式/REPL 进行快速原型设计。
- 较大的二进制文件/源代码占用空间不太有害。
- 异步语言支持是一项锦上添花的功能，但并非必需。
- 系统测试通常是较小的项目，代码行数只有数百行。偏好可读性高的语言，以便轻松检查几百行代码的正确性。（测试是生产代码，但本身往往没有经过充分测试 - 因此易于进行正确性推理非常有用）。
- 优先考虑开发敏捷性而非性能。
- 一种常见的系统测试模式是协调主机-设备互动，例如在受测 Fuchsia 设备 (DUT) 上触发 API 并断言行为。与传统的 Fuchsia 平台开发相比，这种使用方式受益于一组不同的语言功能；以下是一些主要区别：
Fuchsia 可移植性：易于在主机和 Fuchsia 目标平台上运行
- 虽然本文档中评估的语言将主要用作宿主语言，但存在只能通过目标驱动方式（例如使用未导出到宿主的接口、只能在目标端实现的定时和吞吐量保证）完成的测试用例；因此，考虑语言的可移植性以在 Fuchsia 目标上运行以进行系统测试非常重要。使用可移植语言进行系统测试还具有可重用性优势（例如，在主机和目标平台上重用编码/解码等通用逻辑）。
所需投资：将 OOT 系统测试解决方案投入生产所需的工作
- 了解特定语言的差距有助于我们在时间和资源有限的情况下更好地比较替代方案。
- 以下是一些需要投资的示例：
- 构建支持
- 现有库支持
- 测试框架开发
- 主机-设备互动库和工具（例如 SL4F 支持）
- SDK 中的语言支持
- 文档和开发者教育
可维护性：维持 OOT 系统测试解决方案所需的工作
- 根据所选语言，人员配置要求、代码健康状况和技术债务可能会产生长期影响。
- 可维护性方面的示例：
- 运行时可更新性 - 能够在不影响 OOT 用户的情况下更新运行时。
- Fuchsia API 版本控制 - 用于防止因 Fuchsia API 更改而导致 OOT 损坏的工具。例如，如何检测导出到 OOT 用户的系统测试 API 中的重大更改。
- 代码运行状况
- 大型软件项目通常受益于静态类型化等语言功能。
- 轻松启用自动化静态分析工具（例如 linter、覆盖率等）。
正在考虑添加的语言
本部分介绍了正在考虑用于 OOT 系统测试的几种语言，并提供了支持/反对每种评估指标的证据。为了简化语言之间的比较，评估标准中每种语言的每个类别都会获得“不可行”“差”“一般”或“好”的得分。
Go
生态系统采用情况：中性
- 中性：Go 是一种总体上很受欢迎的语言（TIOBE、PYPL），但没有证据表明 Go 在 Fuchsia 现有 OOT 合作伙伴的系统测试领域得到广泛使用。
- 优点：有证据表明，在广泛的实际测试解决方案中，Go 被用于系统测试：
- Chromium 在 Tast 项目中使用 Go。
- GCP Android 系统测试是用 Go 编写的。
人体工学：良好
- 优点：使用这种语言的人效率很高 (FPLP)。
- 优点：支持垃圾回收并提供内存安全保证 (FPLP)。
- 优点：Goroutine 使异步通信紧凑且更易于推理。
- 缺点：对于交互式系统测试开发，编译型语言不如脚本语言理想。
Fuchsia 可移植性：中性
所需投资：中等
- 缺点：此语言中未实现通用的树内系统测试解决方案。
- 在 System OTA tests 中，有一些基于 Go 的系统测试的现有技术，但没有通用的解决方案来支持所有类型的系统测试（例如多设备测试）。
- 没有通用的主机到 Fuchsia 设备互动库。
- 优点：Fuchsia 源代码中存在 SL4F 客户端库。
- 中性：需要投入与考虑的其他语言类似的 OOT 资源。
- 来源分布
- 中性：投资与其他语言类似。
- 静态分析
- 优点：
gofmt和govet已在 Fuchsia CI 中启用。
- 优点：
- Bazel 集成
- 优点：Bazel 构建系统支持 Go。
- 来源分布
可维护性：良好
- 优点：可更新性 - 没有证据表明存在严重的可更新性问题。
- 有工具可用于重写 Go 文件，使其符合新的 Go 版本
- https://pkg.go.dev/cmd/fix.
- 优点：代码健康状况 - 静态类型化语言有利于 OOT 代码的健康状况。
- 中性：Fuchsia API 版本控制 - 需要投入资金进行 API 版本控制，类似于考虑中的其他语言。
Python
生态系统采用率：良好
- 优点：Python 是一种非常流行的语言（TIOBE、PYPL）。
- Python 是行业内发展最快的主要编程语言，也是顶尖大学中广泛教授的语言。
- 在 GitHub 活动方面，Python 仅次于 JavaScript，这表明 Python 正在积极开发中。
- 优点：Mobly 是一种开源多设备端到端测试框架，是 Google 内部进行多设备系统测试的理想选择。
人体工学：良好
Fuchsia 可移植性：中性
- 优点：Python 是一种可移植的语言，适用于所有现有的宿主平台，并且最终应在 Fuchsia 上得到全面支持，以便 Fuchsia 成为可行的通用操作系统。
- 缺点：Python 具有庞大的运行时环境，并且在 Fuchsia 中支持 Python 运行时方面没有先例；因此，支持 Python 所需的投资将非常巨大。
所需投资：良好
优点：基于 Python Mobly 的系统测试解决方案已存在于树内。
- 优点：存在 SL4F 客户端库。
优点：Fuchsia 中的 Pigweed 在 Python 方面投入了大量资源。
中性：需要投入与考虑的其他语言类似的 OOT。
可维护性：差（投资后为中等）
- 缺点（投资后为中性）：可更新性 - 需要投资于 Python 静态分析工具才能达到中性得分，否则 Python 的大型运行时接口和非编译语言的特性会导致运行时更新时出现中断的可能性更高，并且难以断言运行时支持。
- 优点：可更新性 - RFC-0129 确立了树内 Python 最佳实践（例如 Python 3.8+），这应可防止出现严重的 Python 运行时可更新性问题。
- Python 在 2020 年收紧了向后兼容性规则 (PEP 387)。
- Python 创建者和核心 Python 开发者表示，从 Python 2 到 3 的经验教训表明，由于会发生广泛的不兼容问题，因此近期不会进行主要版本更新。
- 缺点：Python 的运行时接口相对较大，因此运行时更新比考虑的其他语言更可能导致中断。
- 缺点：Python 是一种解释型语言，因此更难检测到运行时更新时可能发生的 API 中断，因此只能通过执行而非编译来断言正确性。不过，由于为 OOT 系统测试开发的 API 将以测试为导向，因此每次运行时版本升级时，都应通过现有的树内检查对这些 API 进行全面测试。为了最大限度地提高信心，需要投资于 Python 源代码覆盖率，以监控和强制执行所有基于 SDK 的 Python 模块的高绝对覆盖率。
- 优点：可更新性 - RFC-0129 确立了树内 Python 最佳实践（例如 Python 3.8+），这应可防止出现严重的 Python 运行时可更新性问题。
- 缺点（中性，但需要投资）：代码健康状况 - 需要投资于 Python 静态分析工具，才能达到中性得分；否则，Python 缺乏静态类型强制执行功能可能会导致代码健康状况不佳。
- 可能无法将静态类型强制执行扩展到基于 SDK 的 Python API 构建的 OOT 系统测试项目。尽管 Fuchsia 可以在导出的 OOT Python API 中强制执行类型提示和代码覆盖率，但 Python 中没有内置的语言功能来要求继续执行此实践。
- 我们有明确的解决这些挑战的方案（例如，投资于上游 Bazel Python 支持，以便在 build 时强制执行类型提示）。
- 中性：Fuchsia API 版本控制 - 需要投入与考虑的其他语言类似的 API 版本控制资源。
TypeScript
生态系统采用情况：中性
人体工学：良好
- 优点：异步支持功能强大，非常适合编写设备本身的脚本。
- 优点：支持垃圾回收。
- 优点：JS 解释器允许用户以交互方式开发/测试，而无需编译，这在远程控制方面尤其有用。
Fuchsia 可移植性：良好
- 优点：Fuchsia 已通过实验性 JavaScript 解释器/shell - Josh（尚未投入生产）展示了 JS 运行时支持。
所需投资：较差
- 缺点：不是 Fuchsia (FPLP) 中获批使用的语言。
- 缺点：此语言没有树内 GN build 系统支持。
- 缺点：此语言中未实现任何树内系统测试解决方案。
- 缺点：Fuchsia 源代码中不存在 SL4F 客户端库。
- 中性：需要投入与考虑的其他语言类似的 OOT 资源。
- 来源分布
- 中性：投资与其他语言类似。
- 静态分析
- 缺点：没有现有的树内支持 TypeScript。
- Bazel 集成
- 优点：Bazel 构建系统支持 TypeScript。
- 缺点：Pigweed 团队在将 TS 与 Bazel 集成时遇到了负面体验，以至于此后删除了所有 TS Bazel 集成。Pigweed 团队的引述：
- TS Bazel 中断无法调试。
- 节点生态系统未可靠集成。
- 由于 Google 内部工具优先，Bazel 团队缺乏支持。
- OOT 基础设施集成
- 缺点：没有证据表明 TS/JS 被用于 Bazel 中以设备为中心的系统测试。
- 来源分布
可维护性：良好
- 优点：代码健康状况 - 静态类型化语言有利于 OOT 代码的健康状况。
- 中性：Fuchsia API 版本控制 - 需要投入资金进行 API 版本控制，类似于考虑中的其他语言。
被认为不可行的语言
由于一个或多个评估指标存在不可行性，因此从深入分析中移除了这些编程语言。
C/C++
人体工学：不可行
- 缺点：手动内存管理不利于开发敏捷性。
- C/C++ 的性能优势不适用于常见的 OOT 系统测试用例，这些用例更注重简单性而非性能。
- 缺点：对于系统测试开发而言，编译型语言不如脚本语言理想。
Rust
生态系统采用情况：不可行
人体工学：不可行
- 缺点：严格的内存安全语言语法会降低开发灵活性。
- Rust 带来的性能优势和内存安全保证不适用于常见的 OOT 系统测试用例，这些用例更注重简单性而非性能。
- 缺点：Rust 的学习曲线相对陡峭。
- 缺点：Google 的内部代码库不支持 Rust。
- 缺点：对于系统测试开发而言，编译型语言不如脚本语言理想。
Dart
所需投资：不可行
- 缺点：从历史上看，Dart 需要 2 名全职工程师来维护围绕该语言的树内基础架构。
- 目前，滚动更新已冻结，性能团队会尽力维护现有测试。
- 从历史上看，管理第三方库生态系统经常会在上游推出新版本时中断。
- 缺点：历史用法已在 Fuchsia.git 中列入许可名单，新增用法需要获得豁免（RFC-0176、FPLP）。
可维护性：不可行
- 缺点：运行时和库之间的紧密耦合（如 RFC-0176 中记录的其他缺点）使得 Dart 无法成为首选。
- 从 Dart 弃用中总结出的经验教训：
- 不要依赖于不稳定且仍在开发中的语言。
- 不要依赖于用户群较小且定制化的语言。
- 缺少上游支持使得广泛采用变得困难。
- 从 Dart 弃用中总结出的经验教训：
- 缺点：Dart 缺少支持 FIDL 版本控制（缺少条件编译）或动态生成的绑定所需的关键语言功能，因此很难随着 Fuchsia API 表面一起发展 Dart FIDL 绑定。
评估摘要
下图直观总结了 OOT 系统测试的编程语言评估。
总结
根据上述评估，可以看出 Go、Python 和 TypeScript 都是可以切实胜任 OOT 系统测试任务的语言。不过，每种语言都有自己的权衡取舍，因此很难选出明确的“胜者”。最终，为了统一语言，以便尽快解决我们 OOT 客户当前遇到的问题，我们对客户需求（“生态系统采用率”维度）进行了更重的指数化处理，以打破僵局。
目前，建议使用 Python 来获得 OOT 系统测试批准，主要是因为 Python 符合产品要求，尤其是在易于与 Google 现有的测试框架集成方面。由于技术原因，Python 可能并非系统测试的绝对首选，但 Fuchsia 的 OOT 客户需要它。
总而言之，Python 的优势包括：
- 在 OOT 合作伙伴中广泛采用系统测试
- 可提升系统测试用户体验的人体工程学语言功能
- 由于 Fuchsia 源代码中存在现有解决方案，因此可更快地实现生产化
虽然在树内和 OOT 中都需要额外投资才能达到与其他静态类型语言相当的可维护性，但通过改进 Fuchsia 的 Python 静态分析工具，可以实现通过类型提示和覆盖率强制执行来达到同等水平。
不过，如果在树内强制执行类型提示和覆盖率 6 个月后，以及在一个 OOT 代码库中强制执行类型提示后，出现大量与 Python 可维护性相关的 bug 和问题，我们将重新考虑是否使用 Python 进行 OOT 系统测试。
请注意，此 RFC 中批准 Python 用于 OOT 系统测试，并不排除其他语言用于此领域。事实上，Fuchsia 将在 SDK 中导出的关键 OOT 系统测试组件是 Fuchsia 控制器，该控制器专门设计为可扩展到任何主机端语言，以支持主机到 Fuchsia 设备的通信。
实现
需要更新 Fuchsia 编程语言政策，以反映此 RFC 的提议，即批准将 Python 用于 OOT 系统测试。
- 将 Python 语言决策从“不支持最终开发者使用 Python”更新为“批准最终开发者使用 Python 3 进行系统测试”。
工效学设计
上面已讨论过，作为评估指标（人体工学）的一部分，适用于每种语言。
向后兼容性
如上所述，每种语言的评估标准都包含可维护性。
缺点、替代方案和未知因素
如需了解详情，请参阅上文中的考虑中的语言。
性能
不适用
安全注意事项
不适用
隐私注意事项
不适用
测试
不适用