软件测试过程的V、W、H模型

1、V模型

V 模型最早是由Paul Rook 在20 世纪80 年代后期提出的，V 模型在英国国家计算中心文献中发布，目的是改进软件开发的效率和效果。它是软件测试最具代表性的测试模型之一。

在传统的开发模型中，如瀑布模型，通常把软件测试过程作为在需求分析、概要设计、详细设计和编码全部完成之后的一个阶段，尽管有时软件测试工作会占整个项目周期一半的时间，但是仍然被认为软件测试只是一个收尾工作，而不是主要的工程。故对以前的测试模型进行了一定程度的改进，V 模型其实是软件开发瀑布模型的变种，反映了软件测试活动与软件开发过程(从分析到设计)的关系。

V模型大体可以划分为以下几个不同的阶段步骤：需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试。

• 需求分析

即首先要明确客户需要的是什么，需要软件做成什么样子，需要有哪几项功能，这一点上比较关键的是分析师和客户沟通时的理解能力与交互性。要求分析师能准确的把客户所需要达到的功能，实现方式，等表述出来，给出分析结果，写出需求规格说明书。

• 概要设计

主要是架构的实现，指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务。

• 详细设计

对概要设计中表述的各模块进行深入分析，对各模块组合进行分析等，这一阶段要求达到伪代码级别，已经把程序的具体实现的功能，现象等描述出来。其中需要包含数据库设计说明。

• 软件编码

按照详细设计好的模块功能表，编程人员编写出实际的代码。

• 单元测试

按照设定好的最小测试单元进行按单元测试，主要是测试程序代码，为的是确保各单元模块被正确的编译，单元的具体划分按不同的单位与不同的软件有不同，比如有具体到模块的测试，也有具体到类，函数的测试等。

• 集成测试

经过了单元测试后，将各单元组合成完整的体系，主要测试各模块间组合后的功能实现情况，以及模块接口连接的成功与否，数据传递的正确性等，其主要目的是检查软件单位之间的接口是否正确。根据集成测试计划，一边将模块或其他软件单位组合成系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。

• 系统测试

将整个软件系统看做一个整体进行测试，包括对功能、性能以及软件所运行的软硬件环境进行测试 。

系统测试由黑盒测试员来完成，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，是否存在漏洞，以及在不同的软硬件环境中的兼容性，主要依据是《系统需求规格说明》文档 。

• 验收测试

主要就是用户在拿到软件的时候，在使用现场，会根据用户需求，以及规格说明书来做相应测试，以确定软件达到符合效果的。包括功能确认测试、安全可靠性测试、易用性测试、可扩充性测试、兼容性测试、资源占用率测试、用户文档资料验收等。

• α测试

非正式验收测试，由用户、测试人员、开发人员共同参与的内部测试 。

α测试是指软件开发公司组织内部人员在开发环境下模拟各类用户对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。

α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。经过α测试调整的软件产品称为β版本。

• β测试

内测后的公测，即将正式发布，完全交给最终用户的测试。

β测试是由软件的多个用户在实际使用环境下进行的测试，这些用户返回有关错误信息给开发者。测试时，开发者通常不在测试现场。因而，β测试是在开发者无法控制的环境下进行的软件现场应用。在β测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告。β测试主要衡量产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)，着重于产品的支持性，包括文档，客户培训和支持产品生产能力。

**注：**α测试和β测试均不能由程序员和测试员完成。

V 模型从左到右，描述了基本的开发过程和测试行为，明确地标明了测试工程中存在的不同级别以及测试阶段和开发过程各阶段的对应关系。图中箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即测试过程各阶段。

V 模型指出，单元和集成测试是验证程序设计，单元测试主要由白盒测试工程对代码进行测试，但目前国内真正做白盒测试的企业不多。这主要有两大原因：第一，白盒测试投入的成本很高，并且产出不明显，很多企业不希望投入更多的资源去做这项工作;第二，白盒测试对测试工程师的要求较高，在目前系统测试还没有完全成熟的情况下很难真正地开展白盒测试。而集成测试是介于白盒测试与系统测试之间的一种测试，也叫灰盒测试，由于它与白盒测试和系统测试之间没有明显的界限，所以在实际的测试过程中，即使开展集成测试也是由系统测试工程师来完成。

系统测试主要验证系统设计，检测系统功能、性能的质量特性是否达到系统设计的指标，由测试人员和用户进行软件的确认测试和验收测试，以及对需求说明书进行测试，以确定软件的实现是否满足用户需求或合同要求。

V 模型存在一定的局限性，它把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。如果不做白盒测试，那么其实都是在系统完成集成后才开始系统测试的，这样需求分析阶段隐藏的问题一直到后期的验收测试才被发现，因此修改缺陷的成本就高了很多。

V 模型详细的描述了每个测试阶段所对应验证的对象，单元测试验收的对象是详细测试说明书、集成测试验证的对象是概要设计说明书，系统测试验证的对象是需求说明书。在测试过程中，我们经常说测试的目的就是验证产品是否满足客户的需求，那么如何确保我们的产品是满足客户需求的呢?换一个角度来理解，其实结果是靠过程来保证的，也就是说，如果我们可以确保开发每个阶段的工作是正确的，那么就说明开发出来的产品肯定是满足客户需求的，因为开发每个阶段的工作都是以需求说明书为依据的，所以V 模型有一个优点是其详细地介绍了测试每个阶段所测试验证的依据。

由于V 模型是软件开发中瀑布模型的变种，所以它存在和瀑布模型相似的一些问题。由于测试阶段处于软件实现后，这意味着在代码完成后必须有足够的时间预留给测试活动;否则将导致测试不充分，开发前期未发现的错误会传递并扩散到后面的阶段，而在后面发现这些错误时，可能已经很难再修正，从而导致项目的失败。

V 模型最大的缺陷就是只把程序作为被测试对象，而需求、说明书等其他规格说明书都未被列为测试对象。

总之V 模型具有以下特征：

(1)测试阶段划分得很清楚。

(2)每个开发阶段都有相应的测试对其进行验证。

(3)测试与开发是串行进行的而不是并行，也就是测试需要等开发完成后再开始。

(4)测试对象只有程序，而不包括需求等其他的说明书。

(5)V 模型是瀑布模型的变种，瀑布模型存在的问题V 模型也存在。

2、W模型

W模型由Evolutif公司提出，相对于V模型，W模型增加了软件开发各阶段中同步进行的验证和确认活动。，W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。

W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等开发输出的文档同样要测试（这里针对设计文档，一般可以划分为需求设计文档、概要设计文档、详细设计文档和代码文档）， 也就是说，测试与开发是同步进行的。

从这个角度来说，一个完整合格的测试人员对软件各方面把握程度应该比开发人员更高，一个测试人员要能胜任软件研究任何一个岗位。

W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求文档的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。

但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临的困惑。

W模型优点：

1、测试的活动与软件开发同步进行

2、测试的对象不仅仅是程序，还包括需求和设计

3、尽早发现软件缺陷可降低软件开发的成本

3、H模型

H模型将测试活动完全独立出来，形成一个完整的流程，同时将测试准备和测试执行清晰表现出来。

测试流程：

–测试准备：所有测试活动的准备判断是否到测试就绪点。

–测试就绪点：测试准入准则，即是否可以开始执行测试的条件

–测试执行：具体的执行测试的程序

其它流程:回归测试、冒烟测试、探索性测试

H模型优点：

（1）开发的H模型揭示了软件测试除测试执行外，还有很多工作。

（2）软件测试完全独立贯穿整个生命周期与其它流程并发进行；

（3）软件测试活动可以尽早准备尽早执行，具有很强的灵活性；

（4）软件测试可以根据被测对象的不同而分层次、分阶段、分次序的执行，同时也是可以被迭代的。

H模型的缺点：

（1）管理型要求高：要定义清晰的规则和管理制度，否则测试过程将很难管理和控制

（2）技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小；

（3）测试就绪点分析困难：测试很多时候，你并不知道测试准备到什么时候是合适的，就绪点在哪，就绪点标准是什么，对后续的测试执行启动带来很大的困难

（4）对整个项目组的人员要求非常高：在很好的制度下，大家都能高效的1工作，否则容易混乱（对整个项目足够熟悉）。例如：你分了一个很小的迭代，但因为人员技能不足，使得无法完成，那么整个项目会受到很大的干扰。

总结：

V模型适用于中小企业

W模型适用于中大型企业

H模型人员要求非常高，很少有人使用。