早在2010年，在淘宝、阿里巴巴B2B联合主办、专属社区支持的第二届互联网测试交流会上，来自网易、腾讯、淘宝、阿里巴巴等公司的测试经理分别分享了基于测试的经验根据我在现场的经验，原计划容纳 500 人的会场有 800 人出席。讲师交流环节，大家讨论了“研发团队中开发与测试的比例是多少最合适？”这个话题。 （编者注：为方便起见，本文对每位测试经理使用昵称，请勿识别！）

郭靖是一家大型网上商城测试团队的负责人。 2003年加入公司后，他组建了网站的测试团队，并推动团队进行性能测试、自动化测试、接口测试等。随着团队的壮大，他遇到的更麻烦的问题是多少比例合适？在研发团队中从开发到测试？据他了解，微软的开发和测试比例是10比1，微软是1比3，大家都做得很好。纠结了半天，他问自己，这个比例真的重要吗？事实上，在他看来，大家关注的是开发测试人员的技能、效率、成本和质量，而不是具体的比例。同时，他也质疑是否有合适的方法来明确某个研发团队最合适的开发测试比例。

来自另一家知名互联网公司、负责整个公司测试框架的测试经理杨康谈了他对这个问题的理解：

公司高层通常会给质量部门设定一些目标，并要求你的人员配置比例。但我的理解是，质量部门的工作成果很难定义和衡量。对于高层管理人员来说，给质量部门施加压力最有力的方式就是人员配置比例。至于接下来该怎么做，就得你自己想办法了。坦白讲，高层希望有一种手段能够让质量部门人员尽快完成工作。一开始我们整个研发团队也有过1:2或者1:3的比例，高层一直要求我们降低开发人员和测试人员的比例。但现在大家已经不再提这件事情了，因为高层认为我们做的事情是可以的，我们对产品的贡献也不错。现在他们更多地谈论如何更好地提高质量。

也来自一家大型互联网公司，也是测试团队的负责人。对于杨康提到的有关公司高层的问题，他也深有感触：

我进公司后，我的直接上司换了好几次。每次新老板上任时，他都会问这些问题。我需要再次告诉他我们是如何做测试的，开发测试比例是多少等等。工作了一两年后，他基本上就不再问了。但可惜的是，老板又变了，他第一件事就是又问了一遍这个问题。三年前我又说过类似的话。我想这个情况大家都知道。有时负责测试的高级人员可能不在测试领域。他们中的许多人可能有开发背景，但可能并不真正了解测试。所以我想是否可以找到一种更科学的方法，比如性能测试，可以大致看到它的瓶颈和容量规划的程度。

来自某新兴互联网公司的测试经理欧阳科从“存在即合理”的哲学角度分享了自己的观点：

开发测试比实际上反映了公司内部开发和测试架构的关系。有些公司的开发人员较多，测试人员较少。相应地，这个比率是最低的。有些公司更依赖QA，他们的开发和测试比例可能更高。因此，不同公司之间的差异肯定会比较大。这件事情可能没有一个合适的方式来统计清楚。我的观点是，存在就是合理的。

对研发团队比较了解的洪七公介绍了开发与测试比例10比1的背景，他也认为开发与测试比例并不是最重要的。最重要的是根据公司的情况确定合适的比例：

我非常同意郭靖的观点。其实高层管理人员普遍面临的一个问题就是人员比例，因为这个问题大家都懂，但是有的人可能根本不理解缺陷率等问题。而且人员配置比例和成本有很大关系，老板们都很关心这个问题。所以，在与高层沟通的时候，千万不要纠结这个问题。你必须告诉他们，人员比例不是最关键的问题。如果他坚持有一个标准来强迫你这么做，你就需要告诉他其他公司的人员配置比例背景。

比如开发与测试的比例是10比1，其实是有前提条件的：第一，测试部门不必进入所有项目：如果你的项目做得太差，程序写得太差，测试人员将根本无法做到。他们不肯进去；其次，测试人员拥有绝对的权力来控制自己的资源；第三，开发工程师自己要做大量的测试。没有这三个条件，怎么能进行10比1的谈判呢？这根本不可能。所以你必须告诉你的老板，开发测试比不是最重要的。我们要根据公司的具体情况来确定合适的比例。某个研发团队的开发和测试比例如何合适，这也与团队的开发和测试工程师的素质密切相关。一灯大师解释说，基于大家对测试的偏见以及对开发和测试的理解，应该实现压缩。开发与测试比的一个可行途径是提高测试工程师的素质：

10比1只是一个数量问题。其实背后还有一个质的问题，那就是人员素质问题。在很多传统的软件公司，很多测试人员的素质都不是很高。例如，普遍的观点是“如果不能做开发，就做测试”。必须扭转这样的局面。在我们公司，现在特别注重提高测试人员的技能和素质。同时，我们一直在提高招聘门槛，加强测试人员的培训，包括培训开发人员配合单元测试。因此，研发比例是10比1。这里不能忽视的一点是研发人员和测试人员的素质很高，尤其是研发工程师对单元测试和代码质量的要求非常高。而我们其他一些互联网行业的研发和测试人员可能没有这么高的素质。这种情况下，我们只能采取人海战术。

读者们，你们公司的开发与测试比率是多少？您对这个话题有何看法？欢迎讨论。如需浏览中文网站更多测试内容，请点击测试主题。

我也在交流会上，可惜只能观摩“华山论剑”，无法表达“自己的心声”。

我的观点是：软件开发总是需要测试工作。在一些团队中，开发人员将完成测试工作，因此不需要全职测试人员。

既然开发也可以轻松测试，为什么还需要专职测试人员呢？答案是“专业化”。软件开发的趋势是“多面手”：每个人都可以做所有的工作，但总有一些任务仍然需要专业人员来做。例如，安全测试没有长期的积累就无法取得成果。很多测试都需要长时间的积累才能在短时间内掌握并达到高质量的要求。

在竞争激烈的行业中，趋势是相似的。在一般复杂性领域，团队对员工的要求是通才：你可以编写代码、编写测试、维护构建，并在构建完成时自动运行你编写的测试（单元、集成、系统、验收测试）。在少数高复杂性领域，需要专家来处理特殊问题。因此，技术员工的发展方向是“通才专家”。

测试的独特价值在于它在真实环境中的实际使用，这可能会导致许多意想不到的情况。那么谁来执行呢？对于很多小团队来说，执行者成为开发者是最经济的。对于+这样大的系统，可能需要联合多个团队的测试人员来进行实际测试。设立测试岗位在经济上是划算的。因此，如果专门的测试人员不能提供相应的价值，他们的职位就会被淘汰或减少。互联网的高度竞争性要求整个团队对质量负责，从而减少对专门测试人员的需求。这其实是一件好事。大家一起开发产品，一起保证质量，这是最经济、最快（也是最和谐）的。在这样的环境中，测试人员需要发展成为专家并提供特殊的价值。

谁需要测试人员？

我也参加了这次交流会。在参与之前，我一直在问3个问题：“什么是测试？谁需要测试人员？测试人员的核心价值观是什么？”，我也尝试按照自己的理解来回答。以下是我的理解。如有错误或不同意见，请指正。

1. 什么是测试？测试是尝试使用指标的一种方法。谁需要使用测试？使用产品需要进行测试来判断产品的质量。

2. 谁需要测试人员？一个产品有两类用户，一类是产品的最终用户，另一类是产品的维护者（或开发者）；产品的最终用户和产品维护者需要判断产品的质量，需要找到一个“质量代理人”——即测试人员。

3、测试人员的核心价值观是什么？核心价值是保证用户的利益，最有价值的工作是协助用户制定合适的衡量标准。

看来你对测试的理解有点肤浅了。

研发人员需要测试，但是测试团队还是需要存在的。至于比例，则取决于公司产品的性质。如果产品测试侧重于功能，那么测试人员就会减少；如果产品测试侧重于分布式和集群，测试人员就会更多。企业的产品线越大，各个部门测试人员的比例可能不同，不能一概而论。

测试中完成的大部分工作是QC（尽管大多数IT公司称之为QA）。 QC的工作是针对产品本身，而不是针对过程改进。一个公司的测试人员应该兼顾双方，同时负责QC/QA工作是至关重要的。

对于软件行业来说，参与质量体系（QA）过程改进和正常运行的人员比例远远低于QC。

另外，很多公司的测试人员素质与开发人员相当。测试必须存在，因为开发人员永远无法达到测试人员的有效性。你可以说研发还可以做单元测试、功能测试、自动化测试、TDD。然而，研发永远无法进行测试。测试人员对产品缺陷的看法，因为人们通常很难看到自己流程中的错误和缺陷。即使是代码或者自动化工具，这些都是工具，并不能达到测试人员所扮演的角色。

没有人能保证写出的代码没有bug，即使是工程师也不能保证；没有人能够在完全满足研发工作的同时完全满足测试工程师的职责，因为世界上没有完美的人。因此，说研发替代测试是专业性的体现是有失偏颇的。

由各种属性决定

我是一名开发人员，我担心我所从事的项目中一些紧急变更的质量。一部分原因是时间紧张，单元测试和集成测试不多，对自己的代码不太有信心（确实很紧张，不是为自己写了少量的单元测试辩护）；另一部分原因是项目本身就很重要，很容易不会出现太多错误。但担忧终究是担忧。从外部来看，对于这样一个项目，即使是一次开发十次测试（或者开发与测试时间的比例）也无法保证高质量。原因是开发者自己的单元测试不完整，没有限制最容易发现bug的地方。让测试人员一层层厚厚地挖掘bug，不管难度、深度、时间等补救措施，都是无效的。

因此，在讨论开发测试比时，我们应该回顾一下不同阶段发现Bug的成本。代码经过充分的单元测试和少量的集成测试可以保证其可靠性。否则，我们就只能求神了。

在我看来，决定开发与测试比率的重要属性是：

1. 开发和测试人员经验

2、开发过程中是否有足够、完整的单元测试？

3.项目的重要性（平台系统或UI相关项目等）

4、开发代码有代码吗？

我们大部分的项目都是基于平台、算法、架构等，然后用户能看到的应用就是基于这些基础平台构建出来的。这些项目更加注重开发商的素质和专业水平。像这样的平台，有大量的用户交互，这就需要测试人员站在用户的角度去发现问题（传闻MS测试人员中有专业的白盒编码人员，这一点有待验证）。