L2 冒烟与逻辑验证

文档定位

每个子任务只维护一份：

03.冒烟与逻辑验证.md

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

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

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

G2 前必须设计

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

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

文档结构

# 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、消息和日志验证。

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

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

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

失败处理

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

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

提测结论

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

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

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

3.9 KiB Raw Permalink Blame History