就象开发有开发模型一样，测试也有测试模型，尽管这些方法比较鲜为人知。部分原因是因为很多测试人员已经在他们的工作中积累了大量的经验，利用这些经验就可以做好他们的工作。总的来说，测试往往要占据整个开发周期的一般时间，但即使在很多正规的大学中，也没有为那些即将开始软件身涯的学生们设置软件测试的课程。

软件专家们不断在提供新的开发模型，这也是实际开发需要使然，与此同时，在开发过程中也不断感受到这些已存在的方法的不足，例如，还没有比RUP更充分的方法，但RUP也存在一些明显的不足，例如，RUP没有对测试计划进行定位。

V-模型
V模型只得到软件业内比较模糊的认可。V-模型宣称测试并不是一个事后弥补行为，而是一个同开发过程同样重要的过程。V模型如下图所示：

图1：V模型示意图

V模型最早由已故的Paul Rook在80年代后期提出，V模型被包含在英国国家计算中心文献中发布，旨在改进软件开发的效率和效果。V模型在欧洲尤其是英国被接受，并被认为是瀑布模型的替代品，而在美国则被误解为是又一种瀑布模型。

在传统开发过程中，仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段，事实上，V模型的推出也是针对于此而进行的改进。在瀑布模型中，确实给人们造成了这样的不良影响，即在很多重要开发活动完成后，测试只是收尾工作，而不是主要的过程，尽管有时测试会占据项目周期一半的时间，很多项目主管却仍然还是坚持这么认为。

测试是一项意义显著的工作
V模型描述了一些不同的测试级别，并说明了这些级别所对应的生命周期中不同的阶段。如模型图中所示，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。请注意在不同的组织中，对测试阶段的命名可能有所不同。

在模型图中的开发阶段一侧，先从定义业务需求开始，然后要把这些需求不断地转换到概要设计和详细设计中去，最后进行开发成为程序代码。在测试执行阶段一侧，执行先从单元测试开始，然后是集成测试、系统测试和验收测试。

V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系：

• 单元测试的主要目的是针对编码过程中可能存在的各种错误，例如用户输入验证过程中的边界值的错误。
• 集成测试主要目的是针对详细设计中可能存在的问题，尤其是检查各单元与其它程序部分之间的接口上可能存在的错误。
• 系统测试主要针对概要设计，检查了系统作为一个整体是否有效地得到运行，例如在产品设置中是否能达到了预期的高性能。
• 验收测试通常由业务专家或用户进行，以确认产品能真正符合用户业务上的需要。

在不同的开发阶段，会出现不同类型的缺陷和错误，所以需要不同的测试技术和方法来发现这些缺陷。

发现缺陷的艺术
大多数测试人员比较容易接受V模型的观点，即测试和开发在开发过程中是平等的。即使是开发人员也同样很欣赏V模型所提出的测试级别和开发过程相对应的方式，但很少有人去充分利用V模型的全部威力。很多人认为测试只是在编码或者系统某个部分完成后会发生什么，并且错误地将测试看作为“执行测试”。这样，他们知道要开始执行测试的时候才真正想到了测试。

测试不仅仅是测试。测试过程还包括确定要测试什么（测试范围和条件）以及产品如何被测试（制作测试用例），建立测试环境，执行测试，最后再评估测试结果，检查是否达到已完成测试的标准，并报告进展情况。而且，仅有这些还不够，根据很多测试者的经验，当你认为什么地方有问题时，你就很可能会在那里发现问题。如测试专家Boris Beizer在他经典的测试著作《Software Testing Techniques (Thomson Computer Press, 1990)》中所说，测试设计可以发现缺陷和错误。

而且，如果你把测试设计放在最后阶段，就错过了发现构架设计和业务逻辑设计中存在的严重问题的时机，到那时，要修复这些缺陷将很不方便，因为缺陷已经扩散到系统中去了，所以这样的错误将很难寻找和修复，并且代价更高。

比较灵活的解释，尽量提早的测试
V模型在欧洲，至少在英国很容易被解释，但在美国却比较难以被接受。例如，虽然V模型没有明确说明早期的测试设计，而Graham则认为它体现在了处理过程中，并认为这是V模型的强大力量所在。V模型所没有明确说明的这些其它的测试行为有时被演化为一种W模型，因为实际上开发是"V"，测试也是与此相重叠的"V"。不管V模型是否明确说明了早期的测试设计行为，测试设计确实是值得强调的。

根据V模型的要求，一旦有文档提供，就要及时确定测试条件，以及编写测试用例，这些工作对测试的各级别都有意义。当需求被提交后，就需要确定高级别的测试用例来测试这些需求。当概要设计编写完成后，就需要确定测试条件来查找该阶段的设计缺陷。

如果测试文档能尽早提交，那么就有了更多的检查和检阅的时间，这些文档还可用于评估开发文档。另外还有一个很大的益处是，测试者可以在项目中尽可能早地面对规格说明书的挑战（测试是一种接受挑战的行为）。

这意味着测试不仅仅是评定软件的质量，测试还可以尽可能早地找出缺陷所在，从而帮助改进项目内部的质量。参与前期工作的测试者可以预先估计问题和难度，这将可以显著地减少总体测试时间，加快项目进度。 (在这个专辑的第三篇就是Goldsmith的文章"前置测试"方法的介绍)

What-How-Do
对于传统的瀑布生命周期模型来说，V模型常被错误地认为是要求开发和测试保持一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可正式开始下一个阶段。这样就无法支持迭代，自发性以及变更调整。例如，Brian Marickarick(《The Craft of Software Testing (Prentice Hall, 1995)》一书的作者)在"测试过程新模型"一文中提到，" V模型的问题在于一定要将系统开发过程分为具有严格边界的阶段，这使人们无法在这些边界之间交接和交换测试信息。"

情况其实并不是这样的，严格规定不是有效的开发人员和测试人员在应用各种模型过程中所采用的方式。 实际上，各种模型只是简单地提醒我们，有必要定义一些必须要做什么（需求）--What，然后描述如何做(设计)--How，然后花很多力气来实现(编码)--Do。V模型所做的是强调每一个开发级别都有一个与之相关联的测试级别，并且建议测试应该在各级别之前进行设计。

各模型并没有规定工作量大小。有效的开发人员总是能将项目分解为可操作的小阶段，例如在迭代式开发中整个项目被分解为很多小片断，并忽略了各片段的实际大小。此时，模型的what-how-do顺序对于按时交付就具有重要意义，而且对于保证每一个阶段目标的实现也非常重要。

V模型所不能做的
V模型适用于所有类型的开发过程，但并不一定适用于开发和测试过程的所有方面。不管是GUI还是批处理、 大型机还是Web、Java还是Cobol，都需要单元测试、集成测试、系统测试和验收测试。但是，V模型本身并不会告诉你如何定义单元测试或集成测试的内容、以如何顺利工作、如何进行具体的测试设计，以及该输入怎样的数据，输出怎样的输出结果才是正确的。

有些测试者认为：“是否使用V模型要看该所应用的项目。有些项目需要应用V模型，而有些项目不需要。可以只在需要V模型的项目中采用。”这样的做法实际上对任何模型都是有害的。我们应该尽可能地去应用模型中对项目有实用价值的方面，但不强行地为使用模型而使用模型，否则也没有实际意义。

例如，V模型的反对者经常声称V模型只有对需求非常明确，已经文档化了的项目才有用，因为所有的开发人员和测试人员都需要严格定义好的需求和设计来开展工作。对于当前很多文档需要事后补充，或者根本没有文档的做法下（这已成为一种开发的文化），开发人员和测试人员都面临同样的困惑。在这种情况下，V模型的概念仍然是有用的，但在需求不明确的情况下更难应用，因为不管要开展什么工作，要测试什么，首先需要明确知道开发了什么。

V模型的反对者可能会声称V模型不适用于极限编程(XP)，在XP中提倡快速开发，结对编程，在编码之前就已完成测试用例。首先，我们提倡同时应用这两种方法，另外，也需要指出的是XP方法也强调在编程之前尽可能发现需求。

V模型没有明确说明需求和设计文档应如何定义，要定义多少文档，同时V模型也没有说明在各测试阶段如何进行测试设计。在采用XP策略的开发过程中，V模型的支持者认为，可以将单元测试应用于所划分的各个代码片段上，但V模型没有定义各单元测试之间应如何匹配。只在必要的时候，才需要进行集成测试，而最终意义上的集成测试也就是系统测试。尽管一些XP工作者将这些测试看作为“验收测试”，其实际目的只是希望降低让用户进行测试的必要性，同时又希望能确保系统在功能上满足用户业务的需要。

V模型的替代品--X模型?
也许是由于V模型存在已有了一段时间，它曾带来过一定程度上的滥用，尤其是在那些Internet时代比较紧急的项目中。

Marick认为："我们对V模型的需要就象是鱼对自行车的需要一样。"在他的文章中提出了测试过程的新模型。他认为，有些测试要比商业行为更早些，而另外一些测试则要在更晚的时候得以进行。而且，V模型使人很难对不同阶段的系统描述进行综合。

V模型的支持者则认为，虽然在显示面前没有一个模型表现得无可挑剔，但在实践过程中，有些模型还是比较有用的。在下一篇中，我们将审视Marick所提倡的X模型。