大规模基础设施测试性能优化：5种方法提升pytest-testinfra执行效率

1. 项目概述：当基础设施测试慢如蜗牛

如果你和我一样，长期负责维护成百上千台服务器、容器集群或者复杂的云环境，那么你一定对pytest-testinfra这个组合不陌生。它几乎是做基础设施即代码（IaC）验证和服务器状态测试的“瑞士军刀”，用 Python 写断言，通过 SSH、Docker、Salt、Ansible 等各种后端去检查远程主机的文件、包、服务、用户——写起来爽，读起来也清晰。但爽快感往往止步于测试套件真正跑起来的那一刻。当你的测试目标从一两台机器膨胀到一个包含数十种角色、数百个节点的集群时，原本几分钟的测试可能会拉长到半小时甚至更久。屏幕前的你，是不是也经历过盯着缓慢滚动的测试输出，心里盘算着这时间够喝几杯咖啡的焦灼？

这就是我们今天要啃的硬骨头：大规模基础设施测试下的pytest-testinfra性能优化。性能瓶颈从来不是单一原因造成的，它可能源于不合理的测试结构、低效的后端连接、冗余的资源检查，甚至是pytest本身运行机制的理解偏差。单纯地“加机器、加资源”是粗放且昂贵的做法。真正的优化，是从代码和流程的每一个环节里，把被浪费的时间“挤”出来。经过多个大规模云平台和容器化项目的洗礼，我总结出了五种经过实战检验的优化方法，它们分别从测试设计、执行策略、工具配置和底层原理入手，能够系统性地将测试速度提升数倍。无论你是在验证一个全新的 Kubernetes 集群部署，还是在对一个已有的数据中心进行合规性扫描，这些方法都能让你和你的团队从漫长的等待中解放出来。

2. 核心瓶颈分析与优化思路拆解

在动手优化之前，我们必须像医生诊断一样，先找到“病根”。pytest-testinfra测试慢，通常不是pytest或testinfra本身慢，而是我们的使用方式在规模放大后暴露了问题。我们可以从以下几个维度来系统性分析瓶颈：

2.1 连接建立与销毁的成本

这是最直观的瓶颈。testinfra支持多种后端（ssh,docker,salt,ansible,kubectl等）。每次执行一个测试函数，testinfra都可能需要为每个被测主机建立一次连接（例如 SSH 握手），测试结束后再断开。对于成百上千次测试，这种连接开销是巨大的。尤其是在使用 SSH 后端时，TCP 三次握手、密钥交换、用户认证等一系列步骤，即使每次只花 100 毫秒，累积起来也是可观的时间。

2.2 测试用例的粒度和独立性

pytest默认的测试发现和执行模式，是尽可能保持测试的独立性和隔离性。这意味着，默认情况下，每个test_函数都是一个独立的“会话”，testinfra的hostfixture 可能会被多次初始化和销毁。如果我们写了很多细粒度的测试，比如一个测试文件里包含了test_nginx_installed,test_nginx_service_enabled,test_nginx_listening_on_port_80，那么testinfra可能会为同一个主机建立三次连接，执行三次类似的检查（例如，三次都需要获取包管理器的状态）。

2.3 断言执行的冗余与顺序

我们常常会无意识地编写重复的检查。例如，在测试一个 Web 服务器配置时，我们可能先检查 Nginx 包是否安装，再检查配置文件是否存在，最后检查服务是否运行。如果包都没安装，后面的检查注定失败，但测试框架依然会执行它们，这浪费了时间。此外，测试的执行顺序如果是随机的（pytest默认随机化），可能导致缓存失效或状态依赖问题，间接影响性能。

2.4 资源检查的低效实现

testinfra提供的host.package,host.service,host.file等模块非常方便，但其底层实现可能并非最优。例如，host.package(“nginx”).is_installed在 Debian 系统上可能会执行dpkg -l | grep nginx，在 RHEL 系统上执行rpm -q nginx。如果我们在一个测试中多次检查同一个包，或者检查大量不同的包，就会产生大量独立的 shell 命令调用，其进程创建和输出的解析开销也不容忽视。

2.5 Pytest 框架自身的开销与配置

pytest本身功能强大，插件众多。但一些默认行为或不当配置在测试用例极多时会带来显著开销。例如，pytest默认会为每个测试函数收集和设置大量的 fixtures（即使你没用），会输出详细的终端信息（-v），会进行断言重写等。这些操作在几千个测试用例的场景下，累积的开销会变得非常明显。

基于以上分析，我们的优化思路就清晰了：减少连接次数、合并检查动作、复用已有结果、优化执行流程、精简框架开销。接下来，我们将深入这五种具体的优化方法。

3. 方法一：活用 Pytest Fixture 作用域与缓存

这是性价比最高的优化手段，直接从pytest的核心机制入手。pytest的 fixture 可以通过scope参数定义其生命周期，从而控制资源的创建和销毁频率。

默认的陷阱：当你使用testinfra时，获取主机连接的典型写法是在测试函数中直接使用hostfixture，或者通过testinfra.get_host。在默认的function作用域下，每个测试函数都会获取一个新的主机连接对象。

优化策略：将主机连接 fixture 的作用域提升。对于一组针对同一个主机的测试，将 fixture 的作用域设为class（类级别）或module（模块级别）。这样，同一个测试模块或类中的所有测试函数，将共享同一个主机连接，避免了反复建立连接的开销。

实操示例： 假设我们有一个测试文件test_web_servers.py，要测试两台主机web01和web02。

# 优化前：每个测试函数都重新建立连接（低效） def test_nginx_installed(host): nginx = host.package(“nginx”) assert nginx.is_installed def test_nginx_service(host): service = host.service(“nginx”) assert service.is_running # 优化后：使用 module 作用域的 fixture 复用连接 import pytest import testinfra @pytest.fixture(scope=“module”) def web_host(request): # 通过参数化或环境变量决定测试哪台主机 hostname = getattr(request.module, “TARGET_HOST”, “web01”) return testinfra.get_host(f“ssh://{hostname}”, sudo=True) def test_nginx_installed(web_host): nginx = web_host.package(“nginx”) assert nginx.is_installed def test_nginx_service(web_host): service = web_host.service(“nginx”) assert service.is_running

在这个例子中，web_hostfixture 在整个test_web_servers.py模块中只会被创建一次。所有测试函数都使用这个缓存的连接对象。对于 SSH 后端，这意味着省去了数十甚至上百次的 SSH 连接建立和断开过程。

更进一步：会话级缓存与自定义缓存： 对于跨多个测试模块都需要访问的、且状态稳定的信息，可以定义scope=“session”的 fixture。例如，获取所有主机的清单、解析一个全局的配置模板。

@pytest.fixture(scope=“session”) def app_config(): # 解析一个复杂的 YAML 配置文件，这个操作很耗时 with open(“deploy/config.yaml”) as f: config = yaml.safe_load(f) return config # 所有测试模块中的测试函数都可以直接使用 app_config fixture，它只被加载一次。

注意：提升 fixture 作用域时，必须确保测试之间没有状态污染。如果测试 A 修改了主机的某个配置（例如，改了文件内容），那么共享同一连接的测试 B 可能会看到被修改后的状态，导致非预期的失败或通过。因此，只对只读的、状态稳定的检查使用高级别作用域的 fixture。对于需要修改状态的测试，要么隔离到独立的测试会话中，要么在测试完成后主动清理状态。

4. 方法二：合并测试用例与使用参数化

细粒度的测试有利于定位问题，但过度的碎片化会带来巨大的执行开销。我们需要在“定位精度”和“执行效率”之间找到平衡。

优化策略：将一系列逻辑紧密关联、针对同一主机同一状态的检查，合并到一个测试函数中。同时，利用pytest.mark.parametrize来覆盖不同的测试输入（如不同的主机名、不同的端口号），而不是为每个输入写一个独立的测试函数。

实操示例：合并检查

# 优化前：三个独立测试，三次连接，三次检查 def test_nginx_package(host): assert host.package(“nginx”).is_installed def test_nginx_config(host): config_file = host.file(“/etc/nginx/nginx.conf”) assert config_file.exists assert config_file.user == “root” assert config_file.mode == 0o644 def test_nginx_service(host): service = host.service(“nginx”) assert service.is_enabled assert service.is_running # 优化后：合并为一个“集成检查”测试函数 def test_nginx_integrated(host): # 包检查 nginx_pkg = host.package(“nginx”) assert nginx_pkg.is_installed, “Nginx package is not installed” # 配置文件检查 config_file = host.file(“/etc/nginx/nginx.conf”) assert config_file.exists, “Nginx config file is missing” assert config_file.user == “root”, f“Config file owned by {config_file.user}, expected root” assert config_file.mode == 0o644, f“Config file mode is {oct(config_file.mode)}, expected 0o644” # 服务检查 service = host.service(“nginx”) assert service.is_enabled, “Nginx service is not enabled to start on boot” assert service.is_running, “Nginx service is not running”

合并后，一次连接就完成了所有相关检查。断言失败时，通过自定义的错误信息也能快速定位是哪个环节出了问题。虽然它不如三个独立测试报告得那么精细，但在大规模测试中，这种权衡往往是值得的。

实操示例：参数化覆盖多主机

import pytest # 假设我们要用同样的测试套件检查 web01, web02, web03 三台主机 HOSTS = [“web01”, “web02”, “web03”] @pytest.fixture(scope=“module”, params=HOSTS) def hostname(request): return request.param @pytest.fixture(scope=“module”) def host(hostname): # 这个 fixture 依赖 hostname，会对每个参数（主机）创建一次模块级连接 return testinfra.get_host(f“ssh://{hostname}”, sudo=True) # 这个测试函数会自动为 HOSTS 列表中的每个主机运行一次 def test_nginx_on_all_hosts(host): assert host.package(“nginx”).is_installed assert host.service(“nginx”).is_running

通过params参数，pytest会自动展开测试。这样，你只需要维护一份测试逻辑代码，就能覆盖所有目标主机。从测试报告看，它仍然是三个独立的测试项，但背后的 fixture 初始化逻辑是高效的（模块级作用域）。

心得：合并测试时，要遵循“单一状态”原则。即，这个合并后的测试函数应该只验证主机在某一个特定配置或角色下的状态。不要将验证“基础系统”和验证“上层应用”的检查胡乱合并在一起。清晰的逻辑分组，即使在合并后也利于维护。

5. 方法三：选择高效后端与连接复用

testinfra的后端决定了它如何与目标系统通信。不同的后端，性能特征天差地别。

后端性能对比与分析：

1. ssh后端：最通用，但性能最差。每个命令都意味着一次 SSH 连接（除非使用连接池或 ControlMaster）。适用于临时测试或主机数量不多的场景。
2. docker后端：如果测试目标是 Docker 容器，此后端直接通过 Docker API 执行命令，速度极快，开销极小。
3. ansible后端：这是大规模基础设施测试的利器。testinfra通过 Ansible 在目标主机上执行模块。Ansible 本身具有强大的连接复用和优化能力（如pipelining,fact_caching）。它可以在一次 SSH 连接中执行多个模块，并且能缓存收集到的“事实”（Facts），如 IP 地址、包列表等，供多个测试复用。
4. salt后端：与 Ansible 类似，通过 SaltStack 执行命令，适合已有 Salt 管理环境。
5. kubectl后端：用于测试 Kubernetes Pod，通过在 Pod 内执行命令实现。

强烈推荐：为大规模测试配置 Ansible 后端使用 Ansible 后端，并正确配置其连接优化参数，是提升性能最有效的方法之一。

配置步骤：

1. 安装依赖：确保运行测试的机器上安装了ansible和testinfra[ansible]。
2. 创建 Ansible 清单：创建一个inventory.yml文件，列出所有待测主机。

   all: hosts: web01: ansible_host: 192.168.1.101 ansible_user: deploy web02: ansible_host: 192.168.1.102 ansible_user: deploy app01: ansible_host: 192.168.1.201 ansible_user: deploy

3. 配置ansible.cfg优化连接：

   [defaults] # 启用管道化，减少 SSH 连接次数 pipelining = True # 启用事实缓存，避免重复收集系统信息 fact_caching = jsonfile fact_caching_connection = /tmp/ansible_facts_cache fact_caching_timeout = 86400 # 缓存一天 # 使用更快的 SSH 传输和控制策略 [ssh_connection] ssh_args = -o ControlMaster=auto -o ControlPersist=60s -o ControlPath=~/.ssh/ansible-%r@%h:%p

4. 在测试中使用 Ansible 后端：

   import testinfra # 通过 ansible 后端和清单文件获取主机对象 host = testinfra.get_host(“ansible://web01?ansible_inventory=inventory.yml”)

   或者，通过环境变量指定清单文件：export TESTINFRA_INVENTORY=inventory.yml，然后在代码中直接使用host = testinfra.get_host(“ansible://web01”)。

连接复用技巧： 即使使用 SSH 后端，也可以通过配置 SSH 的ControlMaster和ControlPersist来实现连接复用。这需要在~/.ssh/config中为你的目标主机进行配置。testinfra本身不管理这个，但底层的paramiko或openssh客户端会受益于此配置，从而大幅减少 TCP 和 SSH 握手开销。

踩坑记录：使用 Ansible 后端时，务必注意 Ansible 模块的“幂等性”和测试的“只读性”。避免在测试中使用会修改系统状态的 Ansible 模块（如command执行rm -rf），因为这可能会影响后续测试或其他并行测试。测试应该专注于“断言”状态，而非“改变”状态。

6. 方法四：编写高效检查与避免冗余命令

testinfra的便捷性有时会让我们写出低效的断言。我们需要以“系统管理员”的思维，思考如何用最少的命令获取最多的信息。

反模式与优化示例：

1. 冗余的包检查：

   # 低效：多次检查不同包，产生多个 dpkg/rpm 命令 def test_packages(host): assert host.package(“nginx”).is_installed assert host.package(“openssl”).is_installed assert host.package(“python3”).is_installed # 高效：使用 host.ansible 模块或一次性命令获取所有包信息 def test_packages_efficiently(host): # 方法A：使用 Ansible 的 `package_facts` (如果后端是 ansible) # 这通常会在连接初始化时自动收集并缓存，此处直接使用 # packages = host.ansible(“setup”)[“ansible_facts”][“packages”] # 但更通用的方法是： # 方法B：执行一次命令，解析输出 if host.system_info.type == “linux” and host.system_info.distribution == “debian”: result = host.check_output(“dpkg -l | grep -E ‘^(ii|hi)’ | awk ‘{print $2}’”) installed_packages = set(result.splitlines()) required = {“nginx”, “openssl”, “python3”} assert required.issubset(installed_packages), f“Missing packages: {required - installed_packages}” # 类似地，可以处理 RHEL 系的 `rpm -qa`

   一次命令获取所有包列表，然后在内存中进行集合运算，比发起三次独立的包检查快得多。

2. 低效的文件属性检查：

   # 低效：每个属性检查可能触发一次 stat 调用 config = host.file(“/etc/nginx/nginx.conf”) assert config.exists assert config.user == “root” assert config.group == “root” assert config.mode == 0o644 # 高效：一次获取所有属性，或使用更强大的检查模块 # testinfra 的 `host.file` 内部已经做了优化，通常一次调用获取所有属性。 # 但如果你需要检查多个文件的多个属性，可以考虑： files_to_check = [“/etc/nginx/nginx.conf”, “/etc/nginx/sites-enabled/default”] for fpath in files_to_check: f = host.file(fpath) # 一次性断言所有属性 assert f.exists and f.user == “root” and f.mode == 0o644, f“File {fpath} check failed”

3. 使用host.run或host.check_output执行复杂检查： 对于testinfra没有提供直接模块的复杂检查，不要拆分成多个host.run。尽量用一个精心构造的 shell 命令或 Python 脚本（通过host.file上传并执行）来完成。

   # 低效：多次执行简单命令 def test_memory(host): # 假设要检查内存大于 2G total_mem_kb = int(host.check_output(“grep MemTotal /proc/meminfo | awk ‘{print $2}’”)) assert total_mem_kb > 2 * 1024 * 1024, “Insufficient memory” # 高效：如果检查很复杂，考虑将逻辑放在一个脚本里，一次执行 # 或者，如果这个检查在很多测试中都用，可以做成一个 session 级别的 fixture 来缓存结果。

核心原则：将远程命令执行次数视为宝贵资源，尽可能合并请求。思考“为了做出这个断言，我最少需要从远程主机获取哪些信息？能否通过一次交互获取？”

7. 方法五：调优 Pytest 执行与报告输出

pytest本身丰富的功能在测试规模很大时，可能成为负担。通过调整命令行参数和配置文件，我们可以剥离不必要的开销。

关键配置与参数：

1. 禁用详细输出与进度指示：-q(quiet) 或--tb=short。在 CI/CD 流水线中，我们通常只需要知道测试通过与否，以及失败时的简短回溯。满屏的PASSED详细信息会消耗 I/O 和时间。

   # 优化前 pytest -v tests/ # 优化后 pytest -q --tb=line tests/ # 只显示一行错误摘要

2. 控制测试发现与收集：使用-k进行关键字过滤，或者-m运行特定标记的测试。在开发或修复特定模块时，只运行相关测试。

   pytest -k “nginx” tests/ # 只运行测试名或标记中含“nginx”的测试 pytest -m “slow” tests/ # 只运行标记为 @pytest.mark.slow 的测试

3. 并行执行：使用pytest-xdist插件进行多进程并行测试。这是应对大规模测试的杀手锏。它可以将测试套件分发到多个 CPU 核心上同时运行。

   pip install pytest-xdist pytest -n auto tests/ # 使用与 CPU 核心数相同的 worker 进程

   重要提示：使用xdist时，必须确保你的测试是可并行化的，即测试之间没有依赖，不共享可变的外部状态（如同一台测试主机）。对于testinfra，通常意味着每个 worker 进程测试的是不同的主机或容器。你需要精心设计你的测试集和 fixture 作用域，或者使用xdist的--dist=loadscope等策略来确保同一个主机的测试在同一个 worker 中执行，避免冲突。

4. 优化断言重写：pytest会重写断言语句以提供更好的错误信息。这个过程有轻微开销。在极度追求速度且不需要详细断言信息的场景（如冒烟测试），可以考虑在pytest.ini中禁用：

   [pytest] addopts = -q --tb=no --disable-warnings # 注意：禁用断言重写需谨慎，一般不推荐。

5. 使用pytest.ini统一配置：将常用的优化参数写入项目根目录的pytest.ini文件，避免每次输入冗长的命令行。

   [pytest] testpaths = tests python_files = test_*.py python_classes = Test* python_functions = test_* addopts = -q --tb=short --strict-markers -n auto markers = slow: marks tests as slow (deselect with ‘-m “not slow”’) integration: integration test with external dependencies

执行策略建议：

• 分层测试：将测试分为“单元/快速测试”和“集成/慢速测试”。使用pytest.mark进行标记。在每次提交时只运行快速测试，在合并请求或夜间构建时运行全部测试。
• 增量测试：与版本控制系统结合，只运行受代码变更影响的测试。这需要更复杂的工具链支持（如pytest-testmon），但在超大型项目中效果显著。

8. 实战：一个大规模K8s集群测试的优化案例

让我们通过一个真实场景来串联以上方法。假设我们有一个 Kubernetes 集群，包含 100 个节点，我们需要验证所有节点上的基础配置（如内核参数、容器运行时版本、关键守护进程）是否符合安全基准。

初始方案（性能低下）：

• 一个测试文件，里面定义了 20 个测试函数（检查项）。
• 使用testinfra的kubectl后端，在每个测试函数中遍历所有 100 个节点（通过for node in nodes:循环）。
• 结果：20个测试函数 × 100个节点 = 2000次kubectl exec调用。每次调用都有 Pod 创建/删除（如果使用kubectl run）或 exec 会话建立的 overhead。测试耗时超过 2 小时。

优化方案：

1. 重构测试结构（对应方法一、二）：

   • 将针对单个节点的 20 项检查合并为 1 个“节点合规性扫描”测试函数。
   • 使用pytest.mark.parametrize，让这个合并后的测试函数对 100 个节点参数化运行。
   • 为每个节点创建一个module作用域的 fixture，在该 fixture 内使用kubectl后端建立到该节点某个特权 Pod 的连接，并缓存这个连接对象。

   import pytest import testinfra NODE_NAMES = [f“node-{i:03d}” for i in range(1, 101)] # 假设的节点名列表 @pytest.fixture(scope=“module”, params=NODE_NAMES) def node_name(request): return request.param @pytest.fixture(scope=“module”) def node_host(node_name): # 为每个节点创建一个长期存在的 Pod 用于测试 pod_name = f“test-pod-{node_name}” # 这里需要有一个机制确保 Pod 存在，可以使用 k8s API 或 kubectl # 假设我们有一个 helper 函数 get_or_create_test_pod(node_name) pod_name = get_or_create_test_pod(node_name) # 获取连接到该 Pod 的 host 对象 return testinfra.get_host(f“kubectl://{pod_name}?namespace=test-infra”) @pytest.mark.integration def test_node_compliance(node_host, node_name): “““一次性检查一个节点的所有合规项””” # 1. 内核参数检查 (一次性读取 /proc/sys/... 多个值) sysctl = node_host.sysctl assert sysctl.get(“net.ipv4.ip_forward”) == “0”, “IP forwarding should be disabled” assert sysctl.get(“kernel.panic”) == “10”, “Kernel panic timeout incorrect” # … 其他参数 # 2. 服务检查 (一次性检查多个服务) required_services = [“kubelet”, “containerd”, “systemd-journald”] for svc in required_services: s = node_host.service(svc) assert s.is_running, f“Service {svc} is not running on {node_name}” assert s.is_enabled, f“Service {svc} is not enabled on {node_name}” # 3. 文件权限检查 (批量检查) critical_files = [ (“/etc/kubernetes/pki/ca.crt”, 0o644), (“/var/lib/kubelet/config.yaml”, 0o600), ] for path, expected_mode in critical_files: f = node_host.file(path) assert f.exists, f“Critical file {path} missing on {node_name}” assert f.mode == expected_mode, f“File {path} has wrong mode {oct(f.mode)} on {node_name}” # 4. 容器运行时版本检查 result = node_host.check_output(“containerd --version”) assert “1.6.” in result, f“Unsupported containerd version on {node_name}: {result}” # … 更多检查项

   这样，测试数量从 2000 个降为 100 个（每个节点一个测试项），每个测试项内部高效地执行多个检查。

2. 优化连接与执行（对应方法三、五）：

   • 连接复用：node_hostfixture 是module作用域，意味着每个节点的所有检查共享同一个 Pod 连接。我们甚至可以考虑使用session作用域，让整个测试会话只创建一次 Pod 连接（需确保 Pod 在整个测试期间存活）。
   • 并行执行：使用pytest -n auto启动多个 worker 进程。由于我们将测试按节点拆分了（每个节点的测试是独立的），它们可以安全地并行运行。100 个节点的测试可以在多个 CPU 核心上同时进行。
   • 精简输出：在 CI 中运行测试时，使用-q --tb=short --junitxml=report.xml。输出简洁，并将结果生成 JUnit 格式报告供后续分析。

3. 结果对比：

   • 优化前：2000+ 次远程调用，耗时 > 120 分钟。
   • 优化后：100 个测试项，每个项内约 10-15 次远程调用（因为合并了命令），总计 ~1500 次调用。但得益于连接复用（每个节点 1 次 Pod 连接建立）和并行执行（例如 8 核并行），实际耗时可以降低到10-15 分钟，性能提升近10 倍。

9. 性能监控与持续优化

优化不是一劳永逸的。随着基础设施和测试套件的演进，新的性能瓶颈会出现。我们需要建立监控机制。

1. 使用pytest计时插件：

   • pytest-timeout：为测试设置超时，防止某个卡住的测试拖垮整个套件。
   • pytest-profiling或pytest自带的--durations参数：找出最耗时的测试。

   pytest --durations=10 tests/ # 列出最慢的10个测试

2. 分析测试报告：在 CI/CD 流水线中，收集每次测试运行的时长，绘制趋势图。如果某个测试模块的耗时突然增长，就需要及时介入分析。

3. 定期审查测试代码：在代码审查中，将“测试效率”作为一项审查要点。警惕在循环中调用host.run，警惕创建大量独立的小测试函数。

4. 探索更底层的优化：

   • 自定义testinfra模块：如果某个检查逻辑非常复杂且频繁使用，可以考虑为testinfra编写一个自定义模块。这个模块用更优化的方式（可能是一个复杂的 Shell 脚本或 Python 函数）在目标主机上执行，并返回结构化的结果。这可以将多次远程交互减少为一次。
   • 使用更快的序列化协议：如果使用 Ansible 后端，并且传输的数据量很大，可以研究是否可以使用msgpack等更快的序列化格式（需 Ansible 和受管主机支持）。

性能优化是一场与复杂度的持久战。对于pytest-testinfra而言，核心思想始终是：减少远程交互、复用已有连接、合并检查逻辑、并行执行任务。从调整一个 fixture 的作用域开始，到重构整个测试套件的架构，每一步优化都能为你和你的团队赢得宝贵的反馈时间，让基础设施的变更更加敏捷、可靠。