1,單元測試

單元測試試模組測試和整合測試的基礎

是指對程式中單獨的一個單元進行測試（類，或類的集合甚至是函式）

其主要工作分為兩個步驟：人工靜態檢查和動態執行跟蹤

這些工作主要是由程式編寫者來進行的，因為他們對自己寫的程式碼是最瞭解的

單元測試的主要目標是：

驗證程式碼和設計相符合 

跟蹤需求和設計的實現

發現設計和需求中存在的缺陷

發現在編碼過程中引入的錯誤

也可以說單元測試的總目標就是驗證開發人員書寫的編碼是否能按照其設計的方式執行並生成符合預期的結果，確保產生符合其需求的可靠程式單元

2.單元測試和整合測試，系統測試的區別

（1）單元測試與整合測試的區別主要在與測試物件不同

單元測試的物件是程式中的類，包或者函式等

整合測試的物件是概念設計時規劃好的模組，這些模組通常是分給不同的工作組開發的

單元測試的主要測試方法是基於程式碼的白盒測試

而整合測試主要是基於功能的黑盒測試

由於只有單元測試通過之後才能進行整合測試，所以單元測試是整合測試的基礎，直接影響著整合測試

（2）單元測試和系統測試的主要區別是測試的性質不同

系統測試是站在使用者的角度來看待系統並進行測試的，是基於需求規格說明書的

它是一種後期測試，發現錯誤後的定位工作也比較困難

3.單元測試環境

單元測試的環境並不是系統交付後的具體環境，應建立一個滿足單元測試要求的環境才能順利的做好測試工作

由於一個單元並不是一個獨立的程式，所以在測試時需要考慮他和外界的聯絡，因此要用到一些輔助模組，用來模擬被測單元與其他模組的關係

輔助模組分為兩種

（1）驅動模組：相當於被測單元的主程式

（2）樁模組：用於代替被測單元呼叫的子單元

這樣被測單元和與他相關的驅動模組以及樁模組共同構成了一個“測試環境”

4.單元測試策略

由於單元模組的好壞直接影響到整個系統的效能

所以為了提供單元測試的質量，在測試的時候還要使用一些測試策略，如：

自頂向下的單元測試策略

自底向上的單元測試策略

孤立的單元測試策略

（1）自頂向下的單元測試策略

從最頂層開始，用樁模組代替呼叫的單元，對頂層進行單元測試

對第二層測試時，用已經測試過的頂層作為驅動單元，編寫新的樁模組

以此類推，直到全部單元測試結束

優點：可以在整合測試之前為系統提供早期的整合途徑

缺點：程式被樁模組控制，隨著測試的進一步進行，測試過程將會變得很複雜

（2）自底向上的單元測試策略

先對程式的最底層進行測試，使用驅動模組代替呼叫它的上層

對上一層進行測試時，用已經測試過的單元作為樁模組，併為測試單元編寫新的驅動模組

以此類推，直至全部單元測試結束

優點：不需要獨立設計樁模組，可以直接從功能設計中獲取測試用例，可以為系統提供早期的整合路徑，在詳細設計文件中缺少結構細節時可以用該策略

缺點：隨著單元測試的不斷進行，測試工作變得十分複雜

（3）獨孤立測試

孤立測試的策略不需要考慮每個單元之間的關係，分別為每個單元單獨設計樁模組和驅動模組逐一完成所有測試

優點：方法簡單，容易操作，因此所需測試的時間短，能夠達到高覆蓋率

3.單元測試分析

在進行單元測試時，測試人員要依據詳細設計規格說明和源程式清單，理解模組的I/O條件和模組的邏輯結構

從以下五個方面進行考慮

（1）模組介面：如果資料在模組接口出錯，不能正確的輸入和輸出資料就無法進行下一步的工作

（2）區域性資料結構：區域性資料結構往往是錯誤的根源，對其檢查主要是為了保證臨時儲存在模組內的資料在程式執行過程中完整正確

（3）獨立路徑：單元測試的基本任務是保證模組中的每條語句至少執行一次，對重要的獨立路徑進行測試往往會發現大量的錯誤

（4）出錯處理：一個好的設計應能預見各種出錯條件，並進行適當的出錯處理，即預設各種出錯處理通路

（5）邊界條件：邊界條件是指在程式中判斷或迴圈的操作接線的邊緣條件，軟體經常在這類邊界上出現錯誤

4.單元測試的測試用例設計原則

設計步驟：

（1）為系統執行設計測試用例

（2）為正面測試設計測試用例

（3）為負面測試設計測試用例

（4）為滿足特殊需求設計用例

（5）為程式碼覆蓋設計測試用例

（6）為覆蓋率指標完成測試用例的設計

5.整合測試的基本概念

整合測試時介於單元測試和系統測試之間的過度階段，與軟體概要設計階段相對應，是單元測試的擴充套件和延伸

整合測試和系統測試的區別：

（1）測試物件：整合測試的測試物件是通過了單元測試的各個模組組成的構建或者子系統，而系統測試除了軟體之外還包括計算機硬體及相關的外圍裝置等

（2）測試方法：整合測試主要是黑盒白盒測試結合，又稱為灰盒測試，系統測試主要是黑盒測試

（3）測試內容：整合測試的內容是各個程式單元或構件間的介面，以及單元整合之後的功能，系統測試的內容是驗證整個系統的功能和其他肺功能需求是否實現

（4）測試目的：整合測試的目的是為了發現單元之間介面的錯誤，系統測試的目的是通過與系統需求說明書相比較之後發現軟體與系統定義不符合或矛盾的地方

（5）測試角度：整合測試多是站在測試人員的角度開展的以便發現更多的問題，系統測試則更多是站在使用者的角度開展的

6.整合測試策略

整合測試的策略是指被測軟體模組的整合方式

（1）基於分解的整合策略

基於分解的整合策略又分為增量式和非增量式

一次性整合方式：

是一種非增量式的整合測試，將所有系統構件一次性整合到一起進行測試，目的是在最短的時間內將系統組裝起來，使用最少的測試來驗證整個系統

適用範圍：

一個維護性或功能增強型的專案，修改或增強的部分很少

被測系統比較小，並且它的每個構件都經過了充分的單元測試

產品使用了嚴格的淨室軟體工程過程，每個開發階段的質量和單元測試的質量都非常高

自頂向下的增量式整合：

此方式採用了與設計一樣的順序，將單元按系統結構的層次，沿控制層次自頂向下逐步整合

適用範圍：

產品控制結構比較清晰穩定

產品的高層介面變化很小，底層介面可能經常需要修改

產品的控制模組具有較大的技術風險，需要儘早被驗證

希望儘早能夠看到產品的系統功能行為

自底向上的增量式整合：

適用範圍：

底層介面比較穩定，高層介面變化比較頻繁的產品

底層單元比較早被開發完畢的產品

混合的增量式（三明治）整合

該方式將系統劃分成3層，中間一層為目標層，對上一層採用自頂向下，對下一層採用自底向上，最後測試在目標層彙總

這種方式結合了自頂向下和自底向上的優點，缺點是對目標層測試不夠徹底，大部分軟體開發專案都可以使用

（2）基於功能的整合

該策略從功能的角度出發，按照功能的關鍵程度對模組的繼承順序進行組織

優點是：採用該方法，可以儘快的看到優先順序高的功能的實現，並驗證這些功能的正確性

適用範圍：

關鍵功能具有較大風險的產品

技術探索型的專案，其功能的實現遠比質量更關鍵

對於功能實現沒有把握的產品