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

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

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

完全理解需求

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

尽可能了解现有业务

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

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

考虑环境差异

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

提升用例质量

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

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

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

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