在总结线上问题的时候,我们发现大部分的线上问题是由于功能漏测所导致的。原本应该测试的流程没有测到,或者是根本没有考虑到一些情况,这些都会产生漏测。

在大部分的产品中,漏测是难以避免的,只要不出大问题,漏测的危害会被人为的粉饰和缩小,但是在某些跟货币或货币等价物打交道的行业,漏测往往意味着经济损失,一次漏测可能会影响一群人的职业生涯,万万马虎不得。

下面描述的方法可能对降低漏测有所帮助。

完全理解需求

站在业务和用户的角度去理解需求。尽量发现需求中不合理的地方或者是对用户来说讲不通的地方,给需求瘦身,让需求更加清晰简明。需求越明确,验证点也就越明确,用例设计起来难度也会降低。

尽可能了解现有业务

如果是新接受一个产品或项目,尽可能的了解现有系统的逻辑和业务也可以降低漏测风险。

现有系统中总是或多或少有一些坑,由于某些复杂或者不可描述的原因,这些坑不会有人告诉你。举一个我朋友的例子,他在做开发的时候因为偷懒,某些异常就直接捕获而不做相应的逻辑处理,在一些特殊条件下,这会造成数据丢失或者不一致的问题,但他认为这些问题发生的概率非常低,所以他谁也没告诉,天知地知你不知我知。像这种坑,一般来说要么测试同学自己试出来,要么跟开发关系好,让他善意的提醒某些异常场景。当然,前者可能更加靠谱一点点。

考虑环境差异

因为环境问题而翻车也是大概率事件。某些问题明明测试环境测出来是没问题的,但是在生产环境就各种问题,有经验的测试同学应该都遇到过。一般的解决思路是准备一个准生产环境,尽量跟线上环境保持一致,比如软硬件一致,数据量一致等,在准生产环境做最后一轮的回归。

提升用例质量

一些用例看起来测了很多东西,但是场景实际上覆盖是不完全的。怎么判断场景覆盖是否全面的,常规做法是用例评审,邀请相关责任人做评审,发现用例中考虑不全面的地方,然后改进。因为用例评审会占用项目时间,所以在项目紧急的时候往往会被砍掉,又或者评审一般流于形式,这样到后来各方参与者的热情不高,直接变成了流程性的东西,没办法提出一些有建设性的建议,所以评审在某些时候的效果是一般的。

去年曾经听到过用代码覆盖率去衡量用例质量的案例,今年在测试沙龙上也听到了类似的分享。既然场景都是由代码实现的,那么如果用例覆盖的场景够全的话,覆盖率相应就会更高。具体可以这样操作,对于增量代码,先把用例用手工和自动化的方式去运行用例,然后跑出代码覆盖率,如果增量代码中有代码没有覆盖到,那么就可能证明测试用例考虑的场景不全,需要改进。

代码覆盖率并不能证明代码质量的高低,但是可以让我们知道哪些代码没有被测试到。没有被测试到,就改进用例,试着去覆盖。

但是有些代码中的异常很难从黑盒端构造,对于这些情况,白盒用例可能更加适合。