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

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

V模型

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

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

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

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

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

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

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

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

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

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

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

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

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