2010年软考软件评测师软件测试流程及步骤(5)2

  一个假想的子系统

　　对于一个单元应该多大才最为合适的问题，已经有过很多的讨论，究竟一个单元仅仅是一个函数，一个类，还是相关的类的集合?这些讨论并不影响我在这里所要阐述的观点。我们权且认为一个单元就是一个最小程度的代码块，开发人员可以对进行独立地讨论。

　　V模型认为人们首先应该对每一个单元进行测试。当子系统中所有的单元都已经测试完毕，它们将被集中到一起进行测试，以验证它们是否可以构成一个可运行的整体。

　　那么，如何针对单元进行测试呢?我们会查看在详细设计中对接口的定义，或者查看源代码，或者同时对两者进行查看，找出符合某些测试设计中的有关准则的输入数据来进行输入，然后检查结果，看其是否正确。由于各单元一般来说不能独立地运行，所以我们不得不另外设计桩模块(Stub)和驱动模块(Driver)，如下图所示。

　　 单元及其外部的驱动模块和桩模块

　　图中的箭头代表了测试的执行轨迹。这就是大多数人所说的"单元测试"。我认为这样的方法有时候是一种不好的方法。

　　同样的输入也可以有同一子系统中的其它单元来提供，这样，其它的单元既扮演了桩模块，又扮演了驱动模块。如下图所示：

　　子系统内部各单元间的测试执行轨迹

　　到底选择哪一种方法，这需要一种折衷和权衡。设计桩模块和驱动模块要付出多少代价?这些模块如何进行维护?子系统是否会由此而掩盖了一些故障?在整个子系统范围内进行排错的困难程度有多大?如果我们的测试直到集成测试时才真正开始，那么一些bug可能较晚才被发现。由此造成的代价同设计桩模块和驱动模块的代价如何比较?

　　V模型分析< 2>

　　V模型没有去考虑这些问题，当单元开发完成后就执行单元测试，而当自系统被集中在一起后就执行集成测试，仅此而已。令我奇怪和沮丧的是，人们从不去做一些权衡，他们已经受制于他们的模型。

　　因此，一个有用的模型应该允许测试人员考虑节省并推迟测试的可能性。

　　一个测试，如果要发现一个特定的单元中的bug，最好是在该单元保持独立的情况下执行，并且在其外部辅以特定的桩模块和驱动模块。而另一种方法则是让它作为子系统的一部分来进行测试，该测试的设计主要是为了发现集成的问题。由于一个子系统本身也需要桩模块和驱动模块来模拟该子系统和其它子系统的联系，因此，单元测试和集成测试可能被推迟到至少整个系统已经部分集成的时候。在这种情况下，测试者可能通过产品的外部接口同时进行单元测试、集成测试和系统测试，同样的，其主要目的还是为了减少总体生命周期的成本，对测试成本和延期进行测试及由此造成延期发现bug的代价成本进行权衡。据此而言，"单元测试"、"集成测试"和"系统测试"的区别已经大大削弱了。其结果可参考下图：

　　 新的方法：在部分阶段延迟进行单元测试和集成测试