第 1 章 用例收集与评审：来源、优先级、可测试性评审、记录模板
适用场景
本章适用于以下场景：
- 芯片或系统级原型验证启动前，需要系统化收集功能及性能用例；
- 已有需求文档或用户故事，但缺乏可执行的验证用例清单；
- 验证团队与设计、架构、系统测试团队之间需要对齐用例优先级与验证深度；
- 需要为新项目建立用例库模板与评审机制，避免漏测或重复测试。
前置条件
- 项目已确定产品需求文档（PRD）或系统功能规格书（SFS）；
- 已分配至少一位验证负责人（DVT Lead）；
- 具备可访问的用例管理系统（如 Polarion、TestRail 或 Excel 模板）；
- 已明确项目时间节点与里程碑（M1/M2/M3）。
操作步骤
- 确定用例来源：从 PRD、架构文档、用户手册、历史验证清单、Bug 库、FAE 反馈中筛选原始用例。
- 分类与编号：为每个用例分配唯一 ID（如 DVT_UC_001），并按功能域、功耗域、性能域、异常域分类。
- 优先级评定：采用 P0~P3 四级（P0 必测，P1 重要，P2 可选，P3 未来迭代），由验证负责人、设计负责人、产品经理共同确认。
- 可测试性评审：检查用例是否具备可观测输出、可控输入、激励时机、预期结果明确性；对于不可测用例，标注“需补充测试特征”并退回修改。
- 填写记录模板：按统一模板录入用例 ID、名称、来源、优先级、可测试性状态、验证负责人、关联需求、预期结果、备注。
- 交叉评审：组织专题评审会（TCR），验证组、设计组、系统测试组各一人，逐条审核用例内容、优先级与可测试性。
关键指标：用例收集阶段结束时，用例库覆盖率达到需求总数的≥90%，P0/P1 用例可测试性通过率≥95%。
输入输出物
| 类别 | 输入物 | 输出物 |
|---|---|---|
| 文档 | PRD / SFS / 用户故事 | DVT 用例库 V1.0（含优先级与可测试性标注） |
| 工具 | 用例管理工具（如 TestRail） | 用例评审报告（TCR Report） |
| 数据 | 历史 Bug 清单、FAE 反馈表 | 可测试性评估表 |
| 人 | 验证负责人、设计代表、产品经理 | 评审签名确认单（电子签或会议纪要） |
责任边界
- 验证负责人：主持用例收集与评审，维护模板，跟踪可测试性问题闭环。
- 设计/架构代表：提供技术可行性判断，协助补充未列出的关键用例。
- 产品经理：确认用例与实际业务场景匹配，裁定 P0/P1 优先级争议。
- 系统测试/FAE：提供用户侧真实反馈，识别隐式用例。
最佳实践：每个新迭代开始时，将上一迭代的“修复验证用例”作为新增用例纳入收集环节，确保回归覆盖。
记录材料
以下为用例记录模板的示例结构（JSON 格式仅用于说明字段，实际可在 Excel/TestRail 中使用）：
{
"用例ID": "DVT_UC_001",
"名称": "系统冷启动加载固件至 DDR",
"来源": "PRD-3.2.1 启动时序",
"优先级": "P0",
"可测试性": "可测",
"验证负责人": "张三",
"关联需求ID": "REQ-101",
"预期结果": "上电后 500ms 内固件校验完成，DDR 初始化成功",
"备注": "需配合外挂 Flash 模拟器"
}
注意：若用例的可测试性被评审为“不可测”，必须在备注中写明缺少的测试特征（如“无专用测试点”或“需增加 DfT 逻辑”），并指定责任人给出修订计划。
异常处理
- 用例重复：在评审环节直接合并，保留较早 ID，更新来源字段。
- 优先级争议：由产品经理仲裁，并记录仲裁理由在评审报告中。
- 可测试性不通过：在模板状态栏标记“退回”，联动至 DfT 或设计团队在 3 个工作日内回复解决方案；若超过期限未解决，降级至 P3。
- 用例缺失：评审中发现的遗漏用例，现场编号并录入 “紧急补录” 清单，于 24 小时内补填完整内容。
验收标准
- 用例库总条款数≥需求总数 × 1.2（含负面/异常场景）；
- 所有 P0 用例的可测试性评审结果为“可测”；
- P1 用例可测试性通过率≥90%，不通过的用例均已创建跟踪任务；
- 用例模板完整填写率 100%，无空字段。