L2 冒烟自测

定位

03.冒烟自测用例.md 是提测前的精简自测清单，目标是：

保证提测版本核心业务主流程可用；
保证需求范围内每个功能点都经过有效验证。

它不是完整测试方案，不要求穷举所有异常、并发和基础设施故障。只有某类风险属于本次需求核心内容时，才必须纳入冒烟。

编写时机

技术方案完成后、编码前编写初稿：

01 需求分析
→ 02 技术方案
→ 03 冒烟用例
→ G2
→ 代码实现

实现中发现新的关键功能或影响范围时，先更新 02 和 03。

必须覆盖

本次需求核心主流程；
01.需求分析.md 中全部范围内功能点；
02.技术实现方案.md 中新增或修改的接口；
明确要求的关键业务规则；
关键权限和状态流转；
主要数据新增、修改、查询和删除结果；
接口变更直接影响的关键旧功能；
会阻断提测的主要异常场景。

通常不在冒烟阶段全面覆盖性能压测、全部并发组合、故障注入、全量兼容和无关系统级回归。

文档结构

# ST-XXX 冒烟自测用例

## 1. 文档信息
- 大需求编号：
- 子任务编号：
- 需求版本：
- 技术方案版本：
- 提测版本或 Commit：
- 测试环境：

## 2. 自测范围
- 核心主流程：
- 本次功能点：
- 关键回归：
- 非本次自测范围：

## 3. 前置条件和测试数据

## 4. 冒烟自测用例
| 编号 | 功能点 | 验证场景 | 前置条件 | 操作步骤 | 预期结果 | 实际结果 | 状态 | 证据 |
|---|---|---|---|---|---|---|---|---|

## 5. 功能覆盖检查
| 功能编号 | 功能名称 | 对应用例 | 是否已验证 |
|---|---|---|---|

## 6. 自测结论
- 核心主流程是否通过：
- 需求功能点是否全部验证：
- 是否存在阻断问题：
- 未通过或未验证项：
- 是否具备提测条件：

编码前填写场景和预期结果；执行后再填写实际结果、状态和证据。

最小用例原则

每个功能点至少一条有效用例。简单 CRUD 可采用：

功能点	最低验证
新增	创建成功且数据结果正确
修改	修改成功且查询结果正确
查询	能查询到正确目标数据
列表	核心筛选和分页可用
删除	删除成功且后续结果符合规则

只有明确关键的边界才增加用例，例如无权限、非法状态、重复提交、审核中禁止删除，或接口变更后的关键调用方回归。

技术方案中的完整回归范围可以大于冒烟范围；冒烟只选择影响主流程、需求功能和提测质量的关键场景。

通过结论

只有以下条件同时满足，才能写“具备提测条件”：

核心主流程通过；
范围内功能点都有验证记录；
没有阻断缺陷；
接口变更影响的关键旧功能完成必要回归；
未验证内容已明确且不阻断提测。

环境、权限或依赖不足时标记“未验证”，禁止默认通过。

3.0 KiB Raw Permalink Blame History Unescape Escape