如何划分异常测试用例
通常我们认为，异常测试就是通过设计并执行异常相关的测试用例，以检验系统对异常情况的处理是否满足需求。与之相关的概念有变异测试和缺陷注入，在这里不做过多的概念辨析，只讨论一个问题：工作中产生冲突的原因，可能是由于不同的人对于同一个概念有着截然不同的理解，比如「异常相关的测试用例」。
讨论分歧之前，先举个例子直观感受一下：
Case 1：电商下单场景，用户把商品加入购物车，然后下单成功。
这很明显是正常用例，用户想下单，下单成功了很 happy，就叫 happy path。
Case 2：还是电商下单，用户把商品加购物车准备下单，由于存在下单前的库存检查逻辑，导致用户下单失败了。
对于用户来说，想下单没成功，这就是 sad path。
因为下单前就是需要校验是否有库存，所以「库存检查逻辑」是正常的业务逻辑，这个用例是“为了验证库存不足无法下单而设计的”正常用例。
Case 3：用户想下单，库存也正常，结算时由于网络问题或高并发等原因，导致下单超时了。
这种并不在业务可接受的失败范围内，是异常场景。
测试用例的 happy path 和 sad path 可以按用户期望是否满足来区分：
- 期望满足就是正常场景，happy path
- 期望不满足，但在业务需求范围内，就是 sad path（一些不能让用户下单成功的场景，比如防薅羊毛）
- 期望不满足，不在业务认同的范围内，就是异常 exceptional path（业务没约束，因为其他各种原因的下单失败）
是否需要区分这么清晰？
想回答这个问题，需要考虑为什么会有争议。这个问题来源于社区的讨论：“公司要加强异常逻辑的分支覆盖，因此就希望加大异常用例的占比，但是大家对异常用例的定义存在分歧。”
从问题描述可看出，想加强异常覆盖是为了预防缺陷，不管各个角色如何看待某个场景，只要这些场景都被用例覆盖到了，预防缺陷的目的就达到了。观察「异常用例占比」这个指标是否合理，是很值得讨论的。如果盲目追求占比的提升，那么不同角色就会站在利于自己的角度去理解和定义异常，势必会产生分歧。在我看来，这并不是一个对错问题，而是一个视角问题。
- 产品视角：只要需求明确提出了就是正常场景，比如会导致下单失败的业务逻辑，提了就不算异常
- 测试视角：不管需求怎么提，业务没进行下去就是异常场景，下单失败就是异常了
- 研发视角：不管需求怎么提，测试怎么测，只要程序没触发异常处理，就不算异常
遇到这样的情况，不妨反问自己，我想要的是异常用例占比的提升吗？并不是，我真正想要的是减少和预防由于缺乏异常覆盖而引入的缺陷。只要能达到提升质量预防缺陷的目的，就不必过分在意不同的理解。
所以最终从价值出发，还是看我们到底为什么要区分，如果能导向更好的质量，我们就做。如果没有，并且徒增烦恼和分歧，那就算了。
正如那句话所说的：“我们已经走得太远，以致忘记了为什么出发。” 共勉。
