單體測試簡單的講就是軟體開發人員把開發完了單個畫面或頁面（web開發）提交給獨立的測試人員進行的測試的過程。由於單體測試與其單體關聯性不大甚至沒有關聯，所以會有不少人認為單體測試分量不重，太簡單，從概念上講單體測試確實簡單，但是單體測試是以後系統測試的基礎，如果單體測試不過關沒有發現並曝漏出問題，那么對於整個系統來說將會存在很大的隱患和風險。
基本介紹
- 中文名：單體測試
- 外文名：無
- 解釋：發現單體時錯誤和漏洞
- 作用：檢查
簡介,注意事項,舉例說明,配置工程,獨立,依賴,創建測試目標,區別,
簡介
單體測試的目的是發現軟體設計人員在設計單體時錯誤和漏洞，以及開發人員的Bug和漏洞。不同的公司，不同的項目都具有自己的測試規範和要求，並且以文檔的形式記錄在案，單體測試人員應該嚴格按照測試規範和要求進行測試。但是，在實際的測試中，即使測試人員拿著具體的測試要求往往好多基本問題仍然沒有發現，那么原因何在呢？不是他的測試方法不對，也不是測試時間不充分，而是測試人員不夠嚴謹和仔細。軟體測試是一件很辛苦的工作，有些項目會專門配有測試團隊，有些可能是因為項目規模不大或者團隊人員不足而沒有專門的測試人員，開發人員之間相互進行單體測試。這時候可能是相互之間由於個人關係存在私心,導致測試結果不理想不能達到預期的要求，因為大多數軟體開發公司都會將測試出來的Bug記錄在案，在項目結束時要統計分析，甚至年終時評定年終獎作為重要的指標。
因此如果條件允許儘可能建立獨立的測試團隊，實在沒有這樣的資源，那么對測試人員必須有嚴格的要求，至少做到以下幾點： 單體測試時測試人員首先要根據測試式樣書看逐項檢查開發者是否實現；其次要按照開發式樣書的要求測試開發人員所有功能和需求是否全部實現；最後要提交測試結果報告書，開發人員修改後再測試。項目管理者要對測試結果進行抽查，如果發現Bug沒有測試出來的原因是測試人員不夠認真，這時要建立相應的處罰機制，比如說這個Bug不僅要記在開發人員身上，同時也要記在對應的測試人員身上。
注意事項
單體測試時需要注意幾點：1、建立測試計畫2、測試結果文檔化 3、測試數據規範化 4、修改及時性。
舉例說明
配置工程
為Objective-C代碼創建測試用例
為C++代碼創建測試用例
往工程中加入單體測試的第一步是創建一個新的目標，用於連編和運行相應的測試代碼。在Xcode中，您可以創建類型為“單體測試程式包（Unit Test Bundle）”的連編目標。這種目標在連編時會對您的測試代碼進行編譯，並通過一個外殼腳本來運行該代碼。在測試完成後，Xcode控制台會將所有失敗的測試點報告為錯誤。
在配置測試目標的時候，您需要決定目標的工作方式。Xcode帶有的單體測試程式包可以以兩種方式集成到您的執行程式中。一種是將測試目標配置為一個單獨的實體，您可以獨立地連編和運行主執行程式；另一種是在目標中加入依賴關係，使目標在每次連編時自動地連編您的執行程式，並進行測試。
單體測試-比較依賴於執行程式的目標和獨立的目標
在建立測試代碼的時候，您需要決定測試目標是依賴於主執行程式，還是與執行程式相獨立。這兩種技術各有各的優
獨立
目標的建立比較簡單，只在希望的時候運行。
必須手工運行，可能使用得不頻繁。
依賴
測試的自動運行比較容易。允許開發者獨立連編主執行程式。
目標的建立要求一些額外的步驟。不能使用零連線。
如果您正在寫的是一個Objective-C的程式，配置一個依賴於主執行程式的目標需要的額外步驟最少。然而，如果是一個C或者C++程式，則需要更多的工作，當然，這些工作也比較直接。
您需要做的一個重要事情是決定執行測試的頻繁程度。定期執行測試可以得到各個連編的錯誤報告。如果工程需要定期進行連編，則這種方式可以比較容易地跟蹤導致問題的代碼。
另外一個需要做的決定是在每個連編周期中希望進行哪些測試。如果您有幾千個測試用例，則可能希望只在特定的檢查點處執行測試，比如將修改提交到代碼庫之後的時刻，而不是每個連編都進行測試。將測試組合的名稱作為命令行參數傳遞給定製的執行程式，就可以指定您希望運行的測試用例了。更多的信息請參見“運行測試代碼”部分。
創建測試目標
無論是依賴於主執行程式的目標，還是獨立的目標，其初始的配置過程都是一樣的：
打開Xcode工程。
選擇工程>新建目標（Project > New Target）選單，顯示新建目標（New Target）助手視窗。
單體測試-選擇您期望的目標類型
如果您正在寫的是一個Objective-C程式，則選擇Cocoa > 單體測試程式包（Cocoa > Unit Test Bundle）目標。
如果您正在寫的是一個C/C++程式，則選擇Carbon > 單體測試程式包（Carbon > Unit Test Bundle）目標。這種目標不必使用Carbon庫。
指定目標的名稱，並點擊完成（Finish）鍵。
在目標被創建時，其初始狀態是一個獨立的目標。如果您需要的就是獨立的目標，則可以將代碼和測試用例直接加入到目標中，並開始連編。如果您需要的是依賴於主執行程式的目標，那么反過來，必須進行下面的配置：
必須使您的目標依賴於主執行程式的目標（請參見“使目標依賴於主執行程式”部分）。
如果您的程式是用C或者C++寫的，則必須在應用程式中加入代碼，來對測試進行初始化（請參見“在C和C++工程中執行依賴於主執行程式的測試”部分）。對於基於Objective-C的測試，則不需要初始化。
使目標依賴於主執行程式
為了使您的目標依賴於主執行程式，必須在Xcode工程中為其建立依賴關係：
選擇您的單體測試程式包目標。
打開該目標的查看器。
選擇一般（General）頁簽。
點擊位於視窗底部的+按鍵。
在出現的對話框中，選擇代表主執行程式的目標，並點擊增加目標（Add Target）鍵。
如果您正在連編的是一個應用程式，則還必須在程式包裝載器（Bundle Loader）和測試宿主（Test Host） 這兩個連編設定中指定應用程式的執行程式。舉例來說，如果要設定MyApp.app的執行程式路徑，需要執行如下的步驟：
選擇單體測試程式包目標。
打開該工程的查看器。
選擇連編（Build）頁簽。
選擇連線（Linking）集合。
將程式包裝載器設定賦值為$(BUILT_PRODUCTS_DIR)/MyApp.app/Contents/MacOS/MyApp。
選擇單體測試（Unit Testing）集合。
將測試宿主設定賦值為$(BUILT_PRODUCTS_DIR)/MyApp.app/Contents/MacOS/MyApp。由於它們使用的是同樣的值，所以也可以將這個設定賦值為$(BUNDLE_LOADER)。
請注意：如果您正在測試的是一個框架或者共享庫，則不必為測試宿主設定指定值。
預設情況下，程式包裝載器和測試宿主設定是沒有賦值的。對程式包裝載器進行設定告訴連線器在連線時將指定的執行程式處理為額外的框架（這種處理方式有助於在連編測試目標的時候避免產生應用程式類的引用無法識別的錯誤）。對測試宿主進行設定則告訴RunUnitTests腳本（在最後的連編階段執行）啟動指定的應用程式，並將您的測試程式包注入到該程式中。
在測試目標配置完成之後，應該將它設定為活動目標，並往目標中加入包含測試用例代碼的源檔案。在下次編譯的時候，Xcode會考察測試目標的依賴性，並首先連編您的主執行程式，之後再連編測試目標，並在完成之後運行您的測試用例。這個過程確保主程式被連編，且對應的測試用例被運行。
請注意：對於依賴於主執行程式的測試目標，只需要把將測試代碼的源檔案加入到工程中就可以了。不要將主執行程式的任何源檔案加入到測試目標中。在測試代碼運行的時候，測試目標程式包會被注入到主執行程式中，並可以訪問測試需要的任何原始碼。
在C和C++工程中執行依賴於主執行程式的測試
如果您在C++工程中使用依賴於主執行程式的測試目標，則需要在測試工程中加入一些額外的代碼，才能執行測試。由於Objective-C的動態本質，依賴於主執行程式的測試目標產生的程式包可以被自動地注入到執行程式中。而在C++中，這是不可能的。相反，您必須顯式告訴CPlusTest框架什麼時候可以安全地運行測試代碼。在Carbon應用程式中，實現這個目標的方法之一是建立一個定時器，使其處理函式在應用程式啟動完成後馬上啟動測試組件，而且具有處理事件的能力。當定時器觸發時，相應的處理函式就可以運行已經註冊完成了的測試組件，並記錄測試過程的輸出（有關如何註冊測試用例的信息，請參見“為C++代碼創建測試用例”部分）。
列表1顯示了Carbon程式中用於啟動定時器的類定義。我們需要在初始化時構造該類的一個實例（參見列表2），目的是安裝一個定時器。當定時器最終被觸發時，程式就會調用firedTimerBridge和firedTimer方法來執行實際的測試。
區別
單體測試（白盒測試）階段，不但要保證，程式能跑到和跑通所有對應本機能的開發的代碼，同時也必須保證代碼的質量（機上レビュー），是否符合規約，是否已經是最好，這個非常重要。遇到bug，及時進行確認和相關開發人員修正。單體測試完了，並將遇到bug進行修正完了，確認單體測試完畢，隨後進入結合測試階段。
結合測試(SI測試或稱為黑盒測試)，不是重複的單體測試。單體測試的時候，我們是站在理解業務的開發人員的角度上看的，能debug著進行測試，一旦進入結合測試階段，我們就是站在客戶觀點上來對應測試了（處非非得debug解決不了的測試點，特殊！）。（與開發沒有任何關聯的人，可以進入這個階段的測試。緣由是，已經不是程式的想法，而是業務的想法了。）結合測試的任務量應該至少是coding與單體測試量之和，應該最大限度做到不重複不漏。
測試的既包括單體的內容，也得把所有的異常通過case跑出來（在業務業面上正確顯示出來），該錯，不該錯，能輸入，不能輸入，多次longin不入進行lock，多人同時更新一個表，排他測試（比如，測試資料庫連線時候，可以斷網測試一下，看是否是出現我們理想的提示信息）等等。（式樣書的做成階段）在做測試票與測試點或者測試case的時候，原則上大約1K的開發內容，要出六十到七十左右的測試點，多了或許就重複了，少了是不夠用的或者不全面的。各個機能（畫面）之間比較巧妙的連線，各個測試票之間的連線巧安排，包括聯動，所有的CHECK，做儘量少的重複，儘量大的不漏。在真正進行結合測試的時候，可能會對應BUG修正的，這個時候，一定一定要控制好版本（管理）。對庫（伺服器代碼所在）的進出嚴格控制。
每天的進度統計與把握對項目的順利進行也非常重要。如果遇到式樣變更，一定要有專門的式樣變更管理，控制好限度，如果超過限度，要進行相應的協商，以免對納品日期（工期）和品質產生大的影響。
