软件测试V模型.docVIP

软件测试：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（本系列文章的另一位作者）进行过一场论争，并在其个人网站上对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模型在这层意义上看也并不是一个真的模型