1. 验收测试启动条件

适用场景

本流程适用于所有参与生产级上线发布的项目——包括功能迭代、重大缺陷修复、基础设施变更及第三方集成版本交付。

• 本次发布包含数据库结构变更或数据迁移脚本
• 变更影响已有API契约（请求/响应字段增加、删除、类型变更）
• 发布范围涉及多微服务协同部署，且依赖顺序明确
• 合规审计要求留存验收测试全过程证据链

前置条件

验收测试启动前，必须同时满足以下三项硬性门槛，缺一不可：

1. 开发团队已完成代码冻结，且所有预定修复/特性均已合入目标分支
2. 冒烟测试（Smoke Test）通过率 ≥ 95%，且无 P0/P1 级未解决缺陷
3. 缺陷管理系统（如Jira/Tapd）中关联该版本的“待验收”状态工单已清空

# 确认代码冻结标签已打
git tag -l | grep v1.2.3-rc

# 冒烟测试结果检查（假设使用Allure报告）
ls -la ./allure-report/index.html || echo "冒烟报告不存在，终止启动"

# 查询P0/P1缺陷数量（JQL示例）
project = YOUR_PROJECT AND fixVersion = v1.2.3 AND priority in (P0, P1) AND status != Done

输入输出物

环境就绪标准

验收测试环境（Staging/UAT）必须与生产环境严格同构，逐项确认：

• 基础资源：CPU/内存/磁盘配额 ≥ 生产规划基线，节点数量一致
• 中间件版本：数据库、消息队列、缓存服务版本号精确匹配生产
• 网络策略：防火墙白名单已放开，服务间域名解析可达
• 监控接入：APM（如SkyWalking）、日志采集（如ELK）、告警通道已部署并验证数据上报
• 测试数据：脱敏后的批量数据已导入，且包含边界值场景

#!/bin/bash
# 环境就绪自动化检查片段
SERVICES=("api-gateway" "user-service" "order-service")
for svc in "${SERVICES[@]}"; do
  curl -sf -o /dev/null http://${svc}.internal:8080/health && \
    echo "${svc}: healthy" || echo "${svc}: UNREACHABLE"
done

角色与职责确认

验收测试阶段涉及四个关键角色，责任边界必须通过流程签字单明确：

操作步骤

1. 输入物核查：QA Lead 对照《输入输出物表》逐项获取并归档，缺少任何一项则流程终止。
2. 环境就绪验证：Ops Rep 执行自动化环境检查脚本，通过后签署《环境就绪确认单》。
3. 角色权责对齐：召开15分钟启动站会，各方确认签字矩阵，明确阻断决策人。
4. 缺陷回归批次确认：Dev Rep 提供已修复缺陷的MR/commit列表，QA Lead 纳入回归套件。
5. 正式进入验收测试执行：将验收用例分配给执行人，系统打标“验收中”。

记录材料

本章节要求留存以下记录，作为发布评审输入附件：

• 《验收测试启动检查单》（含3项前置条件逐项确认）
• 《环境就绪确认单》（含基础资源、中间件、网络、监控、数据五项检查结果截图）
• 《角色签字矩阵》（含4个角色姓名、签字日期、是否代签备注）

异常处理

验收标准

本章节（启动阶段）的验收通过标准简单明确：

• 所有输入物已归档且版本匹配（通过Git hash或文件MD5校验）
• 环境就绪确认单已签字，且扫描件上传至知识库
• 四方角色（QA/Dev/Ops/PM）责任人在启动站会中无异议

关键提示