级的单元提供高层的功能，而低等级的单元实现细节，自上而下的单元测试将提供一种早期
的“可见”的功能化集成。它给予单元测试一种必要的合理的实现途径。较低层次的多余功能
可以通过自上而下法来鉴别，这是因为没有路径来测试它。(但是，这可能在区分多余的功
能和没有被测试的功能时带来困难)。
3. 缺点
自上而下法是通过桩模块来进行控制的，而且测试用例常常涉及很多的桩模块。对于每个已
测单元来说，测试变得越来越复杂，结果是开发和维护的费用也越来越昂贵。依层次进行的
自上而下的测试，要达到一个好的覆盖结构也很困难，而这对于一个较为完善、安全的关键
性应用来说至为重要，同时这也是很多的标准所要求的。难于达到一个好的覆盖结构也可能
导致最终的多余功能和未测试功能之间的混乱。由此，测试一些低层次的功能，特别是错误
处理代码，将彻底不切实际。
一个单元的变化往往会影响对其兄弟单元和下层单元的测试。例如，考虑一下D 单元一个变
化。很明显，对D 单元的单元测试不得不发生变化和重新进行。另外，要使用已测试单元D
的E、F、G、H、I 和J 单元也不得不重新测试。作为单元D 改变的结果，上述测试自身可能
也不得不发生改变，即使单元E、F、G、H、I 和J 实际上并没有改变。这将导致当变化发生
时，重复测试带来的高成本，以及高额的维护成本和高额的整个软件生产周期的成本。
在为自上而下测试法设计测试用例当中，当被测单元调用其他单元时需要测试人员具备结构
化知识。被测试单元的顺序受限于单元的层次结构，低层次的单元必须要等到高层次的单元
被测试后才能被测试，这样就形成了一个“又长又瘦”的单元测试阶段。(然而，这可能会导
致测试详细设计与软件生命周期编码阶段的整体重叠。)如图2.1 所示的例子程序中各个单
元之间的层次关系十分简单，在实际的编程过程中可能会遇到类似的情形，而且各个单元之
间的层次关系会更复杂。所以自上而下测试法的缺点对单元测试造成的不利影响会随着被测
单元之间复杂的联系而加深。
4. 总结
文章来源于领测软件测试网 https://www.ltesting.net/
