# L2 冒烟与逻辑验证

## 文档定位

每个子任务只维护一份：

```text
03.冒烟与逻辑验证.md
```

该文档分两个生命周期使用：

1. **G2 前：**设计核心主流程、范围内功能点和关键回归的验证计划。
2. **代码 Review 后：**填写实际执行结果、证据、失败修复和提测结论。

冒烟用于证明提测版本主流程可用、需求范围内功能点已验证；逻辑验证补充静态检查、构建、自动化测试、接口、数据及关键回归。二者使用同一组 `TC-XXX` 编号，禁止再维护第二份重复结果。

## G2 前必须设计

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

通常不要求穷举性能压测、所有并发组合、故障注入、全量兼容和无关系统级回归。某类风险属于本次需求核心内容时必须纳入。

## 文档结构

```markdown
# ST-XXX 冒烟与逻辑验证

## 1. 文档信息与验证基线
## 2. 验证目标、范围和非范围
## 3. 环境、前置条件和测试数据
## 4. 验证计划
### 4.1 静态检查、构建和自动化测试计划
### 4.2 冒烟及功能用例
### 4.3 关键影响回归计划
## 5. 实际执行基线
## 6. 静态检查、构建和自动化测试结果
## 7. 冒烟及功能用例结果
## 8. 关键回归结果
## 9. 接口和数据验证
## 10. 失败、修复和重验
## 11. 未执行项、遗留问题和风险
## 12. 验证结论
```

G2 时只确认第 1–4 节。第 5–12 节必须在代码实现和 Review 后按实际结果填写。

## 用例设计

计划表只描述如何验证：

| 编号 | 功能点 | 验证场景 | 前置条件 | 操作步骤 | 预期结果 | 验证类型 |
|---|---|---|---|---|---|---|

每个功能点至少一条有效用例。简单 CRUD 的最低验证：

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

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

## Review 后执行

Review 阻断问题处理完成后，执行：

- 最终代码检查；
- 项目适用的格式化、Lint、静态分析和类型检查；
- 编译或构建；
- 单元测试和集成测试；
- 核心调用链、权限、事务、幂等和状态流转检查；
- `TC-XXX` 冒烟及功能用例；
- 技术方案中的关键影响回归；
- 本地接口与数据库、Redis、ES、消息和日志验证。

结果表只记录实际执行事实：

| 用例编号 | 实际结果 | 状态 | 证据 | 执行时间 |
|---|---|---|---|---|

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

## 失败处理

```text
记录失败
→ 分析原因
→ 返回实现阶段修复
→ 重新 Code Review
→ 重跑失败项和受影响回归
→ 更新结果
```

不得删除失败测试、弱化断言、跳过必要用例、吞掉异常或只重跑成功项。

## 提测结论

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

- 核心主流程通过；
- 范围内功能点均有执行记录；
- 没有未处理的 Critical/High 或其他阻断缺陷；
- 接口变更影响的关键旧功能完成必要回归；
- 未验证内容已明确且不阻断提测；
- 已记录实际验证基线，包括工程、分支和 Commit 或等价版本标识。

完成第 5–12 节后，该文档与 04、05 一起提交 G3。