不——没有“正确”的比例。答案取决于产品（是提供初级曲棍球成绩的网络服务，还是宇宙飞船？），以及程序员和测试人员在团队中扮演的角色。我见过非常成功的团队，程序员与测试人员的比例为 15 或 20 比 1，而制作垃圾软件的团队比例为 1 比 1。

在上面的高比率示例中，程序员编写了单元测试、功能测试，并与测试人员一起进行验收测试、集成测试以及许多级别的可靠性、性能和规模测试。

在我正在考虑的 1:1 示例中，程序员会在代码编译后立即将其提供给测试团队，并随着质量慢慢进入程序而处理大量的来回处理。

现在，当然，你可以用 1:1 的比例制作出色的软件，用 10:1 的比例制作糟糕的软件 - 重要的是你要弄清楚谁在追求质量做什么，并且每个人都知道他们的角色是什么在努力中。

我不相信有一个“正确”的比例。我会考虑需要更接近比例的因素：

• QA 人员使用此特定模块的经验，因为新手需要学习曲线
• 开发人员在编码和特定模块方面的经验（因为我不止一次必须向开发人员解释功能）
• 由于复杂功能需要更多时间，因此要添加的功能范围（希望它们尽早完成以适应更多时间进行测试）
• 生产时间（我是否需要在关键时刻从另一个部门或团队“借用”测试人员，或者压力很小？哈哈）
• 开发人员是否正在运行任何单元测试或进行任何同行评审？（请多多指教）
• 在此时间范围内还有哪些其他可交付成果？服务包发布等
• 如果该比率与应有的目标相差甚远，公司愿意承担多大的风险？（推迟日期？降低复杂性？引进更多部队？等）

没有“正确”的答案。

尽管我很想说大多数公司的主要影响因素是应用程序的目标质量，但这不是我的经验。

多年来我看到的最大的一个因素是，它定义了公司愿意花费的可用预算比率，而且许多公司更看重降低成本而不是质量。

我可以给你一些我过去项目中的真实数字以供参考。

对我来说，我在澳大利亚见过的最高比例可能是 1:3（所以每三个开发人员进行一次测试），1:5 或更高（更少的测试人员）更常见。正在开发的应用程序类型是大型的、企业级的，通常是内部基于 Web 的应用程序。

我认为当您使用商业软件时，随着测试配置数量的增加，比率需要上升。

例如，如果我正在测试一个仅限内部的应用程序，我通常只需要在一个浏览器上进行测试。对于一个公共的、互联网部署的站点，您需要测试很多很多。

如果您正在 iPhone 上测试软件，并且您需要针对包括 iPod touch 在内的所有设备，那么现在有 12 种硬件设备，具有 3 个 4 个主要操作系统版本。

考虑到这一点，我倾向于专注于从我拥有的可用员工人数中提供尽可能多的“物有所值”。

我见过的让天平向你倾斜的最大方法之一是有效的测试自动化套件。这是一个重要因素的原因是，它基本上可以将您的测试人员从手动回归中“解放出来”，以便在其他地方更有效。

如果您试图证明更多员工的合理性，我建议您使用指标来支持您需要更高比率的案例，然后捕获结果以供将来参考和证明给您的同行。

虽然 Dev-to-Test 比率因其简单性而成为一个吸引人的概念，但它不是确定测试人员规模的糟糕方法。

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

情况1

假设您有这个新要求：

您的产品以前从未在 Windows XP SP2 上进行过测试，现在必须支持该操作系统版本。

开发需要 1 天（Windows XP SP1 运行良好，他们不得不更改“系统要求”文档中的一些文本，但不要相信他们必须做任何其他事情）

你能预测测试需要多长时间吗？

• 对于某些公司，他们可能需要 1 天的临时测试。
• 对于其他公司，他们可能需要 6 个月的时间（可能他们在受监管的行业，错过一个 bug 的成本非常高）

案例二

假设公司想要更改他们的 About 框。

用漂亮的图形替换以前的纯文本对话框。

由于开发人员不是很好的图形艺术家，他们需要 3 天的时间来学习新的图形工具，需要 3 天的时间与市场部试错，使其看起来“恰到好处”，并需要 2 天的时间才能得到它集成到构建中。

你能预测测试可能需要多长时间吗？

• 在某些商店，初级 QAer 可能会花一个小时或更短的时间来检查它。
• 在其他商店，由于新的公司标志嵌入在图形中，并且必须与市场营销现在要求的新尺寸和颜色规格精确匹配，因此可能需要更长的时间。

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

还要考虑：

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

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

要确定合适的人员配备模型，您必须确定您的 QA/测试人员应该做什么以及不应该做什么。您必须确定他们将按照什么样的时间表运作。您必须确定他们需要具备的专业知识水平（技术和领域专业知识）。您必须确定他们将获得多少外部帮助。

简而言之，想想 QA/Test 的期望是什么，然后让它指导你的人员配置决策，而不是盲目地遵循一个比率。