许多公司领导总是希望得到一个合理的比例，然后按这个比例分配招聘的名额，或者设法缩小测试队伍，减少开发成本。
多数情况下，测试人员工作量大，比开发人员忙，所以想寻求一个数据，来说服其公司，多招些测试人员。
有些专家说，根据调查结果发现通常的比例是1个测试人员对3个开发人员。实际上，这样的比例毫无意义。测试人员与开发人员的比例会受到很多因素的影响，因不同的业务、文化和产品而不同。如果不管公司的文化、产品的类型和责任定义等，一定要按照某个比例来分配测试人员与开发人员，这是武断的做法，缺乏科学性。有两个典型的例子能说明这个问题：
微软公司的测试人员与开发人员比例一般为1:1，甚至在Windows 2000开发团队中，有1800个测试人员，900个开发人员，测试人员与开发人员比例为2:1。
在Google (谷歌)公司，则测试人员与开发人员比例则很低，据谷歌公司的测试经理介绍，为1:10.
那为什么呢?这里主要是测试人员与开发人员工作范围的定义，在这两家公司差别挺大，在微软，单元测试由测试人员(Software Development Engineer in Test, SDET)做, 相当于SDET再写一套代码来测试开发人员写的产品代码，其工作量不比开发人员低，另外，微软开发的产品都是比较复杂的操作系统、服务器软件等，自然就需要很多的测试人员。而Google的单元测试和功能测试一般都是由开发人员自己来完成，测试人员主要提供自动化测试工具的支持。软件开发人员进行了足够的单元测试，单元测试的覆盖度高达85%以上，软件在交给测试人员时，在功能上基本没有缺陷，这样测试人员主要集中精力进行性能测试、负载测试、安全性测试等，而这些都是自动化工具来完成的，自然需要较少的测试人员。
另外，测试人员与开发人员还受所开发的产品类型、企业文化、项目环境、质量要求水平、开发人员或测试人员的自身素质等影响。例如：
所开发的产品是操作系统、基础平台，和一般的客户端软件、简单的Web应用系统，其测试需求、范围和工作量都是不同的。如Windows操作系统要支持第3方各种应用程序、支持大量的API和各种硬件驱动程序等，还有兼容DOS、32位/64位等应用程序，系统非常复杂、用户操作也非常灵活，所以测试的工作量也大得多，需要大量测试人员的付出。
软件设计、代码的质量，也就是企业文化、开发人员的素质和能力等直接影响了软件的阶段性成果的质量，如果软件构造质量很高，其回归测试范围有限、重复测试的次数只有1～2次，而不是4～5次，结果，测试的工作量大大降低，测试人员数量随之降低。
例如，许多免费的网络应用产品总是将自己定位在Beta版，那么，会降低质量水平，让用户试用，并帮助发现一些缺陷(因为免费，用户也不能抱怨什么)，这样的话，公司内部测试的努力会少多了。
测试人员素质高，精兵强将，那么人数就会少些;如果测试人员定位低、待遇低，就可能靠人海战术，那么人数就会多。
在敏捷方法中，开发人员的主导作用比较明显，测试人员对开发人员的比例会低些。如果采用测试驱动开发，测试人员对开发人员的比例会更低。这时，测试人员和开发人员的界限也变得模糊些。
当然，针对一个具体公司，流程、产品和文化等都定型了，可以根据自己的经验、历史数据等，定出一个合适的比例，如1:2、1:3等，都是可以的。如果一个软件公司，硬要参考微软、谷歌或其它某个公司的做法，也许就不合理。一定要找相似的公司，那家公司又做得很成功，那就可以直接参考。
也许将来某一天，测试人员和开发人员会合二为一，并没有明显的区分，只是每个人的任务会有所不同，大家都能胜任、完成某个任务中的测试和开发的工作。所以，作为测试人员，掌握良好的技术也是必要的，包括编程能力。
[新发现的文章 4/14/2010] google v. microsoft, and the dev:test ratio debate
Google 测试工程师职责:
Developing test strategies.
Automating tests using test works.
Write moderately complex code/s to test systems.
Take responsibility for monitoring product development and usage at all levels with an eye toward improving product quality.
May create test harnesses and infrastructure.
微软SDET的责任：
Hire developers to write code to test code. Our goal is to have engineers writing robust, reliable and repeatable tests that find issues early and cover the surface area of the component under test thoroughly.
SDETs are in the source code for the product as much as they are working with test source and our SDETs build the work used for testing.
Build programmatic tests that are self-verifying, that are easily extensible and that are not simply comparing “data in” to “expected out”.
A successful SDET derives pleasure from building lasting designs, implementing robust maintainable code, and being a partner in the design of the components while advancing the technologies and approaches for testing software
文章来源于领测软件测试网 https://www.ltesting.net/
