只要是软件，就不可能没有bug。但是并不是所有的bug都可以被找到，被修改的。那么，作为一名合格的测试人员，如果能有效的避免bug的漏测，尽可能的找出软件的bug呢？虽然说漏测在所难免，但是如果漏测率太高，领导又会说，那么要你们何用。其实吧，找bug就是找茬，看不顺眼的都可以说是bug，不好用的就更加是bug了。

需求评审

参加需求评审会，理解需求文档，在编码前找出需求的bug，与客户以及研发在需求的理解上达成一致的观念。但是也可能存在以下的问题：

1.没有需求文档？客户对需要的产品目标不明确，研发人员也不明确，这个时候，只能使用敏捷开发，把产品开发出来之后，先给用户使用，然后再根据用户提示的问题进行修改，这样的bug都比较难确定；

2.需求总是不能固定？不固定需求就会引出问题，然后引出一系列的bug；

3.需求已经定义，是否吻合客户实际应用？那么，这就需要我们在理解完需求之后，找用户进行确认，并通知项目的参与人员，进行一个有效的需求评审会议。是大家对需求都达到一致的认识。

梳理需求，尽早与开发人员、需求人员进行需求确认，统一不同角色对需求的认识

开发测试人员都可能存在对需求的认识不一致。越早进行，越能够避免出现因为对需求的认识不同而导致出现的问题（最可怕的是因此产生的隐性bug），这样也能减少后期很多不必要的资源浪费。

用例设计与评审

1.前期的模块支持数据量的调研和要求

2.用例编写考虑面要广，包括:使用不同的测试方法，不同的测试数据类型，正常流与异常流等来覆盖所有的需求。

3.如果缺少评审，自己抽时间找研发同事沟通用例的覆盖度，查漏补缺

测试执行

在固定的时间内，尽可能全面地执行测试用例。

1.在测试过程中不断的添加遗漏的用例，一定要在发现时及时补充，有些用例是无意间操作发现的；

2.详细标识每一个被执行过的用例。

bug回归

测试过程中，遇到过一个小小的参数变动可能引起一个比较远的功能点的大bug，开发不知道，测试不清晰，势必引发遗漏。在修改bug的这种情况下，有可能是牵一发而动全身的，是非常危险的。如果研发考虑的不周全，只修改了此bug，并没有考虑到与它接口的功能，那将会引发更多的bug。

发布前的功能回归

1.首先保证所有fixed的bug验证通过，并且没有引起别的bug；

2.在测试的过程中，最好自己编写checklist表，这样到最后一轮的时候，就不用再执行测试用例，只要执行一下checklist表就可以了。（checklist表记录的就是在测试中容易出bug而且比较重要的模块的简易测试用例）

3.如果时间和技术允许的话，可以使用QTP进行自动化脚本，方便回归。

4.细心细心再细心。只要一步步走下来，那么就可以把遗漏的bug数量减到最低。一句话，减少漏测的方法就是相关的文档全面化，标准化，统一化。