软件测试：V模型问题分析[2] 软件测试
V模型有着很吸引人的对称外形，并且把很多人都带入了歧途。本文将集中讨论它在单元测试和集成测试中引起的问题。
为了说明的方便，这里专门制作了以下图片，图中包括一个单独的单元，以及一个单元组，我称之为子系统(subsystem)。
图4 一个假想的子系统
对于一个单元应该多大才最为合适的问题，已经有过很多的讨论，究竟一个单元仅仅是一个函数，一个类，还是相关的类的集合?这些讨论并不影响我在这里所要阐述的观点。我们权且认为一个单元就是一个最小程度的代码块，开发人员可以对进行独立地讨论。
V模型认为人们首先应该对每一个单元进行测试。当子系统中所有的单元都已经测试完毕，它们将被集中到一起进行测试，以验证它们是否可以构成一个可运行的整体。
那么，如何针对单元进行测试呢?我们会查看在详细设计中对接口的定义，或者查看源代码，或者同时对两者进行查看，找出符合某些测试设计中的有关准则的输入数据来进行输入，然后检查结果，看其是否正确。由于各单元一般来说不能独立地运行，所以我们不得不另外设计桩模块(Stub)和驱动模块(Driver)，如下图所示。
图5 单元及其外部的驱动模块和桩模块
图中的箭头代表了测试的执行轨迹。这就是大多数人所说的“单元测试”。我认为这样的方法有时候是一种不好的方法。
同样的输入也可以有同一子系统中的其它单元来提供，这样，其它的单元既扮演了桩模块，又扮演了驱动模块。如下图所示：
图6 子系统内部各单元间的测试执行轨迹
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/