Testing 开发人员与测试人员的良好比例是多少？

人们认为[高级]开发人员与测试人员的比例是多少

显然，这在一定程度上取决于开发/维护的吞吐量，但是否有一个新公司/项目可以根据的经验法则

此外，您会使用“纯”测试人员，还是将测试与其他角色（例如文档、用户培训等）结合起来

---

显然，答案可能取决于所使用的公司战略/发展模式，因此请具体说明您的回答是一般性的，还是针对特定的产品/发布风格，等等。

最近有一篇相关文章，您可能会对此感兴趣。

在我看来，确定所需测试人员数量的一个好指标是需求的复杂性，而不是开发人员的数量。如果我雇用测试人员，我会查看需求列表（或者在必要时将设计文档分解为需求列表），并考虑每个需求需要多少测试时间来验证它是否正常工作。我会使用最初的分析来雇佣一批测试人员，如果工作量对我最初的基础来说太高，我会在以后添加测试人员

如果你准备了一个预算，并且以后再雇佣测试人员不是一个选择，那么你可能希望预算中的测试资源比你的分析显示的稍微多一些。太多总比不够好

是否使用“纯”测试人员是另一个真正取决于您需要多少测试资源的问题。我发现一个很好的折衷办法是雇佣能够从事其他工作的测试人员，并在测试负载较轻的时候在其他方面使用他们

编辑：如果您有幸在早期进行了一组验收测试，请将上面的“需求列表”替换为“验收测试”。：-）

我想说（取决于您需要测试的速度），通过自动化，您可以为每5个开发人员配备1到2名测试人员

原因：

• 有了自动化，他们只需要担心测试新模块
• 回归测试将处理较旧的测试
• 一个或两个测试人员可以轻松涵盖5个开发人员将要做的所有工作，例如每周
• 我学到的一个很好的比率是，每开发10个小时，质量保证团队将花费大约3或4个小时来跟踪这10个小时产生的大部分缺陷

希望它能有所帮助：）

每两名工程师配备一名测试人员，并涵盖人们因没有这些测试人员而使用的借口

另外，您会使用“纯”测试仪，还是 你会把测试和其他测试结合起来吗 角色（例如文档、用户 培训等）

这取决于测试的类型，但我不会让测试人员承担其他角色。称职的测试工程师与称职的软件工程师不相上下。如果你给他们的任务超出了他们的专业领域，你会让他们慢下来，然后把他们赶走。软件工程师喜欢做文档或用户培训吗？通常不会。测试人员也一样

然而，用来自其他领域的人来补充您的测试团队并没有什么错，特别是在可用性测试、验收测试、快速评审等方面。

我曾经在博客中提到过这一点。最相关的摘录如下

“我见过高质量的产品以10:1的开发：测试比率生产，可怕的产品以1:1的比率生产。区别在于对质量的关注和关心。如果每个人（包括管理层）团队成员非常关心产品质量，无论比例如何，都有很好的机会发生。但是，如果质量是应该在产品中测试的东西，那么无论如何，每个开发人员至少要有一名测试人员——如果你能得到他们，就要有更多的测试人员。”

没有广义的“好”比例

显然，测试某项功能所需的时间是与上下文相关的——它取决于一些因素，这些因素可能与开发该功能所需的时间几乎没有关系，或者根本没有关系

还应考虑：

• 什么算发展
• 什么算测试
• 如果我们无论如何都要执行回归测试，那么这算不算“零”额外测试小时

---

请参阅：

首先，开发人员对测试人员来说是一个好的经验法则，但它是一个坏的规则

你需要考虑的是你的应用程序有多少个用例。用户将以不受控制的方式与之交互的应用程序（即web应用程序或桌面应用程序）比类似的控制台应用程序需要更多的测试人员

采用单个文件并检测其中正则表达式模式的应用程序需要的测试人员比新操作系统少

虽然这些都是一般准则，但实际的建议是使用基于这些因素的某种近似公式

1） 有多少（划分的）用例？

我之所以说划分用例，是因为如果您包括状态更改和持久变量，那么程序中看似不相关的部分可能会变成相关的。 即2+2=4（1个用例）2*2=4（第2个用例）。这是两个简单的操作符，两类用例。但是，如果您可以

添加

然后

乘法

，那么您不能只单独检查

添加

和

乘法

，必须检查它们的所有可能排列

检查用例数量时，请确保包括涉及命令链接的用例

2） 每个测试需要多长时间？

这并不意味着（扩展计算器的比喻）只加2+2，然后看答案。您必须包括从崩溃中恢复所需的时间。如果答案不正确，您可能希望测试人员使用屏幕截图和特定说明记录错误