早在2010年，淘宝网和阿里巴巴B2B联合主办、InfoQ独家社区支持的第二届互联网测试交流大会上，来自Google、Baidu、网易、腾讯、淘宝、阿里巴巴、FreeWheel等公司的测试经理分别分享了他们在测试领域的心得体会，原计划500人的会场到会了800人。在讲师交流环节，大家对“研发团队中最合适的开发测试比是多少”话题做了讨论。（编辑注：方便起见，本文对各测试经理均使用花名，请勿对号入座！）
郭靖是某大型网上商城测试团队的负责人，自2003年加入公司后就组建了该网站的测试团队，推动团队进行性能测试、自动化测试、接口测试等。随着团队的壮大，他遇到的比较头疼的问题是一个研发团队中开发测试比究竟多少比较合适？根据他的了解，Google的开发测试比是10比1，微软的比例是1比3，大家都做得很好。在长时间的纠结之后，他问自己，这个比例真的很重要吗？其实在他看来，大家关注的是开发测试人员的技能、效率、成本和质量等维度，而不是某个具体的比例。同时，他也疑问能否有一种合适的手段来说清楚某个研发团队最合适的开发测试比是多少。
来自另一家知名互联网公司的测试经理，也是负责整个公司测试框架的杨康谈到自己对这个问题的理解：
公司高层通常会给质量部定一些目标，要求你的人员配比是多少。但我的理解是，很难定义和衡量质量部的工作成果。对于高层来说，给质量部最有力的一个施压办法就是人员配比，至于下一步你怎么去做，你自己去想办法。坦白来说，高层是希望能有一个手段，让质量部的人员能尽可能快地完成工作。在开始的时候，我们整个研发团队也有过1比2或者1比3的时候，高层就不断地要求我们降低开发测试人员比。但是现在大家已经都不提这个事情了，因为高层认为我们现在做的还可以，对产品的贡献还不错，现在提的更多是如何更好地提高质量。
托雷同样来自一家大型互联网公司，也是测试团队的负责人，就杨康提到的和公司高层相关的问题，他同样深有感触：
在我加入公司后，我的直接老板换过几次。每次新的老板上任，都会问这些问题，我都需要重新给他讲一遍我们是如何做测试的，开发测试比是多少等等。做了一两年之后，他基本就不问了，但是不幸地是老板又换了，第一件事又是来问这个问题。然后自己就将3年前类似的话再说一遍。我想大家都了解这种情况，有时主管测试的高层也许是测试领域外的，可能很多是开发出身，不一定真得懂测试。所以我就想能否找到一种比较科学的方法，像性能测试一样，能大体看到它的瓶颈，看到它的容量规划到什么样的程度等。
来自新创互联网公司的测试经理欧阳克从“存在即合理”的哲学角度分享了自己的观点：
开发测试比其实反映的是公司内部开发和测试结构的关系，有的公司开发人员多一些，测试人员少一些，这个比例相应来说是最低的。而有的公司比较依赖于QA，可能开发测试比就高一些。所以不同的公司，差异肯定会比较大。可能没有一种合适的办法能数清楚这个事情。我的看法就是存在就是合理。
对Google研发团队比较有了解的洪七公介绍了Google开发测试比10比1的背景，同样认为开发测试比不是最重要的，最重要的是要根据公司的情况确定合适的比例：
我非常同意郭靖的观点，其实高层经常的问题就是人员配比，因为这个问题大家都理解，而像缺陷比率这些问题，有些人可能根本就不懂。而且人员配比和成本非常相关，老板都关心这个问题。所以说和高层沟通的时候，一定不能纠缠于这个问题，你要告诉他人员比例不是最关键的问题。如果他非要有个标准逼着你这样去做的话，你要给他讲其他公司的人员配比的背景。
比如Google的开发测试比是10比1，其实是有前提条件的：第一，测试部门并不是要进入所有的项目:，如果你的项目做得太糟，程序写得太烂，测试人员压根就不会进去；第二，测试人员有绝对的权力控制自己的资源；第三是开发工程师自己要做大量的测试。如果没有这三个条件，你怎么去谈10比1？根本是不可能的事情。所以你一定要告诉老板，开发测试比不是最重要的，我们要根据公司的具体情况确定合适的比例。究竟某个研发团队的开发测试比多少合适，这和团队的开发、测试工程师的素质也有密不可分的关系，一灯大师从大家对测试的偏见，结合Google对开发和测试的理解，解释说要压缩开发测试比，可行的办法是提高测试工程师的素质：
10比1只是一个量的问题，其实背后还有一个质的问题，即人员素质的问题。在很多传统软件公司中，很多测试人员的素质不是非常高，比如大家通常说的观点就是“你做不了开发就去做测试”。像这种情况必须要扭转。在我们公司，现在就特别重视提高测试人员的技能、素质，同时也一直在提高招聘门槛，加强对测试人员的培养，包括调教开发人员配合做单元测试等。所以说Google的研发比例是10比1，这里面不能忽视的一点是Google的研发人员和测试人员素质都很高，尤其是研发工程师对单元测试和代码质量要求非常高。而咱们其他的一些互联网行业的研发、测试人员可能就没有这么高的素质，这种情况下只能采取人海战术。
我也在交流会现场，可惜只能观摩“华山论剑”，没能发出“自己的声音”。
我的观点是：软件开发总是需要测试工作的，有些团队中开发者会完成测试工作，因此不需要专职的测试工作者。
既然开发也能顺手做测试，为什么还需要专职的测试人员呢？答案是“专业化”。软件开发的趋势是“通才”：所有人能够做所有工作，但是总有些工作还是要专业人士来做。例如安全测试，没有相当长时间的积累，没办法获得成果。许多测试是需要长时间积累才能精通，才能在短时间内达到高质量的要求。
在高竞争性行业，趋势都是类似的。在一般复杂性的领域，团队对员工的要求就是通才：你能够写代码、写测试、维护构建、当构建完毕之后自动运行你写的测试（单元、集成、系统、验收测试）。在少量的高复杂性领域，需要专家来处理特殊问题。因此技术员工的发展方向是“通才型专家”。
测试的独特价值在于在真实的环境中真实的使用，这会导致许多意想不到的情况。那到底是谁来执行呢？对于许多小团队而言，执行者就是开发者，这是最经济的。对于像Office+Sharepoint这么庞大的系统，可能需要联合若干个团队的测试人员来做真实环境的测试。设立测试职位，在经济上是划算的。所以，如果专职的测试人员不能提供相应价值，他们的职位就会被取消或压缩。互联网的高竞争性要求整个团队承担质量责任，因此降低了对专职的测试人员的需求。这实际是好事，大家一起开发产品、一起保障质量，这样最经济、最迅速（Google和Facebook的水平）。在这样的环境中，测试人员要向专家发展，提供特殊的价值。
谁需要测试人员？
我也参加了交流会。在参加之前，我一直在问3个问题：“测试是什么？谁需要测试人员？测试人员的核心价值是什么？”，我也尝试按照我的理解进行了回答。下面是我的理解，有不对或不同意见的地方欢迎指正。
1.测试是什么？测试是一种手段，是拿着度量标准去尝试。谁需要用测试这种手段？使用产品会需要通过测试评判产品的质量。
2.谁需要测试人员？一个产品有两类用户，一类是产品最终使用者，一类是产品维护者（或开发者）；产品的最终使用者和产品维护者需要评判产品质量，需要找“质量代理人”-即测试人员。
3.测试人员的核心价值是什么？核心价值在于保证用户的利益，最有价值的工作是协助用户制定适合的度量标准。
研发人员需要测试，但是测试团队还是需要存在，至于比例是多少，跟公司产品性质有关。产品测试偏重功能的，测试人员就少一些，产品偏重分布式、集群的，测试人员就多一些。企业产品线越大，可能每个部门的测试人员比例都不同，不能一概而论。
测试做的工作多是QC(虽然大多数IT公司都叫QA)，QC的工作针对产品本身的，而不是针对过程改进的。一个企业的测试人员应该双向关注，QC/QA的工作都承担的话，就必不可少。
针对软件行业，过程改进、质量体系的正常运行(QA)的人员比例远不如QC。
另外很多公司的测试人员素质，和开发人员是等同的。测试必须存在，因为开发人员永远达不到测试人员所起到的功效，你可以说研发也可以做单元测试、可以做功能测试自动化测试、可以做TDD，但是呢，研发做测试，永远不能起到一个测试人员对于产品缺陷上的看法，因为往往人很难看到自己的Bug，自己过程中的缺陷。即使Codereview也好，自动化工具也好，这些都是工具，远不能达到测试人员所起到的作用。
没有任何人能保证写的code没有Bug，即使Google工程师也一样；没有任何人能够在研发工作完全满足的同时，也能够完全满足测试工程师的责任，因为世界上没有完人。所以，说研发替代测试，就是专业化的表现，是有失偏颇的。
由各种属性决定吧
我是开发人员，在我做过的项目中，有些紧迫改动我很担心它的质量问题。一部分原因是时间紧，没有太多的单元和集成测试，对自己的代码不怎么放心（真的是很紧，不是为自己写少量单元测试辩护）；另一部分原因是项目本来就很重要，容不得太多误差。但担心归担心，站在局外看，这样的项目，就是一个开发配十个测试（或是开发与测试时间比例）都不能保证很高质量。咎其原因是因为开发人员自己的单元测试不完备，在最容易发现bug的地方不约束，而让测试人员去拨开层层厚夹去找bug，无论难度，深度，时间等都不是有效的弥补措施。
所以在讨论开发测试比的时候更应该回头去看看一个bug在不同阶段的发现成本。单元测试充分完备的代码，少量的集成测试都能保证它的可靠性。反之，只能问天了。
在我看来决定开发测试比的重要属性有这些：
1.开发和测试人员的经验
2.开发过程中是否有充分完备的单元测试
3.项目的重要性（平台系统还是UI相关的项目等）
4.对开发代码是否有codereview
Google的项目大部分是基于平台，算法，架构等，然后由这些基础平台构建起用户可以看到的应用。这些项目更强调开发人员的素质与专业性。而像Windows这样一个平台，极多的用户交互，更需要测试人员从用户的角度查找问题（传言MS在测试人员中有专业的白盒codereview人员，待验证）。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
