测试人员如何避免漏测

? ? ? ? 最近因为有同事漏测，领导很生气，于是组织大家对这个话题进行了讨论，我自己也思考了一下，从漏测的场景进行分析并提出解决方案。

一、需求文档写了，但是测试没有测到位

? ? ? ? 第一种需求文档写了，但是测试却没有测到，一般这种情况测试就很难甩锅了。为了避免这种情况，我的建议是写测试用例的时候测试人员自己要仔细梳理需求，建立一个测试范围功能清单，然后组织测试用例评审，首先确认测试范围是不是自己列的清单里的那些。然后在用例评审的过程中，如果存在一些需求待确认或者需求变更的地方的时候务必做好笔记，形成评审会议记录，并且将问题具体到人，然后发在工作交流群里，让大家都知道有哪些是需要注意的。

二、需求文档没有写，测试也没有测到位

????????第二种情况是需求文档没写，测试也没有测到位。这总情况还得再具体分析一下，比如说漏测的是一些用户体验的问题，那这种其实需求文档不写也很正常，需求文档更多的还是对功能和业务的描述，像一些用户体验上的、兼容性的、安全性的等等都是需要测试人员去考虑的，这种情况就需要测试提升自己的技能，提高测试用例的覆盖率了。

????????如果整个过程就是没有需求文档的，那还是可以参考第一种情况，列清单，确认范围，然后针对一些细节存在疑惑的地方及时找需求确认，确认之后要记得同步给开发。

? ? ? ? 如果是某些关联的业务但是需求文档没有写的话这个虽然说需求也有部分责任，但是测试人员在执行过程中也是有了解系统业务的要求的，所以也难逃干系，遇到这种情况最好是在测试前把整个业务流程梳理出来，能画出流程图是最好不过了；如果自己确实是不了解也不知道是否梳理正确，那么可以在需求评审的时候直接说自己对这个业务不了解，可以让需求详细介绍一下这个业务流程，如果会上不好意思说，也可以会下单独问，大家一定不要害怕在工作中承认自己的无知，最终的目标就是把事情做好，如果因为害怕没有了解清楚导致漏测，最后背锅的只会是自己。

三、需求发生变更，导致测试没有测到位

? ? ? ? 第三种，需求发生变更，导致测试没有测到位。这种情况最好就是在上线前再次确认一下上线的范围，有时候可能因为一些bug没有改完某个功能不上线，或者其他原因导致上线内容和一开始提出的需求不一致，因此上线前确认上线范围，确认后再针对性的进行回归测试，避免拆代码产生一些新的问题。

四、没有按照测试用例执行测试，导致漏测

? ? ? ? 测试用例写了，但是测试没有按照用例执行，这种必然是测试人员的责任。但是也可以具体情况具体分析，比如说当出现测试用例书写人和执行人不一致的时候，这种情况执行的人可能就没那么细心，认为流程通了就可以了；也可能是测试用例写的不是很清晰，但是执行的时候忽略了某些点，这种情况最好执行人要和写用例的人进行沟通，把问题落实到位，当然，自己在写用例的时候也要注意，一行就是一个测试点，避免一些含糊不清的词语或者句子出现在用例。

????????有时候可能是测试时间不够，测试人员挑了一些重要的先执行了，其实这种情况完全是可以理解，但是好巧不巧问题就出现在没执行的那块，那只能说太倒霉了。但是针对这种情况也不是什么都不能做，大家首先要知道测试用例是有优先级的，在时间紧急的情况完成优先级高的内容是完全没问题的，重要的是，没有完成的部分必须要让项目负责人知道，负责人同意不执行后在测试报告中说明情况，这样就算出现问题，测试人员已经做了预警，领导也不好算测试的完全责任。

五、测试用例覆盖不全，场景漏测

? ? ? ? 提高测试用例覆盖率是测试工作的重中之重，但是有时候确实是因为经验不足或者业务不了解导致一些场景没有考虑到，漏测。这种情况只能量力而行了，遇到问题就记录一个问题，慢慢的经验积累多了也就会了。另外就是进行测试用例评审，人多力量大，可能自己没考虑到的东西别人能考虑到，所以用例评审还是很有必要的。最后大家一定要多多提升自己，多看一些书，多了解一些测试的东西，多和前辈交流，通过多种途径去提升自己。如果一直在在自己的的岗位默守陈规，那就算工作五年，经验和能力也还是和一两年没啥区别的。

六、开发修改bug引发了新的问题没有测到位

? ? ? ? 最后一种情况就是开发修改了一个bug又引发了一个新的bug，这种情况如果开发能评估出自己修改的bug的影响范围是最好的，但现实一般是难以做到的，测试能做的就是在改完bug之后做好回归测试，回归的内容主要有以下几个：第一个是修改的功能的回归测试；第二个是本次上线所有需求的回归测试；第三个是整个系统的关键业务的回归测试（第二第三个上线前测一下就好了）

七、总结

? ? ? ? 综上所述，为了避免漏测，测试人员在执行测试的整个过程中应该做到以下几点：

总结：

1.测试前确认好测试范围，建立测试范围功能清单；

2.组织测试用例评审，并形成评审会议记录，并且将记录的内容同步给所以项目组成员；

3.上线前确认上线范围，并进行回归测试。

4.测试用例书写的时候注意一行就是一个测试点，避免含糊不清的描述，尤其是预期结果。

5.时间不充分的时候，给用例排优先级，重要的先执行，没有执行的用例要提前告知项目经理并在测试报告中注明。

6.多多学习，提升自己，用更多更高效的方法进行测试。