第2章 验证策略制定流程
适用场景
本流程适用于新功能开发、产品迭代、兼容性验证、性能基线建立等阶段。主要场景包括：
- 产品需求评审通过后，需要制定功能和性能验证方案。
- 兼容性矩阵尚未建立，需要优先确定验证范围。
- 资源有限时，需要合理分配测试深度与广度。
- 项目立项或版本发布前，需要输出验证计划模板。
前置条件
- 已获得产品需求文档（PRD）或需求规格说明书（SRS）。
- 已明确目标硬件平台和操作系统版本清单。
- 测试环境（工具、设备、授权）已基本可用。
- 核心干系人（产品经理、开发负责人、测试负责人）已确认。
操作步骤
- 产品需求分析：提取功能点、性能指标、兼容性目标，分类标注为“必测”“选测”“不测”。
- 风险等级划分：基于影响域、发生概率、严重程度，将需求项划分为P0/P1/P2三级。
- 验证深度与广度权衡：根据风险等级和资源约束，确定每个需求项的测试深度（功能全覆盖、边界场景、压力测试）和广度（设备矩阵、系统组合）。
- 资源估算：计算人力、设备、时间需求，形成资源预算表。
- 编写计划模板：使用验证计划模板填入关键信息：版本号、测试范围、资源分配、里程碑、交付物。
输入输出物
| 类别 | 输入物 | 输出物 |
|---|---|---|
| 需求分析 | PRD / SRS / 用户故事 | 功能-性能-兼容性分类清单 |
| 风险划分 | 分类清单 + 历史缺陷数据 | 风险等级表（P0/P1/P2） |
| 权衡决策 | 风险等级表 + 资源池数据 | 验证范围矩阵 |
| 资源估算 | 验证范围矩阵 + 人力成本 | 资源估算报告 |
| 计划编制 | 以上所有输出 | 验证计划文档（含里程碑） |
责任边界
- 产品经理：提供PRD并确认需求分级。
- 测试负责人：主导风险划分、权衡决策、资源估算、输出计划模板。
- 开发负责人：提供技术可行性意见和缺陷历史数据。
- 项目管理者：审批资源预算和最终计划。
记录材料
需求项-风险-验证范围对照表（Excel/在线文档）资源估算工作簿（含人力、设备、时间）验证计划模板（Markdown或Word）
记录材料由测试负责人归档至项目管理平台，版本号与产品发布版本绑定。
异常处理
常见异常及处理方式：
- 需求频繁变更：冻结需求基线后再启动策略制定，变更时执行变更评审并更新对照表。
- 风险等级争议：组织跨角色评审会，采用投票或加权打分表仲裁。
- 资源严重不足：触发降级策略，优先保障P0级全测，P1/P2采用抽测或自动回归。
- 时间计划冲突：与项目管理确认可用测试窗口，调整深度/广度后重新估算。
验收标准
- 需求分析清单中每项均有明确的功能/性能/兼容性标记。
- 风险等级表中所有需求已标注P0/P1/P2，无遗漏。
- 验证范围矩阵覆盖P0项全量测试，P1/P2项有明确抽测比例。
- 资源估算报告可支撑验证计划执行，无逻辑矛盾。
- 验证计划模板包含版本号、范围、资源、里程碑、交付物，并已完成干系人确认。
关键提示：验证策略制定是测试质量的核心驱动。建议在每次版本启动时执行本流程，通常耗时2~4小时。P0级需求必须100%覆盖，P2级可考虑自动化或探索性测试。资源估算结果需对项目管理者做一次正式汇报。
模板示例（验证计划模板节选）
# 验证计划模板 v1.0
## 产品版本
- 版本号：v2.5.1
- 目标发布时间：2026-01-15
## 验证范围
- 功能点：登录、搜索、下单（P0）；历史订单（P1）；推荐算法（P2）
- 性能指标：响应时间≤200ms，TPS≥500
- 兼容性矩阵：Android 11~15 + iOS 15~18 + PC Chrome/Edge
## 资源分配
- 人力：功能测试2人，性能测试1人，兼容性测试1人
- 设备：Android 6部，iOS 4部，PC 2台
## 里程碑
| 阶段 | 开始日期 | 结束日期 | 交付物 |
|------|----------|----------|--------|
| 策略制定 | 12-01 | 12-02 | 本计划文档 |
| 用例编写 | 12-03 | 12-10 | 测试用例集 |
| 执行 | 12-11 | 12-28 | 测试报告 |
| 回归 | 12-29 | 01-05 | 回归报告 |