4. 冒烟测试清单设计原则：最小化原则、可重复原则、自动化优先原则、覆盖率与风险平衡

在集成测试环境下，数据库迁移的冒烟测试清单并非简单的“能跑就行”，而是一套经过精密权衡的工程产物。设计冒烟清单时，必须遵循四项核心原则：最小化、可重复、自动化优先以及覆盖率与风险平衡。这四项原则共同决定了冒烟测试的效率和可靠性，是后续故障排查的基础。

4.1 最小化原则：用最少的用例覆盖最核心的路径

最小化原则要求冒烟测试用例数量必须精简到极致，通常控制在 5～15 个 核心用例以内。其目标是：在 5～10 分钟内验证迁移后的数据库是否具备“可被进一步测试”的基本条件。

• 排除非关键路径：不测试报表统计、历史数据归档、批量导出等非实时功能。
• 聚焦核心事务：只验证用户登录、订单创建、主键自增、外键约束、唯一索引等最基础的数据操作。
• 剔除重复验证：如果某个存储过程已经覆盖了表结构验证，则不再单独为表结构设计用例。

4.2 可重复原则：环境无关、数据无关、顺序无关

可重复原则确保冒烟测试在任何环境（开发、测试、预发布）下都能产生一致的结果。这要求测试用例必须满足以下条件：

4.3 自动化优先原则：从手动验证到持续集成

冒烟测试必须优先实现自动化，并集成到 CI/CD 流水线中。手动执行冒烟测试不仅耗时，而且容易遗漏步骤或误判结果。自动化优先原则包含三个层次：

1. 脚本化：将 SQL 验证语句、API 调用、断言逻辑编写为可重复执行的脚本。
2. 参数化：支持通过环境变量或配置文件切换数据库连接、Schema 名称等参数。
3. 流水线化：将冒烟测试作为 CI/CD 流水线中的一个独立 Stage，迁移完成后自动触发。

# 示例：自动化冒烟测试脚本片段（伪代码）
def test_primary_key_auto_increment():
    # 1. 插入一条记录
    db.execute("INSERT INTO users (name, email) VALUES ('test_user', 'test@example.com')")
    # 2. 查询自增 ID
    result = db.query("SELECT id FROM users WHERE email = 'test@example.com'")
    # 3. 断言 ID 大于 0
    assert result[0]['id'] > 0, "自增主键未正确生成"
    # 4. 清理数据
    db.execute("DELETE FROM users WHERE email = 'test@example.com'")

4.4 覆盖率与风险平衡：不做全量，只做关键

冒烟测试不追求代码覆盖率或功能覆盖率，而是追求风险覆盖率。设计清单时，需要评估每个数据库变更点的风险等级，优先覆盖高风险区域。

在实际操作中，建议使用以下风险分类表来筛选冒烟用例：

4.5 四项原则的协同关系

这四项原则并非孤立存在，而是相互制约、共同作用。下图展示了它们之间的协同关系：