4. 自动化测试体系：测试金字塔（单元/集成/E2E）、测试覆盖率要求、测试环境管理

自动化测试是变更门禁的核心质量防线。一个结构合理的测试体系能够快速反馈代码变更的影响范围，防止缺陷流入生产环境。本章围绕测试金字塔模型、覆盖率量化标准以及测试环境的分层管理展开，为门禁流水线中的测试阶段提供可落地的设计依据。

4.1 测试金字塔模型与分层策略

测试金字塔由 Mike Cohn 提出，强调底层单元测试数量多、执行快、维护成本低；顶层端到端（E2E）测试数量少、执行慢、维护成本高。在变更门禁场景中，每一层都有明确的通过/失败判定规则。

4.2 各层测试的详细定义与门禁要求

4.3 测试覆盖率要求与度量标准

覆盖率是衡量测试充分性的量化指标，但并非越高越好。门禁体系需要平衡覆盖率与执行效率，通常采用以下三种覆盖率维度联合评估：

• 行覆盖率（Line Coverage）： 代码中被执行的行数占总行数的比例。门禁基线 ≥ 80%。
• 分支覆盖率（Branch Coverage）： 条件语句中 true/false 分支被覆盖的比例。门禁基线 ≥ 75%。
• 变更覆盖率（Change Coverage）： 本次提交新增/修改代码中被测试覆盖的比例。门禁基线 ≥ 90%。

4.4 测试环境分层管理

测试环境是自动化测试稳定运行的基础。不同层级的测试对环境的要求差异显著，需要独立管理、隔离部署。

4.5 环境配置管理与数据隔离

测试环境管理中最容易出问题的环节是配置泄露和数据污染。以下策略可有效降低风险：

• 配置外部化： 所有环境差异配置（数据库连接、API 端点、密钥）通过环境变量或配置中心注入，禁止硬编码。
• 数据隔离原则： 单元测试使用 Mock 数据；集成测试使用 Testcontainers 或独立 Schema；E2E 测试使用脱敏数据副本。
• 环境标签化： 每个环境打上唯一标签（env: dev/staging/prod），门禁流水线根据标签自动选择对应配置。

4.6 测试环境健康检查与自愈

在门禁流水线启动测试之前，必须对环境进行健康检查，避免因环境故障导致误报。

# 环境健康检查脚本示例（伪代码）
check_environment() {
  # 1. 检查服务端口是否可达
  nc -zv $SERVICE_HOST $SERVICE_PORT || exit 1

  # 2. 检查数据库连接
  pg_isready -h $DB_HOST -p $DB_PORT || exit 1

  # 3. 检查消息队列状态
  curl -s $MQ_ENDPOINT/health | grep -q '"status":"ok"' || exit 1

  # 4. 检查依赖服务版本
  VERSION=$(curl -s $SERVICE_HOST/version)
  [ "$VERSION" == "$EXPECTED_VERSION" ] || exit 1

  echo "Environment health check passed"
}

4.7 本章小结