软件测试的新模型(2)

　　(图5：单元及其外部的驱动模块和桩模块)

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

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

　　(图6--子系统内部各单元间的测试执行轨迹)

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

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

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

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

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

　　在上图右边的方块中，最好要改成为“执行某些适当的测试并得到相应的结果”。

　　图中的左边会怎样?考虑一下系统测试设计，它的主要根据和信息来源是是规格说明。假设你知道有2个单元处在一个特定的子系统中，它们在运行时相互联系，并且要执行规格说明中的一个特定的声明。为什么不在该子系统被集成时立即对此规格说明中的声明进行测试，就象是在设计完成后立即开始测试的设计一样呢?如果该声明的执行和子系统外的子系统没有任何关系，为什么还要等到整个系统完成以后再测试呢?难道越早发现bug成本越低不对吗?

　　在上一张图片中，我们用了向上指的箭头(更有效，但在时间上有延迟)。这里还可以把箭头往下指(在时间上提前)：

　　(图8--新的方法：在不同阶段上提前进行测试设计)

　　在这种情况下，左边的方块中最好被标记为：“在当前信息条件和情况下可以做的任何测试设计”。这样，当测试设计得自于系统中某一个组件的描述时，模型必须允许这样的测试在组件被装配之前被执行。我必须承认我的图片非常难看，这些箭头指得到处都是，对此我有2点说明：

　　1. 我们所讨论的事情不是创造美，而是想要发现尽可能多的严重错误，同时尽可能地降低成本。

　　2. 难看的部分原因也是因为必须按照某些次序来执行的结果，亦即开发人员先提供系统描述文档，然后测试和这些文档进行关联。这些文档就象是坚实的老橡树，而测试设计则象是细细的枝条缠绕在树上。如果我们采用不同的原理来进行组织，图片可能就会变得好看些。但复杂性仍不可避免，因为我们要讨论的问题本身就很复杂。

　　V模型失败的原因是它把系统开发过程划分为具有固定边界的不同阶段，这使得人们很难跨过这些边界来采集测试所需要的信息。有些测试应该执行得更早些，有些测试则需要延后进行。而且，它也阻碍了你从系统描述的不同阶段中取得信息进行综合。例如，某些组织有时执行这样的做法，即对完成的工作进行签署。这样的规定也扩展到系统测试的设计。签署表示已经过评估，该测试设计工作已经完成，除非对应的设计文档改变，否则就不会被修订。如果同这些测试相关的信息后来被重新挖掘和认识，例如，架构设计表明有些测试是多余的，或者，详细设计表明有一个内部的边界可以和已存在的系统测试组合在一起进行测试的话，那么实际上还需要继续调整原来的系统测试设计。

原文转自：http://www.uml.org.cn/Test/test47.htm