什么是合理的开发测试比

什么是合理的开发测试比

不同公司，对质量风险的承受度是不一样的，同样是做职能手机，apple和那些"手机中的战斗机"公司显然对质量风险的承受度是不一样的，这不需要解释。其次即使是同一家公司，对不同产品的要求也可能不同，这很可能受到产品的用户群，产品对公司的重要性等因素影响。当然同一家公司在不同阶段对同一个产品，质量要求也可能是不同的，初期阶段，为了抢占市场，抢占先机，质量要求不要，随后产业做大了，质量要求会逐步上升。

2、决定开发测试比的第二因素取决于开发工程师的重要素质：测试意识

不要以为提高开发测试比应该首先提升测试工程师的效率和能力，恰恰相反，首先应该提升的是开发工程师的测试意识和能力。我接触过的众多开发工程师当中，这种规律无一例外：能力越强的开发工程师，测试意识越强。

那些把第一次问题发现由开发工程来负责，测试工程师负责系统性回归测试的团队，总体效率是最高的。

3、决定开发测试比的第三因素是发布流程

经典的风险控制案例是迪斯尼公司发布的一款DVD动画片无法播放而被迫召回给公司造成巨大损失。这个发布流程决定了具有重大风险，并且问题遗漏的代价很高。如果我们能够控制分步发布的话，先让一小部分地区试用，然后再逐步扩大到其他区域，即使出现问题代价不会那么高。分步发布其实是线上测试的一种，让真实用户帮我们测试，得到反馈和确认后再进一步发布，如此反复迭代。在迭代中不断增强信心。

其实当今互联网很多产品都已经做到了分布式，那么如果在release的时候也能够考虑到分布式发布的话，其实风险可以极大地得到控制。把测试放到线上去，事实证明，效果非常好。有人也管这种过程叫做灰度发布。

4、决定开发测试比的最后一个因素是测试效率

提升自动化率，引入持续集成，等等。可做的事情很多，听起来也很炫，但是。。。我看到过的项目，能够单纯依靠提升测试效率而达到减少开发测试比的，寥寥无几。这种效率的提升，我更倾向于，可以提升工程师的成就感，减轻工作压力。

最后，如何合理估计项目的开发测试比呢?我认为：

1)首先看项目的性质，那些单点的，遇到问题影响范围是100%的核心业务，应该给予最低的开发测试比，甚至可以是1:1

2)那些可以有主备模式的甚至是集群模式的，遇到问题影响范围可控的，上线步骤是递进的，比例可以高一点

3)那些测试工程师只负责回归测试和性能测试的，比例可以非常高。但能做到的企业很少。我依然认为这是开发测试最好的合作模式。

请不要迷信5:1还是10:1，也不要鄙视2:1，3:1。更不要瞎扯我们不需要QA。引用总书记的一句话：空谈误国，实干兴邦!