下载掌阅APP，畅读海量书库
立即打开
在确定测试规范前，首先要确定测试过程，例如要采用什么测试过程模型，是传统的W模型、TMap Next模型，还是采用敏捷测试模型。但由于测试只是整个软件开发生命周期的一部分，除非是单独的测试外包项目，有什么开发过程模型，就有相应的测试模型。我们不能在W模型里采用敏捷测试流程，也很难在敏捷开发模型中采用传统的测试过程模型。关于两种典型的测试过程模型，在前面的引子中已有介绍，后面还会在某个特定阶段进行更深的讨论。
为了确保后续的测试工作质量，需要制定软件测试规范。当然，对于一个软件组织来说，并不是等到每个测试项目到来时，才开始进行测试规范的制定。实际上，一个规范的软件组织，事先已有一套软件开发过程规范，这其中包括软件测试规范。但对于一个具体项目，可能要对组织层次上定义的测试规范进行剪裁，从而获得适合本项目的软件测试规范。不管是哪种情况，软件测试规范都是重要的，它伴随着整个测试过程，规范着测试活动的行为，能确保测试工作的质量，进而确保软件产品的质量。
软件测试规范 就是对软件测试的流程过程化，并对每一个过程元素进行明确的界定，形成完整的规范体系。规范一般形成在标准之后，与标准相比，规范显得更微观，往往是标准在某个领域的具体应用中逐步形成的，它更具领域特点、更易于操作。
软件测试规范可分为行业规范与操作规范，行业规范主要是指软件行业长期总结形成的通用规范，而操作规范则指某一公司在长期的软件测试工作中总结出的属于自己企业的规范，特别是专门提供测试服务的企业，这种操作规范的内容与实施情况往往是其取得软件开发商信任的法宝。
软件测试规范，可以参见国家标准GB-8566《信息技术软件生存期过程》和国际标准ISO/IEC TR 15504。
一个完整的软件测试规范应该包括规范本身的详细说明，比如规范目的、范围、文档结构、词汇表、参考信息、可追溯性、方针、过程/规范、指南、模板、检查表、培训、工具、参考资料等。这里主要讨论软件测试规范中实质性的内容，而不讨论一些附属性的内容（如规范目的、范围、文档结构、词汇表、参考信息、可追溯性等）。
在软件开发实践中，一般会从以下几个方面入手来规范测试过程，并在每个子过程中明确角色、职责、活动内容及所需文档。
● 角色的确定
● 进入准则
● 输入项
● 活动过程
● 输出项
● 验证与确认
● 退出准则
● 度量
任何项目的实施，首先要考虑的是人的因素，对人进行识别与确认，软件测试尤其不能例外。在软件测试中，通常会把所有涉及的人员进行分类以确立角色，并按角色进行职责划分，如表1-1所示。
表1-1 软件测试中最基本的角色定义
进入准则也就是对软件测试切入点的确立。根据软件测试的广义观点，软件测试伴随着整个软件开发生命周期中的活动，在软件过程的各个阶段都离不开验证和确认活动。因此，软件项目立项并得到批准就意味着软件测试的开始。对于各个阶段，也需要定义测试进入准则，见下面“4.活动过程”的描述。即使在敏捷测试中强调持续测试，但也有几个明显的节点，如产品发布计划、迭代（如Scrum中的Sprint）计划、迭代、验收测试等进入准则。
软件测试需要相关的文档作为测试设计及测试过程中判断是否符合要求的依据和标准，包括需求描述、系统设计、程序代码及软件配置计划等文档资料。这些文档都是测试的输入项，如表1-2所示。
表1-2 软件测试输入项
角色：测试设计人员，一般由测试组长、资深测试工程师担任。
活动描述：
● 制订测试计划——收集和组织测试计划信息，并且创建测试计划。
● 确定测试需求——根据需求规格说明书、质量计划等收集和整理测试需求信息，确定质量需求和测试目标。
● 制定测试策略——针对测试需求，定义测试阶段、测试类型、测试方法、测试风险回避措施及所需的测试工具等。
● 建立测试通过准则——根据项目实际情况，为每一个层次的测试或每一个测试阶段建立通过准则。
● 确定资源和进度——确定测试所需的软硬件资源、人力资源及测试进度。
● 评审测试计划——根据同行评审规范，对测试计划进行同行评审。
角色：测试设计人员（测试工程师）。
活动描述：设计测试的目的是确定如何有效地完成测试需求所确定的测试任务，为每一个测试需求确定要执行的测试任务、测试脚本或用例集，并且明确测试执行的过程。这里以“设计测试用例”为例说明，测试脚本和测试用例类似，只是用脚本（代码）方式来描述测试执行的过程，而在其他一些测试方式中进行更高层次的设计。
设计测试用例：
● 为每一个测试需求，确定其需要的测试用例。
● 为每一个测试用例，确定其输入及预期结果。
● 根据界面原型为每一个测试用例定义详细的测试步骤。
● 确定测试用例的测试环境配置、需要的驱动程序或桩程序。
● 为测试用例准备输入数据。
● 编写测试用例文档。
● 对测试用例进行同行评审。
角色：自动化测试工程师、测试工程师和程序员。
活动描述：实施测试的目的是创建可重用的测试脚本，并且实施测试驱动程序和桩程序。
● 根据测试过程，创建、开发测试脚本，并且调试测试脚本。
● 根据设计编写测试需要的测试驱动程序和桩程序。
角色：以程序员为主，测试工程师为辅。
活动描述：执行单元测试的目的是验证单元的内部结构及单元实现的功能，具体做法如下。
● 按照测试过程，手工执行单元测试或运行测试脚本自动执行测试。
● 详细记录单元测试结果，并将测试结果提交给相关人员（项目经理、开发组长、产品经理等）。
● 回归测试——对修改后的单元执行回归测试。
角色：程序员和测试工程师。
活动描述：执行集成测试的目的是验证单元之间的接口，以及集成工作的功能、性能等，现在采用的“持续集成”实践，单元测试和集成测试一般同时进行。
● 执行集成测试——按照测试过程，手工执行集成测试或运行测试自动化脚本执行集成测试。
● 详细记录集成测试的结果，并将测试结果提交给相关人员。
角色：（资深）测试工程师、测试实验室管理员。
活动描述：执行系统测试的目的是确认软件系统工作版本不仅满足功能性需求，还满足非功能性需求，如性能、安全性、兼容性等，具体做法如下。
● 执行系统测试——按照测试过程手工执行系统测试或运行测试脚本，自动执行系统测试。
● 详细记录系统测试结果，并对测试结果进行分析，提交测试结果和分析报告给相关人员。
● 回归测试——对修改后的软件系统版本执行回归测试。
角色：测试人员和相关人员。
活动描述：评估测试的目的是对每一次测试结果进行分析评估、提交测试分析报告，并根据评估结果，决定是否需要对测试计划进行修改、对下一次测试活动做出调整。
● 分析测试结果——由测试人员对每一次测试结果进行分析，并提出变更请求或其他处理意见。
● 评估阶段测试状态和产品质量状态，如对每一个阶段的测试覆盖率进行评估；对每一个阶段发现的缺陷进行统计分析；确定每一个测试阶段是否完成测试和提供测试分析报告并进行审查。
（1） 单元测试 是对软件基本组成单元进行的测试，其测试对象是软件设计的最小单位——模块或组件，也可以包括类或函数。软件单元具有独立性，可以将它与系统/程序的其他部分隔离出来，从而完成测试。单元测试也是软件测试过程中最早期的测试活动，是软件的基础测试。
（2） 集成测试 是将已分别通过测试的单元按设计要求组合起来再进行的测试，以检查这些单元之间的接口是否存在问题。集成测试一般是一个逐渐加入单元进行测试的持续过程，直至所有单元被组合在一起，成功地构成完整的软件系统，从而完成集成测试的使命。
（3） 系统测试 就是充分运行或模拟运行软件系统，以验证系统是否满足产品的质量需求。系统测试包含系统功能测试和系统非功能性测试，系统非功能性测试主要是指系统性能测试、容量测试、安全性测试、兼容性测试和可靠性测试等。系统功能测试和非功能性测试可以并行实施，但一般在基本功能已能正常运行后，才进行系统性能测试、兼容性测试、可靠性测试等。
（4） 验收测试 是在软件产品完成了系统测试之后、产品发布之前所进行的软件测试活动。它是技术测试的最后一个阶段，也称为交付测试。验收测试一般会根据产品规格说明书、或用户故事等各种需求定义，严格地、逐项检查产品，确保所开发的软件产品符合用户预期的各项要求，即验收测试是检验产品和产品规格说明书（包括软件开发的技术合同）的一致性，同时考虑用户的实际使用环境、数据和习惯等。验收测试的重要特征就是用户参与，或用户代表（如产品经理、Product Owner）参与。
（5） 回归测试 是由于软件修改或变更，对修改后的工作版本所有可能影响的范围进行测试。回归测试的目的是发现原来正常的功能特性出现新的问题——回归缺陷，从而确保原来正常的或符合要求的特性不受其他区域修改的影响。回归测试伴随着整个测试过程，在功能测试和系统测试、单元测试和集成测试中，一旦有变更或修正，都要进行相应的回归测试。
软件输出项较多，包括软件测试计划、测试用例，还包括测试缺陷记录、测试结果分析报告等，如表1-3所示。
表1-3 软件测试输出项
验证和确认是一个过程，在这过程中，依据需求定义和产品规范，确定软件活动和产品是否满足所给定的要求和条件，判断产品中所实现的功能、特性是否满足客户的实际需求，如表1-4所示。
表1-4 软件测试验证与确认项
退出准则满足组织/项目的测试结束的标准。
软件测试活动达到退出准则的要求时，对于当前版本的测试活动就结束了。软件质量量度工作，一般由SQA人员通过一系列活动收集数据，利用统计学知识对软件质量进行统计分析，得出较准确的软件质量可靠性评估报告，提供给客户及组织内部的管理层。