第4章 输入输出物定义：验证计划模板、边界检查表、测试用例规范
章节定位：本章定义协同验证过程中三个核心工件的标准模板与规范。验证计划模板驱动整体验证策略，边界检查表确保覆盖完整性，测试用例规范保证执行一致性。这三个文档构成了验证流程的“铁三角”。
适用场景
- 项目启动阶段，需要建立统一的验证文档基线
- 验证团队与固件/硬件设计团队之间需要明确交付物格式和内容深度
- 项目审查或审计时，需要标准化的模板来核验覆盖率
- 多项目复用或人员轮换时，保证文档的一致性与可读性
前置条件
- 已完成系统需求分析和架构定义（第2/3章输出）
- 已识别所有硬件固件交互接口（寄存器地址、中断号、DMA通道等）
- 已确定验证方法论（UVM、Formal、定向测试或组合）
- 版本控制仓库已建立，用于存储和管理所有模板文档
操作步骤
步骤1：制定验证计划模板（VPT 4.1）
验证计划是验证过程的蓝图，必须覆盖所有功能点与边界场景。模板应包含以下标准节段：
| 节段编号 | 节段名称 | 必填内容 |
|---|---|---|
| VP-1 | 版本历史 | 日期、版本号、作者、变更描述 |
| VP-2 | 验证范围 | 被验证模块列表、排除项（含理由） |
| VP-3 | 功能分解矩阵 | 需求ID、功能描述、硬件/固件归属、优先级（P0/P1/P2） |
| VP-4 | 边界场景清单 | 场景ID、边界类型、预期行为、检查方式 |
| VP-5 | 测试策略 | 定向测试、随机测试、形式化验证的比例与选择依据 |
| VP-6 | 覆盖率目标 | 代码覆盖率、功能覆盖率、固件路径覆盖率的量化目标 |
| VP-7 | 资源与里程碑 | 人力投入、仿真环境、时间节点（RTL冻结、固件冻结、正式投片前） |
// 验证计划模板JSON Schema示例（精简）
{
"version": "1.0",
"scope": {
"modules": ["uart", "spi", "dma"],
"exclusions": ["pmu (low power unit) — 由系统级验证覆盖"]
},
"feature_matrix": [
{
"req_id": "REQ_UART_001",
"description": "UART波特率配置寄存器写入后立即生效",
"owner": "hw",
"priority": "P0"
}
],
"coverage_goal": {
"code_line": 95,
"toggle": 90,
"functional_assert": 100
}
}
步骤2：制作边界检查表（BCT 4.2）
边界检查表是验证计划中边界场景清单的补充，专注于接口级、时序级和协议级的边界条件。每一条检查项必须明确描述硬件侧和固件侧的预期行为。
常见陷阱：边界检查表中容易出现“刚过边界”场景缺失。例如 FIFO 满时再写一个数据（满+1）与 FIFO 空时再读一个数据（空-1）必须分别列项，不能合并为“FIFO 溢出场景”。
// 边界检查表标准条目示例
条目编号: BCT_UART_007
边界类型: 寄存器边界（写入最小值/最大值）
描述: UART 数据位长度字段为 3-bit（0-7），允许值为 5/6/7/8 bits
硬件预期: 写入值 5/6/7/8 时配置生效；写入 0-4 或 7 以外的值时保持上一次有效值
固件预期: 固件必须检查写回确认值，并针对无效写入触发错误处理
验证方法: 定向寄存器读写 + 硬件 assert 检查
优先级: P0
步骤3：编写测试用例规范（TCS 4.3）
测试用例规范是验证工程师的执行手册。每个测试用例必须按照以下统一结构编写，不得自定义格式：
| 字段 | 说明 | 示例 |
|---|---|---|
| Test ID | 命名规则：模块_场景_变体_编号 | UART_BOUND_STOPBITS_01 |
| Title | 简明概括测试目的 | UART 停止位配置为2位时发送完整帧 |
| Precondition | 固件/硬件初始化状态 | UART 已复位，中断使能关闭，DMA 未配置 |
| Stimulus | 激励序列（硬件写入 + 固件寄存器操作） | 写 UART_CTRL 寄存器设置停止位=2，立即发送 0x55 |
| Expected Outcome | 硬件行为 + 固件响应 + 观测点 | TX 线上出现两个停止位；状态寄存器 bit[4] = 1 表示帧结束；ISR 触发 |
| Coverage Points | 关联功能覆盖点和覆盖组 | cover_stopbit[2], cover_frame_complete |
| Pass/Fail Criteria | 明确的判据 | 示波器或逻辑分析仪捕获停止位宽度为2个位时间 ±5%，且固件收到完成中断 |
输入输出物
- 输入物：系统需求文档（RSD）、硬件寄存器描述列表（HRDL）、固件架构规范（FAS）、接口协议规范（IPS）
- 输出物：验证计划模板 VPT.4.1（经过评审）、边界检查表 BCT.4.2（基线版本）、测试用例规范 TCS.4.3（至少覆盖所有 P0 场景）
责任边界
- 固件验证工程师：主导测试用例规范的编写，确保激励和预期结果在固件中可实现；评审边界检查表中固件相关条目
- 硬件验证工程师：主导验证计划模板的制定，负责边界检查表中硬件侧（assert、时序）内容的补充；提供仿真环境兼容性反馈
- 设计架构师：验证计划模板中功能分解矩阵的最终批准人
- 质量 assurance（QA）：模板规范使用的合规性审计，每两周抽查一次文档完整性
记录材料
所有模板、检查表和规范文档必须存入项目数据库，版本号同步更新。记录清单如下：
- 验证计划模板 vX.Y（含评审签字页扫描件）
- 边界检查表 vX.Y（关联每个检查项的通过/失败标记）
- 测试用例规范 vX.Y（每轮回归后更新执行结果状态）
异常处理
异常场景1：需求中途变更
处理流程：变更请求（CR）提交 → 验证计划模板中对应功能分解矩阵项标记为“待废弃” → 边界检查表相关条目暂停执行 → 测试用例规范中附加“失效标记”字段，打印新需求覆盖的测试用例 ID。
异常场景2：验证计划与边界检查表内容冲突
处理流程：冲突条目上升至每周验证-设计联席会裁决 → 记录裁决结果到冲突处理日志 → 更新模板和检查表版本号，修复对应条目后自动触发通知。
处理流程：变更请求（CR）提交 → 验证计划模板中对应功能分解矩阵项标记为“待废弃” → 边界检查表相关条目暂停执行 → 测试用例规范中附加“失效标记”字段，打印新需求覆盖的测试用例 ID。
异常场景2：验证计划与边界检查表内容冲突
处理流程：冲突条目上升至每周验证-设计联席会裁决 → 记录裁决结果到冲突处理日志 → 更新模板和检查表版本号，修复对应条目后自动触发通知。
验收标准
- 三个模板文档均通过团队评审，评审参会人数≥3人，且包含至少1名非本项目的人员作为独立评审员
- 边界检查表条目数量≥验证计划中 P0 场景数的 2 倍（每个 P0 场景至少对应 2 条边界检查）
- 测试用例规范中每个用例的“Expected Outcome”字段长度≥3行，明确区分硬件和固件预期行为
- 模板一致性与合规性检查（手动或脚本）无严重违规项（严重违规定义为：缺失必填字段、不存在的需求ID引用、无关联覆盖率点）