RFC-0164：Test Suite API

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

通过 API 审核将套件协议发布到 SDK
Gerrit 更改
  • 655031
作者
审核人
提交日期（年-月-日）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 树中常用的测试套件运行测试。
    • 将测试结果表示为结构化数据（而不是将字符流表示到 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 每秒收到多少次查询？
    • 每项测试都通过测试运行程序实现并公开此协议，并在测试执行完成后进行拆解。对于每个测试客户端，查询数取决于测试用例数和吞吐量。
  • 您希望典型查询传输多少数据？
    • 对于枚举 API，它可以传输相当于每次迭代最大 FIDL 大小的数据。其余 API 以较低的 KB 传输数据。

安全注意事项

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

隐私注意事项

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

测试不是交互式用户程序。不向消费者送货。 开发者会在自己完全拥有的设备上或从共享池借用的设备调用测试，这些设备会在返回池前被擦除。

缺点和替代方案

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