1、需求评审参加需求评审会，理解需求文档，在编码前找出需求的bug，与客户以及研发在需求的理解上达成一致的观念。但是也可能存在以下的问题：1.没有需求文档？客户对需要的产品目标不明确，研发人员也不明确，这个时候，只能使用敏捷开发，把产品开发出来之后，先给用户使用，然后再根据用户提示的问题进行修改，这样的bug都比较难确定；2.需求总是不能固定？不固定需求就会引出问题，然后引出一系列的bug；3.需求已经定义，是否吻合客户实际应用？那么，这就需要我们在理解完需求之后，找用户进行确认，并通知项目的参与人员，进行一个有效的需求评审会议。是大家对需求都达到一致的认识。
2、梳理需求，尽早与开发人员、需求人员进行需求确认，统一不同角色对需求的认识开发测试人员都可能存在对需求的认识不一致。越早进行，越能够避免出现因为对需求的认识不同而导致出现的问题（最可怕的是因此产生的隐性bug），这样也能减少后期很多不必要的资源浪费。
3、用例设计与评审1.前期的模块支持数据量的调研和要求2.用例编写考虑面要广，包括:使用不同的测试方法，不同的测试数据类型，正常流与异常流等来覆盖所有的需求。3.如果缺少评审，自己抽时间找研发同事沟通用例的覆盖度，查漏补缺
4、测试执行在固定的时间内，尽可能全面地执行测试用例。1.在测试过程中不断的添加遗漏的用例，一定要在发现时及时补充，有些用例是无意间操作发现的；2.详细标识每一个被执行过的用例。
5、bug回归测试过程中，遇到过一个小小的参数变动可能引起一个比较远的功能点的大bug，开发不知道，测试不清晰，势必引发遗漏。在修改bug的这种情况下，有可能是牵一发而动全身的，是非常危险的。如果研发考虑的不周全，只修改了此bug，并没有考虑到与它接口的功能，那将会引发更多的bug。
6、发布前的功能回归1.首先保证所有fixed的bug验证通过，并且没有引起别的bug；2.在测试的过程中，最好自己编写checklist表，这样到最后一轮的时候，就不用再执行测试用例，只要执行一下checklist表就可以了。（checklist表记录的就是在测试中容易出bug而且比较重要的模块的简易测试用例）3.如果时间和技术允许的话，可以使用QTP进行自动化脚本，方便回归。4.细心细心再细心。只要一步步走下来，那么就可以把遗漏的bug数量减到最低。一句话，减少漏测的方法就是相关的文档全面化，标准化，统一化。
