V模型问题分析[参照].pdfVIP

V 模型问题分析 文章出处：转载 作者： Brian Marick 著 Blueski 编译 发布时间： 2005-11-19 在本文中我要把 V 模型作为不好的模型的典型来进行分析。选择 V 模型作为分析的典 型是因为 V 模型是最广为人知的测试模型。 最典型的 V 模型版本一般会在其开始部分对软件开发过程进行描述，如下图所示： 图 1 V 模型的各级开发阶段 这是古老的瀑布模型。 作为开发模型， 它有很多侍猓 ? 还? 饫锊蛔魈致邸＞」 芩? 母髦 肿刺 ? 俏颐墙幼乓 ? 致鄣拇蠹易钍煜さ腣模型的基础。 我的批评意见同时也针对其它的装饰 在一些更好的开发模型之上的测试模型，例如螺旋模型 [Boehm88] 。 在 V 模型中，测试过程被加在开发过程的后半部分，如下图所示： 图 2 V 模型示意图 单元测试所检测代码的开发是否符合详细设计的要求。 集成测试所检测此前测试过的各 组成部分是否能完好地结合到一起。 系统测试所检测已集成在一起的产品是否符合系统规格 说明书的要求。而验收测试则检测产品是否符合最终用户的需求。 对于测试设计，显而易见的是， V 模型的用户往往会把执行测试与测试设计分开对待。 在开发文档准备就绪后， 就可以开始进行相关的测试设计。 如下图所示， 相应的测试设计覆 盖在了相关的开发过程之上： 图 3 将测试设计覆盖了开发过程后的 V 模型 V 模型有着很吸引人的对称外形， 并且把很多人都带入了歧途。 本文将集中讨论它在单 元测试和集成测试中引起的问题。 为了说明的方便， 这里专门制作了以下图片， 图中包括一个单独的单元， 以及一个单元 组，我称之为子系统（ subsystem ）。 图 4 一个假想的子系统 对于一个单元应该多大才最为合适的问题， 已经有过很多的讨论， 究竟一个单元仅仅是 一个函数， 一个类， 还是相关的类的集合？这些讨论并不影响我在这里所要阐述的观点。 我 们权且认为一个单元就是一个最小程度的代码块，开发人员可以对进行独立地讨论。 V 模型认为人们首先应该对每一个单元进行测试。 当子系统中所有的单元都已经测试完 毕，它们将被集中到一起进行测试，以验证它们是否可以构成一个可运行的整体。 那么， 如何针对单元进行测试呢？我们会查看在详细设计中对接口的定义， 或者查看源 代码，或者同时对两者进行查看， 找出符合某些测试设计中的有关准则的输入数据来进行输 入，然后检查结果， 看其是否正确。 由于各单元一般来说不能独立地运行， 所以我们不得不 另外设计桩模块（ Stub ）和驱动模块（ Driver ），如下图所示。 图 5 单元及其外部的驱动模块和桩模块 图中的箭头代表了测试的执行轨迹。这就是大多数人所说的“单元测试” 。我认为这样 的方法有时候是一种不好的方法。 同样的输入也可以有同一子系统中的其它单元来提供， 这样， 其它的单元既扮演了桩模 块，又扮演了驱动模块。如下图所示： 图 6 子系统内部各单元间的测试执行轨迹 到底选择哪一种方法，这需要一种折衷和权衡。设计桩模块和驱动模块要付出多少代 价？这些模块如何进行维护？子系统是否会由此而掩盖了一些故障？在整个子系统范围内 进行排错的困难程度有多大？如果我们的测试直到集成测试时才真正开始，那么一些 bug 可能较晚才