需要明确区分异常测试用例吗?

走得太远,忘了初衷

如何划分异常测试用例

通常我们认为,异常测试就是通过设计并执行异常相关的测试用例,以检验系统对异常情况的处理是否满足需求。与之相关的概念有变异测试和缺陷注入,在这里不做过多的概念辨析,只讨论一个问题:工作中产生冲突的原因,可能是由于不同的人对于同一个概念有着截然不同的理解,比如「异常相关的测试用例」。

讨论分歧之前,先举个例子直观感受一下:

Case 1:电商下单场景,用户把商品加入购物车,然后下单成功。
这很明显是正常用例,用户想下单,下单成功了很 happy,就叫 happy path。

Case 2:还是电商下单,用户把商品加购物车准备下单,由于存在下单前的库存检查逻辑,导致用户下单失败了。
对于用户来说,想下单没成功,这就是 sad path。
因为下单前就是需要校验是否有库存,所以「库存检查逻辑」是正常的业务逻辑,这个用例是“为了验证库存不足无法下单而设计的”正常用例。

Case 3:用户想下单,库存也正常,结算时由于网络问题或高并发等原因,导致下单超时了。
这种并不在业务可接受的失败范围内,是异常场景。

测试用例的 happy path 和 sad path 可以按用户期望是否满足来区分:

  • 期望满足就是正常场景,happy path
  • 期望不满足,但在业务需求范围内,就是 sad path(一些不能让用户下单成功的场景,比如防薅羊毛)
  • 期望不满足,不在业务认同的范围内,就是异常 exceptional path(业务没约束,因为其他各种原因的下单失败)
不同场景的划分示例
不同场景的划分示例

是否需要区分这么清晰?

想回答这个问题,需要考虑为什么会有争议。这个问题来源于社区的讨论:“公司要加强异常逻辑的分支覆盖,因此就希望加大异常用例的占比,但是大家对异常用例的定义存在分歧。”

从问题描述可看出,想加强异常覆盖是为了预防缺陷,不管各个角色如何看待某个场景,只要这些场景都被用例覆盖到了,预防缺陷的目的就达到了。观察「异常用例占比」这个指标是否合理,是很值得讨论的。如果盲目追求占比的提升,那么不同角色就会站在利于自己的角度去理解和定义异常,势必会产生分歧。在我看来,这并不是一个对错问题,而是一个视角问题。

  • 产品视角:只要需求明确提出了就是正常场景,比如会导致下单失败的业务逻辑,提了就不算异常
  • 测试视角:不管需求怎么提,业务没进行下去就是异常场景,下单失败就是异常了
  • 研发视角:不管需求怎么提,测试怎么测,只要程序没触发异常处理,就不算异常

遇到这样的情况,不妨反问自己,我想要的是异常用例占比的提升吗?并不是,我真正想要的是减少和预防由于缺乏异常覆盖而引入的缺陷。只要能达到提升质量预防缺陷的目的,就不必过分在意不同的理解。

所以最终从价值出发,还是看我们到底为什么要区分,如果能导向更好的质量,我们就做。如果没有,并且徒增烦恼和分歧,那就算了。

正如那句话所说的:“我们已经走得太远,以致忘记了为什么出发。” 共勉。

All rights reserved
Except where otherwise noted, content on this page is copyrighted.