| RFC-0221：用于树外系统测试的 Python | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 批准将 Python 用于树外系统测试。 |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2023-04-27 |
| 审核日期（年-月-日） | 2023-06-13 |
总结
批准将 Python 用于树外 (OOT) 系统测试。
设计初衷
我们已知需要改进 Fuchsia 面向最终开发者的系统测试支持。随着驱动程序开发工作移出树外 (OOT)，迫切需要通过 SDK 交付标准化系统测试解决方案，以支持硬件资格认证。
开始这项工作的前提条件是，您需要选择用于构建解决方案的编程语言。本文档针对 OOT 系统测试提议了评估标准和数据点，以涵盖使用各种编程语言进行 OOT 系统测试。从评估练习中得出的结果将用于针对 Fuchsia 应采用的编程语言提出明智的建议，以满足当今的 OOT 系统测试需求。
利益相关方
教员：
- 大卫·摩尔 (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
社交：
FEC、测试架构团队、测试基础架构团队和工具团队的成员在 Google 文档中讨论了 OOT 系统测试评估评分准则以及针对每种编程语言的评估。
定义
- 系统测试通常称为 E2E 或 CUJ 测试，此类测试是在完整的已组合系统上进行的测试，用于验证系统是否满足特定要求。如需了解全面的定义，请参阅什么是系统测试？。
产品要求
总结了为 Fuchsia 支持新一代 OOT 系统测试的产品动机和要求。
主要用户：测试 Fuchsia 平台和产品的开发者和系统集成商。
环境：树内，以及 SDK 随附的所有环境和花瓣。
策略
- 将用例的范围限定为涉及一个或多个目标设备的端到端设备测试。
- 提供将现有 SL4F 测试和用户迁移到新框架的路径。
- 利用 SL4F 解决现有的痛点，侧重于以工效学设计，以易于使用的语言编写测试。
- 确保与 Google 的端到端测试框架轻松集成。
- 投资于 Fuchsia 用户要求的其他功能，以满足平台测试需求（例如性能监控、内存用量等）。
编程语言选择的重要性
测试框架采用在很大程度上取决于语言选择。一种在该系统测试用例中被广泛采用的易用语言非常有助于拓展到核心 SWE 之外，并包括测试工程师和系统集成商。
评估评分准则
Fuchsia 编程语言政策 (FPLP) 中已详细载明了每种语言（TypeScript 和 JavaScript 除外）的一般优缺点。本文档中使用的指标涵盖与 OOT 系统测试明确相关的语言方面。
评估评分准则（排名不分先后）：
生态系统采用：语言在 OOT 系统测试空间中的受欢迎程度
- 一种广泛使用的主流系统测试语言有助于采用 OOT。
- 首选已在 OOT 客户代码库中用于系统测试的语言。
工效学：语言在支持系统测试常用模式方面的表现
- 一种常见的系统测试模式是协调主机与设备的交互，例如在被测设备 (DUT) 上触发 API 并断言行为。与传统的 Fuchsia 平台开发相比，这种使用方式受益于一组不同的语言功能；一些关键区别：
- 优先考虑开发敏捷性，而非性能。
- 首选自动内存管理和垃圾回收。
- 测试主机性能通常只是一个次要考虑因素。
- 首选交互模式/REPL 进行快速原型设计。
- 较大的二进制文件/源代码占用空间越小。
- 异步语言支持是一项不错的选择，但并非必需。
- 系统测试通常是只有几行代码行的较小项目。首选便于检查正确情况的易读语言（有几百行）。（测试是生产环境代码，本身通常无法进行充分的测试，因此简化正确性推理非常有用）。
- 优先考虑开发敏捷性，而非性能。
- 一种常见的系统测试模式是协调主机与设备的交互，例如在被测设备 (DUT) 上触发 API 并断言行为。与传统的 Fuchsia 平台开发相比，这种使用方式受益于一组不同的语言功能；一些关键区别：
紫红色可移植性：可在主机和 Fuchsia 目标平台上轻松运行
- 虽然本文档中评估的语言将主要用作主语言，但有些测试用例只能通过目标驱动的方式完成（例如，使用未导出到主机的接口、时间和吞吐量保证，这些保证只能在目标端运行）；因此，语言在 Fuchsia 目标上运行以进行系统测试的可移植性非常重要。使用可移植的语言进行系统测试还有可重用性方面的优势（例如，在主机和目标上重复使用编码/解码等通用逻辑）。
需要投资：将 OOT 系统测试解决方案投入生产环境所需的工作
- 了解特定语言的差距，让我们能够在考虑到时间和资源限制的情况下更好地比较备选方案。
- 下面是一些需要投入的投资示例：
- 构建支持
- 现有库支持
- 测试框架开发
- 主机设备交互库和工具（例如 SL4F 支持）
- SDK 中的语言支持
- 文档和开发者培训
可维护性：维护 OOT 系统测试解决方案所需的工作
- 这可能会对人员配备要求、代码运行状况和技术债务产生长期影响，具体取决于所选语言。
- 可维护性方面示例：
- 运行时可更新性 - 能够在不破坏 OOT 用户的情况下更新运行时。
- Fuchsia API 版本控制 - 用于防止因 Fuchsia API 更改而导致的 OOT 损坏的工具，例如，如何检测导出到 OOT 用户的系统测试 API 中的破坏性更改。
- 代码运行状况
- 大型软件项目通常可以从静态类型等语言功能中受益。
- 可以轻松启用自动化静态分析工具（例如 linter、coverage 等）。
考虑的语言
本部分介绍了用于 OOT 系统测试的几种语言，并提供了每种评估指标的证据。为使这两种语言之间的比较更加简单，我们会为每种语言的评估评分准则中的每个类别分配一个分数：Infeasible、Bad、Neutral 或 Good。
Go
生态系统采用：中立
- 中性：Go 通常是流行语言（TIOBE、PYPL），但没有证据表明 Go 广泛用于 Fuchsia 现有 OOT 合作伙伴的系统测试空间。
- 优点：有证据表明，在所有实际测试解决方案中，Go 都用于进行系统测试：
- Chromium 在测试中使用 Go。
- GCP Android 系统测试是用 Go 编写的。
工效学：良好
- 优点：使用此语言的用户的工作效率很高 (FPLP)。
- 优点：支持垃圾回收并提供内存安全保证 (FPLP)。
- 优点：Goroutine 使异步通信紧凑且更易于使用。
- 缺点：编译语言不适合交互式系统测试开发。
紫红色可移植性：中性
需要的投资：中性
- 缺点：没有采用此语言实现的通用树内系统测试解决方案。
- 系统 OTA 测试中有一些基于 Go 的系统测试的先验技术，但没有一个解决方案可以普遍支持所有类型的系统测试（例如多设备测试）。
- 没有 Fuchsia 设备交互库的通用主机。
- 优点：Fucsia 源代码中存在 SL4F 客户端库。
- 中性：需要考虑使用其他语言的 OOT 项目。
- 源代码分发
- 中性：与其他语言类似的投资。
- 静态分析
- Pro：
gofmt和govet在 Fuchsia CI 中已启用。
- Pro：
- Bazel 集成
- 优点：Bazel 构建系统支持 Go。
- 源代码分发
可维护性：良好
- 优点：可更新性 - 没有证据表明存在重大的可更新性问题。
- 现有工具可用于重写 Go 文件以符合新的 Go 版本
- https://pkg.go.dev/cmd/fix.
- 优点：代码运行状况 - 静态类型的语言有益于 OOT 代码运行状况。
- 中性：Fucsia API 版本控制 - 需要投资与其他语言类似的 API 版本控制。
Python
生态系统采用：良好
- 优点：Python 通常是一种流行语言（TIOBE、PYPL）。
- Python 是发展最快的主流编程语言行业，在顶尖大学中得到广泛教授。
- 在 GitHub activity 中，该代码仅次于 JavaScript，这是积极开发的迹象。
- 优点：Mobly 是一种开源多设备 e2e 测试框架，也是 Google 内部多设备系统测试的内部路径。
工效学：良好
紫红色可移植性：中性
- 优点：Python 是一种适用于所有现有主机平台的可移植语言，Fuchsia 也应该会支持 Python。为了将 Fuchsia 作为通用操作系统作为可行的选择，Fuchsia 有充足的时间来支持 Python。
- 缺点：Python 具有丰富的运行时环境，并且没有任何在 Fuchsia 中支持 Python 运行时的前期技术；因此，支持 Python 所需的投资将非常可观。
所需投资：良好
优点：树内已存在基于 Python Mobly 的系统测试解决方案。
- 优点：存在 SL4F 客户端库。
优点：Fucsia 中的 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 2 到 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 支持，以在构建时强制执行类型提示）。
- 中性：Fucsia API 版本控制 - 需要投资与其他语言类似的 API 版本控制。
TypeScript
生态系统采用：中立
工效学：良好
- 优点：异步支持稳健，适合为设备本身编写脚本。
- 优点：支持垃圾回收。
- 优点：JS 解释器可让用户以交互方式进行开发/测试，而无需编译，这在远程控制环境中尤其有用。
紫红色可移植性：良好
- 优点：Fucsia 证明了可使用实验性 JavaScript 解释器/shell - Josh（未正式版化）的 JS 运行时支持。
所需投资：不佳
- 缺点：未获准在 Fuchsia (FPLP) 中使用。
- 缺点：此语言不支持树内 GN 构建系统。
- 缺点：没有使用此语言实现树内系统测试解决方案。
- 缺点：Fuchsia 源代码中不存在 SL4F 客户端库。
- 中性：需要考虑使用其他语言的 OOT 项目。
- 源代码分发
- 中性：与其他语言类似的投资。
- 静态分析
- 缺点：目前没有对 TypeScript 的树内支持。
- Bazel 集成
- 优点：Bazel 构建系统支持 TypeScript。
- 缺点：Pigweed 团队在将 TS 与 Bazel 集成方面经历过糟糕，导致所有 TS Bazel 集成都被删除了。引述 Pigweed 团队的话：
- 无法调试 TS Bazel 破坏情况。
- 节点生态系统无法可靠地集成。
- 缺少 Bazel 团队的支持，因为 Google 内部工具的优先级更高。
- OOT 基础架构集成
- 缺点：没有证据表明在 Bazel 中正在使用 TS/JS 进行以设备为中心的系统测试。
- 源代码分发
可维护性：良好
- 优点：代码运行状况 - 静态类型的语言有益于 OOT 代码运行状况。
- 中性：Fucsia 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 Surface 改进 Dart FIDL 绑定。
评估摘要
以下是针对 OOT 系统测试的编程语言评估的直观摘要。
总结
根据上面的评估，我们发现 Go、Python 和 TypeScript 这些语言都很有可能适合 OOT 系统测试任务。但是，每种语言都有自己的取舍，这使得选择明确共识的“胜出者”变得非常困难。归根结底，客户需求（“生态系统采用”维度）按照指数化程度提高到最终决定成败，目的是就一种语言达成一致，立即解锁我们的 OOT 客户。
目前，建议使用 Python 进行 OOT 系统测试审批，这主要是因为它符合产品要求，尤其是因为它易于与 Google 的现有测试框架集成。由于技术原因，Python 可能并非绝对首选的系统测试，但 Fuchsia 的 OOT 客户要求使用 Python。
总而言之，Python 的优点：
- OOT 合作伙伴的系统测试被广泛采用
- 人体工程学语言功能，有利于系统测试用户体验
- 由于 Fuchsia 源代码中的现有解决方案，生产环境化路径缩短了
虽然要在树内和 OOT 方面进行额外的投资，才能实现与其他静态类型语言相当的可维护性，但通过改进 Fuchsia 的 Python 静态分析工具，通过类型提示和覆盖率强制执行来实现对等性。
话虽如此，但如果在树中强制执行类型提示和覆盖率 6 个月后，出现大量与 Python 可维护性相关的 bug 和问题，并且已在一个 OOT 代码库中强制执行类型提示，我们将重新考虑使用 Python 进行 OOT 系统测试。
请注意，在此 RFC 中批准 Python 用于 OOT 系统测试并不意味着在此空间中使用其他语言。事实上，Fuchsia 将在 SDK 中导出的关键 OOT 系统测试组件将是 Fuchsia Controller，该组件经过专门设计，可扩展到任何主机端语言，以支持主机到 Fuchsia 设备之间的通信。
实现
您需要更新 Fuchsia 编程语言政策，以反映此 RFC 关于批准将 Python 用于 OOT 系统测试的方案。
- 将 Python 语言决定从“最终开发者不支持 Python”更新为“Python 3 已获准供最终开发者用于系统测试”。
工效学设计
在上文中讨论了每种语言，作为评估指标 - 人体工程学的一部分。
向后兼容性
在评估评分准则“可维护性”部分，上文对每种语言进行了讨论。
缺点、替代方案和未知情况
我们在上文考虑使用的语言部分讨论了此内容。
性能
不适用
安全注意事项
不适用
隐私注意事项
不适用
测试
不适用