第4章 测试用例编写规范:格式、覆盖维度、预期结果、异常场景
4.1 适用场景
本规范适用于DVT原型验证阶段中所有测试用例的编写活动,包括但不限于:
- 功能验证用例(Feature Verification Test Case)
- 接口时序验证用例(Interface Timing Test Case)
- 边界压力测试用例(Boundary & Stress Test Case)
- 异常注入与恢复验证用例(Error Injection & Recovery Test Case)
- 回归验证用例(Regression Test Case)
测试用例编写结果是整个DVT验证交付物的核心资产,直接影响验证覆盖率和问题定位效率。
4.2 前置条件
- 需求基线已冻结:PRD(产品需求文档)与功能规格书完成基线评审,变更受控。
- 设计规格已发布:模块级设计文档(Module Design Spec)已通过技术评审。
- 验证计划已签发:DVT验证计划(Verification Plan)已明确测试范围、里程碑与资源分配。
- 工具链就绪:用例管理平台(如 Jira / TestRail / Polarion)、版本管理工具(Git / SVN)及原型环境已部署。
- 模板已定版:测试用例模板(Test Case Template)经QA团队评审并冻结。
4.3 操作步骤
下图为测试用例编写规范的核心要素结构,四个维度必须同时在用例中完整体现。
4.3.1 格式规范
所有DVT测试用例必须使用统一模板,模板包含以下强制字段:
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 用例编号 | DVT-{模块}-{序号}-{版本} | DVT-I2C-001-v1.2 |
| 用例标题 | 动词+对象+条件,不超过20字 | I2C Master 写操作多字节校验 |
| 测试目标 | 明确验证的需求ID与功能点 | 验证 REQ-I2C-03: 多字节连续写入数据完整性 |
| 预置条件 | 硬件/软件/环境配置清单 | DUT I2C Master 模式,Slave 地址 0x50,时钟 100kHz |
| 测试步骤 | 编号步骤,每步可操作、可观察 | 1. 写入 0xA5 0xB6 0xC7 … |
| 预期结果 | 量化断言 + 时序/电平描述 | SDA 上回读数据与写入一致,无NACK |
| 异常场景标记 | 是/否 + 异常类型标签 | 是 | 错误注入:Slave 无应答 |
推荐格式:用例模板建议使用 JSON 或 YAML 结构化存储,便于自动化解析与回归。以下为推荐 JSON 格式示例:
{
"case_id": "DVT-I2C-001-v1.2",
"title": "I2C Master 写操作多字节校验",
"target": ["REQ-I2C-03", "REQ-I2C-05"],
"config": {
"role": "master",
"slave_addr": "0x50",
"clock_khz": 100,
"pullup_enable": true
},
"preconditions": [
"DUT 处于 I2C Master 模式",
"Slave 模拟器已加载应答脚本"
],
"steps": [
{"step": 1, "action": "发送 START + Slave地址(0x50) + 写位(0)", "expected": "ACK 接收"},
{"step": 2, "action": "连续写入 0xA5 0xB6 0xC7", "expected": "每字节后 ACK"},
{"step": 3, "action": "发送 STOP", "expected": "总线进入空闲态"}
],
"expected_result": "回读缓冲区数据 = [0xA5, 0xB6, 0xC7],无 NACK 产生",
"is_abnormal": false,
"tags": ["functional", "multi-byte"]
}
4.3.2 覆盖维度
测试用例必须从以下四个维度进行覆盖,每个维度在用例集中不可缺失:
| 覆盖维度 | 覆盖要求 | 典型覆盖项 |
|---|---|---|
| 功能覆盖 | 每个功能需求至少对应一个正向用例 | 寄存器读写、中断触发、数据路径、状态机跳转、协议命令 |
| 接口覆盖 | 所有对外接口(信号/总线/外设)的时序、电平、协议 | I2C 时序参数、SPI 模式、GPIO 电平、DDR 训练序列 |
| 边界覆盖 | 输入/输出参数的边界值、临界值、饱和值 | FIFO 空/满、计数器最大值、时钟分频极限、电压阈值 |
| 异常覆盖 | 错误注入、超时、断连、非法操作、资源竞争 | 总线冲突、CRC 错误、看门狗超时、电源跌落、内存越界 |
注意:“功能覆盖”不等于“全覆盖”。每个维度的覆盖深度由验证计划中的覆盖率目标(Coverage Target)定义,不得低于 90% 的代码覆盖率和 100% 的需求覆盖率。
4.3.3 预期结果
预期结果是测试用例通过/失败的判定基准,必须满足以下三性:
- 可判定性:结果描述必须是布尔可验证的(通过/失败),不得使用模糊表述如“系统正常”、“数据正确”。应写明具体数值、电平、时序窗口。
- 可观测性:结果必须能在原型环境中通过示波器、逻辑分析仪、日志、寄存器回读等手段直接观测。
- 确定性:在相同预置条件下,预期结果必须唯一且可重复产生。
正确示例:“SPI MISO 数据在第 3~18 个 SCK 周期内逐位输出:0x3A,CS 拉高前最后一位保持 valid ≥ 5ns。”
错误示例:“SPI 通信正常,数据正确。” — 未量化,不可判定。
错误示例:“SPI 通信正常,数据正确。” — 未量化,不可判定。
4.3.4 异常场景
异常场景用于验证DUT在非理想条件下的鲁棒性,必须在用例中明确标记并单独描述。常见异常场景分类如下:
| 异常类别 | 注入方式 | 典型用例 |
|---|---|---|
| 信号异常 | 强制拉高/拉低、毛刺注入、时钟抖动脉冲 | SCL 毛刺时 I2C 从机是否误触发 |
| 协议异常 | 非法命令、错误校验、超时未响应 | SPI 写入未定义命令寄存器,DUT 应返回错误码 |
| 资源异常 | 缓冲区满、DMA 冲突、电源欠压 | FIFO 满时继续写入,DUT 应产生溢出标志 |
| 恢复验证 | 异常触发后观察DUT是否自主恢复或进入安全态 | 看门狗超时后 DUT 是否复位并重新初始化 |
关联操作:每个异常场景用例必须写明“异常注入点”和“预期恢复行为”。若DUT在异常后不能自动恢复,则应在预期结果中明确标注“需人工复位”或“触发系统告警”。
4.4 输入输出物
| 类型 | 输入物 | 输出物 |
|---|---|---|
| 文档类 | PRD、功能规格书、验证计划、模板文件 | 测试用例单(Test Case Spec)、用例评审记录 |
| 数据类 | 寄存器列表、接口时序图、波形参考 | 测试向量文件(.bin / .hex / .json)、激励脚本 |
| 配置类 | 原型环境配置清单、工具链参数 | 用例执行配置(.yaml / .cfg)、覆盖率目标文件 |
4.5 责任边界
- 验证工程师(Owner):负责用例编写、自检、提审,确保格式规范、维度完整、预期结果可判定、异常场景可复现。
- 设计工程师(Reviewer):负责评审用例的功能正确性、接口时序匹配度、异常场景的合理性。
- QA工程师(Auditor):负责审计用例对验证计划的覆盖率、格式合规性、异常标签完整性。
- 项目经理(Approver):批准用例基线冻结,确认用例集满足里程碑出口标准。
4.6 记录材料
以下记录材料必须在用例编写阶段归档并受版本管理:
- 测试用例主清单(Test Case Master List):包含所有用例编号、状态、责任人、版本。
- 用例评审纪要(Review Minutes):记录评审意见、修改项、结论。
- 覆盖率映射表(Coverage Mapping Table):每个用例与需求ID、覆盖维度的映射关系。
- 异常场景索引表(Abnormal Scenario Index):所有带异常标记的用例汇总,用于回归测试优先级排序。
4.7 异常处理
| 异常现象 | 可能原因 | 处理措施 |
|---|---|---|
| 用例模板字段缺失 | 模板版本与验证计划未对齐 | 回退到已冻结模板版本,重新填写 |