前两天出的线上故障：一批量审批功能，对当前页显示的所有记录可以一次性审批。同时，每页显示的记录数可以在页面上直接修改。当每页显示20条记录时，批量审批没问题；当每页显示80条时，批量审批仍只审批了20条；当每页显示80条并跳转到最后一页进行审批时，最后一页的所有记录（44条）均被审批。
这里不探讨故障原因是什么，主要说下为什么会出现漏测，怎样才不会漏测。
我一直在说我们做测试不能学土八路，拍脑袋做测试设计，经验主义害死人。需要有专业的测试理论来指导我们做设计，这是测试人员的专业技能，是有别于开发人员的主要技能。这里附带鄙视下部门的某些人某些观点，整天要求一线测试人员编码，说只有这样才能晋升，搞得业务测试没人做整天人心惶惶，我呸。
首先我们要识别出测试范围，也就是本次测试任务需要涵盖哪些测试点。很明显，本次测试人员没有识别出分页也是测试点之一，只测试了批量审批。那么如何才能识别出呢？我个人喜欢用路径法确认测试范围，路径法是什么网上有很多资料，在我之前的文章中也多次有过描述。简单讲，使用此方法并不关心上下文，只关心通过不同路径到达的一个个节点，这些节点就是功能点，就是测试点。本例中，既然是批量，那就需要多条记录，既然是多条记录，那就需要分页，一条路径两个节点。当然，此功能延伸的其它逻辑就不一一细表了。
确定了测试点之后如何设计测试场景呢？个人喜欢用场景法。本例中，批量审批可以分为零条审批、单条审批、多条审批、全部审批（当前页）等几个场景；分页可分为第一页、中间页、最后页、只有一页且页面记录未满（或已满）、有多页且最后一页只有一条记录（或多条及已满记录）、页面跳转等几个场景。还有很多场景就不一一列出了，列出个大概，知道意思就行。然后关注上下文，例如多条审批第一页、多条审批最后页、全部审批最后页且最后页有多条记录等等。注意，测试结果要留意记录条数及分页数量。
有人说这样设计会产生冗余，甚至有些是无效的测试用例。没错，的确会。所以个人喜欢用组合测试来筛选测试用例。组合测试是什么讲过很多次了，不清楚可以看部门博客。本例中，组合测试的因子可以设计为审批状态、分页状态、记录数量等，筛选条件也可以设置几条避免产生无效用例。
采用这几种方式做下来，不敢说测试100％无遗漏，至少大多数的场景都能覆盖到。另外，在开始的时候可能会觉得累赘、麻烦，但熟能生巧，多用几次后就会觉得简单甚至脑海里能自动推演。
大致就这么多。
PS：为缺陷预防会议准备的，写了几个小时竟然，一方面是最近状态不好，一方面是破事儿太多。能不能把我这主管身份拿掉TMD，烦都要烦死。