测试过程管理介绍的内容包括：测试演化、测试设计、测试执行、测试监控。
测试演化
软件测试应该是软件研发全生命周期的测试，包括软件需求测试、软件设计测试、单元测试、集成测试、接口测试、系统测试、用户验收测试和非功能测试等。软件非功能测试一般会有性能测试、容量测试、易用性测试、安全测试等。
迭代开发对应迭代测试
软件开发方式一般分为了多次迭代开发，每次迭代都对应相关的测试，直至整个软件功能齐备然后进行系统测试，如下图所示。
瀑布模型测试
瀑布模型在1970年由 Winston W. Royce 最早提出，提供了软件开发的基本框架。瀑布模型软件开发的生命周期分为用户需求阶段、软件需求阶段、软件分析阶段、软件设计阶段、编码阶段、测试阶段和运行维护阶段，如下图所示。软件开发工作依次进行，给人感觉很有条理性。从测试的角度而言，对于软件需求明确且比较固定的软件项目开发也许比较适合，但对于软件需求不明确或软件需求多变的项目就存在重大的缺点。一是软件需求变化后不能及时响应，二是测试阶段在软件产品发布之前进行，测试中发现的问题和缺陷修复起来将会有巨大的成本。
为了尽量降低瀑布模型缺点的影响，结合 TMMI 思想，在瀑布模型研发生命周期的各个阶段可以加入不同的测试（评审）。例如用户需求和软件需求中都可以进行需求合理性、完整性、逻辑性等方面的测试。在需求分析阶段可以对需求分析的产出进行分析的覆盖完整性，分析的合理性等方面的测试。在软件设计阶段可以对软件设计产物进行设计文档测试，检查设计文档对软件功能和各项指标的要求是否合理和可行。在编码阶段对编码进行代码评审并进行相关的单元测试和接口测试。
V模型测试
由于瀑布模型存在的明显缺陷，根据瀑布模型演变出了 V 模型的软件开发方式。在 V 模型中开发任务由对等的测试任务与其相对，如下图所示。
V 模型中软件测试分成了不同的级别和相关的软件开发阶段相对应。例如组件说明对应组件测试，系统技术设计对应集成测试，软件需求对应系统测试，用户需求对应验收测试。
用户需求是从客户或用户获得的需求，并对需求进行详细的描述，在获得客户或用户的批准和认可后，作为软件开发工作需要实现的特性和功能的输入。软件需求是用户需求在软件的系统功能和架构上的映射，说明的软件需要实现的功能特性以及相关系统指标。系统技术设计是软件系统的具体实现方式，它包括定义系统环境的接口、系统分解成更小更容易实现的子系统，从而每个子系统都可以独立开发。组件说明是提供一个独立功能的软件单元，它定义了该单元的任务、行为、内部结构和与其它组件协同工作的接口。编码是使用具体的编程语言，例如 Java、C/C++、PHP 等，实现已经定义的软件组件，例如模块、单元、类等。
接下来，对 V 模型中的各部分做解释说明。
（1）组件测试
组件测试是针对一个软件单元的测试，组件可以是软件测试的最小单元。组件测试有时也称为模块测试、单元测试或类测试等。组件测试是为了检查相关组件是否满足组件说明或详细设计说明的要求，保证每个最小的单元满足功能和相关指标要求并能够正常运行。组件测试可以由开发人员执行，也可以由测试人员进行。组件测试首先确定最小的测试单元，然后设计相关的测试用例检查功能的正确性、健壮性（对错误输入的适当反应）以及组件的性能。
（2）集成测试
集成测试主要检查系统与系统之间的接口交互是否满足系统设计的要求。集成测试可以发现接口缺陷和系统之间协同工作的缺陷，例如操作系统、文件系统、硬件接口等。
（3）系统测试
系统测试是形成完整的系统后，对整个系统进行测试，检查系统是否满足了软件需求。系统测试中应重点检查软件需求中定义的功能是否实现并能按照需求要求正确运行，功能的输入和输出是否合乎要求，以及非功能的质量特性是否满足软件需求要求。
（4）验收测试
验收测试一般由客户或用户进行，它的目的是检查整个软件系统是否满足由客户需求预先定义验收条件。通常根据客户需求或业务流程进行正式测试，确保软件系统满足客户的要求。
敏捷项目测试
使用敏捷开发管理方式的开发过程一般分为多次冲刺，每次冲刺拥有自己的用户故事，相对应的软件测试既包括新增故事的用户故事测试，也包括已有故事的故事覆盖。因此敏捷项目的开发测试应尽量采用自动化测试来提高开发效率。
常见的敏捷项目测试方法有以下几种。
（1）测试驱动开发
TDD 的全称为 Test Driver Development，测试驱动开发就是开发要以测试为驱动。编码之前，测试先行。
TDD 带来的好处有以下几点。
你会更加站在用户的角度去看你将要完成的产品，你要尽可能想到用户所有进行的操作。而不是从程序员的角度想用户应该会如何去使用我们的产品。
测试用例是对功能进行测试。在写代码之前先写测试用例，可以对我们编写代码提供指导性的参考。防止我们漏掉一些功能。它使我们对自己代码有了信心，因为我们事先设计好的所有测试用例都 Pass 了，如下图所示。
如果在更改代码后测试用例不能通过，我们可以根据不能通过的测试用例精确的定位问题，并轻而易举的解决的这个 Bug。
（2）验收测试驱动开发
验收测试驱动开发英文全称为 Acceptance Test Driver Development，简称 ATDD，是产品人员、开发人员、测试人员都需要参与到产品验收测试中来。在验收测试开发活动中团队需要就需求定义出期望的质量标准和验收细则，以明确而且达成共识的验收测试计划（包含一系列测试场景）来驱动产品的代码开发和测试脚本开发。一般来说 ATDD 一定是基于测试自动化和持续集成的，如下图所示。
（3）行为驱动开发
行为驱动开发英文全称 Behavior Driven Development，行为驱动开发是一种敏捷软件开发的技术，它鼓励软件项目中的开发者、QA 和非技术人员或商业参与者之间的协作，如下图所示。
测试设计
软件测试指导思想主要有以下三项。
在当前大规模的软件系统生产过程中，软件测试是无法找到全部缺陷的。
发现大规模系统中的所有缺陷是一个无限期的工作，而能用于测试的时间、人员、设备是有限的。
测试的关键，就是测试的覆盖。应该使用有限的测试资源完成最有价值的测试覆盖（用户使用的软件功能应该完全覆盖测试）。如下图所示。
案例设计技术
软件测试技术分为白盒测试和黑盒测试。白盒测试技术一般使用在代码走查、单元测试、接口测试等较为底层的测试类型当中。白盒测试当中一般使用语句覆盖和判定覆盖案例设计方法。黑盒测试一般使用在系统功能测试和验收测试中。常用案例设计方法包括等价类划分、边界值分析、决策表、状态转化测试等。
总体而言，软件测试设计遵循以下指导原则：
依据系统功能进行测试大纲的设计，保证测试的覆盖范围；
引入用户场景的描述，保证测试覆盖的重心不偏离；
进行系统的业务流程分析和数据流向分析，保证测试数据的全面性；
依据被测试部分的复杂度和关键度以及质量的要求，选择不同的测试设计方法；
针对用户的业务特征、角色权限和数据特征，进行流程测试设计，保证测试与实际应用的一致性；
按照用户需求，功能的复杂度、重要度和测试执行的要求，对测试用例进行优先级、适用阶段的分类，保证测试设计可以更好地指导测试执行。
执行测试用例评审活动，保证测试设计的准确性。
测试执行
软件测试执行，是指执行测试用例，并发现系统缺陷的活动。测试执行与缺陷修正活动同时开展，它是软件测试的关键环节。
软件测试执行，是软件测试活动中周期最长，工作量最大的环节，在测试执行中要关注以下内容:
接收测试
回归测试
扩展测试
交叉测试
自动化测试
缺陷管理
4.测试监控
需求和测试的双向追踪
需求的变化应该反映在测试需求跟踪矩阵表中，并进行测试需求分析、测试范围调整。测试计划、测试用例、测试执行也应有相应的改变和对应，如下图所示。
测试过程的质量控制和质量保证活动
在测试过程的每个阶段，均应有相对应的 QA 和 QC 活动相对应。
例如，测试准备阶段应该评审需求变更和测试方案。在测试设计阶段应该评审开发计划、测试计划、接收测试标准、风险管理计划等。在测试执行阶段应该监控测试进度、缺陷密度和缺陷分布。测试总结阶段应该编写测试总结报告对测试状态、缺陷数据进行分析；测试过程的经验教训也应该总结。相关测试数据和缺陷数据应该进入质量数据库，为以后测试过程改进提高支撑。
本文主要对测试管理的要素人、过程和技术以及测试过程进行了说明。由于测试管理是一个庞大的话题，作者从个人工作经验的角度进行了总结。欢迎大家参加讨论。
GITBook：测试管理要素
微信公众号：
