1、需求评审参加需求评审会，理解需求文档，在编码前找出需求的bug，与客户以及研发在需求的理解上达成一致的观念。但是也可能存在以下的问题：1.没有需求文档？客户对需要的产品目标不明确，研发人员也不明确，这个时候，只能使用敏捷开发，把产品开发出来之后，先给用户使用，然后再根据用户提示的问题进行修改，这样的bug都比较难确定；2.需求总是不能固定？不固定需求就会引出问题，然后引出一系列的bug；3.需求已经定义，是否吻合客户实际应用？那么，这就需要我们在理解完需求之后，找用户进行确认，并通知项目的参与人员，进行一个有效的需求评审会议。是大家对需求都达到一致的认识。
3、用例设计与评审1.前期的模块支持数据量的调研和要求2.用例编写考虑面要广，包括:使用不同的测试方法，不同的测试数据类型，正常流与异常流等来覆盖所有的需求。3.如果缺少评审，自己抽时间找研发同事沟通用例的覆盖度，查漏补缺
6、发布前的功能回归1.首先保证所有fixed的bug验证通过，并且没有引起别的bug；2.在测试的过程中，最好自己编写checklist表，这样到最后一轮的时候，就不用再执行测试用例，只要执行一下checklist表就可以了。（checklist表记录的就是在测试中容易出bug而且比较重要的模块的简易测试用例）3.如果时间和技术允许的话，可以使用QTP进行自动化脚本，方便回归。4.细心细心再细心。只要一步步走下来，那么就可以把遗漏的bug数量减到最低。一句话，减少漏测的方法就是相关的文档全面化，标准化，统一化。
