105 lines
3.0 KiB
Markdown
105 lines
3.0 KiB
Markdown
# 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 可采用：
|
||
|
||
| 功能点 | 最低验证 |
|
||
|---|---|
|
||
| 新增 | 创建成功且数据结果正确 |
|
||
| 修改 | 修改成功且查询结果正确 |
|
||
| 查询 | 能查询到正确目标数据 |
|
||
| 列表 | 核心筛选和分页可用 |
|
||
| 删除 | 删除成功且后续结果符合规则 |
|
||
|
||
只有明确关键的边界才增加用例，例如无权限、非法状态、重复提交、审核中禁止删除，或接口变更后的关键调用方回归。
|
||
|
||
技术方案中的完整回归范围可以大于冒烟范围；冒烟只选择影响主流程、需求功能和提测质量的关键场景。
|
||
|
||
## 通过结论
|
||
|
||
只有以下条件同时满足，才能写“具备提测条件”：
|
||
|
||
- 核心主流程通过；
|
||
- 范围内功能点都有验证记录；
|
||
- 没有阻断缺陷；
|
||
- 接口变更影响的关键旧功能完成必要回归；
|
||
- 未验证内容已明确且不阻断提测。
|
||
|
||
环境、权限或依赖不足时标记“未验证”，禁止默认通过。
|