下载掌阅APP，畅读海量书库
立即打开
在敏捷测试开发中没有测试团队，但还是有测试人员去完成相关的测试任务，特别是验收测试。所以，这节的标题就没有写成“测试团队的组建”，而是定为“项目测试团队”，既适合传统软件开发模式，也适合敏捷开发模式。在敏捷开发团队中，强调协作和沟通，所有人员同时进入一个项目，从一个迭代走向另一个迭代，没有测试过程，只有一个整体的开发过程，没必要单独讨论“测试人员问题”。但在传统开发模式中，虽然开发团队和测试团队同时介入一个项目，但在前期，对测试人员的需求会少些，测试团队负责人（暂且称测试组长，可能是测试经理）可以先于测试组其他人员进入项目，了解项目背景、审查项目有关文档并制订测试计划。这时并不需要很多的测试人员，此时项目组的测试人员还在其他项目的收尾工作上，虽然大部分开发人员已从那个项目抽出来了。开发人员和测试人员在项目上的投入存在一定的时间差。动态地平衡项目人力资源，能更充分地利用资源，提高生产力，创造更好的效益。
测试过程和开发过程都贯穿于软件过程的整个生命周期，它们是相辅相成、相互依赖的关系，概括起来有3个关键点。
（1）测试过程和开发过程是同时开始的，同时结束的，两者保持同步的关系。
（2）测试过程是对开发过程中阶段性成果和最终的产品进行验证的过程，所以两者相互依赖。前期，测试过程更多地依赖于开发过程；后期，开发过程更多地依赖于测试过程。
（3）测试工作的重点和开发工作的重点可能是不一样的，两者有各自的特点。不论是在资源管理，还是在风险管理上，两者都存在着差异。
改进的V模型和W模型（也可视为V模型的延伸），是对测试过程和开发过程同步关系的最好描述。V模型，在参考书《软件测试方法和技术》和《单元测试之道》〈请见附录H〉中已有描述，这里以W模型为例，说明两者的同步关系。
从图1-1可以看出，软件分析、设计和实现的过程，同时伴随着软件测试——验证和确认的过程，而且包括软件测试目标设定、测试计划和用例设计、测试环境建立等一系列测试活动的过程。也就是说，项目一启动，软件测试的工作也就启动了，避免了瀑布模型所带来的误区——软件测试是在代码完成之后进行的。对软件开发过程和测试过程两者之间的同步关系，做进一步阐述如下。
● 在做需求分析、产品功能设计的同时，测试人员就可以阅读、审查需求分析的结果，从而了解产品的设计特性、用户的真正需求，确定测试目标，可以准备用例（Use Case）并策划测试活动。
图1-1 测试过程和开发过程的同步关系
● 在做系统设计时，测试人员可以了解系统是如何实现的，基于什么样的运行平台，这样可以设计系统的测试方案和测试计划，并尽早准备系统的测试环境，包括硬件和第三方软件的采购。这些准备工作往往需要较长的时间来处理。
● 在做详细设计时，测试人员可以参与设计，并对设计进行评审，找出设计的缺陷，同时设计功能、新特性等各方面的测试用例，完善测试计划，并基于这些测试用例开发测试脚本。
● 在编程的同时进行单元测试是一种很有效的办法，此法可以尽快找出程序中的错误。充分的单元测试可以大幅度提高程序质量、减少成本。
测试过程和开发过程的依赖关系很明显，两者的同步关系从侧面也说明了这一点。再者，测试活动是建立在软件开发的成果之上的，即测试的对象就是软件开发的阶段性成果，如设计文档、程序代码和可执行的程序。而软件开发的进一步活动又依赖于测试的结果，如果测试结果反映开发成果正确、良好，开发活动就可以快速地进入下一个阶段，否则，开发活动则需要修正当前阶段所存在的缺陷，不能进入下一个阶段。
如果将软件产品研发周期分为两半，前一半称为前期，主要是设计、实现，相当于V模型的左边；后一半称为后期，主要是验证和缺陷修正阶段，相当于V模型的右边。
在前期，软件研发过程主要集中在设计、实现阶段，设计和实现的能力决定了整个软件研发过程的进展状态，自然，测试过程前期更多地依赖于开发过程。在后期，测试策略和能力会直接影响测试效率，测试效率高就能更快地发现缺陷，缺陷也能更快地得到修正，所以开发过程后期更多地依赖于测试过程。
开发过程的中心任务是构建软件，而测试过程的中心任务是发现构建过程中存在的问题。由于关键任务不同，思维方式、方法和策略都会不同，资源、风险等过程管理也不相同。在后面的章节，我们会不断触及这些主题，并进行深入讨论，这里着重讨论资源分配。
从图1-2可以看出，开发前期投入的资源较多，在编程时到达高峰，然后逐渐减少。而测试人员在后期投入的资源较多，前期投入的资源相对少。当然，如果自动化程度很高的话，等所有测试脚本都完成之后，测试执行的工作量会大大降低。所以，测试资源的分配依赖于测试自动化的程度。另外，测试资源的分配还依赖于软件构建（设计、编程等）的质量、应用系统的规模和复杂度等。
图1-2 测试过程和开发过程资源分配的差异
团队组建是动态的，可针对一个项目建立测试小组，这个测试小组因项目存在而存在，因项目结束而撤销。根据所评估的测试工作量以及产品开发的时间表，就能确定测试小组的人数。有时，也可以根据开发人员的人数来决定测试人员的比例，这取决于应用领域、产品类型、开发人员承担的责任、开发人员的素质和技术能力、开发流程等因素。例如从产品类型看，像操作系统一类产品，对测试要求最高，测试人员与开发人员的比例可高配为2:1～1:1。因为操作系统功能多、应用复杂、操作非常灵活，其用户的水平层次千差万别，但同时要求其具有很强的稳定性，支持各类硬件，提供各种应用接口，所以测试的工作量非常大。如微软公司参与Windows 2000的开发人员是900人，而测试人员达1800人。对于一般的应用系统一类的产品，由于用户对象清楚、范围小，甚至对应用平台或应用环境加了限制，测试工作量有限，测试人员与开发人员的比例可以配置为1:2～1:3。
也可以从应用领域看，如航空管制、铁路交通信号控制、银行核心业务等关键业务领域，对系统的正确性、可靠性、容错性等都有很高的要求，不能有丝毫差错，自然应加强测试，要有足够的测试人员。而对一些非关键系统，如社区应用系统，人们只是娱乐、消遣，对缺陷有一定的容忍度。如果是互联网应用，出现问题可以及时修复，这样也可降低质量要求，测试工作则集中在功能的基本操作上，测试人员可以很少，如1:5。如果开发人员做更多的事情，除了完成足够的单元测试，还做了基本的功能测试，那么测试人员则集中在端到端的测试、系统性能、安全性和可靠性等测试上，测试人员数量还可以降低，如1:8～1:10。总体来说，没有一个标准的比例，需要根据不同的开发环境或上下文条件，具体问题具体分析，来确定测试人员的数量。
而软件测试团队的任务是相对明确的，包括制订测试计划、设计测试用例、执行测试、评估测试结果和递交测试报告等。除了这些主要的任务，测试团队还要完成其他任务：阅读和审查软件功能说明书、设计文档，审查代码，与开发人员、项目经理等进行充分交流，参加各种业务、技术讨论会等。一个比较健全的测试团队包含的角色有以下6种。
（1）测试组长或测试经理：全面负责该项目的测试工作，如协调测试计划、统筹资源、组织测试件的评审、监控测试的执行等。测试组长的能力要相对全面，包括项目管理、测试流程控制、沟通、业务、技术等各个方面的能力。
（2）系统工程师：负责测试环境的部署和调试，甚至包括持续构建、持续集成的工作，以及产品发布的技术流程。
（3）自动化测试工程师，或者说，测试开发工程师（Software Development Engineer in Test，SDET）：负责所需的测试工具开发，以及自动化测试框架或整个应用测试平台的维护。
（4）测试分析和设计人员：一般由具有丰富经验的资深测试工程师承担，和测试组长一起，比较早进入项目，负责需求评审、设计评审、测试需求分析、测试用例设计或测试脚本开发等。
（5）性能测试、安全性测试人员：性能测试和安全性测试都需要性能或安全性方面的知识、技术和经验，一般由专职的测试人员完成。
（6）测试执行人员：如果项目规模大，测试团队人员需求量大，有一部分外包人员。另外，每个团队也不可能是清一色的资深测试人员，总是有一些刚加入公司的新手，这些初级测试人员则适合测试的执行。
对于规模小的测试团队，上面某些角色（如2）、3）、5）等）的资源可以和其他团队共享。测试组长是一个关键的角色，不只是管理，还会兼任测试分析和设计人员，参与或主导测试分析与设计的工作。虽然测试组长不是神人，但要承担的责任还是很多的（也可以授权其他资深测试人员承担部分责任），列举如下。
● 负责一个独立的测试项目及其测试组的管理工作。
● 制定整个项目的测试计划、测试策略，包括风险评估、日程表安排等。
● 负责工作量的预估和测试项目内部的资源、任务安排。
● 熟悉产品的功能、特性，审查产品需求规格说明书，并提出改进意见。
● 审查系统、程序设计说明书。
● 验证产品是否满足规格说明书所描述的需求。
● 对项目组成员进行培训和指导。
● 作为测试组代表，参与项目组的有关会议，如缺陷复审或清理会议。
● 根据需求设计文档和代码，负责和参与测试用例的设计和评审。
● 参与代码的审查、检查单元测试的状态。
● 选择测试工具或拟定测试脚本的结构，指导或参与脚本的开发。
● 确定和审查测试环境的配置，协助测试实验室管理员在本项目测试环境的工作。
● 实施软件测试，控制测试进度，并对所发现的缺陷进行跟踪分析和报告。
● 解决测试中的项目问题，或者将这些问题反馈给项目经理或测试经理，推动这些问题得到及时、合理的解决。
● 编写项目的整体测试报告，保证产品质量。
● 负责项目的总结，总结经验、吸取教训。
测试件（Test ware） 是用来描述测试工作产品的术语，包括测试计划文档、测试需求文档、测试用例、测试脚本、测试数据、测试log或结果、缺陷分析报告、测试报告等。
测试用例（Test case） 是为了特定的测试目的（如考察特定程序路径或验证某个产品特性）而设计的测试条件、测试数据及与之相关的测试规程的一个特定的使用实例或场景。测试用例也可以被称为有效地发现软件缺陷的最小测试执行单元。
测试脚本（Test script） 是测试工具执行的一组指令集合，使计算机能自动完成测试用例的执行，也是计算机程序的一种形式。脚本可以通过录制测试的操作产生，也可以直接用脚本语言编写脚本。测试工具脚本中包含的数据和指令，可以根据指令组合形式分为线性脚本、结构化脚本和共享脚本，也可以根据指令和数据的分离形式，分为数据驱动脚本和关键字驱动脚本。
项目测试组的内部培训不容忽视，特别是当项目组有新人或初级测试工程师时，培训的作用更大。除了整个项目组所做的有关产品、业务领域的培训外，测试组还根据需要就有关开发或测试流程、测试用例设计方法、测试自动化原理、测试脚本开发技术、环境设置等方面进行培训，如具体的培训内容如下。
● 标准的测试流程有哪些？本项目中有什么具体的或特定的测试流程？
● 自己在本项目的职责和任务是什么？
● 本项目的用户有何特殊需求，如何更好地理解测试目标？
● 怎样设计和编写测试用例，有哪些具体方法？哪些方法可以用于本项目？
● 如何检查测试环境的正确性？如何准备测试数据？
● 如何使用当前的测试工具？如何针对当前测试工具开发测试脚本？
● 如何在本项目中有效地实施探索式测试？
● 怎样报告软件缺陷，哪些信息是必须附上的？
● 工作报告内容和格式有什么要求，日报和周报有什么区别？
培训可以有正式的和非正式的两种形式，而且通常可以采用非正式的形式，如组内技术交流和讨论、让经验丰富或技术好的小组成员进行指导或举办讲座，以及建立一帮一的伙伴关系或者师傅带徒弟的关系。还可以邀请其他团队（如开发团队、软件工程过程组等）对测试人员进行有关技术、流程管理等方面的培训。通过培训，可以达到下面一些目标。
● 对业务流程、测试需求有一个全面、深刻、正确的认识。
● 了解大家所存在的问题或困惑，帮助大家解决问题，在测试目标、测试风险等许多方面达成一致的理解。
● 提高部分测试人员的测试设计和开发能力，保证测试用例、脚本的质量。
● 培训就是一个知识传递、知识共享的过程，保持信息同步。
讲究培训的有效性、及时性、正确性和完整性，可以加强培训考核。如果培训不和考核结合起来，不能达到应用的效果，那就很难了解培训的效果。
单靠软件测试是不能保证产品质量的，也就是说，产品的质量不是靠测出来的，而是靠产品开发的所有人员（需求分析人员、系统设计人员、程序员、测试人员等）共同努力来获得的。测试团队的基本责任如下。
● 发现软件程序、系统或产品中所有的问题。
● 尽早地发现问题。
● 督促和协助开发人员尽快地解决程序中的缺陷。
● 帮助项目管理人员制定合理的开发计划。
● 对缺陷进行跟踪、分析和分类总结，以便让项目的管理人员和相关的负责人能够及时、清楚地了解产品当前的质量状态。
● 帮助改善开发流程、提高产品开发效率。
● 促进程序编写的规范性、易读性、可维护性等。
质量始终是产品和企业的生命，质量第一，所以为了保证质量，不要受过紧的进度和预算所左右，在质量和进度冲突时如何确保产品发布的质量没有大幅度降低？这时可能需要质量保证人员和测试人员站出来，护卫质量，所以软件公司应赋予质量保证人员具有一定的权威性和与之相称的地位，如对产品发布有否决权。不少公司（包括微软公司），都将软件测试团队和质量保证（QA）团队合在一起，组成测试（或QA）部门。不管名称如何，但其责任已从测试团队的责任扩张到整个质量保证的领域。作为这样一个团队，拥有更多的责任，具有两个基本职能：软件测试和质量保证。
（1）在产品的整个生命周期，要与项目中相关的部门（市场、设计、开发、产品配置等）合作，负责跟踪和分析产品中的问题，并站在用户的角度，对产品进行全面测试，对不足之处提出质疑。
（2）更重要的是对产品的开发过程进行跟踪、审查，定义流程并推广流程，及时纠正在执行新的流程中所出现的问题，不断改进流程。
（3）分析竞争对手的产品，了解自己产品设计不足之处，提出改进的意见。
把软件测试和质量保证两项职能结合起来做，形成完整的链条，工作会更有效。软件测试为质量保证提供数据和质量评判的依据，质量保证可以指导软件测试的进行，质量保证和软件测试相辅相成，质量保证主要审查开发过程、流程，强调质量以预防为主；而测试主要审查产品，包括需求文档、设计文档等，以事后检查为主，旨在保证每个阶段的产品输出是正确的、符合产品质量要求的。
在不同的公司中，开发团队的模式可能会存在一些差别，甚至有比较大的区别，从而软件测试团队的地位也是不一样的。如果进行分类，可以概括为如下3类。
（1）以开发为核心，测试只是开发队伍的一部分，也就是开发团队中有测试人员，但没有形成独立的团队，见图1-3。
图1-3 以开发为核心的组织模型
（2）以项目经理为核心，开发小组和测试小组并存，隶属于项目经理领导，见图1-4。
图1-4 以项目经理为核心的组织模型
（3）项目经理、开发组长和测试组长“三足鼎立”，测试团队具有独立的、权威的地位，见图1-5。
图1-5 三足鼎立的组织模型