不少公司有單元測試的需求，但單元測試到底誰來做，每個公司都不一樣。

開發寫單測

優點：

1、開發對程式碼最熟悉，而且開發技能也強，開發自己寫單元測試效率上和覆蓋率上都比較高。

2、單元測試有時候需要開發對程式碼進行部分重構才方便進行，開發自己做這些重構也比較順手。

缺點：

1、開發平時寫業務程式碼就忙不過來了，哪有時間寫單元測試？

2、大部分開發沒有太好的測試思想，單元測試可能只是寫個最簡單的用例就完了，最終可能單元測試通過，但基本的功能還是有問題，這樣的單測沒有太大作用。

測試寫單測

優點：

1、測試有比較好的測試思想，可以更好地保證用例的覆蓋。

2、通過寫單測測試能更好地瞭解具體程式碼結構、流程，對於後續的業務測試也有利。

缺點：

1、有比較好程式碼能力的測試人員不多，而且測試對程式碼沒有開發熟悉，遇上為了可測性需要重構的時候還是得開發花時間配合。

2、效率上不如開發自己寫。

無論誰來做，那到底怎樣才能做好單元測試？

如果你沒有開發背景，感覺這篇文章理解起來有難度，那你可以在學完後續的“程式碼級測試”系列的文章後，再回過頭來看一遍這篇文章，相信你會有醍醐灌頂的感覺。



什麼是單元測試？

如果把電視機的生產、測試和軟體的開發、測試進行類比，你可以發現：

• 電子元器件就像是軟體中的單元，通常是函式或者類，對單個元器件的測試就像是軟體測試中的單元測試；

• 組裝完成的功能電路板就像是軟體中的模組，對電路板的測試就像是軟體中的整合測試；

• 電視機全部組裝完成就像是軟體完成了預釋出版本，電視機全部組裝完成後的開機測試就像是軟體中的系統測試。

通過這個類比，相信你已經體會到了單元測試對於軟體整體質量的重要性，那麼單元測試到底是什麼呢？

單元測試是指，對軟體中的最小可測試單元在與程式其他部分相隔離的情況下進行檢查和驗證的工作，這裡的最小可測試單元通常是指函式或者類。

單元測試通常由開發工程師完成，一般會伴隨開發程式碼一起遞交至程式碼庫。單元測試屬於最嚴格的軟體測試手段，是最接近程式碼底層實現的驗證手段，可以在軟體開發的早期以最小的成本保證區域性程式碼的質量。

另外，單元測試都是以自動化的方式執行，所以在大量回歸測試的場景下更能帶來高收益。

同時，你還會發現，單元測試的實施過程還可以幫助開發工程師改善程式碼的設計與實現，並能在單元測試程式碼裡提供函式的使用示例，因為單元測試的具體表現形式就是對函式以各種不同輸入引數組合進行呼叫，這些呼叫方法構成了函式的使用說明。

如何做好單元測試？

要做好單元測試，你首先必須弄清楚單元測試的物件是程式碼，以及程式碼的基本特徵和產生錯誤的原因，然後你必須掌握單元測試的基本方法和主要技術手段，比如什麼是驅動程式碼、樁程式碼和Mock程式碼等。

• 程式碼的基本特徵與產生錯誤的原因

開發語言多種多樣，程式實現的功能更是千變萬化，我可以提煉出程式碼的基本特徵，並總結出程式碼缺陷的主要原因麼？答案是肯定，你靜下心來思考時，會發現其中是有規律可尋的。

因為無論是開發語言還是指令碼語言，都會有條件分支、迴圈處理和函式呼叫等最基本的邏輯控制，如果拋開程式碼需要實現的具體業務邏輯，僅看程式碼結構的話，你會發現所有的程式碼都是在對資料進行分類處理，每一次條件判定都是一次分類處理，巢狀的條件判定或者迴圈執行，也是在做分類處理。

如果有任何一個分類遺漏，都會產生缺陷；如果有任何一個分類錯誤，也會產生缺陷；如果分類正確也沒有遺漏，但是分類時的處理邏輯錯誤，也同樣會產生缺陷。

可見，要做到程式碼功能邏輯正確，必須做到分類正確並且完備無遺漏，同時每個分類的處理邏輯必須正確。

在具體的工程實踐中，開發工程師為了設計並實現邏輯功能正確的程式碼，通常會有如下的考慮過程：

1. 如果要實現正確的功能邏輯，會有哪幾種正常的輸入；

2. 是否有需要特殊處理的多種邊界輸入；

3. 各種潛在非法輸入的可能性以及如何處理。

講到這裡，你有沒有回想起我跟你分享的“等價類”。沒錯，這些開發工程師眼中的程式碼“功能點”，就是單元測試的“等價類”。

單元測試用例詳解

在實際工作中，你想做好單元測試，就必須對單元測試的用例設計有深入的理解。

通常來講，單元測試的用例是一個“輸入資料”和“預計輸出”的集合。你需要針對確定的輸入，根據邏輯功能推算出預期正確的輸出，並且以執行被測試程式碼的方式進行驗證，用一句話概括就是“在明確了程式碼需要實現的邏輯功能的基礎上，什麼輸入，應該產生什麼輸出”。

但是，對於單元測試來講，測試用例的“輸入資料”和“預計輸出”可能遠比你想得要複雜得多。

首先，讓我來解釋一下單元測試用例“輸入資料”都有哪些種類，如果你想當然的認為只有被測試函式的輸入引數是“輸入資料”的話，那就大錯特錯了。這裡我總結了幾種“輸入資料”，希望可以幫助你理解什麼才是完整的單元測試“輸入資料”：

• 被測試函式的輸入引數；

• 被測試函式內部需要讀取的全域性靜態變數；

• 被測試函式內部需要讀取的成員變數；

• 函式內部呼叫子函式獲得的資料；

• 函式內部呼叫子函式改寫的資料；

• 嵌入式系統中，在中斷呼叫時改寫的資料；

• …

後續，這篇文章的作者茹炳晟老師也深入分析了“預計輸出”的幾大分類，驅動程式碼，樁程式碼和Mock程式碼三者之間的異同點及不同功能，真的值得一讀。但由於篇幅的限制，我就不分享太多了，大家可以掃描下方的二維碼進入專欄，可試讀《軟體測試52講》的前三篇文章。即使不購買，前三篇文章也值得你去看一看。



驅動程式碼，樁程式碼和Mock程式碼三者的邏輯關係

今日福利

1. 即日起至8月18日24點：《軟體測試52講》限時團購優惠價79元/人（原價99元），掃描下圖二維碼或點選閱讀原文。

2. 訂閱專欄後，每邀請一位好友訂閱專欄，立享24元返現，上不封頂， 極客時間App/服務號立即提現。



79元，52篇好文，點選“閱讀原文”，支援原創，支援極客時間上值得一看的專欄。

趕緊了，這福利只有2天了。