软件测试：V模型，还是X模型？
作者：Robin F. Goldsmith著 Blueski编译
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模型的缺陷，并可为测试人员和开发人员带来明显的帮助。
