软件测试：V模型问题分析[3] 软件测试
到底选择哪一种方法，这需要一种折衷和权衡。设计桩模块和驱动模块要付出多少代价?这些模块如何进行维护?子系统是否会由此而掩盖了一些故障?在整个子系统范围内进行排错的困难程度有多大?如果我们的测试直到集成测试时才真正开始，那么一些bug可能较晚才被发现。由此造成的代价同设计桩模块和驱动模块的代价如何比较?
V模型没有去考虑这些问题，当单元开发完成后就执行单元测试，而当自系统被集中在一起后就执行集成测试，仅此而已。令我奇怪和沮丧的是，人们从不去做一些权衡，他们已经受制于他们的模型。
因此，一个有用的模型应该允许测试人员考虑节省并推迟测试的可能性。
一个测试，如果要发现一个特定的单元中的bug，最好是在该单元保持独立的情况下执行，并且在其外部辅以特定的桩模块和驱动模块。而另一种方法则是让它作为子系统的一部分来进行测试，该测试的设计主要是为了发现集成的问题。由于一个子系统本身也需要桩模块和驱动模块来模拟该子系统和其它子系统的联系，因此，单元测试和集成测试可能被推迟到至少整个系统已经部分集成的时候。在这种情况下，测试者可能通过产品的外部接口同时进行单元测试、集成测试和系统测试，同样的，其主要目的还是为了减少总体生命周期的成本，对测试成本和延期进行测试及由此造成延期发现bug的代价成本进行权衡。据此而言，"单元测试"、"集成测试"和"系统测试"的区别已经大大削弱了。其结果可参考下图：
图7 新的方法：在部分阶段延迟进行单元测试和集成测试
在上图右边的方块中，最好要改成为“执行某些适当的测试并得到相应的结果”。
图中的左边会怎样?考虑一下系统测试设计，它的主要根据和信息来源是是规格说明。假设你知道有2个单元处在一个特定的子系统中，它们在运行时相互联系，并且要执行规格说明中的一个特定的声明。为什么不在该子系统被集成时立即对此规格说明中的声明进行测试，就象是在设计完成后立即开始测试的设计一样呢?如果该声明的执行和子系统外的子系统没有任何关系，为什么还要等到整个系统完成以后再测试呢?难道越早发现bug成本越低不对吗?
在上一张图片中，我们用了向上指的箭头(更有效，但在时间上有延迟)。这里还可以把箭头往下指(在时间上提前)：
图8 新的方法：在不同阶段上提前进行测试设计
文章来源于领测软件测试网 https://www.ltesting.net/