| RFC-0221：用于树外系统测试的 Python | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 批准 Python 用于树外系统测试。 |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2023-04-27 |
| 审核日期（年-月-日） | 2023-06-13 |
摘要
批准 Python 进行树外 (OOT) 系统测试。
设计初衷
我们已知需要改进 Fuchsia 面向最终开发者的系统测试支持。随着驱动程序开发逐渐转向树外 (OOT) 开发，因此迫切需要通过 SDK 提供标准化系统测试解决方案，以支持硬件认证。
在开始此工作之前，需要先选择用于构建解决方案的编程语言。本文档提出了评估标准，并为每种语言提供了数据点，以便考虑各种编程语言是否适用于 OOT 系统测试。评估练习的结果将用于就 Fuchsia 应使用哪种编程语言来满足当前的 OOT 系统测试需求做出明智的建议。
利益相关方
教员：
- David Moore（davemoore@google.com）
待定
Reviewers:
- 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
社交：
我们在 Google 文档中与 FEC、测试架构团队、测试基础架构团队和工具团队的成员讨论了 OOT 系统测试评估标准以及考虑的每种编程语言的评估。
定义
- 系统测试通常称为 E2E 或 CUJ 测试，这些测试是在完全组装好的系统上进行的，用于验证系统是否符合特定要求。如需了解全面的定义，请参阅什么是系统测试？。
商品要求
为支持 Fuchsia 的下一代 OOT 系统测试而提供的产品动机和要求摘要。
主要用户：测试 Fuchsia 平台和产品的开发者和系统集成商。
环境：树内环境，以及 SDK 分发到的所有环境和花瓣。
策略
- 将用例范围限定为涉及一个或多个目标设备的端到端设备测试。
- 提供将现有 SL4F 测试和用户迁移到新框架的途径。
- 使用 SL4F 解决现有痛点，重点关注使用简单易用的语言编写测试的人体工学。
- 确保能够轻松与 Google 的端到端测试框架集成。
- 投资开发 Fuchsia 用户请求的其他功能，以满足平台测试需求（例如性能监控、内存用量等）。
编程语言选择的重要性
测试框架的采用在很大程度上取决于所选语言。在这种系统测试用例中已经广泛采用的易用语言非常有助于扩展到核心 SWE 之外，还包括测试工程师和系统集成商。
评估准则
Fuchsia 编程语言政策 (FPLP) 中已详细记录了每种语言（TypeScript 和 JavaScript 除外）的一般优缺点。本文档中使用的指标涵盖与 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 中的破坏性更改。
- 代码运行状况
- 大型软件项目通常会受益于静态类型等语言功能。
- 轻松启用自动化静态分析工具（例如 lint 工具、代码覆盖率等）。
考虑中的语言
本部分介绍了正在考虑用于 OOT 系统测试的几种语言，并提供了支持/反对每个评估指标的证据。为简化不同语言之间的比较，我们会为每种语言的评估标准中的每个类别分配 Infeasible、Bad、Neutral 或 Good 得分。
Go
生态系统采用情况：中性
- 中立：Go 通常是一种流行的语言（TIOBE、PYPL），但没有证据表明 Go 在 Fuchsia 现有 OOT 合作伙伴的系统测试领域中得到广泛使用。
- 优点：有证据表明，Go 在更广泛的范围内用于实际环境中的所有测试解决方案的系统测试：
- Chromium 在 Tast 计划中使用 Go。
- GCP Android 系统测试是用 Go 编写的。
人体工学：良好
Fuchsia 可移植性：中性
所需投资：中性
- 缺点：此语言中未实现通用的树内系统测试解决方案。
- 系统 OTA 测试中有一些基于 Go 的系统测试先前技术，但没有任何解决方案可以通用地支持所有类型的系统测试（例如多设备测试）。
- 没有通用的主机到 Fuchsia 设备交互库。
- 优点：Fuchsia 源代码中存在 SL4F 客户端库。
- 中性：需要在 OOT 方面进行与其他考虑中的语言类似的投入。
- 来源分发
- 中性：投资与其他语言类似。
- 静态分析
- Pro：
gofmt和govet已在 Fuchsia CI 中启用。
- Pro：
- Bazel 集成
- 优点：Bazel 构建系统支持 Go。
- 来源分发
可维护性：良好
- 优点：可更新性 - 没有证据表明存在重大可更新性问题。
- 有工具可重写 Go 文件，使其符合新的 Go 版本
- https://pkg.go.dev/cmd/fix.
- 优点：代码健全度 - 静态类型语言有助于 OOT 代码健全度。
- 中性：Fuchsia API 版本控制 - 与其他考虑中的语言一样，需要在 API 版本控制方面进行投资。
Python
生态系统采用率：良好
- 优点：Python 通常是一门热门语言（TIOBE、PYPL）。
- Python 是发展最快的主要编程语言，在顶尖大学中备受推崇。
- 在 GitHub 活动方面，它仅次于 JavaScript，这表明其开发活跃。
- 优点：Mobly 是一个开源多设备端到端测试框架，是 Google 内部进行多设备系统测试的明路。
人体工学：良好
Fuchsia 可移植性：中性
- 优点：Python 是适用于所有现有主机平台的可移植语言，并且最终应该在 Fuchsia 上受支持，以便 Fuchsia 成为可行的通用操作系统选项。
- 缺点：Python 具有庞大的运行时环境，并且在 Fuchsia 中支持 Python 运行时的先例并不多；因此，支持 Python 所需的投资将非常巨大。
所需投资：良好
优点：基于 Python Mobly 的系统测试解决方案已在树内。
- 优点：存在 SL4F 客户端库。
优点：Fuchsia 中的 Pigweed 在 Python 方面投入了大量精力。
中性：与其他考虑中的语言一样，需要在 OOT 方面进行投资。
- 来源分发
- 中性：投资与其他语言类似。
- 静态分析
- 缺点：通过类型提示实现静态类型化的好处 (PEP 484) 需要进行基础架构投资，以实现静态类型检查自动化。
- 优点：Pigweed 已在 GN 中自动执行这些操作，Fuchsia.git 可以利用这些操作。
- Bazel 集成
- 优点：Bazel 构建系统支持 Python。
- 优点：无论 Fuchsia 的决定如何，Pigweed 都将进一步扩展现有的 Bazel Python 集成。
- 来源分发
可维护性：较差（投资后为中性）
- 缺点（投资后为中性）：可更新性 - 需要投资于 Python 静态分析工具才能获得中性评分，否则 Python 的大型运行时接口和非编译语言特性会导致运行时更新更有可能出现故障，并且难以断言运行时支持。
- 优点：可更新性 - RFC-0129 建立了树内 Python 最佳实践（例如 Python 3.8 及更高版本），这应该可以防止出现重大的 Python 运行时可更新性问题。
- Python 在 2020 年收紧了关于向后兼容性的规则（PEP 387）。
- Python 的创建者和核心 Python 开发者表示，由于升级到 Python 3 时出现了广泛的不兼容性问题，因此他们从 Python 2 升级到 Python 3 的经验教训是他们不会很快发布主要版本更新的原因。
- 缺点：与其他考虑的语言相比，Python 的运行时接口相对较大，因此运行时更新更有可能导致故障。
- 缺点：Python 是一种解释型语言，因此更难检测运行时更新可能发生的 API 故障，因此只能通过执行（而非编译）来断言正确性。不过，由于为 OOT 系统测试开发的 API 将以测试为导向，因此每次提升运行时版本时，都应通过现有的树内检查对其进行彻底的演练。为了最大限度地提高信心，需要在 Python 源代码覆盖率方面进行投资，以监控和强制执行所有基于 SDK 的 Python 模块的高绝对覆盖率。
- 优点：可更新性 - RFC-0129 建立了树内 Python 最佳实践（例如 Python 3.8 及更高版本），这应该可以防止出现重大的 Python 运行时可更新性问题。
- 缺点（投资后为中性）：代码健康度 - 需要投资 Python 静态分析工具才能达到中性评分，否则 Python 缺少静态类型强制执行功能可能会导致代码健康度不佳。
- 可能无法将静态类型强制执行扩展到基于 SDK 的 Python API 构建的 OOT 系统测试项目。虽然 Fuchsia 可以在导出的 OOT Python API 中强制执行类型提示和代码覆盖率，但 Python 中没有任何内置语言功能来要求在 OOT 中继续采用此做法。
- 我们有希望解决这些问题（例如，投资于上游 Bazel Python 支持，以便在构建时强制执行类型提示）。
- 中性：Fuchsia API 版本控制 - 与其他考虑使用的语言一样，需要在 API 版本控制方面进行投资。
TypeScript
生态系统采用情况：中性
人体工学：良好
- 优点：异步支持非常强大，非常适合对设备本身进行脚本化处理。
- 优点：支持垃圾回收。
- 优点：JS 解释器允许用户交互式开发/测试，而无需编译，这在远程控制情境中尤其有用。
Fuchsia 可移植性：良好
- 优点：Fuchsia 已通过实验性 JavaScript 解释器/shell Josh（尚未正式发布）展示了 JS 运行时支持。
所需投资：不佳
- 缺点：不符合在 Fuchsia 中使用的语言要求 (FPLP)。
- 缺点：不支持此语言的树内 GN 构建系统。
- 缺点：没有使用此语言实现的树内系统测试解决方案。
- 缺点：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 版本控制（缺少条件编译）或动态生成的绑定所需的关键语言功能，因此很难将 Dart FIDL 绑定与 Fuchsia API 接口一起演变。
评估摘要
下图简要总结了 OOT 系统测试的编程语言评估。
总结
根据上述评估，我们发现 Go、Python 和 TypeScript 都适合执行 OOT 系统测试任务。不过，每种语言都有自己的权衡，这使得很难选择一个明确的“胜出者”。最终，我们会对客户需求（“生态系统采用情况”维度）进行加权编制，以便在出现平局时确定语言，从而为当前的 OOT 客户解除障碍。
目前，我们建议使用 Python 进行 OOT 系统测试审批，这主要是因为 Python 符合产品要求，尤其是在与 Google 现有测试框架轻松集成方面。由于技术原因，Python 可能不是进行系统测试的绝对首选，但 Fuchsia 的 OOT 客户需要它。
总的来说，Python 具有以下优势：
- 在 OOT 合作伙伴中全面采用系统测试
- 人性化的语言功能，有助于提升系统测试用户体验
- 由于 Fuchsia 源代码中存在现有解决方案，因此实现正式版的路径更短
虽然需要在树内和 OOT 中进行额外投资，才能与其他静态类型语言达到可维护性同等水平，但通过改进 Fuchsia 的 Python 静态分析工具，可以通过类型提示和覆盖率强制执行来实现同等水平。
尽管如此，如果在强制执行类型提示和代码覆盖率以及在一个 OOT 代码库中强制执行类型提示 6 个月后，发现大量与 Python 可维护性相关的 bug 和问题，我们将重新考虑是否使用 Python 进行 OOT 系统测试。
请注意，本 RFC 中批准使用 Python 进行 OOT 系统测试并不排除在此领域使用其他语言的可能性。事实上，Fuchsia 将在 SDK 中导出的关键 OOT 系统测试组件将是 Fuchsia Controller，该组件专为可扩展到任何主机端语言而设计，以支持主机与 Fuchsia 设备之间的通信。
实现
Fuchsia 编程语言政策需要更新，以反映此 RFC 中批准 Python 用于 OOT 系统测试的提案。
- 将 Python 语言决策从“不支持最终开发者使用 Python”更新为“最终开发者获准使用 Python 3 进行系统测试”。
工效学设计
在评估指标“人体工学”中，我们已针对每种语言讨论过这一点。
向后兼容性
在评估标准中，我们已针对每种语言讨论了可维护性。
缺点、替代方案和未知情况
如上文所述的考虑使用的语言。
性能
不适用
安全注意事项
不适用
隐私注意事项
不适用
测试
不适用