RFC-0164：Test Suite API

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

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

修改此 RFC

修改 RFC 元数据

之前的 API 设计文档

此 RFC 之前以 API 设计文档的形式提交，在 API 设计文档模板被弃用后转换为 RFC。

目标和用例

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

设计

  • API 的实际代码定义，例如接口的 FIDL 定义。
  • 包含 API 代码的 Gerrit 更改链接：
  • 设计要求
    • 运行测试 ，以测试 Fuchsia 树中目前常用的测试套件。
    • 将测试结果表示为结构化数据，而不是 stdout 字符流、进程返回代码和系统上的各种副作用 。
    • 避免过度拟合特定运行时 和测试框架。
    • 应能轻松支持 新语言和测试框架。
    • 帮助进行 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 的能力。