單元測試常用的方法

　　單元測試

　　單元測試（unit testing），是指對軟體中的最小可測試單元進行檢查和驗證。對於單元測試中單元的含義，一般來說，要根據實際情況去判定其具體含義，如C語言中單元指一個函數，Java裡單元指一個類，圖形化的軟體中可以指一個窗口或一個菜單等。總的來說，單元就是人為規定的最小的被測功能模塊。單元測試是在軟體開發過程中要進行的最低級別的測試活動，軟體的獨立單元將在與程序的其他部分相隔離的情況下進行測試。

　　在一種傳統的結構化程式語言中，比如C，要進行測試的單元一般是函數或子過程。在像C++這樣的面向對象的語言中， 要進行測試的基本單元是類。對Ada語言來說，開發人員可以選擇是在獨立的過程和函數，還是在Ada包的級別上進行單元測試。單元測試的原則同樣被擴展到第四代語言（4GL）的開發中，在這裡基本單元被典型地劃分為一個菜單或顯示界面。

　　經常與單元測試聯繫起來的另外一些開發活動包括代碼走讀（Code review），靜態分析（Static analysis）和動態分析（Dynamic analysis）。靜態分析就是對軟體的原始碼進行研讀，查找錯誤或收集一些度量數據，並不需要對代碼進行編譯和執行。動態分析就是通過觀察軟體運行時的動作，來提供執行跟蹤，時間分析，以及測試覆蓋度方面的信息。

　　單元測試實施要點

　　1. 模塊接口

　　模塊的接口保證了測試模塊的數據流可以正確地流人、流出。在測試中應檢查以下要點：

　　1） 測試模塊的輸入參數和形式參數在個數、屬性、單位上是否一致。

　　2） 調用其他模塊時所給出的實際參數和被調用模塊的形式參數在個數、屬性、單位上是否一致。

　　3） 調用標準函數時所用的參數在屬性、數目和順序上是否正確。

　　4） 全局變量在各模塊中的定義和用法是否一致。

　　5） 輸入是否僅改變了形式參數。

　　6） 開／關的語句是否正確。

　　7） 規定的I／O格式是否與輸入輸出語句一致。

　　8） 在使用文件之前是否已經打開文件或是使用文件之後是否已經關閉文件。

　　2. 局部數據結構。

　　在單元測試中，局部數據結構出錯是比較常見的錯誤，在測試剛應重點考慮以下因素：

　　1） 變量的說明是否合適。

　　2） 是否使用了尚未賦值或尚未初始化的變量。 3） 變量的初始值或默認值是否正確。 4） 變量名是否有錯（例如拼寫錯）。

　　3. 重要的執行路徑。

　　在單元測試中，對路徑的測試是最基本的任務。由於不能進行窮舉測試，需要精心設計測試用例來發現是否有計算、比較或控制流等方面的錯誤。

　　1） 計算方面的錯誤：算術運算的優先次序不正確或理解錯誤；精度不夠；運算對象的

　　類型不匹配；算法錯；表達式的符號表示不正確等。

　　2） 比較和控制流的錯誤：本應相等的量由於精度造成不相等；不同類型進行比較邏輯

　　運算符不正確或優先次序錯誤；循環終止不正確（如多循環一次或少循環一次）、死循環；不恰當地修改循環變量；當遇到分支循環時，出口錯誤等。

　　4. 出錯處理。

　　好的設計應該能預測到出錯的條件並且有出錯處理的途徑。雖然計算機機可以顯示出錯信息的內容，但仍需要程式設計師對出錯進行處理，保證其邏輯的正確性以便於用戶維護。

　　5. 邊界條件

　　邊界條件的測試是單元測試的最後工作，也是非常重要的工作。毫件容易在邊界出現錯誤。塊進行測試時，需要開發兩種模塊：

　　6. 驅動模塊

　　相當於一個主程序，接收測試用例的數據，將這些數據送到測試槨，輸出測試結果。

　　7. 樁模塊

　　也稱為存根模塊。樁模塊用來代替測試模塊中所調用的子模塊，其進行少量的數據處理，目的是為了檢驗人口，輸出調用和返回的信息。 提高模塊的內聚度可以簡化單元測試。如果每個模塊只完成一種功能，對於具一塊來講，所需的測試方案數據就會顯著減少，而且更容易發現和預測模塊中的錯誤。

　　單元測試經驗總結

　　1. 概述

　　工廠在組裝一臺電視機之前，會對每個元件都進行測試，這，就是單元測試。其實我們每天都在做單元測試。你寫了一個函數，除了極簡單的外，總是要執行一下，看看功能是否正常，有時還要想辦法輸出些數據，如彈出信息窗口什麼的，這，也是單元測試，我們把這種單元測試稱為臨時單元測試。只進行了臨時單元測試的軟體，針對代碼的測試很不完整，代碼覆蓋率要超過70%都很困難，未覆蓋的代碼可能遺留大量的細小的錯誤，這些錯誤還會互相影響，當BUG暴露出來的時候難於調試，大幅度提高後期測試和維護成本，也降低了開發商的競爭力。可以說，進行充分的單元測試，是提高軟體質量，降低開發成本的必由之路。對於程式設計師來說，如果養成了對自己寫的代碼進行單元測試的習慣，不但可以寫出高質量的代碼，而且還能提高編程水平。

　　要進行充分的單元測試，應專門編寫測試代碼，並與產品代碼隔離。我們認為，比較簡單的辦法是為產品工程建立對應的測試工程，為每個類建立對應的測試類，為每個函數（很簡單的除外）建立測試函數。首先就幾個概念談談我們的看法。

　　一般認為，在結構化程序時代，單元測試所說的單元是指函數，在當今的面向對象時代，單元測試所說的單元是指類。以我們的實踐來看，以類作為測試單位，複雜度高，可操作性較差，因此仍然主張以函數作為單元測試的測試單位，但可以用一個測試類來組織某個類的所有測試函數。單元測試不應過分強調面向對象，因為局部代碼依然是結構化的。單元測試的工作量較大，簡單實用高效才是硬道理。

　　有一種看法是，只測試類的接口（公有函數），不測試其他函數，從面向對象角度來看，確實有其道理，但是，測試的目的是找錯並最終排錯，因此，只要是包含錯誤的可能性較大的函數都要測試，跟函數是否私有沒有關係。對於C++來說，可以用一種簡單的方法區隔需測試的函數：簡單的函數如數據讀寫函數的實現在頭文件中編寫（inline函數），所有在源文件編寫實現的函數都要進行測試（構造函數和析構函數除外）。

　　2．什麼時間開始測試

　　什麼時候測試？單元測試越早越好，早到什麼程度？XP開發理論講究TDD，即測試驅動開發，先編寫測試代碼，再進行開發。在實際的工作中，可以不必過分強調先什麼後什麼，重要的是高效和感覺舒適。從我們的經驗來看，先編寫產品函數的框架，然後編寫測試函數，針對產品函數的功能編寫測試用例，然後編寫產品函數的代碼，每寫一個功能點都運行測試，隨時補充測試用例。所謂先編寫產品函數的框架，是指先編寫函數空的實現，有返回值的隨便返回一個值，編譯通過後再編寫測試代碼，這時，函數名、參數表、返回類型都應該確定下來了，所編寫的測試代碼以後需修改的可能性比較小。

　　3．誰來測試

　　由誰測試？單元測試與其他測試不同，單元測試可看作是編碼工作的一部分，應該由程式設計師完成，也就是說，經過了單元測試的代碼才是已完成的代碼，提交產品代碼時也要同時提交測試代碼。測試部門可以作一定程度的審核。

　　4．關於樁代碼

　　我們認為，單元測試應避免編寫樁代碼。樁代碼就是用來代替某些代碼的代碼，例如，產品函數或測試函數調用了一個未編寫的函數，可以編寫樁函數來代替該被調用的函數，樁代碼也用於實現測試隔離。採用由底向上的方式進行開發，底層的代碼先開發並先測試，可以避免編寫樁代碼，這樣做的好處有：減少了工作量；測試上層函數時，也是對下層函數的間接測試；當下層函數修改時，通過回歸測試可以確認修改是否導致上層函數產生錯誤。

　　單元測試的基本策略

　　1．概述

　　當設計一個單元測試的策略時，可以採用三種基本的組織方法。它們分別是自上而下法、自下而上法和分離法。在接下來的第二、第三和第四部分將對上述三種方法的詳細內容、各自的優點和缺點分別進行介紹。在文章中要一直用到測試驅動和樁模塊這兩個概念。所謂的測試驅動是指能使軟體執行的軟體，它的目的就是為了測試軟體，提供一個能設置輸入參數的框架，並執行這個框架單元以得到相應的輸出參數。而樁模塊是指一個模擬單元，用這個模擬單元來替代真實的單元完成測試。

　　2. 自上而下法 2.1 詳述

　　在自上而下的測試過程中，每個單元是通過使用它們來進行測試的，這個過程是由調用這些被測單元的其他獨立的單元完成的。

　　首先測試最高層的單元，將所有的調用單元用樁模塊替換。接著用實際的調用單元替換樁模塊，而繼續將較低層次的單元用樁模塊替換。重複這個過程直到測試了最底層的單元。自上而下測試法需要測試樁，而不需要測試驅動。

　　圖2.1描述了使用測試樁和一些已測試單元來測試單元D的過程，假設單元A，B，C已經用自上而下法進行了測試。

　　由圖2.1得到的是一個使用基於自上而下組織方法的單元測試計劃，其過程可以描述如下：

　　1） 步驟1：測試A單元，使用B，C，D單元的樁模塊。

　　2） 步驟2：測試B單元，通過已測試過的A單元來調用它，並且使用C，D單元的樁

　　模塊。步驟3：測試C單元，通過已測試過的A單元來調用它，並且使用已通過測試的B單元和D單元的樁模塊。

　　3） 步驟4：測試D單元，從已測試過的A單元調用它，使用已測試過的B和C單元，

　　並且將E，F和G單元用樁模塊代替。（如圖2.1所示）

　　4） 步驟5：測試E單元，通過已測試過的D單元調用它，而D單元是由已通過測試

　　的A單元來調用的，使用已通過測試的B和C單元，並且將F，G，H，I和J單元用樁模塊代替。

　　5） 步驟6：測試F單元，通過已測試過的D單元調用它，而D單元是由已通過測試

　　的A單元來調用的，使用已通過測試的B，C和E單元，並且將G，H，I和J單元用樁模塊代替。

　　6） 步驟7：測試G單元，通過已測試過的D單元調用它，而D單元是由已通過測試

　　的A單元來調用的，使用已通過測試的B，C和F單元，並且將H，I和J單元用樁模塊代替。

　　7） 步驟8：測試H單元，通過已測試過的E單元調用它，而E單元是由已通過測試的D單元來調用的，而D單元是由已通過測試的A單元來調用的，使用已通過測試的B，C，E，F，G和H單元，並且將J單元用樁模塊代替。

　　8） 步驟9：測試J單元，通過已測試過的E單元調用它，而E單元是由已通過測試的

　　D單元來調用的，而D單元是由已通過測試的A單元來調用的，使用已通過測試的B，C，E，F，G，H和I單元

　　

　　2.2 優點

　　自上而下單元測試法提供了一種軟體集成階段之前的較早的單元集成方法。實際上，自上而下單元測試法確實將單元測試和軟體集成策略進行了組合。

　　單元的詳細設計是自上而下的，自上而下的測試實現過程使得被測單元按照原設計的順序進行，因為單元測試的詳細設計與軟體生命周期代碼設計階段的重疊，所以開發時間將被縮短。

　　在通常的結構化設計中，高等級的單元提供高層的功能，而低等級的單元實現細節，自上而下的單元測試將提供一種早期的「可見」的功能化集成。它給予單元測試一種必要的合理的實現途徑。

　　較低層次的多餘功能可以通過自上而下法來鑑別，這是因為沒有路徑來測試它。（但是，這可能在區分多餘的功能和沒有被測試的功能時帶來困難）。

　　2.3 缺點

　　自上而下法是通過樁模塊來進行控制的，而且測試用例常常涉及很多的樁模塊。對於每個已測單元來說，測試變得越來越複雜，結果是開發和維護的費用也越來越昂貴。

　　依層次進行的自上而下的測試，要達到一個好的覆蓋結構也很困難，而這對於一個較為完善、安全的關鍵性應用來說至為重要，同時這也是很多的標準所要求的。難於達到一個好的覆蓋結構也可能導致最終的多餘功能和未測試功能之間的混亂。由此，測試一些低層次的功能，特別是錯誤處理代碼，將徹底不切實。

　　一個單元的變化往往會影響對其兄弟單元和下層單元的測試。例如，考慮一下D單元一個變化。很明顯，對D單元的單元測試不得不發生變化和重新進行。另外，要使用已測試單元D的E、F、G、H、I和J單元也不得不重新測試。作為單元D改變的結果，上述測試自身可能也不得不發生改變，即使單元E、F、G、H、I和J實際上並沒有改變。這將導致當變化發生時，重複測試帶來的高成本，以及高額的維護成本和高額的整個軟體生產周期的成本。

　　在為自上而下測試法設計測試用例當中，當被測單元調用其他單元時需要測試人員具備結構化知識。被測試單元的順序受限於單元的層次結構，低層次的單元必須要等到高層次的單元被測試後才能被測試，這樣就形成了一個「又長又瘦」的單元測試階段。（然而，這可能會導致測試詳細設計與軟體生命周期編碼階段的整體重疊。）

　　如圖2.1所示的例子程序中各個單元之間的層次關係十分簡單，在實際的編程過程中可能會遇到類似的情形，而且各個單元之間的層次關係會更複雜。所以自上而下測試法的缺點對單元測試造成的不利影響會隨著被測單元之間複雜的聯繫而加深。

　　2.4 總結

　　一個自上而下的測試策略成本將高於基於分離的測試策略，這取決於頂層單元下層單元的複雜程度，以及由於下層單元自身發生變化所帶來的顯著影響。對於單元測試來說自上而下的組織方法不是一個好的選擇。然而，當各個組成單元已經被單獨測試的情況下，用自上而下法進行單元的集成測試是個不錯的手段。

　　3. 自下而上法 3.1 詳述

　　在自下而上的單元測試中，被測單元與調用被測單元的單元是分開測試的，但是測試時所使用的是真實的被調用單元。

　　測試時最底層的單元首先被測試，這樣就方便了對高層次單元的測試。然後使用前面已經被測試過的被調用單元來測試其他的單元。重複這個過程直到最高層的單元被測試為止。自下而上法需要測試驅動，但是不需要測試樁。

　　圖3.1說明了測試D單元時需要的測試驅動和已測單元的情況，假設單元E、F、G、H、I和J已經通過自下而上法進行了測試。

　　

　　圖3.1顯示了一個程序的單元測試的測試計劃，該計劃使用了基於自下而上的組織方法，其過程如下： 步驟（1）（注意在測試步驟中測試的順序不是最主要的，步驟1中的所有測試可以同步進行）。

　　1） 測試單元H，在調用H單元的E單元處使用一個測試驅動； 2） 測試單元I，在調用I單元的E單元處使用一個測試驅動； 3） 測試單元J，在調用J單元的E單元處使用一個測試驅動； 4） 測試單元F，在調用F單元的D單元處使用一個測試驅動； 5） 測試單元G，在調用G單元的D單元處使用一個測試驅動； 6） 測試單元B，在調用B單元的A單元處使用一個測試驅動； 7） 測試單元C，在調用C單元的A單元處使用一個測試驅動。 步驟（2）

　　測試單元E，在調用E單元的D單元處使用一個測試驅動，再加上已測試過的單元H、I和J。 步驟（3）

　　測試單元D，在調用D單元的A單元處使用一個測試驅動，再加上已測試過的單元E、F、G、H、I和J。（如圖3.1所示） 步驟（4）

　　測試單元A，使用已測試過的單元B、C、D、E、F、G、H、I和J。

　　3.2 優點

　　和自上而下法一樣，自下而上單元測試法提供了一種比軟體集成階段更早的單元集成。自下而上單元測試同樣也是真正意義上的單元測試和軟體集成策略的結合。因為不需要測試樁，所以所有的測試用例都由測試驅動控制。這樣就使得低層次單元附近的單元測試相對簡單些。（但是，高層次單元的測試可能會變得很複雜。）

　　在使用自下而上法測試時，測試用例的編寫可能只需要功能性的設計信息，不需要結構化的設計信息（儘管結構化設計信息可能有利於實現測試的全覆蓋）。所以當詳細的設計文檔缺乏結構化的細節時，自下而上的單元測試就變得十分有用處。

　　自下而上單元測試法提供了一種低層次功能性的集成，而較高層次的功能隨著單元測試過程的進行按照單元層次關係逐層增加。這就使得自下而上單元測試很容易地與測試對象相兼容。

　　3.3 缺點

　　隨著測試逐層推進，自下而上單元測試變得越來越複雜，隨之而來的是開發和維護的成本越來越高昂，同樣要實現好的結構覆蓋也變得越來越困難。

　　低層單元的變化經常影響其上層單元的測試。例如：想像一下H單元發生變化的情況。很明顯，對H單元的測試不得不發生變化和重新進行。另外，對於A、D和E單元的測試來說，因為它們共同使用了已測試過的H單元，所以它們的測試也不得不重做。作為H單元發生變化的後果，這些測試本身可能也要進行改變，即使單元A、D和E實際上並沒有發生變化。這就導致了當變化發生時，產生了與重新測試有關的高額代價，以及高額的維護成本和整個軟體生命周期成本的提高。

　　單元測試的順序取決於單元的層次關係，較高層次的單元必須要等到較低層次單元通過測試後才能進行測試，所以就形成了「長瘦」型的單元測試階段。最先被測試的單元是最後被設計的單元，所以單元測試不能與軟體生命周期的詳細設計階段重疊。

　　如圖2.2所示的例子程序中各個單元之間的層次關係十分簡單，在實際的編程過程中可能會遇到類似的情形，而且各個單元之間的層次關係會更複雜。與自上而下測試法一樣，自下而上測試法的缺點會隨著被測單元之間複雜的聯繫而放大。

　　3.4 總結

　　自下而上組織法對於單元測試來說是個比較好的手段，特別是當測試對象和重用情況時。然而，自下而上方法偏向於功能性測試，而不是結構化測試。對於很多標準所需要的高集成度和安全的關鍵性應用，需要達到高層次的結構覆蓋，但自下而上法很難滿足這個要求。

　　自下而上單元測試法與很多軟體開發所要求的緊湊的時間計劃是相衝突的。總的來說，一個自下而上策略成本將高於基於分離的測試策略，這是因為單元層次結構中低層次單元以上單元的複雜程度和它們發生變化所帶來的顯著影響。

　　4. 分離法 4.1 詳述

　　分離測試法是分開測試每一個單元，無論是被調用單元還是調用單元。被測單元可以按照任意順序進行測試，因為被測單元不需要其他任何已測單元的支持。每一個單元的測試都需要一個測試驅動，並且所有的被調用單元都要用測試樁代替。圖4.1 說明了測試單元D 時需要的測試驅動和測試樁的情況。

　　

　　圖4.1 顯示了某個程序中一個單元的測試計劃，該計劃基於分離組織方法的策略，只需要如下所示的一步：

　　步驟（1）（注意該測試計劃只有一步。測試的順序不是最主要的，所有的測試可以同步進行。）

　　1） 測試A 單元，使用一個測試驅動啟動測試，並且將B、C 和D 單元換成測試樁； 2） 測試B 單元，在A 單元處使用一個測試驅動來調用B 單元； 3） 測試C 單元，在A 單元處使用一個測試驅動來調用C 單元；

　　4） 測試D 單元，在A 單元處使用一個測試驅動來調用D 單元，並且將E、F和G

　　單元換成測試樁（如圖3.1 所示）；

　　5） 測試E 單元，在D 單元處使用一個測試驅動來調用E 單元，並且將H、I和J

　　單元換成測試樁；

　　6） 測試F 單元，在D 單元處使用一個測試驅動來調用F 單元； 7） 測試G 單元，在D 單元處使用一個測試驅動來調用G 單元； 8） 測試H 單元，在E 單元處使用一個測試驅動來調用H 單元； 9） 測試I 單元，在E 單元處使用一個測試驅動來調用I 單元； 10） 測試J 單元，在E 單元處使用一個測試驅動來調用J 單元。

　　4.2 優點

　　徹底地測試一個分離的單元是很容易做到的，單元測試將其從與其它單元之間複雜的關係中分離了出來。分離測試是最容易實現良好的結構性覆蓋的方法，並且實現良好結構性覆蓋的困難程度與確定某一個單元在單元層次中所處位置的難易度沒有什麼不同。

　　因為每一次只測試一個單元，所以該方法中所使用的測試驅動比自下而上法中所使用的測試驅動簡單，該方法中所使用的測試樁比自上而下法中使用的測試樁簡單。由於採用了分離的方法進行單元測試，被測單元之間沒有依賴關係，所以單元測試階段可以和詳細設計階段，以及軟體生命周期的代碼編寫階段重疊。所有單元都能同步測試，形成了單元測試階段「短而寬」的特點。這有利於通過擴大團隊規模的手段縮短整個軟體開發的時間。分離測試法另外一個優點是去除了測試單元之間的內部依賴關係，所以當一個單元發生變化時只需要改變那個發生變化的測試單元，而對其它測試單元沒有任何影響。由此可以看出分離組織法的成本要低於自下而上組織法和自上而下組織法，特別是當發生變化時其效果更加明顯。

　　分離法提供了一種與集成測試不同的單元測試分離手段，它允許開發人員在軟體生命周期的單元測試階段專心致力於單元測試工作，而在軟體生命周期的集成測試階段專心致力於集成測試工作。只有分離法是純粹意義上適用於單元測試的方法，自上而下測試法和自下而上測試法適用於單元測試和集成階段的混合過程。與自上而下法和自下而上法不同的是，用分離法進行的單元測試，被測單元不會受到與其關聯的其它任何單元的影響。

　　4.3 缺點

　　用分離法進行單元測試最主要的缺點是它不能提供一個早期的單元集成。這必須要等到軟體生命周期的集成階段才能做到。（這很難說是一個真正的缺點）

　　用分離法進行單元測試時需要結構設計信息和使用測試樁、測試驅動。這會導致在測試靠近底層的單元時，所花費成本要高於自下而上法。然而，這個缺陷可以通過簡化層次較高的單元的測試，以及每個單元每次發生變化時的較低花費得到補償。

　　4.4 總結

　　用分離法進行單元測試是最合適的選擇。在加上適當的集成策略作為補充，將會縮短軟體開發時間所佔比例和降低開發費用，這個優勢將會貫穿整個軟體開發過程和軟體生命周期。按照分離法進行單元測試時，被測單元可以按照自上而下或者自下而上的順序進行集成，或者集成為任何便利的群組和群組的結合。然而，一個自下而上的集成方式是與目前流行的面向對象和面向對象的設計最相兼容的策略。分離法單元測試是實現高層次結構覆蓋的最佳手段，而高層次結構覆蓋對於很多標準所要求的高完善性和安全的關鍵性應用來說是至關重要。在通過單元測試完成了所有實現好的結構覆蓋的困難工作的基礎上，集成測試就可以集中於全面的功能測試和單元交互的測試。

　　5. 使用AdaTEST 和Cantata

　　一個單元的測試在整個軟體生命周期中要重複進行很多次，無論是在開發階段還是維護過程中。一些測試工具如：AdaTEST 和Cantata，可以用於一些易於重複進行和花費較少的自動化單元測試中，這樣可以有效降低人為因素帶來的風險。AdaTEST 和Cantata 測試腳本由一個測試驅動和一個樁的集合（可選的）組成。AdaTEST 和Cantata 可以用於本文所介紹的任何單元測試的組織方法，或者這些方法的任意組合，使得開發人員可以採用最適合於項目應用的測試策略。IPL 提供了兩篇相關論文，如下所示：

　　「Achieving Testability when using Ada Packaging and Data Hiding Methods」「Testing C++ Objects」，論文「Testing C++ Objects」同樣詳細討論了在用自下而上法進行單元測試時，分離的類和層次等級的約束是如何引發問題的。文章介紹了分離單元測試法是如何成為唯一實用的處理分離的類和層次等級約束的途徑

　　變那個發生變化的測試單元，而對其它測試單元沒有任何影響。由此可以看出分離組織法的成本要低於自下而上組織法和自上而下組織法，特別是當發生變化時其效果更加明顯。

　　分離法提供了一種與集成測試不同的單元測試分離手段，它允許開發人員在軟體生命周期的單元測試階段專心致力於單元測試工作，而在軟體生命周期的集成測試階段專心致力於集成測試工作。只有分離法是純粹意義上適用於單元測試的方法，自上而下測試法和自下而上測試法適用於單元測試和集成階段的混合過程。與自上而下法和自下而上法不同的是，用分離法進行的單元測試，被測單元不會受到與其關聯的其它任何單元的影響。

　　4.3 缺點

　　用分離法進行單元測試最主要的缺點是它不能提供一個早期的單元集成。這必須要等到軟體生命周期的集成階段才能做到。（這很難說是一個真正的缺點）

　　用分離法進行單元測試時需要結構設計信息和使用測試樁、測試驅動。這會導致在測試靠近底層的單元時，所花費成本要高於自下而上法。然而，這個缺陷可以通過簡化層次較高的單元的測試，以及每個單元每次發生變化時的較低花費得到補償。

　　4.4 總結

　　用分離法進行單元測試是最合適的選擇。在加上適當的集成策略作為補充，將會縮短軟體開發時間所佔比例和降低開發費用，這個優勢將會貫穿整個軟體開發過程和軟體生命周期。按照分離法進行單元測試時，被測單元可以按照自上而下或者自下而上的順序進行集成，或者集成為任何便利的群組和群組的結合。然而，一個自下而上的集成方式是與目前流行的面向對象和面向對象的設計最相兼容的策略。分離法單元測試是實現高層次結構覆蓋的最佳手段，而高層次結構覆蓋對於很多標準所要求的高完善性和安全的關鍵性應用來說是至關重要。在通過單元測試完成了所有實現好的結構覆蓋的困難工作的基礎上，集成測試就可以集中於全面的功能測試和單元交互的測試。

　　5. 使用AdaTEST 和Cantata

　　一個單元的測試在整個軟體生命周期中要重複進行很多次，無論是在開發階段還是維護過程中。一些測試工具如：AdaTEST 和Cantata，可以用於一些易於重複進行和花費較少的自動化單元測試中，這樣可以有效降低人為因素帶來的風險。AdaTEST 和Cantata 測試腳本由一個測試驅動和一個樁的集合（可選的）組成。AdaTEST 和Cantata 可以用於本文所介紹的任何單元測試的組織方法，或者這些方法的任意組合，使得開發人員可以採用最適合於項目應用的測試策略。IPL 提供了兩篇相關論文，如下所示：

　　「Achieving Testability when using Ada Packaging and Data Hiding Methods」「Testing C++ Objects」，論文「Testing C++ Objects」同樣詳細討論了在用自下而上法進行單元測試時，分離的類和層次等級的約束是如何引發問題的。文章介紹了分離單元測試法是如何成為唯一實用的處理分離的類和層次等級約束的途徑

打開APP閱讀更多精彩內容

聲明：本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人，不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用，如有內容圖片侵權或者其他問題，請聯繫本站作侵刪。 侵權投訴