# L2 冒烟自测

## 定位

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

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

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

## 编写时机

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

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

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

## 必须覆盖

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

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

## 文档结构

```markdown
# ST-XXX 冒烟自测用例

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

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

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

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

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

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

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

## 最小用例原则

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

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

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

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

## 通过结论

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

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

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