软件测试V模型

软件测试：V模型，还是X模型？作者：Robin F. Goldsmith 著 Blueski 编译X模型的目标是弥补V模型的一些缺陷。X模型真的能解决测试过程各方面的问 题，例如交接、经常性的集成？在软件测试方面，V模型是最广为人知的模型，尽管很多富有实际经验的测试人 员还是不太熟悉V模型，或者其它的模型。V模型已存在了很长时间，和瀑布 开发模型有着一些共同的特性，由此也和瀑布模型一样地受到了批评和质疑。在 软件测试：不可忽略的阶段中已经详细讨论了V模型，这里只作一个概要 的介绍。V模型中的过程从左到右，描述了基本的开发过程和测试行为。V模型的价值在 于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试 阶段和开发过程期间各阶段的对应关系。畫求分析验收测试要设计系统测试详31设计集廉测试编码 单元测试图1-V模型示意图在V模型中，单元测试是基于代码的测试，最初由开发人员执行，以验证其可 执行程序代码的各个部分是否已达到了预期的功能要求；集成测试验证了 2个或多个单元之间的集成是否正确，并有针对性地对详细设 计中所定义的各单元之间的接口进行检查；在所有单兀测试和集成测试完成后，系统测试开始以客户环境模拟系统的运行, 以验证系统是否达到了在概要设计中所定义的功能和性能； 最后，当技术部门完成了所有测试工作后，由业务专家或用户进行验收测试，以 确保产品能真正符合用户业务上的需要。尽管很多人对V模型表示了否定，但很少有人真正详细地讨论这些问题。Brian Marick (The Craft of Software Testing (Prentice Hall, 1995)一书的 作者)曾如此表示。在 STAR2000 (Software Testi ng An alysis and Review) 东部会议上，Marick曾经和Dorothy Graham (本系列文章的另一位作者) 进行过一场论争，并在其个人网站上对V模型提出过一些 中肯的反对意见。X模型Marick曾提出过一些观点和意见，其中首先是Marick不建议要建立一个替代 模型。这里我很冒昧地引用了一些Marick的想法，并重新经过组织，形成了X 模型。其实并不是为了和V模型相对应而选择这样的名字，而是由于其它一些 原因：X通常代表未知，而Marick也认为他的观点并不足以支撑一个模型的完 整描述，但其中已经有一个模型所需要的一些主要内容，其中也包括了象探索性 测试(exploratory testing)这样的亮点。我还需要在使用文字方面也向Marick 道歉，因为认同Marick观点的无疑大多属于X 一代(X代)。另外，我勾画 了一张X形状的示意图，我相信该图能够很好地以另一种表达形式来体现 Marick的观点。由于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 模型的缺陷，并可为测试人员和开发人员带来明显的帮助。