單元測試的步驟：
1、理解需求和設計
理解設計是很重要的，特別是要搞清楚被測試模組在整個軟體中所處的位置，這對測試的內容將會有很大的影響。需要記住的乙個原則就是：好的設計，各模組只負責完成自己的事情，層次與分工是很明確的。
在單元測試的時候，可以不用測試不屬於被測試模組所負責的功能，以減少測試用例的冗餘，整合測試的時候會有機會測試到的。
舉例：/*
* 判斷三條邊是否能夠組成三角形
* 返回值：true-是； false-否
*/bool is********(int a, int b, int c);
測試該函式的時候，只需要測試三條邊（在合法的取值範圍內的整數）是否能夠滿足兩邊之和是否大於第三邊的功能，而不需要測試三條邊是否在合法的範圍（0， 200）之間的整數，因為呼叫該函式之前，一定要先通過下面函式的檢查，要是檢查不通過，就不會執行is********函式。
/** 判斷三條邊是否合法(即：判斷三條邊都在合法的範圍內)
* 返回值：true-是； false-否
*/bool islegal(int a, int b, int c);
所以，單元測試主要是關注本單元的內部邏輯，而不用關注整個業務的邏輯，因為會有別的模組去完成相關的功能。
2、概覽源**
瀏覽一下源**，主要任務：
（1）初步檢查源**的編碼風格與規範
（2）大致估算測試工作量，比如：需要多少的測試用例、需要寫多少的驅動模組和裝模組等。
（3）確定模組的複雜程度，初步制定測試的優先順序等。
3、精讀源**
認真閱讀和分析**，主要任務：
（1）理解**的業務邏輯。
（2）檢查**與設計是否相符，如果詳細設計沒有該模組的流程圖的話，先去畫出流程圖。
（3）仔細研究邏輯複雜的模組
（4）可以採用一些檢查列表來檢查程式可能會出現的問題。如果沒有檢查列表，那麼，可以根據程式的特點，有針對性地檢查容易出問題的地方（記得把經驗總結下來供下次使用）。
4、設計測試用例
綜合運用白盒測試方法（和結合黑盒測試方法）來設計測試用例，包括功能測試、效能測試等，要達到一定的測試覆蓋率。在設計測試用例的過程中，流程圖或控制流圖是分析的好幫手。
5、搭建單元測試環境
使用xunit或自己寫的框架將有助於單元測試的實施。在這個階段主要就是寫樁模組和驅動模組，第4步所設計的測試用例是通過驅動模組傳遞給被測試模組的，然後驅動模組想辦法獲取被測試模組對資料的處理結果，並判定返回的實際結果與測試用例的預期結果是否一致，通過測試框架來記錄執行的結果，對於出現的錯誤，還需要統計錯誤的資訊，供執行完之後分析。
。這樣的測試還是沒有擺脫手工測試方式，效率是低下的。同時，對於測試結果是否通過測試也不要使用printf方式列印被測試函式的返回結果值，避免要人工去檢查結果。
6、執行測試
執行寫好的驅動模組完成對被測試模組的測試。
7、補充和完善測試用例
單元測試也是個循序漸進的過程，可能一開始考慮的不夠全面，或預期的覆蓋標準太低，需要在測試過程中不斷補充測試用例，直到滿足要求為止。
8、分析結果，給出評價
根據測試的結果分析、查詢錯誤的原因，並找到解決的辦法。測試結束之後，根據測試過程的資料統計，給出被測試物件評價。
純粹從白盒角度來設計用例，是方向性的錯誤，這是缺少實踐的書本和專家的誤導。這叫跟著**走，費力不討好。
程式中的錯誤，根據產生原因可分為兩類：**錯誤和**缺失。**缺失是程式設計師未考慮到某些輸入，未編寫對應**形成的。
白盒覆蓋基於現有**，無法發現這種錯誤。那麼，白盒覆蓋是否能發現前一種錯誤？未必！
用例必須根據程式功能設定正確的預期輸出，否則再高的白盒覆蓋也沒有意義。也就是說，程式的設計功能是用例設計工作中繞不過去的，是一切的基礎。既然如此，為什麼要純粹從白盒角度來設計用例？
我認為，類似基路徑法之類的純白盒方法都是應該拋棄的，效率低下不說，既不能發現**缺失錯誤，也容易造成忽略程式設計功能這個測試的根本依據。
白盒方法的價值在於衡量對既有**的測試完整性，也可以根據白盒覆蓋找出遺漏的用例，這些價值也是建立在用例是基於功能來設計、設定了必要的預期輸出的基礎上的。
所以，正確的方法應該是：首先根據功能來設計用例，並將資料集中起來，從「有哪些正常輸入？有哪些邊界輸入？
有哪些非法輸入」三個角度檢查完整性，這樣可以有效發現**缺失錯誤。然後，再統計白盒覆蓋，根據未覆蓋的邏輯單位，找出遺漏用例，實現高覆蓋，新加的用例也要根據設計功能設定必要的預期輸出。這樣做，即避免了掉入「跟著**走」的陷阱，白盒方法也不用起頭做起，效率高得多。
袁光東筆記曾經做過一次「程式設計師在專案開發中編寫單元測試的情況」的調查。調查結果：
1. 嚴格的在專案中執行tdd 幾乎沒有
2. 為大部份業務方法編寫單元測試，並保證方法測試通過。 佔16.6%
3. 偶爾編寫單元測試，一般情況下不寫。 佔58.3%
4. 為了應付專案檢查而寫單元測試，但並不保證方法是否測試通過。 佔8.3%
5. 從來不編寫單元測試。佔16.6%
因為調查具有一定的侷限性或片面性，調查結果並不十分精確。也基本能夠反映國內程式設計師編寫單元測試的狀況。很少有程式設計師能夠比較認真的去編寫單元測試。
那麼到底又是什麼原因呢？根據筆者參與的多個討論，主要有下面幾種原因使程式設計師不編寫單元測試。
1. 為了完成編碼任務，沒有足夠的時間編寫單元測試。編寫單元測試會導致不能按時完成編碼任務,推遲專案進度。
2. 單元測試的價值不高，完全是浪費時間。
3. 業務邏輯比較簡單，不值得編寫單元測試。
4. 不知道怎麼編寫單元測試。
5. 專案沒有要求，所以不編寫
6. 在專案的前期還是盡量去編寫單元測試，但是越到專案的後期，就越失控。
測試常常是程式設計師十分厭倦的乙個專案活動。測試能夠為我們帶來什麼？了解這些非常的重要。
測試不可能保證乙個程式是完全正確的，但是測試卻可以增強我們對程式的信心，測試可以讓我們相信程式做了我們期望它做的事情。測試能夠使我們盡量早的發現程式的bug.
乙個bug被隱藏的時間的越長，修復這個bug的代價就越大。在《快速軟體開發》一書中已引用了大量的研究資料。指出：最後才修改乙個bug的代價是在bug產生時修改它的代價的10倍。
在這裡，我們需要討論的重點是單元測試。單元測試是乙個方法層級上的測試，單元測試也是最細粒度的測試。用於測試乙個類的每乙個方法都已經滿足了方法的功能要求。
在現代軟體開發過程中，不管是xp還是rup都是十分重視單元測試。已經把單元測試作為貫穿整個開發周期的一項重要的開發活動。特別是在現代軟體開發過程中，有經常整合和漸近提交的方**。
總結出了非常好的單元測試理論和實踐:
在編寫**之前先編寫單元測試,即測試先行
單元測試是**的一部份，所有的**必須有單元測試，並使測試通過。（像在spring這些優秀的開源專案中在這方面做出了非常好的例子）
在修改**之前先修改單元測試，並使它測試通過。
在編寫**之前先編寫單元測試，會帶來非常多的好處：
在編寫**之前先編寫單元測試，並不是編寫**之前需要一次性為所有的類都事先編寫單元測試。這需要有乙個粒度的把握。最大的粒度應該控制在乙個類級別上，最合適的粒度是控制在乙個方法級別上。
先為某乙個方法編寫測試**，然後再為該方法編寫實現**，直到其測試通過後再為另乙個方法編寫測試**，如此迴圈。單元測試在這裡已經是乙個契約規範了，它規範了方法應該做什麼，實現什麼。測試**遠遠要比難以閱讀和不會及時更新的需求文件更有價值。
測試先行，鼓勵對需求的理解。如果沒有理解需求，你是不可能寫出測試**的，當然你也不可能寫出好的實現**。
測試**與其它文件相比會更有價值。當需求發生改變，實現**也相應改變。而往往需求文件，設計文件得不到及時更新。測試**相比那些過期的文件更具有價值。
測試先行可以編寫出最大覆蓋率的測試**。如果在方法的實現**編寫完後再編寫測試**，這時開發人員總是編寫乙個正確路徑的測試**。它已經很難全面的去分析其它分支邏輯。
如果我們採用測試先行，那麼就自動的完成了為所有的類都編寫測試這個實踐原則。為所有的類都編寫測試會將為你帶來非常多的好處:
我們可以很好的使用自動化測試來測試所有的類，特別是採用日構建的系統。
可以讓我們放心的為類或方法新增新的功能。我們可以很容易的修改測試**並驗證修改後的**是有用的**。
可以讓我們放心的對**進行重構和進行設計優化。重構和設計優化通常會關聯到多個類及多個方法。如果我們為所有的類都編寫了測試，我們就可以在重構**後很輕鬆的進行測試我們的修改是否正確。
為所有的類編寫測試，可以讓我們很容易的修改bug。當接到乙個bug報告後，我們總是先修改測試**，然後修改實現**，使測試成功。這樣不會因為修改乙個問題而造成新問題的產生。
良好的單元測試策略給我們增強了對程式的信心,減少了bug的產生及bug的潛伏期。降低修改bug的代價。單元測試不會是專案開發周期的某乙個生命週期，它貫穿於專案的整個生命週期，是乙個非常重要的日常開發活動。
我們已經知道了單元測試是多麼重要的。為什麼程式設計師仍然不編寫單元測試呢？為什麼程式設計師總是有理由拒絕編寫單元測試呢？
一、編寫單元測試，增加了工作負擔，會延緩專案進度?
這是筆者在多次討論和調查中程式設計師拒絕編寫單元測試的最多理由。「為了完成編碼任務，沒有足夠的時間編寫單元測試。編寫單元測試會導致不能按時完成編碼任務,推遲專案進度」。
事實上真的是這樣的嗎？軟體有著其特殊的生命週期，軟體開發也具有特殊性。
首先，我們需要提供給使用者的至少是乙個能執行的產品。絕對不能是一堆不能執行的和充滿了異味的啞**。只有能夠執行的，滿足客戶需求的**才是真正有用的**。這時**就變成產品了。
很多程式設計師只關注編寫**的完成時間，而乎略了除錯**，整合及修改和維護時間。
如果沒有單元測試，開發活動會是這樣的情景。
以乙個web應用開發為例：業務**編寫完成->打包->發布到伺服器->進行功能測試->發現問題->修改**->再打包……如此迴圈。
任何乙個web程式設計師對於這種開發情景都不會感到陌生。往往不斷的打包，發布，功能測試的時間是**編寫的10倍以上。通過整合系統來發現程式的bug，我們往往很難一下子準確的定位bug產生的地方。
應用伺服器提供的錯誤資訊對於我們來說是非常有限的。
如果為每乙個類都編寫單元測試並讓每乙個方法測試通過，又會是怎麼樣的開發情景呢？
編寫測試**->編寫業務**->執行測試方法->修改**讓測試通過->所有的類都通過測試->打包->發布到伺服器->進行功能測試->發現bug->修改測試**->修改業務**->測試通過->再打包…如此迴圈。
從上面的過程顯而易見，我們需要花費更多的編碼時間。因為需要為每乙個業務類編寫測試**。但是它並不會導致我們總體需要花費更多的時間。
我們只是可以非常輕鬆的在ide環境中執行測試方法。在**尚未打包發布之前我們就已經確保了業務**的正確性。當我們把所有通過測試的**整合到應用伺服器後，出現錯誤的機率要少得多。
當整合測試後發現bug時,我們也總是先修改測試類。保證在整合之前所有的類都經過測試通過。這樣功能測試的時間就成數量級的減少,所以總的花費時間要比沒有單元測試要少得多。
白盒 灰盒 黑盒測試區別
黑盒測試 白盒測試 灰盒測試 什麼是黑盒測試和白盒測試？黑盒測試也稱功能測試或資料驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程式看作乙個不能開啟的黑盆子，在完全不考慮程式內部結構和內部特性的情況下，測試者在程式介面進行測試，它只檢查程式功能是否按照需...
白盒測試複習內容
1物件測試基本三步驟。答 a 建立乙個物件 b 呼叫乙個方法 c 檢查呼叫的結果。2失敗和錯誤的區別。答 乙個失敗的斷言通常表示產品 中有問題，而乙個錯誤卻表示測試本身或周圍的環境存在著問題。3白盒測試及其測試覆蓋標準。答 白盒測試 也稱結構測試或邏輯驅動測試，是一種測試用例設計方法，它從程式的控制...
白盒測試與黑盒測試的比較
白盒測試 白盒測試是根據被測試程式的內部結構設計測試用例的一類測試，有人也稱它為透明盒或者玻璃盒測試，涉及到軟體設計的細節。比如單元測試一般採用白盒測試方法，並參考lld 根據程式的內部結構，比如語句的控制結構 模組間的控制結構以及內部資料結構等進行測試。黑盒測試 黑盒測試又稱功能測試 資料驅動測試...