怎么有效的降低测试轮次，看看这篇文章

软件测试的轮次的次数是多少，大多数情况下取决于项目大小、软件质量和测试效率这三者。下面就来谈谈小编公司的经验做法：

一、要让上面领导重视测试：
1、测试经理作为测试部门的老大，让公司领导重视软件产品测试，明白测试给项目带来的价值，那是义不容辞的责任。如何说服公司的领导，让公司的研发总监重视测试，这一点非常关键。只要这一点做好了，测试才会变得很轻松、愉快。如果公司的领导都不重视测试团队，只看重开发团队，即使测试部门发现了一大堆问题，公司领导也觉的很正常，不在乎，何谈降低测试轮次呢？如果公司研发领导很重视每轮的测试报告，自然开发部门也不敢怠慢，代码的质量肯定要高得多，那么这时降低测试的轮次简直就是轻而易举的事情。文章源自玩技e族-https://www.playezu.com/12979.html

 二、测试团队和开发团队之间的独立性： 
1、国内很多的研发团队都不是很重视测试团队，很多情况下都是开发部门的经理说了算，什么时候开始测试？什么时候项目结束？都是如此，这就让测试团队的成员非常郁闷，很无赖，经常是抱怨居多。在这种情况下，多数时候，项目为了赶进度，项目经理和开发经理急了，为了尽快发现问题，只要开发了几个新功能和修复了几个Bug，也就安排大量测试人员立马验证，这样反反复复，版本频繁发布，测试效果极差，软件质量也得不到保证。如果测试部门和开发部门独立以后，发布版本测试都必须要通过沟通来解决。你说开发部门的经理“说测试就测试”的想法，说了还能算吗？很多公司在很多时候，在测试版本不符合要求时，就要送测试部门进行测试了，都是开发部门的经理和项目经理给测试部门的经理说好话，测试经理允许了，测试人员方才开始测试，否则一切按流程行事，他们也没有办法。保持部门的独立性和平等性，也同样重要。文章源自玩技e族-https://www.playezu.com/12979.html

 三、细化送测标准，建立完善的测试规范： 
1）测试经理在编写测试计划的时候，就应该考虑如下的问题：开发部门开发完成到什么时候我们可以开始接受测试？如果这点测试经理不明白，后面重复测试频繁发布版本，不是什么新鲜事。目前，很多公司的做法是：测试经理编写详细的测试规范，在规范中明确规定了软件版本的送测标准（如：某个独立模块的功能点完成了多少百分比，才能够开始测试等等，都要写成一个标准）。测试规范制定完毕后，开会评审让项目经理、开发经理和测试经理达成一个一致的建议，后面测试的时候就按测试规范中的标准执行就可以了。严格把握软件的送测标准，也是能够有效的减少测试的次数。文章源自玩技e族-https://www.playezu.com/12979.html

四、测试部门建立详尽的预测试标准：
1）如果被测试软件符合送测标准以后，开发部门才能够请求测试部门进行测试。测试部门接受到开发部门的配置表以后，在服务器上取下测试的版本，编译、部署后，安排部分项目核心人员，对部分主要的功能进行预测试，如果预测试通过了，就可以开始测试。如果预测试不通过，就打回开发部门修改好后再预测试，直到预测试通过为止。同时，我们也要制定严格的软件测试结束标准，来把好质量关，避免一味的追求减少测试轮数，而忽视质量，结果自然可想而知。建立详尽的预测试标准，这样也能够减少测试的轮数。文章源自玩技e族-https://www.playezu.com/12979.html

 五、保持测试和开发独立的测试环境： 文章源自玩技e族-https://www.playezu.com/12979.html

1）大部分的项目硬件都非常昂贵，现在很多的公司为了节省成本，开发和测试环境都在同一台机器上。开发人员就在测试机器上开发，这样混乱的测试环境，导致很多测试出来的Bug有可能不能够重现，开发人员对不成功重现的Bug就要求列为无效的Bug，弄得测试递交Bug人员都胆战心惊的。测试人员为了重现Bug不得不另取以前的版本，重新编译后，再测试，这样做无意识又增加了测试的轮次。后来测试环境和开发环境分开了，虽然在同一台机器上，数据库都分开了，测试数据再也不会被开发人员修改了，在测试出现的问题，一般在开发那边都能够出现。后来为了保护测试组里成员的利益，也去掉了绩效考核中“对无效的Bug”的考核项，大家终于可以放心的提缺陷了。文章源自玩技e族-https://www.playezu.com/12979.html

 六、要重视单元测试，提高被测软件质量： 
1）很多时候，测试部门和开发部门单元测试比较马虎或应付了事，测试的时间短，留下了很多缺陷。到了后面每轮系统测试的时候，才被发现很多问题，加之项目进度的压力，给公司也带来了较大的经济成本负担。加大单元测试的力度，力争尽早发现并修复缺陷，同样也是减少测试轮次的一种好方法。文章源自玩技e族-https://www.playezu.com/12979.html

七、重视测试用例的评审，提高测试用例的质量：
1）就目前来说，很多的公司都不是很规范。一种情况：变更了软件需求，相应的测试用例，没有及时增加，测试人员测试时，完全凭个人的理解和经验，想到哪里就测到哪里，随便测试。在这种情况下，不同的人在不同的时间测试时，就会发现并提出不同的缺陷，这样混乱的测试就导致测试轮数较多，效率自然低下。另外一种情况就是测试人员设计测试用例的水平不高，测试用例质量较差，导致测试反复进行，也测试不出Bug。这就要求测试部门主管，加大测试用例评审的力度，力争以最少的测试用例，测试出较多的Bug。文章源自玩技e族-https://www.playezu.com/12979.html

 八、部门员工进行模块交叉测试，避免漏测提高测试效率：
1）测试主管在安排测试的时候，也要注意“用人之长，避人之短”。测试启动阶段，要对这个系统集中培训，让测试部门的成员对整个系统达成一致意见，最好在第一轮测试时，尽可能发现较多缺陷，开发人员尽早修复。第二轮测试就可以进行模块交叉测试。一方面我们可以避免个人原因造成的漏测试，另外一方面也可以利用每个人不同的思维方式，很容易发现其它模块的缺陷，避免多次重复测试，提高测试人员的积极性。测试效率提高了，发现的问题多了，后面测试的轮次自然要减少。文章源自玩技e族-https://www.playezu.com/12979.html

九、严格控制需求变更的流程，减少后期的需求变动：
1）在项目开发中，经常碰到这样的情况，客户代表中有产品部、科技部、业务部等部门的人员，很难通过某个客户代表来讲清需求。客户代表，随着对开发系统的不断深入了解，有可能客户不断的提出新的需求，或者说是不断修改需求，所以对于需求的变更，我们一定要有一个严格的标准流程。通过开发方和客户的评审后，再编写相应需求文档，最后开始开发。很多时候，繁琐的需求变更流程和领导的多级审批签字，并且需求的变更请求，也有相关的记录，很多客户都怕承担需求变更带来风险，也让业务人员觉得变更比较麻烦，不得不放弃需求的变更。严格控制需求的变更流程，做到有效的需求变更，这也许是一种减少测试版本的方法。文章源自玩技e族-https://www.playezu.com/12979.html