4. 回归冒烟清单设计原则

回归冒烟清单是OpenAPI迁移版本质量保障的第一道防线。设计合理的清单，需要在冒烟测试定义、回归测试范围和清单设计三要素之间取得平衡。本节从这三个维度展开，并给出可落地的清单结构。

4.1 冒烟测试定义

冒烟测试（Smoke Testing）源自硬件测试：通电后如果冒烟，则立即停止，不再进行后续测试。在OpenAPI迁移场景中，冒烟测试定义为：对迁移后API的最核心、最基础功能进行快速验证，确认系统可运行、可响应、可返回正确状态码。

4.2 回归测试范围

回归测试（Regression Testing）的目的是确保OpenAPI迁移没有引入新的缺陷。回归范围需要根据变更影响分析来确定，而不是盲目全量回归。

回归范围的三层模型：

1. 直接变更层：被修改的API端点、请求/响应结构、参数约束。必须100%回归。
2. 依赖调用层：调用方（消费者）使用的相关API。如果消费者依赖的字段被删除或重命名，必须回归。
3. 间接影响层：共享Schema、公共组件、网关路由规则。通过OpenAPI diff工具自动识别。

4.3 清单设计三要素

回归冒烟清单的设计必须同时满足三个核心要素：覆盖率、优先级、可执行性。三者缺一不可，构成清单质量的三角模型。

4.3.1 覆盖率

覆盖率衡量清单对OpenAPI迁移变更的覆盖程度。不是追求100%的端点覆盖，而是有策略的覆盖。

4.3.2 优先级

优先级决定哪些用例先执行、哪些可以延迟。在OpenAPI迁移场景中，优先级由变更风险等级和业务影响度共同决定。

优先级分级标准：

• P0（阻塞级）：迁移后API不可用、核心业务链路断裂、数据丢失。必须冒烟通过才能继续。
• P1（关键级）：主要功能异常、响应结构不兼容、消费者集成失败。必须在回归阶段全部通过。
• P2（重要级）：非核心功能异常、性能退化、文档不匹配。可在回归阶段选择性执行。
• P3（建议级）：格式优化、冗余字段、非功能性建议。可延期或手动验证。

4.3.3 可执行性

可执行性确保清单中的每条用例都能自动化执行、稳定通过、结果可判定。这是清单从“理论设计”走向“实际落地”的关键。

可执行性检查清单：

4.4 清单模板示例

综合以上三要素，给出一个可直接复用的回归冒烟清单模板：

# OpenAPI迁移回归冒烟清单
# 版本：v2.3.0 → v3.0.0
# 生成日期：2025-04-01

## 冒烟测试（P0，执行时间 < 5min）
| ID | 端点 | 方法 | 预期状态码 | 断言要点 | 优先级 |
|----|------|------|-----------|---------|-------|
| SM-01 | /api/v2/users | GET | 200 | 返回用户列表，结构含 id/name/email | P0 |
| SM-02 | /api/v2/users/{id} | GET | 200 | 返回单个用户，email字段存在 | P0 |
| SM-03 | /api/v2/orders | POST | 201 | 创建订单成功，返回 orderId | P0 |
| SM-04 | /api/v2/health | GET | 200 | 返回 {"status":"ok"} | P0 |

## 回归测试（P1-P2，执行时间 < 30min）
| ID | 端点 | 方法 | 预期状态码 | 断言要点 | 优先级 |
|----|------|------|-----------|---------|-------|
| RG-01 | /api/v2/users | POST | 201 | 创建用户，验证 email 格式校验 | P1 |
| RG-02 | /api/v2/users/{id} | PUT | 200 | 更新用户，验证字段合并逻辑 | P1 |
| RG-03 | /api/v2/users/{id} | DELETE | 204 | 删除用户，验证级联删除 | P1 |
| RG-04 | /api/v2/orders | GET | 200 | 分页查询，验证 page/size 参数 | P2 |
| RG-05 | /api/v2/orders/{id} | GET | 404 | 不存在的订单，返回标准错误结构 | P1 |