前言
王豆豆一直想写一个有关面试中各类面试题解答系列。
刚好昨天测试群正好讨论到这个面试题：如何有效避免漏测？王豆豆觉得应该把此类面试题写一下，也好给以后面试过程中碰到此类题的面试者一个回答的方向。
首先，分析一下为什么面试官要提出这个面试题。
漏测是软件测试人员的大忌，也是无比大的锅悬在测试人员的头上，让人不行不紧张。
一旦软件上线出现问题，基本上都会认定是软件测试人员漏测了。但这种现象又是完全避免不了的，故漏测是软件测试人员最为关注的，特别是测试领导。
如何有效避免漏测？
这类问题王豆豆在面试过程没有遇到十回至少也遇到过九回了，可见这个问题在面试过程中出现的频率之高。
那在面试过程中遇到我们应该如何回答呢？
答：首先，漏测这种情况不能百分之百地杜绝，所以我们需要使用测试手段或者测试方法来尽量减少漏测现象的出现。
在测试之前：
首先，我们会对需求进行分析，然后再进行需求评审，评审时将产品经理、开发、测试集合在一起开一个评审会议，一起对本次迭代的需求进行讲解，通过评审会议之后测试人员一定要将需求吃透，只有需求完全理解到位，测试工作才能顺利进行。
理解清楚需求之后，测试人员通过各种用例设计方法编写测试用例，用例编写完全后测试小组可以先内部交叉评审后，再联合产品经理、开发人员进行评审会议，这此评审会议主要是检查测试用例是否对需求进行了完全覆盖，此次的评审会议非常重要，这也是避免漏测时最重要的一步。
执行测试之前，测试人员主要要做的就是对需求进行澄清、评审等各种手段来理解需求，掌握需求。
在测试之中：
首先，我们会根据事先已经准备好的测试用例（交叉测试）对软件进行测试，特别是对测试用例中优先级别高的用例着重进行测试。
注：测试过程中，测试人员不测试自己编写的测试用例，而测试其他测试人员的用例，达到再次检验。
同时在测试过程中，我们会根据测试情况一边测试一边修改测试用例，以保证测试用例对软件的高匹配。
首轮测试后期，我们会进行内部功能模块交叉测试。
最后我们会进行回归测试，回归测试时测试人员也是交叉回归bug，本轮测试除了回归bug还需要对上轮测试过程中出现bug频率高的功能模块着重测试。
在测试结束后：
测试人员召开总结会议，对出现的bug进行分析和总结。
在面试过程中，可以从这三个方面多维度来回答，并且在回答过程中，最好能结合实际的工作经验，比如有进行需求评审和未进行需求评审，最终的测试结果对比，这样就更有说服力。
如果面试官这时还说任务紧没有时间做这些，那又应该怎么办？
答：如果任务紧前期的需求分析和评审就更不能省略，如果产品和开发不能集合到一起进行评审，那也要进行测试内部评审。
需求是软件测试人员最重要的东西，如果需求理解不对，用例设计就不对，那最终的执行结果就会天差地别。
每个测试人员的思维都不一样，考虑的重点也有所差别，评审和头脑风暴是最快捷的解决办法。
如果任务紧，时间不充足，测试用例可以不用写得很详细，以前我们针对这种情况就是采用XMIND进行需求点编写，这样会省时和省力，编写完成后测试人员内部评审。
以上都是从技术的实现角度进行分析的，同时这类面试题不能避免面试官还想考察应聘者的抗压能力，任务紧加班现象基本无法避免。
一个同事说得非常好：
跳出技术层面考虑，有时候面试官其实只是为了考察求职者在面试时的抗压能力，思考问题的逻辑条理是否清晰。
他要的不一定是技术能力上的实操性答案，而是求职者的工作上的软素质，看你的临场应变能力是不是能说服他，至于具体到工作上能不能解决问题，是另外一件事。
所以在回答面试题都需要逻辑条理比较强，王豆豆在面试过程中就喜欢列一二三点去回，这样说有个好处，可以留时间思考，同时给面试官的感觉是条理很清楚，有时就算说第一点时，第二点还没想好，等说完第一点时，第二点就自动到嘴边了。
不管是在面试中喜欢这样，在实际工作中王豆豆也喜欢这样分析问题和解决问题。
这也是经常所说的解决问题的思路，在这里举个简单的例子，如果连接服务器电脑连接不上，应该怎么解决？
也是通过一二三来解决的：
第一步：先检查自己的电脑的网络状况
第二步：检查自己电脑的IP和服务器IP是否在同一个网段下
第三步：ping服务器的IP，结果有二，ping得通或者ping不通，一般情况下只要ping得通，连接都没问题
第四步：ping不通，检查自己的电脑防火墙是否开启，如果开启的，关闭了再ping
第五步…………
这样依次逐步排出故障，这就是解决问题的思路。
上面提到的“如何有效避免漏测？”的解决办法在实际工作中也可以使用，这并不只是理论，这完全是来自于实践，只是在工作中会根据实际项目的情况而调整优先级或者增加新的解决方法。
欢迎关注王豆豆的微信公众号：资深Tester(zishentester)，了解更多好文，和王豆豆一起成长。