級的單元提供高層的功能，而低等級的單元實現細節，自上而下的單元測試將提供一種早期
的“可見”的功能化集成。它給予單元測試一種必要的合理的實現途徑。較低層次的多余功能
可以通過自上而下法來鑒別，這是因為沒有路徑來測試它。(但是，這可能在區分多余的功
能和沒有被測試的功能時帶來困難)。
3. 缺點
自上而下法是通過樁模塊來進行控制的，而且測試用例常常涉及很多的樁模塊。對于每個已
測單元來說，測試變得越來越復雜，結果是開發和維護的費用也越來越昂貴。依層次進行的
自上而下的測試，要達到一個好的覆蓋結構也很困難，而這對于一個較為完善、安全的關鍵
性應用來說至為重要，同時這也是很多的標準所要求的。難于達到一個好的覆蓋結構也可能
導致最終的多余功能和未測試功能之間的混亂。由此，測試一些低層次的功能，特別是錯誤
處理代碼，將徹底不切實際。
一個單元的變化往往會影響對其兄弟單元和下層單元的測試。例如，考慮一下D 單元一個變
化。很明顯，對D 單元的單元測試不得不發生變化和重新進行。另外，要使用已測試單元D
的E、F、G、H、I 和J 單元也不得不重新測試。作為單元D 改變的結果，上述測試自身可能
也不得不發生改變，即使單元E、F、G、H、I 和J 實際上并沒有改變。這將導致當變化發生
時，重復測試帶來的高成本，以及高額的維護成本和高額的整個軟件生產周期的成本。
在為自上而下測試法設計測試用例當中，當被測單元調用其他單元時需要測試人員具備結構
化知識。被測試單元的順序受限于單元的層次結構，低層次的單元必須要等到高層次的單元
被測試后才能被測試，這樣就形成了一個“又長又瘦”的單元測試階段。(然而，這可能會導
致測試詳細設計與軟件生命周期編碼階段的整體重疊。)如圖2.1 所示的例子程序中各個單
元之間的層次關系十分簡單，在實際的編程過程中可能會遇到類似的情形，而且各個單元之
間的層次關系會更復雜。所以自上而下測試法的缺點對單元測試造成的不利影響會隨著被測
單元之間復雜的聯系而加深。
4. 總結
文章來源于領測軟件測試網 http://www.kjueaiud.com/
