测试环境

构建系统与持续集成基础架构（下文简称“基础架构”）发现、汇总和运行测试的方式紧密相关。概括来讲，测试作者指定他们希望如何在 GN 中运行他们的测试，并将此信息从构建系统传播到基础架构。

更具体地说

  • build 会为每个测试生成元数据文件，以指定所需的执行环境。
  • 基础架构会将测试组合成共享相同环境的分片。
  • 对于每个分片，基础架构都会安排一个聊天机器人来运行这些测试。
  • 系统会汇总并报告所有分片的结果。

环境

测试在 GN 中的 environments 规范决定着运行测试的位置和方式。它以范围列表的形式提供，格式如下：

environments = [
  {
    dimensions = {
       <dimension key> = <value>
       ...
    }
    tags = ["<environment tags...>"]
    netboot = <boolean>
  },
  ...
]

有关示例，请参阅 guest_integration_tests；有关“维度”和“标记”的定义，请参阅下文

默认行为

如果没有为测试指定环境，则默认行为如下：

  1. __is_fuchsia__：测试仅在运行 Fuchsia 的 QEMU 实例中运行
  2. __is_linux__：测试仅在 Linux 计算机上运行
  3. __is_mac__：测试仅在 Mac 计算机上运行

(1) 表示硬件可选择启用；测试作者必须明确指定硬件环境，才能在该环境中运行测试。这样做的原因是，并非所有测试都需要在硬件上运行，测试作者最清楚情况是否如此，并且硬件是一种稀缺的资源。

预定义环境

可以导入 //build/testing/environments.gni，并使用其中定义的与环境相关的便利变量。例如，basic_envs 包含任何人都可以使用的所有环境，而无需与基础架构团队进行特别咨询。

尺寸

dimensions 在这里是指集群维度，其中 Swarming 是基础架构使用的任务分发系统。维度实际上是键值对，用于描述可作为定位目标的机器人属性。

标签

标记是可以附加到环境的任意字符串。设置此值意味着从常规测试流水线中移除相应的测试；要运行该测试，必须添加对新构建器（针对特定标记运行测试）的支持。标签用于需要不同配置的特殊测试。在使用代码前，请先咨询 fuchsia-infra-team@google.com。”

Netboot

Netboot 指定是否在该环境的分片中运行测试之前执行 netboot 而不是 paving。如果省略，则将被视为 false。

验证

//build/testing/platforms.gni 中的 test_plaforms 列表是关于哪些平台可用于测试以及它们具有哪些维度要匹配的可信来源。假设环境与平台条目匹配（如果前者的 dimensions 是后者的子范围）；如果环境与当前架构匹配，且该环境未指定 cpu 值不同于 current_cpu 的 cpu 值，则假定环境对当前架构有效。test_platforms

环境验证每次进行 gn gen 时，可汇总为以下形式

  • 每个环境都必须对某些架构有效。

  • 每个测试都必须有一个对给定架构有效的环境。

示例

假设 platform.gni 包含

test_platforms = [
  {  # P1
    device_type = "QEMU"
    cpu = "x64"
  },
  { # P2
    device_type = "QEMU"
    cpu = "arm64"
  },
  { # P3
    device_type = "Intel NUC Kit NUC7i5DNHE"
    cpu = "x64"
  },
]

并考虑

environments = [
  { # E1
     dimensions = {
       device_type = "Intel NUC Kit NUC7i5DNHE"
     }
  },
  { # E2
     dimensions = {
       device_type = "QEMU"
     }
  },
]

当 current_cpu 为 x64 时，E1 和 E2 都有效且分别与 P1 和 P3 匹配：测试安排在 NUC 和 QEMU 上运行。当 current_cpu 为 arm64 时，E1 无效但会被忽略，因为 E2 有效且与 P2 匹配：测试仅计划在 QEMU 中运行。