软件测试常见模型

V模型
在V模型中，测试过程被加在开发过程的后半部分，如下图所示：

1.PNG(12.09 KB)

2008-2-20 14:48

   单元测试所检测代码的开发是否符合详细设计的要求。集成测试所检测此前测试过的各组成部分是否能完好地结合到一起。系统测试所检测已集成在一起的产品是否符合系统规格说明书的要求。而验收测试则检测产品是否符合最终用户的需求。

对于测试设计，显而易见的是，V模型的用户往往会把执行测试与测试设计分开对待。在开发文档准备就绪后，就可以开始进行相关的测试设计。如下图所示，相应的测试设计覆盖在了相关的开发过程之上：

2.PNG(12.36 KB)

2008-2-20 14:48

将测试设计覆盖了开发过程后的V模型

    V模型有着很吸引人的对称外形，并且把很多人都带入了歧途。本文将集中讨论它在单元测试和集成测试中引起的问题。

为了说明的方便，这里专门制作了以下图片，图中包括一个单独的单元，以及一个单元组，称之为子系统（subsystem）。

3.PNG(7.7 KB)

2008-2-20 14:48

一个假想的子系统

对于一个单元应该多大才最为合适的问题，已经有过很多的讨论，究竟一个单元仅仅是一个函数，一个类，还是相关的类的集合？这些讨论并不影响我在这里所要阐述的观点。我们权且认为一个单元就是一个最小程度的代码块，开发人员可以对进行独立地讨论。

    V模型认为人们首先应该对每一个单元进行测试。当子系统中所有的单元都已经测试完毕，它们将被集中到一起进行测试，以验证它们是否可以构成一个可运行的整体。

那么，如何针对单元进行测试呢？我们会查看在详细设计中对接口的定义，或者查看源代码，或者同时对两者进行查看，找出符合某些测试设计中的有关准则的输入数据来进行输入，然后检查结果，看其是否正确。由于各单元一般来说不能独立地运行，所以我们不得不另外设计桩模块（Stub）和驱动模块（Driver），如下图所示。

4.PNG(4.38 KB)

2008-2-20 14:48

单元及其外部的驱动模块和桩模块

图中的箭头代表了测试的执行轨迹。这就是大多数人所说的“单元测试”。这样的方法有时候是一种不好的方法。

同样的输入也可以有同一子系统中的其它单元来提供，这样，其它的单元既扮演了桩模块，又扮演了驱动模块。如下图所示：

5.PNG(4.99 KB)

2008-2-20 14:48

子系统内部各单元间的测试执行轨迹

到底选择哪一种方法，这需要一种折衷和权衡。设计桩模块和驱动模块要付出多少代价？这些模块如何进行维护？子系统是否会由此而掩盖了一些故障？在整个子系统范围内进行排错的困难程度有多大？如果我们的测试直到集成测试时才真正开始，那么一些bug可能较晚才被发现。由此造成的代价同设计桩模块和驱动模块的代价如何比较？

    V模型没有去考虑这些问题，当单元开发完成后就执行单元测试，而当自系统被集中在一起后就执行集成测试，仅此而已。令我奇怪和沮丧的是，人们从不去做一些权衡，他们已经受制于他们的模型。

因此，一个有用的模型应该允许测试人员考虑节省并推迟测试的可能性。

一个测试，如果要发现一个特定的单元中的bug，最好是在该单元保持独立的情况下执行，并且在其外部辅以特定的桩模块和驱动模块。而另一种方法则是让它作为子系统的一部分来进行测试，该测试的设计主要是为了发现集成的问题。由于一个子系统本身也需要桩模块和驱动模块来模拟该子系统和其它子系统的联系，因此，单元测试和集成测试可能被推迟到至少整个系统已经部分集成的时候。在这种情况下，测试者可能通过产品的外部接口同时进行单元测试、集成测试和系统测试，同样的，其主要目的还是为了减少总体生命周期的成本，对测试成本和延期进行测试及由此造成延期发现bug的代价成本进行权衡。据此而言，"单元测试"、"集成测试"和"系统测试"的区别已经大大削弱了。其结果可参考下图：

6.PNG(14.49 KB)

2008-2-20 14:48

新的方法：在部分阶段延迟进行单元测试和集成测试

在上图右边的方块中，最好要改成为“执行某些适当的测试并得到相应的结果”。

图中的左边会怎样？考虑一下系统测试设计，它的主要根据和信息来源是是规格说明。假设你知道有2个单元处在一个特定的子系统中，它们在运行时相互联系，并且要执行规格说明中的一个特定的声明。为什么不在该子系统被集成时立即对此规格说明中的声明进行测试，就象是在设计完成后立即开始测试的设计一样呢？如果该声明的执行和子系统外的子系统没有任何关系，为什么还要等到整个系统完成以后再测试呢？难道越早发现bug成本越低不对吗？

在上一张图片中，我们用了向上指的箭头（更有效，但在时间上有延迟）。这里还可以把箭头往下指（在时间上提前）：

7.PNG(16.64 KB)

2008-2-20 14:48

新的方法：在不同阶段上提前进行测试设计

在这种情况下，左边的方块中最好被标记为：“在当前信息条件和情况下可以做的任何测试设计”。这样，当测试设计得自于系统中某一个组件的描述时，模型必须允许这样的测试在组件被装配之前被执行。我必须承认我的图片非常难看，这些箭头指得到处都是，对此我有2点说明：

    1.我们所讨论的事情不是创造美，而是想要发现尽可能多的严重错误，同时尽可能地降低成本。

    2.难看的部分原因也是因为必须按照某些次序来执行的结果，亦即开发人员先提供系统描述文档，然后测试和这些文档进行关联。这些文档就象是坚实的老橡树，而测试设计则象是细细的枝条缠绕在树上。如果我们采用不同的原理来进行组织，图片可能就会变得好看些。但复杂性仍不可避免，因为我们要讨论的问题本身就很复杂。

    V模型失败的原因是它把系统开发过程划分为具有固定边界的不同阶段，这使得人们很难跨过这些边界来采集测试所需要的信息。有些测试应该执行得更早些，有些测试则需要延后进行。而且，它也阻碍了你从系统描述的不同阶段中取得信息进行综合。例如，某些组织有时执行这样的做法，即对完成的工作进行签署。这样的规定也扩展到系统测试的设计。签署表示已经过评估，该测试设计工作已经完成，除非对应的设计文档改变，否则就不会被修订。如果同这些测试相关的信息后来被重新挖掘和认识，例如，架构设计表明有些测试是多余的，或者，详细设计表明有一个内部的边界可以和已存在的系统测试组合在一起进行测试的话，那么实际上还需要继续调整原来的系统测试设计。

因此，模型必须允许利用不同来源的综合信息进行个别的测试设计。另外，模型还应该允许在新的信息来源出现后重新进行测试的设计。

上次说到V模型的局限性在于没有明确地说明早期的测试,无法体现“尽早地和不断地进行软件测试”的原则。在V模型中增加软件各开发阶段应同步进行的测试，演化为W模型。在模型中不难看出，开发是“V”，测试是与此并行的“V”。基于“尽早地和不断地进行软件测试”的原则，在软件的需求和设计阶段的测试活动应遵循IEEE1012-1998《软件验证与确认（V&V）》的原则。

V模型

由Evolutif公司提出，相对于V模型，W模型更科学。W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。

W模型也有局限性。W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动，无法支持迭代、自发性以及变更调整。

上次提到两个测试过程模型，都没有很好地体现测试流程的完整性。为了解决以上问题，提出了H模型。它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

8.PNG(33.44 KB)

2008-2-20 14:48

     

软件测试H模型

示意图演示了在整个生产周期中某个层次上的一次测试“微循环”。图中的其他流程图可以是任意开发流程。例如，设计流程和编码流程。也可以是其他非开发流程，例如，SQA流程，甚至是测试流程本身。只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以进行了。

9.PNG(18.55 KB)

2008-2-20 14:48

H模型揭示了：

·
软件测试不仅仅指测试的执行，还包括很多其他的活动

·
软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行

·
软件测试要尽早准备，尽早执行

·
软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的

在H模型中，软件测试模型是一个独立的流程，贯穿于整个产品周期，与其他流程并发地进行。当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。

X模型的基本思想是由Marick提出的，但首先是Marick不建议要建立一个替代模型。Robin F·Goldsmith引用了一些Marick的想法，并重新经过组织，形成了“X模型”。其实并不是为了和V模型相对应而选择这样的名字，而是由于其它一些原因：X通常代表未知，而Marick也认为他的观点并不足以支撑一个模型的完整描述，但其中已经有一个模型所需要的一些主要内容，其中也包括了象探索性测试（exploratorytesting）这样的亮点。

10.PNG(26.92 KB)

2008-2-20 14:48

X模型示意图

       Marick对V模型的最主要批评是V模型无法引导项目的全部过程。他认为一个模型必须能处理开发的所有方面，包括交接，频繁重复的集成，以及需求文档的缺乏等等。

       Marick认为一个模型不应该规定那些和当前所公认的实践不一致的行为。X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终合成为可执行的程序。(右上半部分），这些可执行程序还需要进行测试。已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。
由上图中可见，X模型还定位了探索性测试（右下方）。这是不进行事先计划的特殊类型的测试，诸如“我这么测一下结果会怎么样？”，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。
然而，关注于这样的低级别的行为可能会引起不同的议论。一个模型和一个单独的项目计划有所不同。模型不应该描述每个项目的具体细节，模型应该对项目进行指导和支持。当然，代码的交接也可以简单地认为是一种集成的形式。而V模型也并没有限制各种创建周期的发生次数。

     Marick和Graham都一致认同，应该在执行测试之前进行测试设计。Marick建议：“在你掌握相关知识时进行设计，在你手头有交付内容时进行测试。”X模型包含了测试设计的步骤，就象使用不同的测试工具所要包含的步骤一样，而V模型没有这么做。但是，Marick的例子提示，X模型在这层意义上看也并不是一个真的模型，取而代之的是，应该允许在任何时候选择使用测试设计步骤。

       Marick对V模型提出质疑，也因为V模型基于一套必须按照一定顺序严格排列的开发步骤，而这很可能并没有反映实际的实践过程。
尽管很多项目缺乏足够的需求，V模型还是从需求处理开始。V模型提示我们要对各开发阶段中已经得到的内容进行测试，但它没有规定我们要取得多少内容。如果没有任何的需求资料，开发人员知道他们要做什么吗？我主张在X模型和其它模型中都需要足够的需求并至少进行一次发布。虽然在没有模型的情况下也必须正常工作，但一个有效的模型，可以鼓励很多好的实践方法的采用。因此，V模型的一个强项是它明确的需求角色的确认，而X模型没有这么做，这大概是X模型的一个不足之处。

      Marick也质疑了单元测试和集成测试的区别，因为在某些场合人们可能会跳过单元测试而热衷于直接进行集成测试。Marick担心人们盲目地跟随“学院派的V模型”，按照模型所指导的步骤进行工作，而实际上某些做法并不切合实用。我已经尽自己的努力把Marick的关于需要很多具有可伸缩性的行为的期望结合进了X模型，这样，X模型并不要求在进行作为创建可执行程序（图中右上方）的一个组成部分的集成测试之前，对每一个程序片段都进行单元测试（图中左侧的行为）。但X模型没能提供是否要跳过单元测试的判断准则。

      X模型填补了V模型和W模型的缺陷，并可为测试人员和开发人员带来明显的帮助。