软件测试基础理论学习-常见软件测试模型

V模型

背景

软件测试中的V模型是在瀑布模型基础上发展起来的一种软件开发和测试过程的图形表示方法，它的背景源于20世纪80年代末至90年代初对传统瀑布模型在实际应用中所暴露的问题进行改进的需求。

传统的瀑布模型是一种线性的开发流程，要求所有需求在项目开始时完全确定，并严格按照需求分析、设计、编码、集成、测试和维护等顺序执行。然而，在实践中发现这种模型对于需求变更的适应性较差，尤其在大型复杂项目中，往往无法一次性准确地捕获所有的需求和技术问题，导致后期修改成本高昂且质量难以保证。

因此，为了更好地整合测试活动与开发阶段，V模型应运而生。在V模型中，每一阶段的开发活动都有对应的测试活动，从左到右呈现出V字形结构

主要特性

• 明确定义了测试的不同级别，也描述了测试阶段和开发阶段的对应关系，下文描述几个测试的主要目的：

  • 验收测试，主要就是去验证最终交付的系统是否符合最开始的需求分析的产品要求，通过运行软件或者其他方式来判断这个产品是否可以满足用户的需求，一般都是一些纯黑盒的测试，就是作为一个用户去运行使用这个系统

  • 系统测试，主要是验证软件的系统架构设计是否合理，是否能够满足性能需求，性能测试、自动化测试，可能都会在这个阶段开展

  • 集成测试，需要把单元测试里面的所有代码进行一个集成，集成后还需要于外部服务、中间件等进行集成后进行测试，关注的是代码或者程序在集成之后是否能够正常运行

  • 单元测试，一般就是对代码层面进行测试，如果是面向对象的语言，可能就会分类（Class），单元测试就需要分别独立的对这些模块进行测试，这些代码测试的时候，一般不会依赖于其他的环境，例如数据库、中间件服务等，可以通过一些其他技术去屏蔽这些依赖，关注的是代码的内部运行逻辑是否正确

优点

• 测试的阶段和开发的阶段能够一一对应

• 有着清晰的阶段划分

缺点

• 该模型是由瀑布模型衍生出来的，就会导致需要在编码结束之后才能进行测试，这其实是违背了测试的原则：“测试需要尽早的不断地进行软件测试”

• 也是瀑布模型的通病，如果在最后的验收测试中发现有需求问题，回溯代价极大

W模型

背景

W模型，也被称为“双V模型”或“双重V模型”，是在传统V模型的基础上发展起来的一种软件测试模型。W模型由Evolutif公司提出，其背景主要针对的是V模型在实际应用中对测试活动的不足之处。

V模型强调了开发过程与测试活动之间的对应关系，但它的局限性在于测试活动往往被安排在编码阶段之后进行，导致测试介入较晚，对于需求和设计阶段的错误可能无法及时发现，从而增加修改成本。

基于这一背景，W模型在V模型的基础上增加了并行的验证（Validation）和确认（Verification）路径。其中一条路径表示传统的从需求分析到系统测试的顺序过程，而另一条并行路径则强调在每个开发阶段都需要同时进行相应的验证和确认活动，即在需求分析阶段就需要考虑需求可验证性，在设计阶段就要考虑设计的可验证性和可确认性，这样就更早地将测试活动融入整个开发生命周期中，从而尽早发现问题，降低修复成本，并提升软件质量。W模型更加明确地体现了测试人员需要早期参与项目，以及测试活动与开发活动并行执行的思想。

核心思想 / 优点

• 第一个“V”代表了软件开发的生命周期，第二个“V”代表了软件测试的生命周期，两个“V”放在一起，代表了软件测试伴随了整个软件开发的周期，也能体现“尽早的不断地进行软件测试”的原则

• 在需求分析阶段就开始介入，例如用户的需求不符合实际要求，或者不太合理（有的用户提出的需求并不是自己想要的需求）

• 并行验证和测试，可以支持两条路线一起并行推进

缺点

• W模型或者V模型都把开发及测试定义为一系列串行的活动

• 前后阶段存在比较强的依赖关系，难以支持迭代

H模型

背景

核心思想

• 相对于V模型和W模型，H模型将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

• 上图仅仅演示了在整个生产周期中某个层次上的一次测试“微循环”。图中标注的其他流程可以是任意的开发流程。例如，设计流程或编码流程。也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以（或者说需要）进行了。

• H模型揭示了一个原理：软件测试是一个独立的流程，以独立完整“微循环”流程，参与产品生命周期的各个阶段，与其他流程并发地进行。

• H模型指出软件测试要尽早准备，尽早执行，只要某个测试达到准备就绪点，测试执行活动就可以开展，并且不同的测试活动可按照某个次序先后进行，但也可以是反复进行的。

主要特性

1. 并行和独立性：H模型强调软件测试活动在整个软件生命周期中是一个独立的流程，并与开发、需求分析等其他活动并发进行。这意味着测试不仅仅是在编码结束后才开始，而是在整个项目周期内持续进行。

2. 贯穿整个生命周期：在H模型中，软件测试不再局限于某个特定阶段，而是从项目启动直至产品维护，测试活动都贯穿始终。这体现了“尽早地和不断地进行软件测试”的原则。

3. 灵活的入口点：H模型中的测试准备和执行可以根据项目的实际进度随时启动，当某个测试点准备就绪时，就可以从测试准备阶段进入测试执行阶段，而不是等待所有开发工作完成后一次性开展测试。

4. 层次化和模块化：H模型允许根据被测对象的不同而分层次、分阶段、分次序地执行测试活动。例如，可以按照单元测试、集成测试、系统测试、验收测试的顺序递进，也可以根据需求优先级或功能模块来组织测试。优点

缺点

1. 测试管理难度高，难以形成有效的测试时间计划，由于强调测试活动在整个软件生命周期中的独立性和并发性，所以团队必须对每个测试阶段进行精细的规划、协调与控制。

2. 要求实现测试的人员对业务有很深的理解，才能够在需求变更的时候能够正常的执行测试任务

3. 相较于敏捷开发中的迭代模型，H模型对适应变化和快速响应方面较弱