自頂向下測試：是從程式的初始模組開始測試。
（1）在早期發現頂層的錯誤。
（2）早期的程式框架可以進行演示
（3）需要開發樁模組輔助測試。有些甚至需要多個樁模組輔助，加大了樁模組本來的錯誤影響。
（4）測試完乙個上層模組後，挑選哪個模組作為下乙個測試模組，以及測試的順序沒有唯一的界定標準。
優點：較早地驗證了主要控制和判斷點；按深度優先可以首先實現和驗證乙個完整的軟體功能；功能較早證實，帶來信心；只需乙個驅動，減少驅動器開發的費用；支援故障隔離。
缺點：柱的開發量大；底層驗證被推遲；底層元件測試不充分。
自底向上測試：是從程式的底層模組開始測試。
（1）i/o操作可以提前測試，更好提交測試用例。
（2）測試後比較容易觀察輸出。
（3）需要開發驅動模組。
（4）直到最後乙個模組提交，程式才能完整的系統測試。
優點：對底層元件行為較早驗證；工作最初可以並行整合，比自頂向下效率高；減少了樁的工作量；支援故障隔離。
缺點：驅動的開發工作量大；對高層的驗證被推遲，設計上的錯誤不能被及時發現。
增量測試 自頂向下測試 自底向上測試
本部落格主要內容 自頂向下測試和自底向上測試的優缺點 軟體開發周期流程 不同的測試方法針對不同的測試階段 一 自頂向下測試 優點 1 如果主要的缺陷發生在程式的頂層將非常有利 2 一旦引入i o功能，提交測試或更容易 3 早期的程式框架可以進行演示，並可激發積極性 缺點 1 必須開發樁模組 2 樁模...
自底向上和自頂向下
動態規劃的式子都是狀態p由狀態q1 q2 q3 之中選擇乙個或幾個計算出來的形式，但是如果一直是一些狀態這樣遞迴下去，最後會無限迴圈的，所以每個式子一直寫下去最後都會得到一些狀態p是常數 遞迴邊界 的形式。以上可構造乙個dag 自底向上就是已經知道了所有遞迴邊界，把所有可能的狀態都算出來。基本步驟是...
自頂向下和自底向上理解程式設計
example 客戶端程式如何從服務端取資料？自頂向下理解 客戶端想要動態地獲取資料 比如使用者手勢 點選等事件觸發 通過呼叫服務即可 如wcf service,rest service domainservice 等 取到資料後 如json 反序列化到客戶端相應的model類中 而服務幫助我們完成...