第3章 · RICE评估前的数据准备
适用场景
本章适用于硬件产品从EVT（工程验证测试）转向DVT（设计验证测试）阶段，需要执行RICE（Reach、Impact、Confidence、Effort）优先级排序的场景。具体包括：
- 待测试项清单已初步建立，但缺乏量化维度支撑排序决策；
- 产品团队需统一各测试项的优先级打分基准，避免主观经验偏差；
- 历史测试数据存在但未结构化，导致RICE评估置信度不足；
- 跨职能团队（硬件、软件、测试、质量）共同参与RICE评估前，需要对齐数据来源和口径。
前置条件
必要条件 —— 在开展本章数据准备工作前，必须满足以下全部条件：
| 序号 | 条件项 | 验收标准 |
|---|---|---|
| 1 | 产品需求基线冻结 | PRD/产品规格书已通过技术评审，变更受控 |
| 2 | EVT测试报告完成 | 至少完成一轮EVT全功能测试并输出汇总报告 |
| 3 | 测试环境及工具就绪 | 被测设备、夹具、仪表、软件版本均可用 |
| 4 | 数据存储权限开通 | 测试团队可访问问题追踪系统、自动化日志、历史故障库 |
操作步骤
本步骤按“收集 → 确认 → 整理”三阶段拆解，每个阶段包含具体动作与检查点。
阶段一：收集待测试项清单
- 导出原始池：从需求管理系统（如Jama、DOORS）或问题追踪系统（如Jira、Redmine）导出EVT阶段所有已验证的测试项、已知问题及用户故事。
- 去重与合并：删除重复条目，合并描述相近或测试目标完全一致的测试项，形成唯一清单。
- 分类打标：按功能模块（电源、射频、结构、热、信号完整性等）为每项打标签，便于后续RICE分析时按域分组。
- 编号锁定：为每个测试项赋予唯一ID（格式：
RICE-IT-3位序号），确保追溯。
常见错误：遗漏“非功能性需求”测试项（如可靠性、安全、法规合规项）。建议在收集阶段人工补充所有已知法律/认证测试项。
阶段二：确认每个测试项的可量化数据源
| 数据维度 | 推荐数据源 | 量化形式 |
|---|---|---|
| 覆盖用户量（Reach） | 市场分析报告、用户画像、产品出货量预测 | 百分比（如 5% / 30% / 80%） |
| 业务影响（Impact） | 历史故障等级（P0~P4）、用户投诉率、故障风险分级 | 1~5 等级分或按故障等级映射 |
| 置信度（Confidence） | 自动化测试通过率、复现率、历史同模块失效率 | 0~100% 或高中低等级 |
| 工作量（Effort） | 工时估算系统、测试用例复杂度、环境搭建工时 | 人天（整数） |
对每个测试项，填写《RICE数据源确认表》，明确各维度数据具体来自哪个系统/报告/责任人，避免评估时无依据。
阶段三：整理历史评估参考
- 建立历史故障库：汇总EVT阶段所有已解决和未解决问题的故障记录，提取与当前测试项同模块的故障率、根因分布。
- 计算同域基准：按功能模块统计历史RICE平均分（若有前序项目），作为当前评估的参考锚点。
- 记录依赖关系：识别测试项之间的耦合（如结构测试失败会导致射频测试需重测），形成依赖矩阵，防止RICE评估重复计算工作量。
输入输出物
| 类型 | 输入物 | 输出物 |
|---|---|---|
| 清单类 | 原始测试项池（EVT遗留+新增） | RICE待评估清单（去重、分类、编号完成） |
| 数据源类 | 各业务系统数据（Jira、自动化平台、工时系统） | RICE数据源确认表（每个测试项四维度映射关系） |
| 参考类 | 历史故障库、前序项目RICE记录 | 历史评估参考基线（模块级平均分、依赖关系矩阵） |
责任边界
| 角色 | 责任 | 边界说明 |
|---|---|---|
| 测试负责人 | 主导测试项收集、分类、去重；确认Effort数据源 | 不对业务影响（Impact）和用户量（Reach）负责，但需提供数据口径 |
| 产品经理 | 提供用户量（Reach）数据来源及业务影响等级定义 | 不参与测试项的技术分类，但需确认市场覆盖率阈值 |
| 质量工程师 | 整理历史故障库，计算置信度（Confidence）参考基线 | 不负责工作量估算，但需提供历史复现率数据 |
| 开发代表 | 协助确认Effort估算、识别技术依赖关系 | 不对业务影响等级负责，但需保证工作量数据准确 |
记录材料
- RICE待评估清单 v1.0.xlsx —— 含编号、名称、模块标签、来源需求ID。
- RICE数据源确认表 v1.0.xlsx —— 每个测试项的 Reach/Impact/Confidence/Effort 数据源字段（名称、系统、责任人、更新时间）。
- 历史评估参考基线.md —— 按模块汇总的统计指标（平均分、中位数、标准差）及依赖关系矩阵图。
所有记录材料需上传至项目文档库，并设置只读权限，后续RICE评估时直接引用。
异常处理
常见异常与应对预案
| 异常场景 | 原因 | 处理方式 |
|---|---|---|
| 部分测试项无法找到量化数据源 | 新功能无历史数据或数据未录入系统 | 启动专家打分替代（Delphi法），记录为“置信度低”并标注数据缺失原因 |
| 待测试项清单超过200项 | 需求膨胀或范围蔓延 | 触发“分级筛选”：先按模块抽验20%关键项，其余项归入低优先级池 |
| 历史数据与当前产品差异过大 | 产品代际变化或技术路线调整 | 仅参考同模块故障分布，不参考绝对分值；使用相对排序而非绝对打分 |
| 多系统数据口径不一致 | Effort在A系统按人天，B系统按小时 | 统一换算为“人天（8小时/天）”，并记录转化系数 |
验收标准
- 完整性：RICE待评估清单至少包含EVT阶段遗留测试项 + 不少于80%新增测试项；缺失项需有明确标注及计划补充日期。
- 可追溯性：每个测试项的四维度数据源均可在《RICE数据源确认表》中找到来源系统、责任人及最后更新日期。
- 一致性：同模块测试项的Effort估算单位统一，历史参考基线覆盖所有已列出的功能模块。
- 评审通过：数据准备工作完成需经过测试负责人、产品经理、质量工程师三方签字确认，并存入项目里程碑基线。
关键检查项
完成本章数据准备后，请逐项核对：
- 待测试清单是否已编号且无重复？
- 每个测试项的Reach/Impact/Confidence/Effort数据源是否具名？
- 历史参考基线是否覆盖所有已分类模块？
若全部“是”，则可进入下一章《RICE评分标准与权重设定》。
完成本章数据准备后，请逐项核对：
- 待测试清单是否已编号且无重复？
- 每个测试项的Reach/Impact/Confidence/Effort数据源是否具名？
- 历史参考基线是否覆盖所有已分类模块？
若全部“是”，则可进入下一章《RICE评分标准与权重设定》。