第1章 验证体系全景：功能验证范围、性能验证范围、兼容性验证范围、三者的关联与冲突处理原则
1.1 适用场景
验证体系全景适用于以下典型场景：
- 新产品研发阶段：需同时确认功能正确、性能达标、多平台兼容。
- 版本迭代发布：新增特性可能影响既有性能和兼容性，需整体评估。
- 跨团队协作验证：功能、性能、兼容性由不同团队负责，需统一范围定义与优先级。
- 验收评审：向管理层或客户交付前，需清晰展示三类验证的覆盖度及冲突解决方案。
1.2 前置条件
- 已获取经过评审的需求规格说明书（含功能性需求、非功能性性能指标、目标平台清单）。
- 已确认系统设计文档，明确模块边界与对外依赖。
- 已准备基准测试环境（硬件型号、操作系统版本、浏览器/设备列表）。
- 已定义验证准入准出标准，例如性能基线、兼容性通过率阈值。
1.3 操作步骤
| 步骤 | 操作内容 | 关键角色 |
|---|---|---|
| 1 | 分解需求，形成功能验证范围（特性清单、用例路径） | 测试工程师 |
| 2 | 提取非功能性指标，定义性能验证范围（响应时间、吞吐量、资源利用率） | 性能工程师 |
| 3 | 根据目标平台矩阵，制定兼容性验证范围（设备/系统/浏览器组合） | 兼容性工程师 |
| 4 | 识别三类范围之间的重叠区域（如某功能在低级设备上的性能约束） | 验证经理 |
| 5 | 评估冲突（功能增加 vs 性能下降、兼容性适配 vs 功能简化），生成冲突处理决策表 | 验证经理 + 产品经理 |
| 6 | 经评审后固化验证体系全景图，作为后续各专项验证的输入 | 所有相关方 |
实践要点：在步骤4和5中，建议使用矩阵或维恩图可视化三类范围的边界，便于快速发现交集和冲突。本课程后续章节将提供具体模板。
1.4 输入输出物
| 类别 | 输入物 | 输出物 |
|---|---|---|
| 功能 | 功能需求清单、用例图 | 功能验证范围矩阵（优先级、测试深度） |
| 性能 | SLA指标、压测模型 | 性能验证范围清单（场景、阈值） |
| 兼容性 | 目标平台列表、用户分布数据 | 兼容性验证矩阵（设备×系统×浏览器） |
| 整体 | 冲突假设、风险登记册 | 验证体系全景图 + 冲突处理决策表 |
1.5 责任边界
- 测试工程师：负责功能验证范围的准确性和完整性。
- 性能工程师：负责性能基线定义、压测场景设计及结果解读。
- 兼容性工程师：负责平台覆盖度分析和兼容性缺陷判定。
- 验证经理：统筹三类范围的交集分析，主持冲突仲裁，维护全景图。
- 产品经理：对功能优先级和性能要求做出最终决策，协助解决冲突。
1.6 记录材料
- 验证范围登记表（含三类范围条目、负责人、版本号）
- 冲突识别与处理记录（冲突描述、影响分析、决策结果、跟踪状态）
- 全景图评审纪要（参加人、结论、待办项）
关键产出示例：冲突处理决策表片段（CSV格式），可使用项目管理工具或文档追踪。
冲突ID, 冲突描述, 影响范围, 决策结果, 责任人
C001, 新增实时渲染功能导致老设备CPU负载超阈值, 功能/性能/兼容性, 功能降级+性能优化, 张工/李工
C002, 微信小程序兼容适配需裁剪高级动画, 功能/兼容性, 桌面端保留动画, 移动端降级, 王工1.7 异常处理
| 异常类型 | 典型表现 | 处理策略 |
|---|---|---|
| 范围遗漏 | 上线后用户报告未覆盖的功能或平台 | 补录至全景图，调整后续验证轮次优先级 |
| 冲突僵持 | 功能/性能/兼容性团队无法达成一致 | 升级至项目决策委员会，基于用户影响面拍板 |
| 环境差异 | 性能结果在预发和生产环境差异大 | 重新校准性能基线，将环境差异因子加入模型 |
| 范围膨胀 | 各团队不断追加验证条目导致资源超载 | 执行红黄绿风险分级，仅关键项进入全景图 |
1.8 验收标准
- 三类验证范围均得到文档化，并经过相关团队会签。
- 所有已识别的冲突项均有明确的处理决定（接受、规避、转移、缓解）。
- 验证体系全景图（内联SVG）更新至当前版本，并纳入配置管理。
- 全景图通过了跨团队评审，无遗留的未定项。
注意事项：全景图不是一次性交付物，需在验证过程中持续更新。若发现新冲突或需求变更，必须回溯修改全景图并通知所有相关方。严禁在未同步全景图的情况下单独启动专项验证。