概述
对于前文软件开发生命周期的实现，为保障软件质量，将测试工作凸显出来（通过前文介绍的线性（linear）、迭代（iterative）、演进（evolutionary）和平行（parallel）等方式），又演化出了针对测试的过程模型，主要有 V 模型、W 模型、X 模型、H 模型等。
V 模型
1978 年 Kevin Forsberg 与 Harold Mooz 提出了 V 模型（也被称为验证和验证模型）。V 模型是一个著名的、以测试为驱动的开发模型，该模型强调开发过程中测试贯穿始终，是瀑布模型的一个变体。V 模型反映了开发过程和测试过程的关系，在测试软件的过程中起着非常重要的作用。测试依旧是开发生命周期中的阶段，与瀑布模型不同的是，有多个测试级别与开发阶段对应。
左侧对应设计阶段：
- 需求分析：要分析用户的需要，整理出系统的需求（功能需求），会和用户面谈，建立用户需求文档（user requirements document）
- 概要设计：系统设计师根据用户需求文档，分析并理解要开发系统的业务流程的阶段，会产生软件规格文档（software specification document），软件规格文档是开发阶段的蓝图
- 详细设计：也称为低阶设计，会将设计的系统拆解为较小的单元或是模组，说明每一部分的内容，让程式设计者可以直接写程式
右侧对应测试阶段：
- 单元测试：主要发现编程和详细设计阶段的错误，测试计划在详细设计阶段制定，在编码阶段完成
- 集成测试：主要发现设计阶段产生的错误，测试计划在概要设计阶段制定，在详细设计阶段完成
- 系统测试：计划在需求分析阶段制定，在概要设计阶段完成
- 验收测试（User Acceptance Test）：计划会在需求分析阶段就订定，测试计划是由企业用户来进行
开发阶段与测试级别的对应关系如下：
flowchart TD
A[需求分析] --- H[验收测试]
B[概要设计] --- I[系统测试]
C[详细设计] --- J[集成测试]
D[编码实现] --- K[单元测试]
A --> B --> C --> D
D --> K --> J --> I --> HV 模型的软件开发不是以直线的方式进行，其过程在源代码阶段之前逐步往下，而在源代码阶段之后逐步往上，形成了 V 字形。V 模型指出了软件开发中的各阶段以及其对应软件测试阶段之间的关系：横轴表示时间或是项目的完成度，而纵轴表示抽象的程度（范围越大、越抽象的在越上方）。
V 模型的中心思想是研发人员和测试人员需要同时工作，在软件做需求分析的同时就会有测试用例的跟踪。这样可以尽快找出程序错误和需求偏离，从而更高效地提高程序质量，最大可能地减少成本，同时满足用户的实际软件需求。V 模型的重要意义在于，非常明确地表明了测试过程中存在的不同级别，并且非常清晰地描述了这些测试阶段和开发阶段的对应关系。
优点：
- 包含了底层测试（单元测试）和高层测试（系统测试）
- 清楚地标识了开发和测试的各个阶段
- 自上而下逐步求精，每个阶段分工明确，便于整体项目的把控
- 像计划、测试设计这样的测试活动会在编码之前很好地进行，这节省了很多时间。因此相比于瀑布模型，成功的几率更高
缺点：
- 测试与开发是串行进行的而不是并行，自上而下的顺序导致了测试工作在编码之后，就导致错误不能及时地进行修改
- 实际工作中，需求经常变化，导致 V 模型步骤反复执行，返工量很大，灵活度较低
- V 模型太过简单，无法准确地反映软件开发的过程，会让管理者有一种错误的安全感。V 模型反映了软件开发中管理者的观点，适合专案管理者、会计师及律师，但不适合软件开发者及用户
- V 模型和瀑布模型一样，过程中产生大量文档，项目反应速度也越来越不能满足当前日新月异的需求和快速更新换代的节奏
与瀑布模型一样，V 模式是一种传统软件开发模型，在当前互联网软件开发中，局限性还是比较大的。
W 模型
V 模型的局限性在于没有明确地说明早期的测试，无法体现”尽早地和不断地进行软件测试”的原则。在 V 模型中增加软件各开发阶段应同步进行的测试，演化为 W 模型。在模型中不难看出，开发是”V”，测试是与此并行的”V”。基于”尽早地和不断地进行软件测试”的原则，在软件的需求和设计阶段的测试活动应遵循 IEEE1012-1998《软件验证与确认（V&V）》的原则。
W 模型由 Evolutif 公司提出，相对于 V 模型，W 模型更科学。W 模型是 V 模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。
W 模型与 V 模型有一个很大的不同：W 模型是一个并行的模型，V 模型是一个串行的模型。W 模型测试是从需求分析开始就开始了，而不是等到编码完成后才开始。并且测试阶段的划分更清楚，而不仅仅是单元测试、集成测试、系统测试，还包括前期的测试计划、测试方案等内容，这更符合现在企业测试的流程。
W 模型具有以下特征：
- 测试阶段划分得更全面，不仅仅是单元测试、集成测试和系统测试；测试的对象不仅是程序，需求、设计等同样要测试
- 测试与开发是并行的，从需求测试就应该开始介入
- 提出尽早测试的概念，这样可以降低缺陷修复成本
- 测试对象不仅仅是程序，还包括需求或其他的相关文档
W 模型仍然是以文档驱动的传统开发方式的一个变种。
优点：
- 测试伴随着整个开发周期，需求和设计同样要测试
- 更早地介入测试，可以发现初期的缺陷，修复成本低
- 分阶段工作，方便项目整体管理
缺点：
- 开发和测试依然是线性的关系，需求的变更和调整依然不方便，这样就无法支持迭代的开发模型
- 如果没有文档，根本无法执行 W 模型；对于项目组成员的技术要求更高
X 模型
X 模型的基本思想是由 Marick 提出的，但是 Marick 不建议建立一个替代模型。Robin F Goldsmith 引用了 Marick 的一些想法，并经过重新组织，形成了”X 模型”。X 模型也是对 V 模型的改进，X 模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序。
X 模型左边是单元测试和单元模型之间的集成测试，右边是功能的集成测试，通过不断的集成最后成为一个系统，如果整个系统测试没有问题就可以封版发布。这个模型有一个很大的优点是它呈现了一种动态测试的过程，也就是测试是一个不断迭代的过程，这更符合企业实际情况，其他模型更像一个静态的测试过程。
X 模型提倡公司可以根据自身的实际情况确定是否要进行单元测试和集成测试，并不是所有的研发公司都会先做单元测试和集成测试，更多的是直接做系统测试。
在 X 模型中还显示了测试步骤，包括测试设计、工具配置、执行测试三个步骤，虽然这个测试步骤并不很完善，但毕竟将一些主要的内容表现出来了。
X 模型提倡探索性测试，指不进行事先计划的特殊类型的测试，这样可以帮助有经验的测试工程师发现测试计划之外更多的软件错误，避免把大量时间花费在编写测试文档上，导致真正用于测试的时间减少。
综上，X 模型具有以下特征：
- 公司可以根据自身的情况确定是否要做单元测试，还是直接做系统测试
- 测试应该是一个不断迭代的过程，直到封版发布
- 提倡探索性测试
H 模型
H 模型中，软件测试过程活动完全独立，贯穿于整个产品的周期，与其他流程并发地进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早地进行，并且可以根据被测物的不同而分层次进行。
其示意图演示了在整个生产周期中某个层次上的一次测试”微循环”。图中标注的其它流程可以是任意的开发流程，例如设计流程或者编码流程。也就是说，只要测试条件成熟了、测试准备活动完成了，测试执行活动就可以进行了。
H 模型揭示了一个原理：软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。H 模型指出软件测试要尽早准备、尽早执行。不同的测试活动可以是按照某个次序先后进行的，但也可能是反复的，只要某个测试达到准备就绪点，测试执行活动就可以开展。
小结
| 模型 | 核心思想 | 局限性 |
|---|---|---|
| V 模型 | 软件开发瀑布模型的变种，主要反映测试活动与分析和设计的关系 | 把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现 |
| W 模型 | 在 V 模型的基础上，增加开发阶段的同步测试；测试与开发同步进行，有利于尽早发现问题 | 仍把开发活动看成是从需求开始到编码结束的串行活动，只有上一阶段完成后才可以开始下一阶段的活动，不能支持迭代、自发性以及变更调整 |
| X 模型 | 针对 单独的程序片段进行相互分离的编码和测试，通过频繁的交接、集成最终合成为可执行的程序 | 测试步骤的表述并不完善 |
| H 模型 | 软件测试过程活动完全独立，贯穿整个产品周期，与其他流程并发进行；某个测试点准备就绪时就可以从测试准备阶段进行到测试执行阶段 | - |
参考文章
V 模型和 W 模型主要整理自如下文章：
其它模型整理自：
- https://blog.51cto.com/sunday208/1393997
- https://www.it610.com/article/1277316151973527552.htm
- https://zhuanlan.zhihu.com/p/57005405