第2章 功能验收前置条件:环境就绪、测试数据准备、准入检查表、输入输出物定义
1. 适用场景
本章定义功能验收启动前必须满足的硬性前置条件。适用于以下场景:
- 新功能首次验收:从零搭建验收环境并准备基线数据。
- 回归验收批次:在已有环境中增量部署新版本,需要校验环境一致性。
- 跨团队交接验收:开发团队移交测试团队时,用于确认双方对“验收起点”的认知对齐。
- 自动化验收流水线触发:CI/CD 管道中的前置检查门禁,确保后续脚本能够正确执行。
实践提示:前置条件文档应在功能冻结前完成审核,避免验收阶段因环境或数据问题反复阻塞。
2. 前置条件(本章核心)
功能验收启动前,必须同时满足以下四大类条件,缺一不可:
| 类别 | 具体要求 | 检查方法 |
|---|---|---|
| 环境就绪 |
- 验收环境与生产环境配置一致(CPU/内存/磁盘/网络)。 - 中间件版本(数据库、消息队列、缓存)已固化。 - 被验收服务已部署至目标环境,健康检查通过。 |
执行环境适配检查脚本,输出合规报告。 |
| 测试数据准备 |
- 至少覆盖正常、边界、异常三类数据集。 - 数据已脱敏且满足隐私合规要求。 - 数据量级达到验收场景峰值(如 10 万条订单/秒)。 |
数据初始化脚本返回成功,时间戳记录在案。 |
| 准入检查表 |
- 关联变更(配置、脚本、依赖库)已全部合并。 - 接口契约(OpenAPI/Swagger)已同步。 - 已知阻塞缺陷已修复或已标注例外。 |
逐条确认并签字,记录检查表版本号。 |
| 输入输出物定义 |
- 验收用例清单及预期结果已评审通过。 - 缺陷管理平台已创建对应迭代。 - 验收报告模板已定稿。 |
模板版本号与评审纪要一致。 |
常见陷阱:验收人员常忽略“输入输出物定义”的版本锁定。若验收中途频繁变更预期结果,会导致度量时钟错乱。建议使用基线冻结机制(
baseline_tag)进行版本控制。
3. 操作步骤
- 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)"
- 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")
- Step 3 – 准入检查表核对:使用检查表模板(CSV/Excel),逐项标记为 通过 或 例外,并由责任方签字。
- Step 4 – 输入输出物确认:在项目管理工具(如 Jira)中锁定迭代,关联用例集与报告模板。
- 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. 记录材料
本章执行过程中需归档以下记录:
env_check_report.json– 环境巡检原始数据。data_coverage.json– 数据准备记录。readiness_checklist_signed.pdf– 准入检查表签字版。io_definition_review.md– 输入输出物评审纪要(含版本号)。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,则前置条件验收通过。