场景建模方法：状态机建模、决策表建模、流程树建模、组合爆炸问题

大家好，我是老张。今天咱们聊聊场景建模。

做测试这么多年，我最大的体会就是：没有好的建模，就没有好的覆盖。你想想看，一个复杂系统动辄几百个功能点，靠脑袋硬记，迟早翻车。我早期吃过这个亏——有一次测支付系统，漏了一个异常状态，结果线上出了资损。嗯，从那以后，我再也不敢跳过建模这一步。

场景建模说白了，就是把业务逻辑翻译成测试能看懂的结构。常用的有三种：状态机、决策表、流程树。咱们一个一个说。

1. 状态机建模：最适合有状态流转的系统

状态机建模，我个人习惯叫它「状态+事件」模型。核心就两个东西：状态和迁移。

举个例子，一个订单系统：

• 状态：待支付、已支付、已发货、已完成、已取消
• 事件：支付、发货、确认收货、取消

状态机模型长这样：

状态: 待支付
  事件: 支付 → 状态: 已支付
  事件: 取消 → 状态: 已取消

状态: 已支付
  事件: 发货 → 状态: 已发货
  事件: 取消 → 状态: 已取消

状态: 已发货
  事件: 确认收货 → 状态: 已完成

状态: 已完成
  事件: (无)

状态: 已取消
  事件: (无)

我在项目中遇到过一个问题：状态机画得太细，导致测试用例爆炸。比如「待支付」状态下，用户连续点击支付按钮10次，算不算有效事件？我的建议是：只关注业务上合法的状态迁移，非法事件统一归到「异常处理」里，不要每个都画一条线。

2. 决策表建模：最适合条件组合多的场景

决策表，说白了就是「条件+动作」的矩阵。什么时候用？当你发现一个功能点有多个条件，每个条件有多个取值，组合起来让人头皮发麻的时候——决策表就是你的救星。

举个例子，一个优惠券系统：

你看，4条规则就把所有组合覆盖了。我曾经见过一个团队，用决策表测一个保险核保系统，30个条件，硬是缩成了64条规则——比全组合的2^30少了不知道多少个数量级。

3. 流程树建模：最适合业务流程清晰的场景

流程树，其实就是把业务流程画成一棵树。根节点是起始状态，叶子节点是结束状态，中间节点是各种分支。

举个例子，一个注册流程：

开始注册
├── 手机号注册
│   ├── 验证码正确 → 注册成功
│   ├── 验证码错误 → 重新输入
│   └── 验证码超时 → 重新获取
├── 邮箱注册
│   ├── 验证链接有效 → 注册成功
│   └── 验证链接失效 → 重新发送
└── 第三方登录
    ├── 授权成功 → 注册成功
    └── 授权失败 → 返回登录页

流程树的优点是直观，适合给产品和开发看。但缺点是：分支多了以后，树会变得很胖。我建议每个节点的分支数控制在5个以内，超过的话就考虑拆成多个子流程。

4. 组合爆炸问题：建模最大的敌人

说到组合爆炸，我得先叹口气。这玩意儿，我早期做测试时被它坑过无数次。

什么叫组合爆炸？就是条件一多，测试用例数呈指数级增长。比如你有10个条件，每个条件2个取值，全组合就是2^10=1024个用例。如果每个条件3个取值，那就是3^10=59049个。你想想看，一个项目周期就两周，哪来的时间跑5万条用例？

怎么解决？我总结了三板斧：

1. 等价类划分：把无限取值变成有限类。比如「年龄」这个条件，你不需要测1岁、2岁、3岁...只需要测「未成年」「成年」「老年」三个类就够了。
2. 边界值分析：很多bug都出在边界上。比如「订单金额≥100」这个条件，你只需要测99、100、101这三个值，中间的不用管。
3. 正交实验法：用最少的用例覆盖最多的组合。比如3个条件，每个条件3个取值，全组合是27条，正交表只需要9条。我在项目中用过一次，效果出奇的好。

最后，我画了一张图，把今天讲的内容串起来：

好了，今天的内容就到这里。记住：建模不是为了画图，而是为了找到测试的边界。下次你遇到一个复杂系统，不妨先问问自己：这个场景适合用哪种模型？

可可精品资料库