软件测试的轮次多少，大多数情况取决于项目大小、开发软件质量和测试效率有关。在项目确定的情况下，谈谈我们团队的做法，希望同行继续补充指正：

1.让研发团队的领导重视测试：

测试经理作为测试部门的老大，让公司领导重视测试，明白测试给项目带了的价值，那是义不容辞的责任。如何说服公司的领导，让公司的研发总监重视，这一点非常关键。只要这一点做好了，测试才会变得很轻松、愉快。如果公司的领导都不重视测试团队，只看重开发团队，即时测试部门发现了一大堆问题，公司领导也觉的很正常，不在乎，何谈降低测试轮次？如果公司研发领导很重视每轮的测试报告，自然开发部门不敢怠慢，代码的质量肯定要高得多，降低测试的轮次简直是轻而易举的事情。

2.测试团队和开发团队的独立性：

国内很多的研发团队都不是很重视测试团队，很多情况下都是开发部门的经理说了算，什么时候测试？什么时候结束？都是如此，这让测试团队的成员非常郁闷，很无赖，经常是抱怨居多。在这种情况下，多数时候，项目为了赶进度，项目经理和开发经理急了。为了尽快发现问题，只要开发了几个新功能和修复了几个 Bug，也安排大量测试人员立马验证，这样反反复复，版本平凡发布，测试效果极差，软件质量也得不到保证。如果测试部门和开发部门独立以后，发布版本测试都必须通过沟通来解决。你说开发部门的经理“说测试测试”的想法，说了还能算吗？呵呵！！我们公司很多时候，在测试版本不符合要求时，要送测试部门进行测试，都是开发部门的经理和项目经理给我们测试部门的老大说好话，拍马屁，老大高兴了，我们方才开始测试，否则一切按流程行事，他们也没有办法。保持部门的独立性和平等性，同样重要。

3.细化送测标准，建立完善的测试规范：

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

4.测试部门建立详尽的预测试标准：

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

5.保持测试和开发独立的测试环境：

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