就目前来说，很多的公司都不是很规范。一种情况：变更了软件需求，相应的测试用例，没有及时增加，测试人员测试时，完全凭个人的理解和经验，想到哪里就测到哪里，随便测试。在这种情况下，不同的人在不同的时间测试时，就会发现并提出不同的缺陷，这样混乱的测试就导致测试轮数较多，效率自然低下。另外一种情况就是测试人员设计测试用例的水平不高，测试用例质量较差，导致测试反复进行，也测试不出Bug。这就要求测试部门主管，加大测试用例评审的力度，力争以最少的测试用例，测试出较多的Bug。
8、部门员工进行模块交叉测试，避免漏测提高测试效率：
测试主管在安排测试的时候，也要注意“用人之长，避人之短”。测试启动阶段，要对这个系统集中培训，让测试部门的成员对整个系统达成一致意见，最好在第一轮测试时，尽可能发现较多缺陷，开发人员尽早修复。第二轮测试就可以进行模块交叉测试。一方面我们可以避免个人原因造成的漏测试，另外一方面也可以利用每个人不同的思维方式，很容易发现其它模块的缺陷，避免多次重复测试，提高测试人员的积极性。测试效率提高了，发现的问题多了，后面测试的轮次自然要减少。
9、加强项目成员的管理，定期报告发现缺陷的情况，增加督促力度：
加强项目成员的管理，同样能够减少版本的发布和测试的轮次。测试人员每天都编写测试日志，邮件抄送给项目部成员和公司领导报告每天测试情况，加强不同层次的领导对开发人员的督促力度。这就对应了第一条，如果公司领导不重视测试，也就无所谓。如果公司领导很重视测试结果，马上作出反应，给各个部门的经理施加压力，软件质量被重视了，自然测试版本减少。如果哪个开发人员开发的模块每天都有很多缺陷，开发人员自然很不光彩，毕竟大家都很要面子，开发人员也敢轻而易举，开发的模块功能不测试就直接扔给测试部。这也是一种有效的方法，当然也可以把缺陷的数量、严重程度作为开发人员的绩效考核标准，提高开发人员的“质量意识”，缺陷自然很少。我们公司就是这样做的，一般在2到3个版本时，就很难发现缺陷，测试人员也相互看看其它成员发现的缺陷，一旦有的测试人员发现了较多的Bug，发现缺陷很少的测试人员很急，比较有个比较吗?特别是测试半天都没发现Bug的测试人员，就经常给我讲自己测试过程中的苦衷，我也很理解他们，多给他们鼓励鼓励。
10、严格控制需求变更的流程，减少后期的需求变动：
在项目开发中，经常碰到这样的情况，客户代表中有产品部、科技部、业务部等等部门的人员，很难通过某个客户代表户讲清需求。客户代表，随着对开发系统的不断深入了解，有可能客户不断的提出新的需求，或者说是不断修改需求，所以对于需求的变更，我们一定要有一个严格的标准流程。通过开发方和客户的评审后，再编写相应需求文档，最后开始开发。很多时候，繁琐的需求变更流程和领导的多级审批签字，并且需求的变更请求，也有相关的记录，很多客户都怕承担需求变更带来风险。也让业务人员觉得变更比较麻烦，不得不放弃需求的变更。严格控制需求的变更流程，做到有效的需求变更，这也许是一种减少测试版本的方法。
文章来源于领测软件测试网 https://www.ltesting.net/
