RFC-0164：Test Suite API

RFC-0164：Test Suite API
状态已接受
区域
  • 测试
说明

对 API 进行审核，以将套件协议发布到 SDK
Gerrit 更改
作者
审核人
提交日期（年-月-日）2022-03-07
审核日期（年-月-日）2022-05-05

修改此 RFC

修改 RFC 元数据

旧版 API 设计文档

此 RFC 之前是作为 API 设计文档提交的，后来在弃用 API 设计文档模板后，转换为 RFC。

目标和用例

  • 此 API 或 API 功能解决了什么问题？您的 API 用户能够实现什么？
    • 此 API 会将所有测试功能（枚举、执行、观察）封装到 FIDL 协议中。
    • 允许 Fuchsia 提供一个通用接口，以便使用统一的用户体验在 Fuchsia 上枚举和执行 POSIX 测试。
    • 允许 Fuchsia 运行测试并在各种测试框架中提取标准结构化输出。
    • 如需运行/执行 Cfv2 组件并获取其状态，该组件需要公开一些功能。此 API 提供了一个不错的接口，用于封装测试执行阶段并将其公开为 Fuchsia 功能。
    • OOT 树客户需要构建和运行树中不存在的测试，因此向 SDK 公开此 API 可让他们实现该协议并带来自己的运行时进行测试。

设计

  • API 的实际代码定义，例如接口的 FIDL 定义。
  • 包含 API 代码的 Gerrit 更改链接：
  • 设计要求
    • 针对目前 Fuchsia 树中常用的测试套件运行测试。
    • 将测试结果表示为结构化数据，而不是向标准输出流输出字符串、处理返回代码以及对系统产生的各种副作用。
    • 避免过度拟合特定运行时和测试框架。
    • 应能够轻松启用对新语言和测试框架的支持。
    • 协助 CFv2 迁移工作
    • 支持 Cfv2 测试。
  • 非目标：
    • 重新定义/发明测试。
      BYOR 表示开发者会带来自己的概念、框架和期望。我们的职责是提供帮助。

未知

在早期设计阶段，我们研究了用于在宿主端控制器和测试运行程序之间进行通信的协议中的先前技术。我们发现，现有技术在很大程度上依赖于特定于产品或运行时的假设。例如，Android Jetpack 和 google3 Nitrogen 假定 Android APK 和 JUnit 语义用于描述测试类、方法、注解、结果、错误等。

我们在设计时参考了语言和测试框架（gtest、Rust、Dart、JUnit、pytest）的一般知识。我们在脑海中检查了能否为这些示例实现客户端和服务器，并为 C++ gtest、Rust 和 Golang 实现了可运行的示例。

我们不知道自己不知道什么，因此未来我们预计会继续修改此协议。

易用性

本部分将回答与 API 易用性相关的以下问题：

  • 从 API 的签名中能否直观地了解其语义？
    • 是
  • 您是否设计了适当的扩展点，以便 API 在未来进行演变？
    • 是
  • 您的 API 的行为是否与执行类似操作的其他 Fuchsia API 类似？
    • 不可以，没有这样的 Fuchsia API 可以在精细级别运行测试并返回结构化结果。
  • 与其他平台的类似 API 相比，您的 API 的行为如何？
    • 不适用

我们使用两种语言（C++ 和 Rust）实现了端到端使用示例，以证明其易用性和通用性

测试

  • 您打算如何测试您的 API？
    • 此 FIDL API 的实现在 Rust 和 C++ 中进行了广泛的测试。
  • 如果开发者要依赖您的 API 功能，他们会如何测试自己的代码？
    • 此实现基本上实现了运行测试的机制。开发者应编写
    • 单元测试，用于测试内部代码。
    • 集成测试，以确保其实现与框架协同工作。

性能注意事项

  • 您的 API 是否涉及跨进程或线程边界进行大量往返？
    • 否
  • 您的 API 是否涉及在远程进程或线程中阻塞？
    • 否
  • 您的 API 是否涉及复制大量数据？
    • 可以，但需要使用套接字和迭代器。
  • 您预计您的 API 每秒会收到多少个查询 (QPS)？
    • 每个测试都会通过测试运行程序实现并公开此协议，并会在测试执行完成后拆解。对于每个测试客户端，查询数量取决于测试用例数量和吞吐量。
  • 您预计一个典型查询会传输多少数据？
    • 对于枚举 API，它可以传输等同于每次迭代的最大 FIDL 大小的数据。其余 API 传输的数据量很小，只有几 KB。

安全注意事项

  • 您的 API 是否会泄露安全敏感信息？
    • 否
  • 您的 API 是否允许用户操控安全敏感资源？
    • 否
  • 您的 API 用户是否彼此隔离？
    • 是（如果按 API 设计实现）。
  • 您的 API 是否遵循对象功能规范？
    • 是
  • 您的 API 是否鼓励用户安全地使用您的 API？
    • 您的 API 是否会导致检查时刻到使用时刻 (TOCTOU) 漏洞？
    • 不需要，但我们只能使用此 API 运行测试，因此无需执行此操作
    • 您的 API 是否明确将任何控制平面与任何数据平面分离开来？
    • 是

隐私注意事项

  • 您的 API 是否会泄露隐私敏感信息？
    • 否
  • 您的 API 是否涉及任何个人身份信息？
    • 否
  • 您的 API 是否涉及任何设备标识符？
    • 否
  • 您的 API 是否让用户能够控制信息的共享方式？
    • 不会分享任何用户信息。

测试不是交互式用户程序。不会面向消费者销售。 开发者可以在他们完全拥有的设备上调用测试，也可以在从共享池借用且在返回池之前已被清空的设备上调用测试。

缺点和替代方案

我们可以继续使用 Cfv1 设计来执行测试，但这会严重限制我们提供结构化测试结果以及将各种测试和相应的正式版组件迁移到 Cfv2 的能力。