开发时间和测试时间之间没有固有的预设关系。并且在开发/测试人员比例和开发/测试时间比例之间没有内在的预设关系。

测试某些东西所需的时间是上下文相关的——它取决于可能与开发该功能所需的时间几乎没有关系的因素。

还要考虑：

• 什么算发展？
• 什么算作测试？
• 如果我们无论如何都要执行回归测试，那是否算作“零”额外的测试时间？

http://strazzere.blogspot.com/2010/04/what-is-correct-ratio-of-development.html

正如乔和林登所说，这取决于。

影响相对于开发时间需要多少测试时间的一些因素是：

• 开发是一个绿地项目还是这些变化可能会影响遗留功能？在后者的情况下，需要比前者更多的测试时间。
• 是否有与开发相关的监管要求？在我的工作场所，税务合规和 PCI 合规是大问题。这些的测试时间通常超过开发时间。
• 申请失败的成本是多少？作为一般规则，任何会产生重大故障成本的东西都需要进行更多测试。一个让浏览器崩溃的新网站不会像 Facebook 升级让浏览器崩溃那样有同样的失败成本。如果开发涉及飞行器软件或医疗软件，预计测试时间要求非常高。
• 有多少开发人员测试？我发现在敏捷的、测试驱动的环境中测试开发的负载要低得多，而且通常比更传统的环境更具探索性。
• 变化有多大？现在，由于开发环境升级，我花费大量时间进行测试，这还要求升级每个第三方组件以及应用程序中的大部分最旧代码（其中一些超过 20 年，并且由于高重构风险和所需时间）进行重构。这样做的时间成本可能不会超过开发时间——但这主要是因为没有时间彻底测试所有内容。理想情况下，测试时间会超过开发时间。

这些只是影响开发和测试时间平衡的几个因素，也是我讨厌公式方法的原因之一。

我似乎记得几年前关于这个的一篇很棒的博客文章。我只是希望我能记住它是谁或它在哪里。

通常，测试时间少于开发时间。很多人说 30-40% 的开发时间，但就我个人而言，每当我收到这么多时间时，我通常会觉得我没有做我应该做的那么多。实际时间总是会有所不同。有时它最终不仅仅是开发时间。这也将根据整个开发团队（包括测试人员）所采用的方法而有很大差异。如果你在做一个传统的项目，测试时间会更长。在敏捷团队中，我发现我的测试时间大大缩短了。

最后，答案是，这取决于。

10% 到 60% - 基于 Gilb 的书软件检查。书中说，通过正式的 QA，您可以将开发时间减少 30% 到 50%。这本书声称，如果您的 QA 流程投资回报率较低，那么测试/QA 会消耗超过 50% 的开发时间。这本书有很多数字，并引用了声称的来源。

上面的 10% 是经过多年收集数据并试图提高 QA 的投资回报率后的个人估计（对不起，我没有更好的了）。Gilb 建议每张 A4 纸大约 1 小时。

项目复杂性也有影响。Gilb 建议估计项目的复杂性。