Files
STM32F4-Base/docs/测试文档模板规范.md
2026-07-22 11:14:22 +08:00

5.5 KiB
Raw Blame History

测试文档模板规范

本文档定义本项目中测试文档的统一模板和编写规范确保各模块CH395F、GD5F2GQ5UE、TPAFE5160 等)的测试文档格式一致、可追溯。


1. 文档结构

每份测试文档包含以下章节:

# [模块名] 测试规范

## 1. 概述
- 测试范围
- 设计原则覆盖表DP-xx → 描述 → 验证用例)
- 测试环境(拓扑、工具链、硬件版本)
- 启用测试的方法

## 2~N. 阶段 x[阶段名]
- 阶段元信息表:阶段 ID、类型、耗时、入口、出口
- TC-NET-xxx: 测试用例(完整表格)

## N+1. 脚本参考(如有 PC 端工具)
## N+2. 已知陷阱与故障模式(引用 Traps 文档)
## 附录 A通过/失败汇总矩阵
## 附录 B测试覆盖 vs 设计原则

2. 阶段元信息表

每个阶段以表格开头,描述阶段的整体属性:

字段名 填写说明
阶段 ID TM-模块缩写-两位数序号,如 TM-PHY-01、TM-NAND-01
类型 独立运行 / 需 PC 配合 / 需物理操作 / 在 xxTask 中运行
耗时 预估执行时间
入口 代码入口函数或宏定义
出口 阶段结束标志(如串口输出内容)

3. 测试用例表格模板

每个测试用例使用统一表格格式:

### TC-模块缩写-序号: 用例标题

| 字段 | 值 |
|------|-----|
| **ID** | TC-XXX-NNN全局唯一 |
| **优先级** | P0 / P1 |
| **类型** | 见下文 3.1 |
| **标题** | 一句话描述测试什么 |
| **前置条件** | 测试执行前必须满足的条件(编号列表) |
| **测试步骤** | 操作步骤(编号列表,动作具体到 API 或操作) |
| **预期结果** | 系统应表现的行为 |
| **通过标准** | 可量化的判定条件 |
| **覆盖原则** | DP-xx可选关联设计原则 |

3.1 类型枚举

类型 说明 适用场景
功能测试 验证某项功能是否符合预期 正常的收发、初始化、配置等
负向测试 验证系统对非法/异常输入的处理 超时、断开、无效参数等
边界测试 验证系统在边界条件的表现 最大包长、最小超时、满队列等
压力测试 验证系统在高负载下的稳定性 多客户端、高频请求、长时运行等
恢复测试 验证系统从故障中恢复的能力 断线重连、PHY 重连、复位恢复等
合规测试 验证实现是否符合特定约束 中断处理位置、等待顺序、字节序等
稳定性测试 验证系统长时间运行的可靠性 长时间压力、反复循环等

3.2 优先级定义

优先级 定义
P0 核心功能,必须通过。阻塞后续测试或影响系统基本可用性
P1 重要功能,建议通过。失败表明潜在缺陷但不阻塞基本功能

4. 命名规则

4.1 阶段 ID

TM-{MOD}-{NN}
  • TM — Test Module
  • {MOD} — 模块缩写(大写)
    • PHY — CH395F 网络
    • NAND — GD5F2GQ5UE NAND Flash
    • ADC — TPAFE5160 ADC
    • RTC — SD2506 RTC
    • RS485 — RS-485 通信
  • {NN} — 两位序号,从 01 开始

示例:TM-PHY-01, TM-NAND-03

4.2 测试用例 ID

TC-{MOD}-{NNN}
  • TC — Test Case
  • {MOD} — 模块缩写(同上)
  • {NNN} — 三位序号,从 001 开始

示例:TC-PHY-101, TC-NAND-201

4.3 设计原则 ID

DP-{NN}
  • DP — Design Principle
  • {NN} — 两位序号,从 01 开始

示例:DP-01, DP-02


5. 编写规范

5.1 表格格式

  • 使用 GFM (GitHub Flavored Markdown) 表格
  • 首列为字段名,加粗(**字段**
  • 第二列为值,左对齐
  • 多行内容使用 <br> 换行(保持表格可读性)

5.2 测试步骤与前置条件

  • 使用有序列表(1. 2. 3.
  • 每个步骤是一个完整的可执行动作
  • 包含具体 API 名或操作名(如 net_recv()ch395f_open_socket()
  • 前置条件写明硬件状态、PC 端命令、代码配置等

5.3 语言

  • 中文书写(技术标识保留英文)
  • 保持客观、精确、可验证
  • 避免模糊表述(如 "应该能正常工作" → "回显内容与发送完全一致"

5.4 通过标准

  • 必须可量化验证
  • 好的示例:70/70 成功率100%串口显示 "PHY_CHANGE: 0x01"10/10 回显匹配
  • 差的示例:功能正常系统稳定

5.5 引用

  • 引用函数、宏、文件名使用反引号(`net_poll()`
  • 引用其他文档使用相对路径:docs/CH395F_Trap_Records.md

6. 快速参考

6.1 新模块测试文档模板

# [模块名] 测试规范

## 1. 概述

### 设计原则覆盖

| 原则 | 描述 | 验证用例 |
|------|------|----------|
| DP-01 | ... | TC-XXX-xxx |

### 测试环境

[硬件拓扑]


## 2. 阶段 1[阶段名]

| 阶段 ID | TM-XXX-01 |
|---------|------------|
| **类型** | ... |
| **耗时** | ... |
| **入口** | ... |

### TC-XXX-001: 用例标题

| 字段 | 值 |
|------|-----|
| **ID** | TC-XXX-001 |
| **优先级** | P0 |
| **类型** | 功能测试 |
| **标题** | ... |
| **前置条件** | 1. ...<br>2. ... |
| **测试步骤** | 1. ... |
| **预期结果** | ... |
| **通过标准** | ... |

6.2 附录模板

## 附录 A通过/失败汇总矩阵

| 阶段 | TC ID | 优先级 | 类型 | 状态 |
|------|-------|--------|------|------|

## 附录 B测试覆盖 vs 设计原则

| 原则 | 覆盖用例 |
|------|----------|