first commit

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