2. 回归冒烟清单概念：回归测试与冒烟测试的定义、区别，以及清单在OpenAPI迁移中的核心作用
2.1 核心定义：回归测试 vs 冒烟测试
在OpenAPI迁移项目中，冒烟测试与回归测试是保障版本质量的两道关键防线。两者目标不同、执行阶段不同，但共同构成了迁移验证的“安全网”。
| 维度 | 冒烟测试（Smoke Test） | 回归测试（Regression Test） |
|---|---|---|
| 核心目标 | 验证新版本API是否“可运行”，核心功能是否正常 | 验证新版本API是否“未破坏”已有功能，行为是否一致 |
| 执行时机 | 每次构建/部署后，第一时间执行 | 冒烟通过后，或版本发布前全面执行 |
| 测试范围 | 窄：仅覆盖关键路径（如认证、健康检查、核心CRUD） | 宽：覆盖所有历史接口、参数组合、边界条件 |
| 执行时间 | 短：通常 1~5 分钟 | 长：可能数十分钟到数小时 |
| 失败影响 | 立即阻断，阻止后续测试或发布 | 标记回归缺陷，但不一定阻断发布 |
| OpenAPI迁移场景 | 检查新版本OpenAPI规范能否正确加载、路由是否生效 | 检查旧版本接口行为在新规范下是否一致 |
实践要点：在OpenAPI迁移中，冒烟测试应优先覆盖“规范解析”、“认证鉴权”、“基础路由”三个维度。如果这三个维度失败，说明迁移后的API规范存在结构性错误，无需继续执行回归测试。
2.2 回归冒烟清单的核心作用
回归冒烟清单是一份结构化的测试用例索引，它将冒烟测试与回归测试的用例按OpenAPI迁移场景进行组织、编号和优先级排序。清单在迁移项目中承担以下核心作用：
- 作用一：迁移前后行为对齐 —— 清单明确列出每个接口在旧版本（v1）和新版本（v2）下的预期行为，确保迁移不改变API契约。
- 作用二：CI流水线自动化触发 —— 清单中的每个用例都可以映射为CI作业中的测试步骤，实现“清单即配置”。
- 作用三：回归范围可视化 —— 通过清单的“覆盖状态”列，团队可以直观看到哪些接口已测试、哪些存在风险。
- 作用四：版本回退决策依据 —— 当冒烟清单中的关键用例失败时，CI自动阻断发布；当回归清单中非关键用例失败时，可人工评估是否回退。
核心公式：OpenAPI迁移质量 = 冒烟清单通过率 × 回归清单覆盖率。两者缺一不可。
2.3 回归冒烟清单的结构设计
一份标准的回归冒烟清单应包含以下字段，便于CI联动和人工审查：
| 字段 | 说明 | 示例 |
|---|---|---|
| 用例ID | 唯一标识，按模块+序号编码 | SMK-AUTH-001 |
| 类型 | 冒烟(Smoke) / 回归(Regression) | Smoke |
| 接口路径 | OpenAPI规范中的路径 | /api/v2/users |
| 方法 | HTTP方法 | GET |
| 预期状态码 | 迁移后期望的HTTP响应码 | 200 |
| 优先级 | P0(阻塞级) / P1(关键) / P2(一般) | P0 |
| CI阻断策略 | 失败时是否阻断流水线 | 阻断 |
2.4 冒烟测试与回归测试在OpenAPI迁移中的执行流程
下图展示了从OpenAPI规范变更到冒烟/回归测试执行的完整流程，以及清单在其中的位置：
2.5 清单在CI联动中的核心价值
回归冒烟清单不仅仅是测试用例的集合，它还是CI流水线的“配置中心”。通过清单，可以实现以下联动能力：
- 自动生成测试任务：CI流水线解析清单YAML/JSON，动态生成测试作业，无需手动维护测试脚本列表。
- 优先级驱动的执行策略：P0冒烟用例并行执行，P1/P2回归用例按资源池排队执行，缩短反馈周期。
- 增量回归：清单记录每个用例的“最后通过版本”，CI只执行自上次通过以来受影响的用例，大幅减少回归时间。
- 版本回退自动化：当冒烟清单中任一P0用例失败时，CI自动触发回滚脚本，并通知相关责任人。
常见误区：不要将冒烟清单与回归清单混为一谈。冒烟清单追求“快”，回归清单追求“全”。在CI流水线中，冒烟失败应直接阻断，回归失败应生成报告供人工决策。混用会导致流水线响应变慢或遗漏关键缺陷。
2.6 回归冒烟清单的维护原则
清单不是一成不变的，它需要随着OpenAPI版本的演进持续更新。以下是三条核心维护原则：
- 版本对齐：每次OpenAPI规范变更后，清单必须同步更新。新增接口自动加入回归清单，废弃接口标记为“已弃用”并保留历史记录。
- 优先级动态调整：根据线上故障数据，将频繁出错的接口提升为P0冒烟用例；将长期稳定的接口降级为P2回归用例。
- 清单即文档：清单中的“预期行为”字段应直接引用OpenAPI规范中的描述，确保测试与规范一致，避免“测试通过但规范错误”的情况。