如何有效避免漏测？

Posted 2021-08-30 wx5829dc12698e5

漏测，指在产品缺陷在测试过程中没有被发现（尤其是测试环境可以重现的缺陷），而是在版本发布后或者在用户使用后发现并反馈回来的缺陷。可以说，漏测的问题是测试管理者最头痛的问题。因为出现漏测，一来给客户带来了不好的影响和印象，二来增加缺陷修复的成本，三来给测试团队也带来负面和不利的影响。因此，作为测试管理者，测漏分析和预防是必须要做好。

　　

漏测的原因分析有以下的几个方面：

　　· 需求评审质量低，或参评人员能力不足，或过程不规范严谨 　　· 需求变更频繁，测试用例无及时更新 　　· 用例设计的过于粗犷，测试步骤不清晰 　　· 测试用例对需求的覆盖面不全，考虑不足 　　· 测试人员测试思维局限，无思考全面 　　· 测试人员执行过程不规范，人为漏测 　　· 测试执行人员质量意识不足，发现的缺陷定义严重性程度低或不认为是问题 　　· 测试环境与生产环境有较大出入 　　· 测试环境或测试数据受限，无法模拟并覆盖执行所有正常和异常的场景分支 　　· 功能回归策略问题 　　· 测试资源有限 　　· …… 　

　漏测预防或改进措施有以下几个方面：

　

　· 需求评审质量的提高

　　· 需求评审过程必须建立规范的评审流程 　　· 需求评审至少有需求、开发和测试人员参加 　　· 需求评审必须安排业务熟悉和测试经验丰富的测试人员参加 　　· 

测试用例的及时更新维护

　　· 每当发起了需求变更必须及时更新测试用例库和做好过程记录及用例评审 　　· 在测试过程中启发的测试用例必须及时更新或录入到测试用例库 　　· 漏测情况出现时，必须分析漏测原因和补充对应的测试用例 　　· 反馈的运维缺陷问题（软件部分）必须分析原因，并补充的测试用例库 　　

· 测试用例质量的提高（颗粒度、需求覆盖度、冗余度等）

　　· 测试用例的设计编写必须由有测试经验和业务基础的测试人员设计编写 　　· 着重正常流程测试用例，尤其常用和典型的用户场景和操作的分析 　　· 建立规范的测试用例评审制度（组长评审、同行评审或组、组之间的交叉评审或发起需求和开发进行评审） 　　· 建立通用测试用例库和测试用例框架，建立优质测试用例 　　· 提前并多方面准备充分的测试数据以覆盖到所有测试用例 　　· 

测试人员测试思维和测试意识的提高

　　· 组织部门内部的业务知识培训 　　· 组织部门内部的技术技能培训 　　· 组织部门内部的测试交流活动 　　

· 测试环境要尽量贴近生产环境

　　· 保证测试环境数据库与生产环境的版本和配置一致 　　· 保证测试环境服务中间件与生产环境的版本和配置一致 　　· 可以的话，保证测试环境主机配置与生产环境主机配置一致 　　· 可以的话，保证或模拟测试环境的网络环境与生产环境的一致 　　· 要注意环境的兼容性测试问题，如系统、版本、分辨率等 　　· 

测试执行过程的规范性、严谨性和策略性

　　· 测试过程严格按照测试用例执行 　　· 适时进行结对测试和交叉测试 　　· 适时加入探索性测试或随机测试 　　· 测试前，测试人员必须熟悉业务需求，亦要熟悉软件逻辑 　　· 测试过程中要不断补充遗漏的测试用例 　　· 测试过程尽量贴近用户实际环境去测 　　· 如有不影响实际使用的生产环境提供测试，最好在生产的环境和接口上进行测试  

测试策略的制定与及时调整

　　· 测试前根据风险定好测试策略，做好测试安排 　　· 测试过程时刻关注项目进度，随时做好测试调整的准备 　　· 如有充足的测试时间，最后一轮应该进行全面的回归测试 　　· 如有充足的测试时间，可以进行生产环境的beta测试 　　· 回归测试必须重点关注开发的修改范围，以免遗漏新引入的缺陷 　　·

 漏测的原因分析及分享和漏测财富库的建立

　　· 每当出现漏测现象，必须分析原因并组内通报，吸取教训 　　· 每当出现漏测，必须将漏测的缺陷及原因分析录入财富库 　

　PS：

　　1、当出现因为漏测反馈回来的问题时，测试管理者必须重视，并积极处理。立刻安排测试人员重现缺陷，并分析漏测原因。 　　2、漏测时缺陷一定要进行分析原因，思考总结和吸取经验教训，并在部门内部公开学习，以免其他成员同样情况再次发生，尽可能减低缺陷的漏测量。 　　3、往往实际项目过程中，测试时间一般不会太充分，测试是基于风险和策略去进行测试的。因此，如何在有限的资源（时间，人力等）内进行有效的，充分的测试是每一个测试管理者需要思考的问题。  

漏测是软件测试人员的大忌，也是无比大的锅悬在测试人员的头上，让人不行不紧张。

一旦软件上线出现问题，基本上都会认定是软件测试人员漏测了。但这种现象又是完全避免不了的，故漏测是软件测试人员最为关注的，特别是测试领导。

如何有效避免漏测？

这类问题测试负责人在面试过程没有遇到十回至少也遇到过九回了，可见这个问题在面试过程中出现的频率之高。

那在面试过程中遇到我们应该如何回答呢？

答：首先，漏测这种情况不能百分之百地杜绝，所以我们需要使用测试手段或者测试方法来尽量减少漏测现象的出现。

01

在测试之前：

首先，我们会对需求进行分析，然后再进行需求评审，评审时将产品经理、开发、测试集合在一起开一个评审会议，一起对本次迭代的需求进行讲解，通过评审会议之后测试人员一定要将需求吃透，只有需求完全理解到位，测试工作才能顺利进行。

理解清楚需求之后，测试人员通过各种用例设计方法编写测试用例，用例编写完全后测试小组可以先内部交叉评审后，再联合产品经理、开发人员进行评审会议，这此评审会议主要是检查测试用例是否对需求进行了完全覆盖，此次的评审会议非常重要，这也是避免漏测时最重要的一步。

执行测试之前，测试人员主要要做的就是对需求进行澄清、评审等各种手段来理解需求，掌握需求。

02

在测试之中：

首先，我们会根据事先已经准备好的测试用例（交叉测试）对软件进行测试，特别是对测试用例中优先级别高的用例着重进行测试。

注：测试过程中，测试人员不测试自己编写的测试用例，而测试其他测试人员的用例，达到再次检验。

同时在测试过程中，我们会根据测试情况一边测试一边修改测试用例，以保证测试用例对软件的高匹配。

首轮测试后期，我们会进行内部功能模块交叉测试。

最后我们会进行回归测试，回归测试时测试人员也是交叉回归bug，本轮测试除了回归bug还需要对上轮测试过程中出现bug频率高的功能模块着重测试。

03

在测试结束后：

测试人员召开总结会议，对出现的bug进行分析和总结。

在面试过程中，可以从这三个方面多维度来回答，并且在回答过程中，最好能结合实际的工作经验，比如有进行需求评审和未进行需求评审，最终的测试结果对比，这样就更有说服力。

如果面试官这时还说任务紧没有时间做这些，那又应该怎么办？

答：如果任务紧前期的需求分析和评审就更不能省略，如果产品和开发不能集合到一起进行评审，那也要进行测试内部评审。

需求是软件测试人员最重要的东西，如果需求理解不对，用例设计就不对，那最终的执行结果就会天差地别。

每个测试人员的思维都不一样，考虑的重点也有所差别，评审和头脑风暴是最快捷的解决办法。

如果任务紧，时间不充足，测试用例可以不用写得很详细，以前我们针对这种情况就是采用XMIND进行需求点编写，这样会省时和省力，编写完成后测试人员内部评审。

以上都是从技术的实现角度进行分析的，同时这类面试题不能避免面试官还想考察应聘者的抗压能力，任务紧加班现象基本无法避免。

昨天一个同事说得非常好：

跳出技术层面考虑，有时候面试官其实只是为了考察求职者在面试时的抗压能力，思考问题的逻辑条理是否清晰。

他要的不一定是技术能力上的实操性答案，而是求职者的工作上的软素质，看你的临场应变能力是不是能说服他，至于具体到工作上能不能解决问题，是另外一件事。

所以在回答面试题都需要逻辑条理比较强，测试负责人在面试过程中就喜欢列一二三点去回，这样说有个好处，可以留时间思考，同时给面试官的感觉是条理很清楚，有时就算说第一点时，第二点还没想好，等说完第一点时，第二点就自动到嘴边了。

不管是在面试中喜欢这样，在实际工作中测试负责人也喜欢这样分析问题和解决问题。

这也是经常所说的解决问题的思路，在这里举个简单的例子，如果连接服务器电脑连接不上，应该怎么解决？

也是通过一二三来解决的：

第一步：先检查自己的电脑的网络状况

第二步：检查自己电脑的IP和服务器IP是否在同一个网段下

第三步：ping服务器的IP，结果有二，ping得通或者ping不通，一般情况下只要ping得通，连接都没问题

第四步：ping不通，检查自己的电脑防火墙是否开启，如果开启的，关闭了再ping

第五步…………

这样依次逐步排出故障，这就是解决问题的思路。

上面提到的“如何有效避免漏测？”的解决办法在实际工作中也可以使用，这并不只是理论，这完全是来自于实践，只是在工作中会根据实际项目的情况而调整优先级或者增加新的解决方法。