4. 冒烟测试清单设计原则：最小化验证集、关键路径覆盖、失败快速反馈机制
数据库迁移冒烟测试不是全量回归，而是用最小代价在最短时间内确认迁移后的数据库核心功能是否可用。设计冒烟清单必须遵循三条硬性原则：最小化验证集、关键路径覆盖、失败快速反馈机制。以下逐一展开。
4.1 最小化验证集：只测“不可不测”的
冒烟测试的用例数量通常控制在全量测试集的 5%～10%。选择标准是：如果这个用例失败，迁移一定不可上线。
| 筛选维度 | 包含内容 | 排除内容 |
|---|---|---|
| 数据完整性 | 主键唯一性、行数校验、最大/最小 ID 范围 | 字段级业务逻辑校验 |
| 连接可达性 | 应用账号登录、基本 SELECT 1、会话数检查 | 连接池压力测试 |
| DDL 兼容性 | 建表、删表、加索引（目标库语法） | 分区表高级特性验证 |
| DML 基础能力 | INSERT / UPDATE / DELETE 各一条 | 批量操作、事务隔离级别验证 |
避坑提示： 不要为了“全面”而把冒烟清单膨胀到 50 条以上。每增加一条用例，反馈周期就会延长。如果冒烟测试超过 5 分钟，说明验证集已经不够“最小化”。
4.2 关键路径覆盖：从用户视角穿透核心链路
关键路径是指用户最常用、业务价值最高、一旦中断影响面最大的数据库操作路径。设计时采用“三层穿透”方法：
- 接入层：应用能否正常建立连接并执行简单查询。
- 数据层：核心表（订单、用户、流水）的 CRUD 是否正常。
- 依赖层：存储过程、视图、触发器等对象是否存在且可执行。
以下 SVG 展示了关键路径覆盖的“三层穿透”模型：
实战建议： 每个业务域（订单、支付、用户）只选 1 条最核心的链路。例如订单域只测“创建订单 → 扣库存 → 生成流水”，支付域只测“发起支付 → 回调 → 更新状态”。链路总数控制在 3～5 条。
4.3 失败快速反馈机制：秒级感知，分钟级定位
冒烟测试的核心价值在于快。如果失败反馈延迟超过 30 秒，测试人员就会失去耐心，甚至跳过冒烟直接进入全量测试。设计反馈机制时需关注以下三个指标：
| 指标 | 目标值 | 实现方式 |
|---|---|---|
| 单用例执行时间 | < 3 秒 | 使用预编译 SQL、连接池复用、跳过复杂 JOIN |
| 失败告警延迟 | < 5 秒 | 实时日志流 + 断言失败即中断 |
| 失败定位信息 | 包含 SQL、错误码、行号 | 异常捕获时输出完整上下文 |
以下 SVG 展示了失败快速反馈的“中断-告警-定位”流程：
常见反模式： 有些团队把冒烟测试设计成“全部执行完再汇总报告”，这完全违背了快速反馈原则。正确的做法是：任何一个用例失败，立即中断整个冒烟流程，并输出失败上下文。这样测试人员可以在 10 秒内知道迁移是否通过。
4.4 三条原则的协同关系
最小化验证集、关键路径覆盖、失败快速反馈机制不是孤立的，它们共同构成一个三角稳定结构：
- 最小化验证集 保证了执行速度，为快速反馈提供时间基础。
- 关键路径覆盖 保证了测试的有效性，避免“测了没用的，漏了关键的”。
- 失败快速反馈机制 保证了问题能被及时捕获，避免“测完了才发现失败”。
在实际落地时，建议将冒烟清单设计为可配置的 YAML 或 JSON 文件，每条用例包含以下字段：
{
"id": "smoke_001",
"name": "订单表行数校验",
"type": "data_integrity",
"sql": "SELECT COUNT(*) FROM orders",
"expected": {"min": 1000, "max": 1000000},
"timeout_ms": 3000,
"on_failure": "abort"
}这种结构化清单可以自动生成测试脚本，同时支持人工审查。每条用例都明确标注 on_failure 行为（abort 或 warn），确保关键路径上的失败能立即中断流程。