3. 测试用例设计原则：等价类、边界值、因果图等，如何用于冒烟测试

讲真，很多人觉得冒烟测试就是随便跑跑主流程。 我就见过不少团队，上来就把几百个用例全塞进冒烟集里。 结果呢？跑一次要好几个小时，开发看到失败报告都懒得翻。 这哪是冒烟，这分明是烤全羊。

冒烟测试的核心是快和准。 快，是指几分钟内必须跑完。 准，是能一把抓住最致命的缺陷。 怎么做到？你想想看，等价类、边界值这些经典方法，其实就是为了解决「怎么用最少用例覆盖最多风险」的问题。

3.1 等价类划分：在冒烟中如何「少测」还「不漏」

等价类划分说白了就是分堆儿。 你把所有可能的输入分成几堆，每堆挑一个来测。 如果这个代表通过了，整堆都认为没问题。

但在冒烟测试里，你不能按常规来。 我以前做大促页面的冒烟测试时，登录模块分了有效账号、无效账号、空账号三堆。 正常全量测试要测6-8个用例。 但在冒烟集里，我只保留了「有效账号登录成功」和「无效账号登录被拒」这两个。

冒烟版本的等价类选择原则：

• 有效等价类：只选最典型、最正常的那个代表
• 无效等价类：只选一个最常见的错误场景（比如密码错误）
• 边界等价类：如果有边界特征，单独拎出来

3.2 边界值分析：冒烟测试的「照妖镜」

为什么边界值在冒烟里特别有用？ 因为我见过太多系统，主流程跑得溜，一到边界就崩。 你想想看，登录表单的密码长度限制是6-20位。 正常用户谁会输5位或21位？ 但攻击者会、程序异常会、数据迁移时也会。

边界值分析在冒烟中的应用，我总结了一个「最小边界集」：

边界值在冒烟中的实际用法：

1. 先找出所有输入域的边界
2. 对每个边界，提取上点（边界本身）、离点（紧挨着边界+1或-1）
3. 在冒烟集中，每个边界只保留一个正向+一个负向

3.3 因果图法：给冒烟测试装上「逻辑大脑」

因果图法比较复杂，但在冒烟里我用的是简化版。 说白了，就是找出「什么条件组合会导致什么结果」。 然后只保留那些「一旦出错影响面最大」的组合。

举个例子：一个订单取消功能。 条件有：订单状态（待支付/已支付/已发货）、用户身份（普通/VIP）、取消时间（30分钟内/30分钟后）。 结果有：取消成功、退款成功、取消被拒。

全量因果图可能有12种组合。 但在冒烟测试里，我只会测这3条：

【冒烟因果路径】
条件: 待支付 + 普通用户 + 30分钟内 → 结果: 取消成功（无退款）
条件: 已支付 + VIP用户 + 30分钟内 → 结果: 取消成功 + 全额退款
条件: 已发货 + 任何用户 + 任何时间 → 结果: 取消被拒

为什么这么选？

• 路径1是最基本的取消能力，任何版本不能丢
• 路径2涉及资金处理，出问题就是P0事故
• 路径3验证了约束边界，防止用户误操作导致发货后还能取消

3.4 三种方法的组合实践

在实际工作中，这三种方法是搭配使用的。 我给你画个我常用的冒烟用例生成流程：

【我个人的冒烟用例生成标准流程】

1. 用 因果图 画出核心功能的条件-结果依赖
   → 找出所有「必须成立」的关键路径

2. 对每个关键路径的输入域，用 等价类 拆分
   → 只保留一个正向代表 + 一个最常见异常代表

3. 对每个输入域的数值/长度/范围，用 边界值 补充
   → 有边界的，额外加1个上点+1个离点

4. 最终汇聚为冒烟测试集（8-15个用例）

5. 评审：如果某个用例去掉后系统仍然能通过冒烟
   → 删除它。冒烟用例不在多，而在精。

你可能会问：因果图不是还要画判定表吗？ 没错，但在冒烟测试里，判定表可以简化。 我通常只保留结论为「生效」和「不生效」的两个极端行。 中间那些过渡状态，比如部分退款、部分取消，放在详细测试里测。