5.模塊分解時應遵循的準則
（1）滿足信息隱蔽原則。
（2）盡量使得模塊的內聚度高，模塊間的耦合度低。
（3）模塊的大小適中（通常一個模塊以50～100個語句行為適宜）。
（4）模塊的調用深度不宜過大。一個模塊A可以調用另一模塊B，模塊B還可調用模塊C，稱模塊A直接調用模塊B，模塊A間接調用模塊C，被間接調用的模塊還可調其他模塊，這樣可形成一棵調用樹，我們把以某個模塊為根結點的調用樹的深度稱為該模塊的調用深度。
（5）模塊的扇入應盡量大，扇出不宜過大。一個模塊的扇入是指直接調用該模塊的上級模塊個數。一個模塊的扇出是指該模塊直接調用的下級模塊的個數。扇入大表示模塊的復用程度高，扇出大表示模塊的復雜度高。
（6）設計單入口和單出口的模塊。
（7）模塊的作用域應在控制域之內。模塊的作用域是指受該模塊內一個判定影響的所在模塊的集合。模塊的控制域是指該模塊本身以及被該模塊直接或間接調用的所有模塊的集合。在設計時，作用域應是控制域的子集，作用域最好是做出判定的模塊本身以及它的直屬下級模塊（直接調用的模塊）。
（8）模塊的功能應是可以預測的，功能可預測是指對相同的輸入數據能產生相同的輸出。
三、軟件測試
在軟件開發的一列活動中，為了保證軟件的可靠性，人們研究并使用了很多方法進行分析、設計及編碼實現。但是由于軟件產品本身無形態，它是復雜的、知識高度密集的邏輯產品，其中不可能沒有錯誤。物理產品在出廠前都要進行嚴格的檢驗，軟件產品也不例外。軟件開發總伴隨著軟件質量保證的活動，而軟件測試是主要活動之一。軟件測試代表了需求分析、設計、編碼的最終復審。
測試是一項很艱苦的工作，其工作量約占軟件開發總工作量的40%以上，特別對一些關系到人的生命安全的軟件，共測試成本可能相當于開發階段總成本的3～5倍。
（一）測試的基本概念1.測試的目的
軟件測試的目的是盡可能多地發現軟件產品（主要是指程序）中的錯誤和缺陷。
明確測試的目的是一件非常重要的事，因為在現實世界中對測試工作存在著許多模糊或者錯誤的看法，這些看法嚴重影響著測試工作的順利進行。
有人認為測試是為了證明程序是正確的，也就是說程序不再有錯誤，事實證明這是不現實的。因為要通過測試來發現程序中的所有錯誤就要窮舉所有可能的輸入數據，檢查它們是否產生正確的結果。例如，一個需要3個16位字長的整型輸入數據的程序，輸入數據的所有組合情況大約有3×10 14 種，若每組數據的測試時間為1ms，那么即使一年365天，每天24小時地測試，也大約需要1萬年的時間。
2.測試用例
要進行測試，除了要有測試數據（或稱輸入數據）外，還應同時給出該組測試數據應該得以怎樣的輸出結果，我們稱它為預期結果。在測試時將實際的輸出結果與預期結果比較，若不同則表示發現了錯誤，因此測試用例是由測試數據和預期結果構成的。
為了發現程序中的錯誤，應竭力設計能暴露錯誤的測試用例。一個好的測試用例是極有可能發現迄今為止尚未發現的錯誤的測試用例。一次成功的測試是發現了至今為止尚未發現的錯誤的測試。
3.測試的原則
基于上述測試目的，我們可以考慮以下有關測試的原則:
（1）確定預期輸出結果是測試用例必不可少的一部分。如果只有測試數據而無預期結果，那么就不易判斷測試結果是否正確。
（2）程序員應避免測試自己的程序，程序設計機構不應測試自己的程序。這是因為程序中的錯誤往往是由于程序員對問題說明的誤解，由他來測試自己的程序就不易找出因這種誤解而產生的錯誤。此外，開發程序是一項建設性的工作，而測試則是一項破壞性的工作（證明程序有錯），這對開發人員或機構來說在心理上是難以容忍的。為了證明自己的程序沒有錯誤或錯誤很少，他們往往不去選擇容易發現錯誤的測試用例，而選擇容易通過的測試用例。當然，這并不意味著程序員都不能測試自己的程序，如單元測試通常就是由程序員自己測試的。
（3）徹底檢查每個測試結果。如果不仔細檢查測試結果，有些已經測試出來的錯誤也可能被遺漏掉。
（4）對非法的非預期的輸入數據也要像合法的和預期的輸入數據一樣編寫測試用例。
（5）檢查程序是否做了應做的事是成功的一半，另一半是看程序是否做了不該做的事。
（6）除了真正沒有用的程序外，一定不要扔掉測試用例。因為在改正錯誤或程序維護后還要進行重新測試。
（7）在規劃測試時不要設想程序中不會查出錯誤。
（8）程序模塊經測試后，殘存的錯誤數目往往與已發現的錯誤數目成比例。實踐證明，程序中的大量錯誤僅與少量的程序模塊有關，因此當A模塊找出的錯誤比B模塊多得多時，很可能A模塊殘存的錯誤仍比B模塊殘存的錯誤多多。
4.白盒測試和黑盒測試
測試的關鍵是測試用例的設計，其方法可分成兩類:白盒測試和黑盒測試。
白盒測試是把程序看成裝在一只透明的白盒子里，測試者完全了解程序結構和處理過程。它根據程序的內部邏輯來設計測試用例，檢查程序中的邏輯通路是否都按預定的要求正確地工作。黑盒測試是把程序看成一只黑盒子，測試者完全不了解（或不考慮）程序的結構和處理過程。它根據規格說明書規定的功能來設計測試用例，檢查程序的功能是否符合規格說明的要求。
（二）測試步驟
軟件測試的主要步驟有單元測試、集成測試和確認測試。
1.單元測試（unit testing）
單元測試也稱模塊測試。通常單元測試可放在編碼階段，程序員在編寫好一個模塊后，總會（也應該）對自己編寫的模塊進行測試，檢查它是否實現了詳細設計說明書中規定的模塊功能和算法。單元測試主要發現編碼和詳細設計中產生的錯誤，通常采用白盒測試。
測試一個模塊時需要編寫一個驅動模塊和若干個樁（stub）模塊，如下圖所示。驅動模塊的功能是向被測試模塊提供測試數據，驅動（即調用）被測模塊，并從被測模塊中接受測試結果。樁模塊的功能是模擬被模塊所調用的子模塊，它接受被測模塊的調用，檢驗調用參數，模擬被
調用的子模塊功能，把結果送回給被測模塊。在模塊結構圖中，頂層模塊測試時不需要驅動模塊，最底層的模塊測試時不需要樁模塊。
2.集成測試（integration testing）
集成測試也稱組裝測試，它是對由各模塊組裝而成的程序進行測試，主要檢查模塊間的接口和通信。集成測試主要發現設計階段產生的錯誤，通常采用黑盒測試。
集成的方式可分成非漸增式集成和漸增式集成。非漸增式集成是先測試所有的模塊，然后把這些模塊集成在一起對整個程序進行測試。漸增式集成是將單元測試和集成測試合并在一起，它根據模塊結構圖，按某種次序選一個尚未測試的模塊，把它同已經測試好的模塊組合在一起對整個程序進行測試，每次增加一個模塊，直至所有模塊全部集成在程序中。
漸增式集成又可分成自頂向下集成和自底向上集成。自頂向下集成先測試上層模塊，再測試下層模塊。由于測試下層模塊時它的上層模塊已測試過，所以可以用其上層模塊作為它的驅動模塊，而不必另編驅動模塊。自底向上集成先測試下層模塊，再測試上層模塊。同樣道理，在自底向上集成時可用下層模塊作為上層模塊的樁模塊，而不必另外編寫樁模塊。
3.確認測試（walidation testing）
確認測試的任務是檢查軟件的功能、性能及其他特征是否與用戶的需求一致，它是以需求規格說明書（即需求規約）作為依據的測試。確認測試通常采用黑盒測試。
確認測試首先測試程序是否滿足需求規格說明書所列的各項要求，然后要進行軟件配置復查，特別是文檔是否齊全，各方面的質量是否符合要求等。如果一個軟件是為某個客戶定制的，那么最后由客戶來實施驗收測試（acceptance testing），以便客戶確認該軟件是否他所需要的。如果一個軟件是作為產品被許多客戶使用的話，那不可能為每個客戶進行驗收測試。大多數軟件生產者使用一種Alpha測試和Beta測試的過程，來揭露僅由最終用戶才能發現的錯誤。
Alpha測試是在開發者的現場由客戶來實施的，被測試的軟件是在開發者從用戶的角度進行常規設置的環境下運行的。Beta測試是在一個或多個客戶的現場由該軟件的最終用戶實施的。與Alpha測試不同的是，Beta測試時開發者通常是不在場的。Alpha測試和Beta測試除了進一步發現程序中的錯誤外，還能發現使用上的問題。經過確認測試后的軟件通常就可交付使用了。