第2章 功能验收前置条件:环境就绪、测试数据准备、准入检查表、输入输出物定义

1. 适用场景

本章定义功能验收启动前必须满足的硬性前置条件。适用于以下场景:

  • 新功能首次验收:从零搭建验收环境并准备基线数据。
  • 回归验收批次:在已有环境中增量部署新版本,需要校验环境一致性。
  • 跨团队交接验收:开发团队移交测试团队时,用于确认双方对“验收起点”的认知对齐。
  • 自动化验收流水线触发:CI/CD 管道中的前置检查门禁,确保后续脚本能够正确执行。
实践提示:前置条件文档应在功能冻结前完成审核,避免验收阶段因环境或数据问题反复阻塞。

2. 前置条件(本章核心)

功能验收启动前,必须同时满足以下四大类条件,缺一不可:

类别 具体要求 检查方法
环境就绪 - 验收环境与生产环境配置一致(CPU/内存/磁盘/网络)。
- 中间件版本(数据库、消息队列、缓存)已固化。
- 被验收服务已部署至目标环境,健康检查通过。
执行环境适配检查脚本,输出合规报告。
测试数据准备 - 至少覆盖正常、边界、异常三类数据集。
- 数据已脱敏且满足隐私合规要求。
- 数据量级达到验收场景峰值(如 10 万条订单/秒)。
数据初始化脚本返回成功,时间戳记录在案。
准入检查表 - 关联变更(配置、脚本、依赖库)已全部合并。
- 接口契约(OpenAPI/Swagger)已同步。
- 已知阻塞缺陷已修复或已标注例外。
逐条确认并签字,记录检查表版本号。
输入输出物定义 - 验收用例清单及预期结果已评审通过。
- 缺陷管理平台已创建对应迭代。
- 验收报告模板已定稿。
模板版本号与评审纪要一致。
常见陷阱:验收人员常忽略“输入输出物定义”的版本锁定。若验收中途频繁变更预期结果,会导致度量时钟错乱。建议使用基线冻结机制(baseline_tag)进行版本控制。

3. 操作步骤

  1. Step 1 – 环境就绪检查:运行环境巡检脚本(示例如下),生成 env_check_report.json。
#!/bin/bash
# env_check.sh – 环境就绪性验证
echo '{"stage":"env","cpu_cores":8,"mem_gb":32,"disk_gb":200,"db_version":"PostgreSQL 15.4","status":"PASS"}' > env_check_report.json
echo "Environment check completed with status: $(jq -r '.status' env_check_report.json)"
  1. Step 2 – 测试数据准备:执行数据加载脚本,验证数据量级与覆盖度。
# data_prepare.py (简化版)
import json
data_count = 100000
coverage = {"normal":30000,"boundary":40000,"exception":30000}
with open("data_coverage.json","w") as f:
    json.dump({"total":data_count,"coverage":coverage},f)
print(f"Data prepared: {data_count} records, coverage OK")
  1. Step 3 – 准入检查表核对:使用检查表模板(CSV/Excel),逐项标记为 通过 或 例外,并由责任方签字。
  2. Step 4 – 输入输出物确认:在项目管理工具(如 Jira)中锁定迭代,关联用例集与报告模板。
  3. Step 5 – 签发前置条件通过凭证:汇总 Step 1–4 的报告,生成 precondition_pass.json。

4. 输入输出物

类型 名称 格式/位置 负责方
输入 环境配置基线文档 docs/env_baseline_v1.2.pdf 运维团队
输入 测试数据规范(含脱敏规则) specs/data_spec_v2.1.md 数据治理组
输入 准入检查表(空白模板) specs/readiness_checklist_v3.xlsx 质量保证组
输出 环境就绪检查报告 env_check_report.json 测试执行人
输出 测试数据覆盖率报告 data_coverage.json 测试执行人
输出 已签字的准入检查表 电子签章 PDF 测试经理 + 开发经理
输出 前置条件通过凭证 precondition_pass.json 验收协调人
关键约定:所有输出物必须使用 precondition_pass.json 作为统一入口凭证,后续验收步骤均以该文件的存在和有效性作为起点。

5. 责任边界

  • 开发团队:提供环境配置基线、已知缺陷清单、接口契约文档;确保部署包版本正确。
  • 测试团队(验收执行):执行环境检查、数据准备、对照准入检查表;生成所有输出报告。
  • 质量保证组:维护准入检查表模板和验收流程文件;监督前置条件完整性。
  • 运维团队:保障验收环境可用性、中间件版本与生产一致、网络连通性。
  • 数据治理组:提供脱敏后的测试数据集,并确认数据量级和覆盖度满足要求。
  • 产品经理:确认输入输出物(用例集、预期结果)与需求一致。

6. 记录材料

本章执行过程中需归档以下记录:

  1. env_check_report.json – 环境巡检原始数据。
  2. data_coverage.json – 数据准备记录。
  3. readiness_checklist_signed.pdf – 准入检查表签字版。
  4. io_definition_review.md – 输入输出物评审纪要(含版本号)。
  5. precondition_pass.json – 最终通过凭证(包含以上各步骤的哈希校验值)。

建议将以上材料打包为 precondition_artifacts_{yyyymmdd}.zip 上传至验收管理平台附件区。

7. 异常处理

异常场景 影响 处理方案
环境健康检查失败(如 DB 连接超时) 后续所有数据准备和用例执行均不可信 立即通知运维团队修复,修复后重新执行 Step 1,并标记延期。
测试数据量级不满足阈值 性能验收场景无法覆盖峰值 数据治理组补充数据,或调整验收范围(需产品经理审批)。
准入检查表存在未通过的“严重”项 验收不能启动 标记为阻塞,相关责任人必须在指定时限内解决;例外项需经变更控制委员会批准。
输入输出物版本不一致(如用例集基于旧版需求) 验收结果与需求不匹配 重新评审并锁定新版,更新 precondition_pass.json 中的版本字段。
升级机制:若异常处理后仍然无法在预设的前置条件超时窗口期(通常为 1 个工作日)内解决,应由验收协调人发起缺陷流程,并通知项目管理层调整验收计划。

8. 验收标准

以下标准全部满足,方可判定本章前置条件验收通过:

  • 环境就绪:env_check_report.json 中所有核心指标(CPU/内存/磁盘/网络/中间件版本)均为 PASS。
  • 测试数据准备:data_coverage.json 中 total ≥ 预期量级,且 coverage 三类均不为空;脱敏合规确认记录存在。
  • 准入检查表:所有必选检查项状态为 通过 或 例外(已审批),且签字有效。
  • 输入输出物定义:验收用例集版本号、报告模板版本号已锁定,且与需求基线版本一致。
  • 凭证完整性:precondition_pass.json 文件生成时间戳小于验收计划开始时间,且哈希校验与各子报告一致。
检查清单:使用以下命令快速校验凭证完整性(假定 jq 和 sha256sum 已安装):
jq -r '.env_check_report.sha256' precondition_pass.json | xargs -I{} sh -c 'echo "$(sha256sum env_check_report.json)" | grep -q {} && echo "Env OK"'
jq -r '.data_coverage.sha256' precondition_pass.json | xargs -I{} sh -c 'echo "$(sha256sum data_coverage.json)" | grep -q {} && echo "Data OK"'
jq -r '.readiness.signed_hash' precondition_pass.json | xargs -I{} sh -c 'echo "$(sha256sum readiness_checklist_signed.pdf)" | grep -q {} && echo "Readiness OK"'
若三条输出均为 OK,则前置条件验收通过。
功能验收前置条件 – 检查流程图 验收启动 环境就绪检查 (env_check_report) 测试数据准备 (data_coverage) 准入检查表核对签字 输入输出物定义 & 版本锁定 验证:所有报告哈希一致 签发 precondition_pass.json