本节书摘来自异步社区《软件测试技术大全：测试基础 流行工具 项目实战(第3版)》一书中的第2章，第2.1节 测试的组织形式，作者陈能技 , 黄志国，更多章节内容可以访问云栖社区“异步社区”公众号查看。
第2章 软件测试的组织
软件测试技术大全：测试基础 流行工具 项目实战(第3版)
一个人的测试是不可能成功的，软件测试人员不是行走江湖的独行侠，测试是一项需要合作进行的工作。
本章从测试组织的形式分析各种测试组织结构的利弊，提出了一个综合型的软件测试组织结构模型。然后介绍对于一个新加入测试团队的测试人员而言，如何找准自己的角色定位，如何快速地融入测试组织。最后看一下测试团队的建设需要注意哪些方面的内容。
2.1 测试的组织形式
早期微软的开发团队中也没有独立的测试组。那个时候通常由几百个人做几个项目，程序员写完程序自己测试一下就算完成了。后来随着微软的项目越来越大，开发的软件也越来越复杂，编码和测试的工作需要并行地开展，于是就渐渐产生了独立的测试组。在微软的产品组中开发人员和测试人员的普遍比例是3:1。在研发团队中开发测试比多少合适是个仁者见仁智者见智的问题，微软是1:3，Google是10:1，百度是5:1。究竟开发测试比多少合适，不但与系统的复杂度、公司对产品的质量要求有关，还和团队的开发、测试工程师的素质有密不可分的关系。
2.1.1 微软的经验教训
在微软的起步初期，微软的许多软件都出现了很多的Bug。例如，在1981年与IBM PC绑定的BASIC软件，用户使用“1”除以10时就会出错，引起了大量用户的投诉。
微软公司的高层领导觉得有必要引入更好的测试和质量控制方法，但是遭到很多开发人员和项目经理的反对，因为他们认为开发人员自己能测试产品，无需加入太多的人力。
1984年，微软公司请到Arthur Anderson咨询公司对其在苹果机上的电子表格软件进行测试，但是外部的测试没有能力进行得很全面，结果漏测的一个Bug让微软为2万多个用户免费提供更新版本，损失达20万美元。
在这以后，微软得出了一个结论：不能依赖开发人员测试，也不能依赖外部的测试，必须自己建立一个独立的测试部门。
2.1.2 最简单的软件测试组织
最简单的软件测试组织形式就是没有任何组织的测试，几个人就把所有软件测试工作做完，这样做没有任何分工、没有任何层次结构。
简单的软件测试组织带来的问题是：软件测试依附在软件开发的组织下，不能真正发挥软件测试的威力。
一两个人的软件测试缺乏交流和思维的碰撞，导致测试人员的进步非常有限。缺乏测试的组织，导致测试无计划进行，测试人员疲于应付各项突如其来的测试任务，测试经验也得不到很好的总结。
2.1.3 组织形式的分类方式
软件测试的组织形式可以按测试人员参与的程度分为专职和兼职两类，如果按测试人员的从属关系则可分为项目型和职能型两大类。
（1）专职VS.兼职。
按照测试人员的职责明确程度，可以划分成兼职测试和专职测试两大类。目前在很多软件企业，尤其是小规模的软件企业，往往没有专职的测试人员。在做测试工作的同时还要兼顾软件开发、配置管理、技术文档编写、用户教育、系统部署实施等工作。
即使是在一些比较大规模的软件企业，拥有专门的质量部门，也会有兼职的情况，最常见的兼职工作是测试+配置管理，或者测试+QA。这种方式的好处是节省成本，可以充分利用资源。但是这样测试人员缺乏专门的独立的发展空间，不利于测试的纵深方向的发展，很难把测试做得精细，也不利于测试经验的积累和测试知识的传播。
当然，由于目前软件企业的现状，很多企业还是使用这种方式。对于测试人员来说，不要过分地去抱怨这些工作，尤其是对于新入行的测试人员来说，可以认为这是对自己很好的锻炼机会。
测试本身的要求就是知识面要广，而这些工作有助于从不同层面、不同角度、不同角色的位置考虑软件的相关问题。
（2）项目型VS.职能型。
按测试人员参与项目的形式来划分，可分成项目型和职能型。
项目型的测试组织是指测试人员作为项目组成员之一紧密地结合到项目中，与项目组其他人员紧密协作，一般是从头到尾跟着项目走。当然，也有些项目是到了中后期才考虑把测试人员加入到项目中。项目型的组织结构一般如图2.1所示。
这种类型的测试组织一般不会有测试组长，测试的管理由项目的主管或项目经理负责。当然，在一些大的项目中，会划分出开发组长、也会划分出测试组长，但是最终报告的对象都是项目经理。因此项目经理是负责测试资源调配和测试计划的主要人员。
而职能型的测试组织是指测试人员参与到项目中是以独立的测试部门委派的方式进入的。职能型的测试组织如图2.2所示。
在这种结构中，一个测试人员有可能不仅仅测试一个项目的产品，可能会同时测试多个项目的产品。测试人员也可能不是长期稳定地从头到尾参与同一个项目。
测试人员不向项目主管或项目经理报告工作，而是向自己所在的部门经理报告工作。并且这种结构的项目经理也可能是虚拟的，或者由多个部门经理共同担当。
这两种方式各有利弊。项目型的好处是测试人员参与的力度很强，能深入了解项目方方面面的信息，有利于稳定持续有效地测试出更多细节问题；但是同时也有弊端，就是测试人员受项目负责人的管理，在对待Bug的处理意见上往往受到约束，同时由于过于亲密，很可能出现“网开一面”，不能严格要求的情况。并且由于缺乏独立的组织，测试人员的知识可能局限在项目组内传播，不利于测试经验在不同项目组之间的传播。某些测试人员在这种组织中可能会感到孤独和无助。
而职能型的好处是能避免项目型的部分问题，并且能节省部分测试资源，充分利用各个项目阶段之间的时间差来合理利用测试资源；但是也不可避免地存在一些问题。例如，深入程度不够，尤其是对项目涉及的领域知识和业务知识理解可能不够深入，导致测试的问题比较表面。
2.1.4 综合型的测试组织
尽管独立的测试部门会有一些不可避免的问题，例如参与项目的深入程度，容易导致“扔过墙”的测试。但是很多软件企业还是倾向于建立一个相对独立的软件测试组织。
一个理想的软件测试组织可以是综合和兼容了几种结构方式的组织，这要视公司的软件测试资源配备和项目经理、测试部门经理的具体职责定义来设计，如图2.3所示。
例如，可以将项目型结构和职能型结构组合并加以改造。测试部门是独立的部门，测试部门经理根据各项目组中项目经理的请求，结合公司对项目的投入和重点方向，决定委派哪些测试人员加入到项目组，并且长期稳定、持续地跟进项目，在项目的各个阶段都参与并做测试的相关工作内容。测试人员作为一种服务资源供项目组调用，测试的结果和报告作为评估软件产品质量的必要参考信息，为项目经理做出产品发布的决定提供参考价值。
测试部门的测试人员分为常规项目测试人员和专项测试人员。常规项目测试人员即参与到项目组中的测试人员。专项测试人员一般由性能测试工程师、自动化功能测试工程师、界面及用户体验测试工程师、安全测试工程师等负责专门测试领域的人员构成，这些测试人员在项目发生专门的测试需求时，被调用到项目组，与常规项目测试人员一起工作，但是重点解决专项的测试问题。
当然还可以根据需要丰富这个组织结构，例如，设置一个专门的培训中心，负责对测试人员的内部培训，同时负责收集和整理各个项目的测试经验和测试知识。
