软件测试：V模型，还是X模型？
作者：Robin F. Goldsmith著 Blueski编译 本文选自：赛迪网 2003年02月14日

X模型的目标是弥补V模型的一些缺陷。X模型真的能解决测试过程各方面的问题，例如交接、经常性的集成？

在软件测试方面，V模型是最广为人知的模型，尽管很多富有实际经验的测试人员还是不太熟悉V模型，或者其它的模型。V模型已存在了很长时间，和瀑布开发模型有着一些共同的特性，由此也和瀑布模型一样地受到了批评和质疑。在《软件测试：不可忽略的阶段》中已经详细讨论了V模型，这里只作一个概要的介绍。

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



图1--V模型示意图


在V模型中，单元测试是基于代码的测试，最初由开发人员执行，以验证其可执行程序代码的各个部分是否已达到了预期的功能要求；

集成测试验证了2个或多个单元之间的集成是否正确，并有针对性地对详细设计中所定义的各单元之间的接口进行检查；

在所有单元测试和集成测试完成后，系统测试开始以客户环境模拟系统的运行，以验证系统是否达到了在概要设计中所定义的功能和性能；

最后，当技术部门完成了所有测试工作后，由业务专家或用户进行验收测试，以确保产品能真正符合用户业务上的需要。

尽管很多人对V模型表示了否定，但很少有人真正详细地讨论这些问题。Brian Marick（《The Craft of Software Testing (Prentice Hall, 1995)》一书的作者）曾如此表示。在STAR2000 (Software Testing Analysis and Review) 东部会议上，Marick曾经和Dorothy Graham（本系列文章的另一位作者）进行过一场论争，并在其个人网站www.testing.com上对V模型提出过一些中肯的反对意见。

X模型


Marick曾提出过一些观点和意见，其中首先是Marick不建议要建立一个替代模型。这里我很冒昧地引用了一些Marick的想法，并重新经过组织，形成了“X模型”。其实并不是为了和V模型相对应而选择这样的名字，而是由于其它一些原因：X通常代表未知，而Marick也认为他的观点并不足以支撑一个模型的完整描述，但其中已经有一个模型所需要的一些主要内容，其中也包括了象探索性测试（exploratory testing）这样的亮点。我还需要在使用文字方面也向Marick道歉，因为认同Marick观点的无疑大多属于X一代（X一代）。另外，我勾画了一张X形状的示意图，我相信该图能够很好地以另一种表达形式来体现Marick的观点。



图2--X模型示意图


由于X模型从没有被文档化，其内容一开始需要从在V模型的相关内容中进行推断，这在Marick的相关文章中已有体现。这里关于X模型的论述比较简短，因为它还没有完全从文字上成为V模型的全面扩展，而且我不想在这里重复在《软件测试：不可忽略的阶段》文章中所提到的很多测试技术的概念。

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


解决交接和频繁集成的周期的问题


Marick认为一个模型不应该规定那些和当前所公认的实践不一致的行为。我也很认同这一点。X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终合成为可执行的程序。(右上半部分），这些可执行程序还需要进行测试。已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。

由上图中可见，X模型还定位了探索性测试（右下方）。这是不进行事先计划的特殊类型的测试，诸如“我这么测一下结果会怎么样？”，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。Marick虽然没有对此进行明确的说明，但一定很乐意看到该方法的界定。

然而，关注于这样的低级别的行为可能会引起不同的议论。一个模型和一个单独的项目计划有所不同。模型不应该描述每个项目的具体细节，模型应该对项目进行指导和支持。当然，代码的交接也可以简单地认为是一种集成的形式。而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模型可能会提倡付出额外的努力来进行更多的实践行为。同样的，也可以因为喜欢集成测试而选择跳过单元测试，但其价值可能有一些虚幻的成分在，因为一般来说，在单元测试中发现问题进行解决的代价较小，而在集成测试中发现问题所付出的代价要大得多。

一个代表落后的实践的模型，其存在仅仅是因为它是普通的、常见的，这样的模型只能简单地保证以后我们可以维持落后的实践的重复，而不对改进作出变化。人们甚至还认为落后的实践不但是难以避免的，而且还是必然的，并终于拒绝把改进作为一种美德。

例如，开发者有时并不真正去研究如何更好地定义用户的业务需求，而是简单地认为这样的工作是不现实的，因为“用户并不真正知道他们要什么”，或者认为“需求始终是要变化的”。于是，这些开发人员可能进一步宣称不了解需求的做法是合理可行的，因为他们可以使用一些更高级的做法，例如原型法。虽然这样的技术对确认需求，达成理解上的一致是有用的，但实际上这不是一条直接通向编码的捷径。这种情况下，编码是非常低效的、要耗费很多工作量来发现真正的用户业务需求。从项目总体计划方面来看，采用迭代方法以及一些更直接的发现需求的方法会显得更有价值。

同样的，X模型及其探索性测试的提倡也是为了避免把大量时间花费在测试文档编写上面，那样的话，真正用于测试的时间就减少了。（不知道为什么，有些测试专家似乎并不把撰写测试计划视为一种美德。我可能是最后一个鼓励写文档和填写一些表格的人，我认为这其中自有价值。我曾经看到过很多存在大量冗余的测试计划文档的例子，这些计划并不值得花那么多时间来写。但这并不说明写测试计划是一件不好的行为，应该说写很糟糕的测试计划才是一件不好的行为。在另一方面，把重要信息写下来，可以取得数倍的回报。这可以使我们更加全面了解，避免遗忘，实现更多的共享。

在此后的2篇文章中，我将揭示合理的结构是如何在实际项目中使软件开发变得更快，成本更低，效果更好的，并将展示我称之为“前置测试”的模型，我的客户、学生和我本人都觉得该模型具有实用价值。我相信该模型填补了V模型和X模型的缺陷，并可为测试人员和开发人员带来明显的帮助。

http://developer.ccidnet.com/pub/ar..._a37975_p1.html
（责任编辑 Sunny）

关于“h模型”的一些信息

h模型的示意图仅仅演示了在整个生产周期中，某个（测试）层次上的一次测试“微循环”。图中的“其他流程”可以是任意的开发流程，例如设计流程和编码流程，也可以是其他非开发流程，甚至是测试流程自身。向上的三
角箭头表示，在某个时间点，由于“其他流程”的进展而（由于先后关系）引发或者（由于因果关系）触发了测试就绪点，这个时候，只要测试准备活动完成，测试执行活动就可以（或者说，需要）进行了。
概括而言，h模型揭示了
1、 软件测试不仅仅指测试的执行，还包括很多其他的活动；
2、 软件测试是一个独立的流程，贯穿产品的整个周期，与其他流程并发的进行；
3、 软件测试要尽早准备，尽早执行；
4、 软件测试根据被测物的不同是分层次的，不同层次的测试活动可以是按照某个次序先后进行的，也可能是反复的。

采用h测试模型的三个理由
1、有利于测试的分工，从而降低成本，提高效率。
首先，h模型强调软件测试准备和测试执行分离。准备阶段和执行阶段有不同的测试活动，例如，测试准备活动，包括测试需求分析、测试计划、测试分析、测试编码、测试验证等等，而测试执行活动，则包括测试运行、测试报
告、测试分析等等。准备阶段和执行阶段有不同的工作侧重点，不同的测试活动也需要不同的知识和技能。显而易见，测试的设计人员比执行人员有更高的能力要求，不同的岗位可以聘用不同的人员。如果一个测试设计人员同时
被指派去执行测试，那既是人力资源的浪费，也可能挫伤设计人员的创造性合积极性。所以，软件测试分工带来的第一个直接好处就是降低人力成本。第二个直接好处就是提高效率。分工带来的间接的长期的好处是，软件测试可
以成为一个有职业前景的职位，这有利于吸引人才以此作为自己的职业生涯，从而形成软件测试领域的人力积累和良性循环。
2、有利于认识到测试的复杂性，从而赢得重视和尊重。
H模型可以促使人们充分认识到软件测试的复杂性。这儿的复杂不是指技术上的复杂，而是指过程上的复杂。正如传统的软件开发被简化为编程一样，软件测试也常常被简化为运行一下被测的软件，观察是否有异常的运行结果
。软件测试也有不同的阶段，有不同的活动，而且这些阶段和活动要被组成一个系统才能有效的运作。没有组织的，非结构化的软件测试除了浪费时间和金钱外，几乎不可能有实质性的产出。认识到复杂性才可能得到足够的重视
和必要的尊重。重视主要来自于管理层，而尊重则主要来自于平行的其它流程的人员，例如编程人员。尽管测试流程是一个独立的流程，但它必须被置于整个软件生产的流程系统中，作为一个有机的组成部分，并与其它流程有效
的交互，才可能发挥作用。
3、有利于了解测试投入的去向，从而得到测试效益的公正评判。
第三个理由与一个长期存在的“测试怪圈”有关。测试经理总是抱怨测试上投入不够；测试人员要么被看作是“无所事事”，要么被看作“忙而无功”；而管理层则因为测试上的投入没有一个可视的结果而拒绝加大投入；更糟
糕的是，用户在投诉软件的质量问题，组织的声誉和利润都每况愈下。H模型并不能扭转这种糟糕的局面，但它有助于跟踪测试投入的流向，例如，在各个测试活动上的投入分别有多少，比例是否合理，哪些是用于测试准备的，
而如果由于其它流程的差错导致重做准备，那么浪费的投入有多少。在h模型中，测试是一个有组织的、结构化的独立流程，既保证了自身的有序和结构清晰，也保证了流程之间的“界面”清晰。这样，软件测试就不是一笔糊涂
帐，才可能得到公正的投入-产出的评判，软件测试才可能避免成为“出气筒”和“替罪羊”的“宿命”。

螺旋式测试模型


它分别对应开发的：
测试计划： Plan /Analysis
测试用例设计： Design
测试开发： Coding
测试执行和评估： Test/Deliver