2. 优点

　　自上而下单元测试法提供了一种软件集成阶段之前的较早的单元集成方法。实际上，自上而下单元测试法确实将单元测试和软件集成策略进行了组合。

　　在通常的结构化设计中，高等级的单元提供高层的功能，而低等级的单元实现细节，自上而下的单元测试将提供一种早期的“可见”的功能化集成。它给予单元测试一种必要的合理的实现途径。

　　较低层次的多余功能可以通过自上而下法来鉴别，这是因为没有路径来测试它。（但是，这可能在区分多余的功能和没有被测试的功能时带来困难）。

　　3. 缺点

　　自上而下法是通过桩模块来进行控制的，而且测试用例常常涉及很多的桩模块。对于每个已测单元来说，测试变得越来越复杂，结果是开发和维护的费用也越来越昂贵。

　　依层次进行的自上而下的测试，要达到一个好的覆盖结构也很困难，而这对于一个较为完善、安全的关键性应用来说至为重要，同时这也是很多的标准所要求的。难于达到一个好的覆盖结构也可能导致最终的多余功能和未测试功能之间的混乱。由此，测试一些低层次的功能，特别是错误处理代码，将彻底不切实。

　　一个单元的变化往往会影响对其兄弟单元和下层单元的测试。例如，考虑一下D单元一个变化。很明显，对D单元的单元测试不得不发生变化和重新进行。另外，要使用已测试单元D的E、F、G、H、I和J单元也不得不重新测试。作为单元D改变的结果，上述测试自身可能也不得不发生改变，即使单元E、F、G、H、I和J实际上并没有改变。这将导致当变化发生时，重复测试带来的高成本，以及高额的维护成本和高额的整个软件生产周期的成本。

　　在为自上而下测试法设计测试用例当中，当被测单元调用其他单元时需要测试人员具备结构化知识。被测试单元的顺序受限于单元的层次结构，低层次的单元必须要等到高层次的单元被测试后才能被测试，这样就形成了一个“又长又瘦”的单元测试阶段。（然而，这可能会导致测试详细设计与软件生命周期编码阶段的整体重叠。）

　　如图2.1所示的例子程序中各个单元之间的层次关系十分简单，在实际的编程过程中可能会遇到类似的情形，而且各个单元之间的层次关系会更复杂。所以自上而下测试法的缺点对单元测试造成的不利影响会随着被测单元之间复杂的联系而加深。

　　4. 总结

　　一个自上而下的测试策略成本将高于基于分离的测试策略，这取决于顶层单元下层单元的复杂程度，以及由于下层单元自身发生变化所带来的显著影响。对于单元测试来说自上而下的组织方法不是一个好的选择。然而，当各个组成单元已经被单独测试的情况下，用自上而下法进行单元的集成测试是个不错的手段。

　　自下而上法

　　1. 详述

　　在自下而上的单元测试中，被测单元与调用被测单元的单元是分开测试的，但是测试时所使用的是真实的被调用单元。

　　测试时最底层的单元首先被测试，这样就方便了对高层次单元的测试。然后使用前面已经被测试过的被调用单元来测试其他的单元。重复这个过程直到最高层的单元被测试为止。自下而上法需要测试驱动，但是不需要测试桩。

　　图3.1说明了测试D单元时需要的测试驱动和已测单元的情况，假设单元E、F、G、H、I和J已经通过自下而上法进行了测试。　　

图3.1 自下而上测试法

版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。