Files
STM32F4-Base/docs/测试说明/流程与规范/测试文档模板规范.md
T
wandering1 4a4ad6bc5f chore(全仓): @build/@test 旧文档别名清退为技能调用名
现状口径:/keil-build 与 /serial-boot-test 是 DSH 会话的技能调用名,
不是 shell 命令;「名 + 命令行参数」的命令形态改为可执行体
run_boot_test.py 的真实调用。

- AGENTS.md:别名说明重写为「技能调用名不是 shell 命令」,两条目改
  「编译(/keil-build)」「串口回归(/serial-boot-test)」
- keil-build / serial-boot-test 两 skill 调用名与示例同步;task-worktree
  方案文档去掉 @build/@test 惯例从句;@task 保留(不在点名范围)
- 123 文件现状陈述全改;台架捕获、变更记录/时间线、rename 映射输入
  等 41 行历史证据保留旧名
- gen_memory_svg.py 6 处措辞随改,3 张 SVG 产物同批重跑
- 顺手补并行方案同行漏网计数 51→52 钩子

验证:提交期快钩子对 123 文件实跑全 Passed;check_doc_links --all
rc=0(3038 处、无法判定 0);check_mermaid --all rc=0;YAML 解析 52
钩子不变;skill-size rc=0;py_compile 全过;字节卫生零漂移。
2026-10-30 13:03:12 +08:00

13 KiB
Raw Blame History

测试文档模板规范

本文档定义本项目测试文档的统一模板与编写规范,确保各模块(CH395F、GD5F2GQ5UE、SD2506 RTC、存储等)测试文档格式一致、可追溯,并能直接接入 /serial-boot-test 自动化闭环与门禁体系。


1. 定位与关联文档

文档 关系
测试开发标准流程.md 测试开发总流程(规划 → 实现 → 门禁 → 沉淀);本文是其"测试规划(文档先行)"环节的可执行模板
自动化测试流程.md /serial-boot-test 闭环命令、参数与失败模式;本文"回归接入"章节引用它
docs/UI设计/UI_自动化测试流程.md UI 类改动的模拟器回归门禁
docs/问题记录/<模块>_Trap_Records.md 陷阱记录;测试文档"已知陷阱"章节引用它

2. 文档结构

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

# [模块名] 测试规范

## 1. 概述
### 1.1 套件与入口(TEST_SUITE_* 宏 / 入口函数 / 阶段宏 / 运行方式)
### 1.2 设计原则覆盖表(原则短语 → 描述 → 验证用例)
### 1.3 测试环境(拓扑、工具链、硬件版本、PC 端依赖)
### 1.4 启用方法(编译开关 + 运行命令)
### 1.5 回归接入(/serial-boot-test 标记 / PC 端脚本 / 门禁层级)

## 2~N. 阶段 x:[阶段名]
- 阶段元信息表(含阶段宏)
- TC-XXX-xxx: 测试用例(完整表格)

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

3. 概述章节要求

3.1 套件与入口(必填)

项 说明
套件宏 TEST_SUITE_XXX(test/board/test_config.h 选择,套件互斥,见 测试开发标准流程.md §3.1)
入口函数 xxx_test_run()(由 start_test_task() 统一调度)
阶段宏 ENABLE_XXX_PHASEN_TESTS(各阶段使能开关,取消注释启用)
运行方式 独立运行 / 需 PC 配合(逐阶段标注所需 PC 端工具)

3.2 回归接入(必填)

项 说明
/serial-boot-test 标记 套件结尾汇总行(如 === Storage Tests:)或阶段标题行;必须与串口实际输出逐字一致(verify_log.py 子串匹配)
禁止模式 默认 FAIL;ERROR;HardFault;assert,可按模块增补
PC 端脚本 test/*.py 工具清单与调用方式
门禁层级 板端测试套件 / 主机侧回归(串口标记 + 模拟器回归)/ 人工目检,见 测试开发标准流程.md §1

标记字符串一律从代码 DBG_* 实际输出复制(含大小写 / 冒号 / 空格);代码改了输出文案必须同步改文档(§7.6)。


4. 阶段元信息表

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

字段名 填写说明
阶段 直接写中文「阶段 N」(如 阶段 1、阶段 6),不再发阶段号
类型 独立运行 / 需 PC 配合 / 需物理操作 / 在 xxTask 中运行
耗时 预估执行时间
入口 代码入口函数或宏定义
出口 阶段结束标志(如串口输出内容,即 /serial-boot-test 可校验的标记)
阶段宏 对应使能宏(如 ENABLE_PHASE1_TESTS)

5. 测试用例表格模板

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

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

| 字段 | 值 |
|------|-----|
| **ID** | TC-XXX-NNN(全局唯一,不复用) |
| **优先级** | P0 / P1 |
| **类型** | 见下文 5.1 |
| **标题** | 一句话描述测试什么 |
| **前置条件** | 测试执行前必须满足的条件(编号列表) |
| **测试步骤** | 操作步骤(编号列表,动作具体到 API 或操作) |
| **预期结果** | 系统应表现的行为 |
| **通过标准** | 可量化的判定条件 |
| **机器可判** | 串口标记 / TEST_CHECK / 像素参考 / 池水位 / 人工目检(见 §7.4) |
| **覆盖原则** | 设计原则短语(可选,关联设计原则) |

5.1 类型枚举

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

5.2 优先级定义

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

6. 命名规则

6.1 阶段

  • 正文、元信息表、汇总表一律写中文**「阶段 N」**(如 阶段 1、阶段 6),不再发阶段号;
  • 用例号的百位已经带阶段信息(§6.3),无需另立阶段标识;
  • 历史文档里出现过的旧阶段号冻结不回改,新文档按本条。

6.2 模块缩写(以项目现用为准)

缩写 模块 现用文档
NET CH395F 网络(驱动 + 协议栈 + FTP 自动化用例) CH395F_Test_Guide.md(FTP_Test_Guide.md 的自动化部分复用其 TC-NET-8xx 编号)
GD5F GD5F2GQ5UE NAND Flash 驱动 GD5F2GQ5UE_Test_Guide.md
STO 存储(FTL + FatFS 集成) GD5F2GQ5UE_Test_Guide.md(TC-STO 章节)
RTC SD2506 RTC SD2506_Test_Guide.md
ADC TPAFE5160 + STM32 ADC1 采集与折算(台架注入验证) ADC前端注入验证流程.md
RS485 RS-485 通信 (待立)

新模块立测试文档时先定缩写(2~4 个大写字母),并同步更新本表与 测试开发标准流程.md §2.2 的缩写表。 注:旧版缩写 PHY / NAND 已被实际用法 NET / GD5F 取代(历史文档不回改,新文档按本表)。

6.3 测试用例 ID(已停发新号,以下形态只用于读现存号)

TC-{MOD}-{NNN}

⚠ 本族的号已于 2026-10-27 停发(用户裁定「批次三,不坐」→ docs/编号规范.md §4.1):新用例不再配 TC 号,标识 = 语义化测试函数名 + 本文档用例表的行名(§6.4 同口径)。下面的形态约定是读现存号用的, 不是起新号的模板。现存号保留、不清、不复用——测试追溯门禁按字面量读它。

  • 分阶段套件(历史形态,只读):序号百位放阶段号,TC-NET-101 = CH395F Phase 1 第 1 项、TC-NET-601 = Phase 6 第 1 项、TC-NET-1101 = Phase 11 第 1 项;
  • 无阶段划分套件(历史形态,只读):全局顺序编号(如 TC-STORAGE-03、TC-RTC-001);
  • 编号不复用:废弃用例保留编号并注明"已废弃";停发之后没有"取哪个号"这一步。

6.4 设计原则

  • 设计原则写语义短语,不再发号:如「单连接 socket」「中断集中处理」「线程安全」「DMA 边界安全」;
  • 覆盖原则处、汇总表与代码注释引用同一条短语(同一事实只在一处详述)。

7. 编写规范

7.1 表格格式

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

7.2 测试步骤与前置条件

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

7.3 语言

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

7.4 通过标准(必须可机器判定,或显式人工层)

通过标准必须落到以下通道之一,并在用例表"机器可判"字段标明:

通道 判定方 适用
串口日志标记 /serial-boot-test / verify_log.py 子串匹配 启动序列、阶段标题行、关键事件
返回值 / 寄存器 / 数据 板端 XXX_TEST_CHECK 断言 驱动命令、协议交互、数据完整性
像素参考 LVGL 模拟器回归(simulator/tests/) UI 渲染、字体、样式
内存池水位 模拟器池基线 / 往返常量 LVGL 对象泄漏、结构漂移
人工目检 人工目检 / 交互 屏幕观感等无法机器判定的项(必须写目检步骤)
  • 好的示例:70/70 成功率(100%)、串口显示 "PHY_CHANGE: 0x01"、10/10 回显匹配、=== Storage Tests: 11/11 PASSED (failed=0) ===
  • 差的示例:功能正常、系统稳定

7.5 引用

  • 引用函数、宏、文件名使用反引号(`net_poll()`)
  • 引用其他文档使用仓库相对路径:docs/问题记录/CH395F_Trap_Records.md、docs/测试说明/流程与规范/自动化测试流程.md
  • 代码位置引用:文件路径:行号 或函数名

7.6 文档维护(与代码同步)

  • 代码变更影响用例 / 判定标准 / 日志文案 → 当天更新本文档正文对应章节(与 测试开发标准流程.md §7.3 同标准);
  • 测试发现陷阱 → 写入 docs/问题记录/<模块>_Trap_Records.md(现象 / 根因 / 修复 / 规避),并在本文档"已知陷阱与故障模式"章节留链接;
  • 判定标准经实测修正 → 更新用例表,并把修正后的判据与实测依据写进正文(为什么这么判、拿什么证的),改动过程本身查 git log。

测试文档不再设「变更记录」节(2026-10-28 用户裁定,口径见 docs/文档规范.md §5.1):文档只写现状,「哪天改了什么」由 git log 负责;例外只有被别处当台账 / 唯一证据出处的文档(那份清单也在 docs/文档规范.md §5.1)。


8. 快速参考

8.1 新模块测试文档模板

# [模块名] 测试规范

## 1. 概述

### 1.1 套件与入口

| 项 | 值 |
|---|---|
| 套件宏 | `TEST_SUITE_XXX` |
| 入口函数 | `xxx_test_run()` |
| 阶段宏 | `ENABLE_XXX_PHASE1_TESTS` … |
| 运行方式 | 独立运行 / 需 PC 配合(列明哪些阶段、用什么 PC 工具) |

### 1.2 设计原则覆盖

| 原则 | 描述 | 验证用例 |
|------|------|----------|
| 单连接 socket | ... | TC-NET-601 |

### 1.3 测试环境

(硬件拓扑 / 工具链 / PC 端依赖)

### 1.4 启用方法

(test_config.h 开关 + 构建 / 运行命令)

### 1.5 回归接入

| 项 | 值 |
|---|---|
| `/serial-boot-test` 标记 | `=== XXX Tests:`(套件结尾汇总行的确切字符串) |
| PC 端脚本 | `test/xxx_test.py` |
| 门禁层级 | 板端测试套件 + 主机侧回归 |

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

| 项 | 值 |
|---|---|
| 阶段 | 阶段 1 |
| 类型 | ... |
| 耗时 | ... |
| 入口 | ... |
| 出口 | ... |
| 阶段宏 | `ENABLE_XXX_PHASE1_TESTS` |

### TC-<模块码>-<序号>: 用例标题

| 字段 | 值 |
|------|-----|
| **ID** | `TC-<模块码>-<序号>`(全局唯一,不复用) |
| **优先级** | P0 |
| **类型** | 功能测试 |
| **标题** | ... |
| **前置条件** | 1. ...<br>2. ... |
| **测试步骤** | 1. ... |
| **预期结果** | ... |
| **通过标准** | ...(可量化) |
| **机器可判** | 串口标记 / TEST_CHECK / 像素参考 / 池水位 / 人工目检 |

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

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

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

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

## 附录 C:API 覆盖(驱动类模块建议)

| API | 已覆盖 | 用例 |
|-----|--------|------|

8.2 附录模板

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

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

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

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

## 附录 C:API 覆盖

| API | 已覆盖 | 用例 |
|-----|--------|------|