軟體工程第六版 第十三章 測試策略

1. 軟體工程第六版第十三章 測試策略

2. 軟體測試的策略 • 軟體測試的策略將軟體測試案例設計方法整合到一系列規劃良好的步驟中，以得到成功的軟體建構。 • 策略提供一個路線圖(road map)以描述被導入做為測試一部分的步驟、這些步驟何時被計畫並著手進行，和需要多少努力、時間與資源。 • 任何測試策略必須要合併測試計畫、測試案例設計、測試執行和結果資料的蒐集與評估。

3. 軟體測試的策略 • 一個軟體測試策略應該有足夠的彈性以促進某種客製化的測試方式。 • 當計畫進展時，必須要夠嚴謹以促進合理的計畫與管理追蹤。 • Shooman討論這些議題時說道： • 測試是一種個人化的流程，而不同測試類型的數量變化就像發展方法一樣多。 • 多年來，我們防護程式設計的錯誤只是很小心的設計與靠程式設計師的智慧。 • 現代設計的技術(和正式的技術檢視)可以協助我們減少繼承程式碼而來的初期錯誤數量。 • 不同的測試方法正在開始群集它們自己到某些較為顯著的方式與哲學。 • 這些「方式與哲學」就是我們所稱的策略(strategy)。 • 第14章中會說明軟體測試的技術。 • 本章聚焦於軟體測試的策略。

4. 快速瀏覽 • 它是什麼？　 • 軟體被測試是要揭開在它設計與建構時所不經意產生的錯誤。 • 但是你要如何主導測試呢？ • 你應該為你的測試發展正式的計畫嗎？ • 你應該測試整個程式或只是其中的一小部分？ • 當你將新的元件加入一個大系統時，應該重做你已經導入過的測試嗎？ • 你何時應該涉及到顧客？ • 當你發展軟體測試策略時，這些與其他許多的問題都是要回答的。

5. 快速瀏覽 • 誰完成它？　 • 軟體測試的策略是由專案經理、軟體工程師和測試專家所共同發展的。 • 它為何重要？　 • 測試時常要對比其他任何軟體工程活動投入更多的專案努力。如果它隨意地被導入，不但浪費時間與花費不必要的努力，甚至更糟的是未發現隱藏錯誤。因此，建立一套系統化策略的測試軟體似乎是合理的。

6. 快速瀏覽 • 步驟為何？　 • 測試從「小的」開始，並且進展到「大的」。由此我們意味著早期的測試聚焦於單一元件或一小群相關的元件，並且應用測試揭發資料和已經含括於元件中的處理邏輯錯誤。在元件測試後，它們必須要整合，直到完整的系統被建構。此時，執行一系列高階的測試以在符合顧客的需求中發現錯誤。當錯誤揭發時，它們必須使用稱為除錯的流程診斷與修正。 • 工作產品為何？　 • 測試規格(Test Specification)記載軟體團隊藉由定義一個描述整體策略、一個定義特定測試步驟和將被導入的測試程序的測試方式。

7. 快速瀏覽 • 我如何確定我所做的是正確的？　 • 藉由在測試之前檢視測試規格，你可以評估測試案例與測試任務的完整性。有效的測試計畫與程序將導致有條理地建構軟體，並在建構流程中每一個階段錯誤的發現。

8. 13.1 軟體測試的策略方法 • 測試是可以預先計畫與系統化導入的一組活動。 • 軟體測試的樣版 - 我們可以放置特定的測試案例技術與測試方法的一組步驟 - 應該為軟體流程而定義。 • 許多軟體測試策略都提供軟體開發者樣版做為測試，且全部都具有下列的一般特性： • 執行有效的測試，一個軟體團隊應該主導有效的正規技術檢視。 • 藉由執行此一檢視，許多錯誤將會在測試開始前就先被消除。 • 測試由元件層級開始，並「向外」朝著整個以電腦為基礎系統的整合。 • 不同的測試技術適用在不同的時間點上。 • 測試由軟體的開發者與獨立的測試群組所導入(對於大的計畫)。 • 測試與除錯是不同的活動，但是除錯必須被容納在任何的測試策略中。

9. 軟體測試的策略範圍 • 軟體測試的策略必須要容納所必須要驗證的一小段原始碼已經正確地實作的低階測試，和以顧客的需求驗證主要系統功能的高階測試。 • 策略必須要對從業人士提供指導，並為經理人提供一組里程碑。 • 因為當截止日期的壓力開始上升時，測試策略的步驟就會出現，進展必須是可量測的，且問題必須要盡快浮現。

10. 13.1.1　驗證與確認 • 軟體測試是廣泛主題中的一項元素，它時常是以驗證與確認(verification and validation, V&V)而被提到。驗證(verification)依據活動組以確保軟體正確地實作特定的功能。確認(validation)依據一個不同的活動組以確保已建構的軟體對顧客的需求是可追蹤的1。Boehm [BOE81] 以另一種方法說明： • 驗證：我們正確地建構產品嗎？ • 確認：我們建構正確的產品嗎？ • V&V的定義含括許多在軟體品質保證(software quality assurance, SQA)中的活動。

11. 驗證與確認的活動內容 • 驗證與確認含括廣泛的SQA活動，它們包括正式的技術檢視、品質與組態審核、效能監控、模擬、可行性研究、文件檢視、資料庫檢視、演算法分析、發展測試、可用性測試、限定條件(qualification)測試和安裝測試。 • 測試確實提供最後的堡壘，其中的品質可被評估，錯誤可以被揭發。 • 測試不應該被視為一張安全網。 • 當他們說：「你不能測試品質。如果在你開始測試前，它不在那裡的話，則在你完成測試後，它也不會在那裡。」 • 品質被併入到遍及整個軟體工程流程的軟體中。 • 適當的方法與工具的應用、有效的正式技術檢視和穩固的管理與量測，全部都會導致在測試期間被確認的品質。

12. 品質保證的軟體測試 • Miller陳述相關品質保證的軟體測試： • 「程式測試的底層動機是以方法證實軟體的品質，此方法可經濟與有效地應用於大小規模的系統。」

13. 13.1.2 軟體測試的組織 • 對於每一個軟體專案，測試的開始都有一個與生俱來的利益衝突發生。 • 已經建構軟體的人現在都被要求測試其軟體。這似乎對本身也無任何害處；畢竟，誰會比開發者更為瞭解此程式呢？ • 不幸地，這些相同的開發者在展示程式是沒有錯誤的時候，是存有既定利益的，它依照顧客的需求進行，且在期限與預算內完成。 • 這些利益的每一項都與測試是衝突的。

14. 軟體測試的心理學觀點 • 從心理學的觀點來看，軟體分析與設計(連同編碼)是有建設性的工作。 • 軟體工程師分析、塑模，然後產生一支電腦程式與它的文件。 • 就像任何的建構者，軟體工程師對所建造的雄偉建築感到驕傲，並且斜眼瞄著任何一個試圖想要拆毀它的人。 • 當測試出現，就會有一個難以捉摸但很明確要「毀壞」軟體工程師所建造事物的企圖。 • 從建構者的觀點來看，測試可被視為(精神上)破壞性的。 • 建構者輕輕地踐踏，設計與執行的測試都展示出程式是可以工作的，而並非是揭發錯誤。 • 不幸地，錯誤還是會出現。 • 如果軟體工程師沒有發現它們，顧客則會找到的！

15. 測試的錯誤推論 • 從前述的討論中經常會有一些錯誤的概念被錯誤地推論： • 軟體的開發者一點都不應該做測試。 • 軟體應該「丟過牆壁」給陌生人進行毫無仁慈的測試。 • 測試者只在測試的相關步驟開始時才參與專案。 • 這些陳述的每一個都是不正確的。 • 軟體開發者總是負責測試程式的個別單位(元件)，以確保每個都實行功能或展現為它所設計的行為。 • 在許多情形中，開發者也導入整合測試 - 一個導致完整軟體架構建構(與測試)的測試步驟。 • 只有在軟體結構完成之後，一個獨立的測試群組才會參與。

16. 獨立測試群組 • 獨立測試群組(independent test group, ITG)的角色是排除讓建構者測試已經建造事物的原有問題。 • 獨立測試除去其他方面可能的利益衝突。 • ITG的員工是付錢請來發現錯誤的。 • 軟體工程師並不是將程式交給ITG就可安然脫身。 • 開發者與ITG在整個軟體工作期間緊密地工作在一起，以確保導入徹底的測試。 • 當測試導入時，開發者必須要有效地修正被揭發出的錯誤。 • ITG是軟體開發專案團隊的一部分。他在分析與設計期間參與，並在整個大型專案內持續參與(計畫與指明測試程序)。 • 在許多情形中ITG將向軟體品質保證組織報告，因此達成某個程度的獨立性，這是做為軟體工程的一部分組織所不可能達到的。

17. 13.1.3 傳統軟體架構的軟體測試策略 • 軟體流程可視為如圖13.1中所例舉的螺旋形。 • 最初，系統工程定義軟體的角色，並在資訊領域、功能、行為、效能、侷限因素和確認軟體建立的標準中導引軟體的需求分析。 • 沿著螺旋形向內移動，我們來到設計並抵達最後的編碼。 • 為了開發電腦軟體，我們沿著螺旋狀的流線型向內，每一次轉向都會降低抽象化的程度。

18. 圖13.1 測試策略

19. 軟體測試的策略 • 軟體測試的策略也可以視為螺旋形(圖13.1)的環境。 • 單元測試(unit testing)從螺旋形的漩渦開始，並聚焦在被實作成原始碼的每一個軟體單元(即元件)。 • 測試沿著螺旋形向外移動進展到整合測試(integration testing)，在此的焦點為設計與軟體架構的建構。 • 朝著螺旋形向外轉一圈，我們遇到確認測試(validation testing)，在此建立做為軟體需求分析一部分的需求對照著已經建構的軟體進行確認。 • 最後，我們來到系統測試(system testing)，在此對軟體與其他的系統元素進行整體測試。 • 要測試電腦軟體，我們沿著螺旋形線流向外，每一次轉向都會擴大測試的範圍。

20. 軟體工程環境中的測試步驟 • 軟體工程環境中的測試實際上是持續實作的一系列四個步驟。此步驟顯示於圖13.2中。 • 最初，測試聚焦在每一個個別的元件，以確保它是一個可適當運作的單元。 • 單元測試運用大量的測試技術，在元件的控制結構中操練指定的路徑，以確保完全地涵蓋與偵測出最多的錯誤。接著，元件必須要組裝或整合成完整的軟體套件(package)。 • 整合測試針對結合驗證與程式建構的雙重問題。 • 雖然操練指定程式路徑的技術可以確保主要控制路徑的涵蓋，聚焦在輸入與輸出的測試案例設計技術在整合期間則更為普遍。

21. 軟體工程環境中的測試步驟 • 在軟體整合(建構)之後，一組高階的測試被導入。 • 確認標準(在需求分析期間所建立的)必須要被評估。 • 確認測試提供最後的保證使軟體符合所有功能的、行為的和效能的需求。 • 最後的高階測試步驟落在軟體工程的界限外，並進入電腦系統工程更為廣闊的環境中。 • 一旦確認，軟體必須與其他的系統元素結合(例如，硬體、人、資料庫)。 • 系統測試正確地驗證所有的元素網路(mesh)，且整體的系統功能/效能是達成的。

22. 圖13.2 軟體測試步驟

23. 13.1.4　物件導向架構的軟體測試策略 • 物件導向的系統測試對軟體工程師呈現出一組不同的挑戰。 • 測試的定義必須要擴大以包括應用在分析與設計模型的錯誤發現技術(例如，正規的技術檢視)。 • 當它們被建構時，必須評估物件導向表示法的完全性與一致性。 • 單元測試喪失它的某些意義，且整合策略顯著地改變。 • 摘要來說，測試策略與測試戰術(第14章)必須要說明物件導向軟體的獨特性。

24. 物件導向軟體的測試策略 • 就哲學上而言，物件導向軟體的整體策略在哲學上與應用到那傳統架構的是同一個，但在方式上有所不同。 • 由「測試小的」開始並向外進行到「測試大的」。 • 然而，我們聚焦於從「測試小的」個別模組(傳統的觀點)轉變成為一個含括屬性和隱含著通訊與協同合作的操作類別上。 • 當類別被整合進入一個物件導向的架構中時，一系列的回歸測試會執行，以找出類別間通訊與協同合作上的錯誤，和由於新類別(元件)加入所造成的副作用。 • 最後，對整個系統進行測試以確保能找出需求上的錯誤。

25. 13.1.5 測試完成的標準 • 在軟體測試討論時，都有一個典型的問題會出現： • 我們何時做測試? • 我們如何知道我們已經做了充分的測試？ • 很不幸地，對這個問題沒有一定的答案，但是有一些務實的回應和在經驗指導下的初期嘗試。 • 對此問題的一個回應是：你從不做測試；只要很簡單地將你(軟體工程師)的負擔轉嫁給你的顧客身上。 • 每次顧客/使用者執行一支電腦程式時，此程式就正被測試中。 • 此一嚴肅的事實強調其他軟體品質保證活動的重要。 • 另一個回應是(有點挖苦，但仍然是正確的)：當你耗費掉所有的時間，或是你花費掉所有的金錢後，你就做完測試了。

26. 基於統計標準的回應 • 軟體工程師需要更多嚴格的標準以決定何時已經執行了充分的測試。 • Musa與Ackerman建議的一種基於統計標準的回應： • 「不，我們絕對不可能確信軟體永遠不會失敗，但相對於理論上可靠的與實驗上確認的統計模型，我們已經執行了充分的測試而有百分之95的把握說出在一個可能被定義環境中的1000個CPU小時內沒有失誤的機率至少為0.995。」 • 以統計塑模與軟體可靠度理論，軟體失敗(在測試期間所揭發)的模型可被發展成為執行時間的函式。

27. 13.2 策略議題 • 如果沒有針對一系列優先性的(overriding)問題，即使是最好的策略都會失敗。 • Tom Gilb主張如果要實作成功的軟體測試策略，必須要針對以下的問題： • 在測試著手很早之前，採用可量化的方法指明產品的需求。 • 雖然測試的壓倒性目標是找出錯誤，一項好的測試策略也可評估其他的品質特性，如可攜性、可維護性和可用性(第15章)。這些應該被量測，使測試的結果不會含糊不清。 • 明確地說明測試的目標。測試的特定目標應該以可測量的項目名稱來陳述。 • 例如，測試有效性、測試範圍、失敗平均時間、發現和修正缺點的成本、剩餘的缺點密度或發生的次數和每次回歸測試的測試工作小時等，都應在測試計畫中說明。

28. 實作成功軟體測試策略的議題 • 瞭解軟體的使用者，並對每一種使用者類型發展基本資料(profile)。 • 描述使用者每個類別互動情境的使用案例，藉由聚焦在產品實際使用的測試，可以降低整體測試的投入。 • 發展一個強調「快速循環測試(rapid cycle testing)」的測試計畫。 • Gilb推薦一個軟體工程團隊的「學習對顧客有用的快速循環測試(2%的專案投入)，至少是實地「可試驗的(trialable)」，功能性和/或品質改進的遞增。 • 從這些快速循環測試所產生的回饋可用來控制品質水準和相對應的測試策略。

29. 實作成功軟體測試策略的議題 • 建立可設計成自我測試「強韌的」軟體。 • 軟體應該使用反除錯(antibugging)(第13.3.1節)技術的方法設計。 • 即軟體應該有診斷某些類別錯誤的能力。 • 設計應該適應自動化測試與回歸測試。 • 使用有效的正規技術檢視做為測試之前的過濾器。 • 正規技術檢視可與測試一樣有效地揭發出錯誤。 • 因為這個原因，檢視能減少生產高品質軟體所必須要的測試投入。

30. 實作成功軟體測試策略的議題 • 主導正規的技術檢視以評估測試策略與測試案例本身。 • 正規技術檢視可以揭發測試方法中的不一致性、疏忽和較為公開的(outrighter)錯誤。 • 這將節省時間並改善產品品質。 • 為測試流程發展持續改善的方式。此一測試策略應該被量測。 • 在測試期間所蒐集的度量(metrics)應該做為軟體測試中統計流程控制方法的一部分。 「只針對終端使用者需求的測試，如同基於室內設計師工作所做的地基、大樑和配管等工作的費用來檢測整個建築物。」 - Boris Beizer

31. 13.3 傳統軟體的測試策略 • 有許多的策略可利用來測試軟體。 • 在極端的狀況，軟體團隊可以等到系統完全建構後，然後再對整個系統導入測試，希望能找到錯誤。 • 雖然很吸引人，但這種方式完全沒有用。 • 它的結果是造成充滿錯誤的軟體，並且使顧客與終端使用者感到失望。 • 在另一極端狀況，無論何時系統的任何一部分被建構完成後，軟體工程師可以每天導入測試。 • 這種方式，雖然對多數的人較不具吸引力，可是非常有效。

32. 測試軟體的策略 • 不幸地，大多數的軟體開發者對於採用它顯得猶豫。能怎麼做呢？ • 大多數軟體團隊所選擇的測試策略都落在二個極端之間。 • 它採用漸進式的測試觀點，由個別程式單元的測試開始，再移轉到設計以促進單元整合的測試，且最後由操練所建構的系統做為結束。

33. 13.3.1單元測試 • 單元測試(unit testing)聚焦於軟體設計最小單元的驗證投入　　 • 軟體元件或模組。 • 使用元件層級的設計描述做為指導，重要的控制路徑會被測試以揭發出模組邊界內的錯誤。 • 測試的相對複雜度和那些測試所揭發出的錯誤被單元測試所建立的侷限範圍所限制。 • 單元測試聚焦在內部的處理邏輯和元件界限內的資料結構。 • 這種測試型態可被平行地導入到多重的元件上。

34. 單元測試的考量 • 發生做為單元測試一部分的測試以圖例的說明方式顯示於圖13.3中。 • 模組介面被測試以確保資訊適當地流入與流出測試中的程式單元。 • 區域資料結構被檢查以確保暫時儲存的資料在演算法執行所有步驟的期間維持它的完整性。 • 遍及控制結構的所有獨立路徑(基本路徑)被操練以確保所有在模組內敘述至少被執行過一次。 • 邊界條件被測試以確保建立用來限制或約束處理的界限可以適當地操作。 • 最後，所有的錯誤處理路徑也都被測試過。

35. 圖13.3 單元測試

36. 單元測試的考量 • 在任何其他的測試啟始前，橫跨模組介面的資料流向測試是必要的。 • 如果資料沒有正常的進入與離去，則所有的其他測試都是沒有意義的。 • 區域資料結構應該被操練，並且局部對全域資料的衝擊應該在單元測試期間確定(如可能的話)。 • 在單元測試期間，執行路徑的選擇測試是必要的工作任務。 • 測試案例應該設計以揭發由於錯誤的計算、不正確的比較或不適當的控制流向所導致的錯誤。

37. 運算式中普遍的錯誤 • 在計算中更為普遍的錯誤還有： • 誤解或不正確的算數優先順序(precedence) • 混合模式的操作 • 不正確的初始值 • 精確度不準確 • 不正確的運算式符號表示。

38. 比較與控制流向的測試 • 比較與控制流向彼此緊密地連接(即在比較後經常發生流向的改變)。測試案例應該揭發出錯誤，例如： • 不同資料型式的比較 • 不正確的邏輯運算子或優先順序 • 當精準度錯誤使得等式不可能發生時的相等式預期 • 變數的不正確比較 • 不當的或不存在的迴圈中止 • 當遇到發散的(divergent)反覆時失敗地退出 • 不當地修正迴圈變數

39. 邊界測試 • 邊界測試是最重要的單元測試任務之一。 • 軟體時常在它的邊界造成失敗。 • 當第n維陣列的第n個元素被處理時、當某個具有i回合的第i次重複被召喚時、當遇到最大或最小可允許的值時，錯誤時常會發生。 • 操練資料結構、控制流程和資料的值小於、正好或大於最大值與最小值等的測試案例很有可能揭發出錯誤。

40. 反除錯的方式 • 當錯誤確實發生時，良好的設計要求錯誤的情況要預先考量，且設定重繞(reroute)的錯誤處理路徑或俐落地結束處理。Yourdon稱此方式為反除錯(antibugging)。 • 不幸地，有將錯誤處理納入軟體的趨勢出現，然而卻從不測試它。 • 一個真實的故事可以做為例子說明： • 電腦輔助設計系統在合約的條件下發展。 • 在某個交易處理模組中，當召喚各種不同控制流程分支的一系列條件測試之後，在隨後的錯誤處理訊息中發生一個真實的笑話：錯誤！你應該沒有路徑可以到達這裡的。 • 這個「錯誤訊息」是在使用者訓練期間由顧客所揭發的！

41. 應被測試的潛在錯誤 • 當錯誤處理被評估時，在這些應該被測試的潛在錯誤有： • 難以理解的錯誤描述 • 所提到的錯誤沒有對應到所遇到的錯誤 • 錯誤條件造成作業系統的干預先於錯誤處理 • 例外條件處理是不正確的 • 錯誤的描述沒有提供充足的資訊，以協助錯誤起因位置的尋找。

42. 單元測試程序 • 單元測試通常考慮成為編碼步驟中的一個附屬產物。 • 單元測試的設計可在編碼開始之前(一種喜好的機敏方式)或在原始碼產生之後可被實行。 • 設計資訊的檢視提供建立測試案例的指導，這些測試案例有可能揭發於先前討論的每種類型的錯誤。 • 每個測試案例應該與一組預期的結果結合在一起。

43. 驅動程式和虛擬常式軟體 • 因為元件並不是一個單獨的(stand-alone)程式，必須為每一個單元測試發展出驅動程式(driver)和/或虛擬常式(stub)軟體。 • 單元測試環境於圖13.4中舉例說明。 • 在大多數的應用程式中，驅動程式如同一支「主程式」，它接受測試案例資料、傳送這些資料給元件(要被測試的)，並列印出相關的結果。 • 虛擬常式(stub)做為替換從屬於(被呼叫)所要測試元件模組的一部分。 • 虛擬常式或「假副程式(dummy subprogram)」使用從屬模組的介面、可以做很小的數據操作、提供進入的驗證和回傳控制給接受的測試模組。

44. 驅動程式和虛擬常式軟體 • 驅動程式與虛擬常式代表著額外的負擔。 • 即兩個都是必須要撰寫的軟體(正規設計的運用並不普遍)，但並不與最終的軟體產品一起遞交。 • 如果驅動程式與虛擬常式保持簡單，實際上的負擔將相對很低。 • 不幸的是許多元件不能夠以「簡單」負擔的軟體進行充份的單元測試。 • 在此情況中，完整的測試可能被延期到整合的測試步驟中(驅動程式或虛擬常式也被使用)。 • 當設計一個具有高度凝聚性的元件時，單元測試會被簡化。 • 當只針對元件的某個功能時，測試案例的數目將會減少，並且錯誤可以更容易地預測與揭發。

45. 圖13.4 單元測試環境

46. 13.3.2 整合測試 • 一旦所有的模組都經過單元測試，軟體界中的生手(neophyte)會詢問一個表面似乎合理的問題： • 「如果它們個別地都可以工作，而當我們將它們聚集在一起時，你為什麼對它們會工作產生懷疑呢？」 • 此問題是「將它們聚集在一起」 - 介接(interfacing)。 • 資料越過介面時可能會遺失； • 一個模組可能對另一個具有疏忽、有害的影響； • 當組合時，子功能可能無法產生所預期的主要功能； • 個別可接受的不精準度，可能會被放大到無法接受的程度； • 全域的資料結構會出現問題。 • 很可悲地，此列表不斷地一直繼續著。

47. 整合測試的目標與方式 • 整合測試(integration testing)是建構軟體架構的一種系統化技術，同時主導測試以揭發與介接有關的錯誤。 • 其目標是拿取經過單元測試的元件，並建造一個由設計所要求的程式結構。 • 整合測試的方式: • 非漸進式整合(nonincremental integration) • 漸進式整合(incremental integration)

48. 非漸進式整合 • 經常會有嘗試非漸進式整合(nonincremental integration)的趨勢，即使用「大爆炸(big bang)」方式建構程式。 • 所有的元件事先組合 • 整個程式做為一個整體進行測試 • 結果通常都是大混亂(chaos) • 在整個計畫的龐大費用之下，當遇到一組錯誤時，改正會變得很困難，因為起因的隔離變得更為複雜。 • 一旦這些錯誤被改正後，新的一些問題又會出現，並且流程在似乎是永無止境的迴圈中繼續。

49. 漸進式整合 • 漸進式整合(incremental integration)是大爆炸方式的對照。 • 程式以較小的增量進行建構與測試，其錯誤比較容易隔離與改正。 • 介面更為可能被完整的測試。 • 且可以應用系統化的測試方式。

50. 由上而下的整合 • 由上而下整合的測試是軟體架構建構的漸進方式。 • 由主要的控制模組(主程式)開始，模組經由控制階層向下整合。 • 主要控制模組的從屬(和最終從屬)模組以深度優先(depth-first)或寬度優先(breadth-first)的方式被併入結構中。