<!-- 視頻end -->
<!-- 幻燈begin -->
<!-- 幻燈end -->
<!-- 音頻begin -->
<!-- 音頻end -->
<!-- 正文begin -->
<p>不少公司有單元測試的需求，但單元測試到底誰來做，每個公司都不一樣。</p>
1 開發寫單測
優：開發對代碼最熟悉，而且開發技能也強，開發自己寫單元測試效率上和覆蓋率上都比較高。而且單元測試有時候需要開發對代碼進行部分重構才方便進行，開發自己做這些重構也比較順手。
缺：開發平時寫業務代碼就忙不過來了，哪有時間寫單元測試？而且大部分開發沒有太好的測試思想，單元測試可能只是寫個最簡單的用例就完了，最終可能單元測試通過，但基本的功能還是有問題，這樣的單測沒有太大作用。
2 測試寫單測優：測試有比較好的測試思想，可以更好地保證用例的覆蓋。而且通過寫單測測試能更好地了解具體代碼結構、流程，對於后續的業務測試也有利。
缺：有比較好代碼能力的測試人員不多，而且測試對代碼沒有開發熟悉，遇上為了可測性需要重構的時候還是得開發花時間配合。效率上不如開發自己寫。
3 無論誰來做，那到底怎樣才能做好單元測試？如果你沒有開發背景，感覺這篇文章理解起來有難度，那你可以在學完后續的“代碼級測試”系列的文章后，再回過頭來看一遍這篇文章，相信你會有醍醐灌頂的感覺。
如果把電視機的生產、測試和軟件的開發、測試進行類比，你可以發現：
電子元器件就像是軟件中的單元，通常是函數或者類，對單個元器件的測試就像是軟件測試中的單元測試；
組裝完成的功能電路板就像是軟件中的模塊，對電路板的測試就像是軟件中的集成測試；
電視機全部組裝完成就像是軟件完成了預發布版本，電視機全部組裝完成后的開機測試就像是軟件中的系統測試。
通過這個類比，相信你已經體會到了單元測試對於軟件整體質量的重要性，那么單元測試到底是什么呢？
單元測試是指，對軟件中的最小可測試單元在與程序其他部分相隔離的情況下進行檢查和驗證的工作，這里的最小可測試單元通常是指函數或者類。
單元測試通常由開發工程師完成，一般會伴隨開發代碼一起遞交至代碼庫。單元測試屬於最嚴格的軟件測試手段，是最接近代碼底層實現的驗證手段，可以在軟件開發的早期以最小的成本保證局部代碼的質量。
另外，單元測試都是以自動化的方式執行，所以在大量回歸測試的場景下更能帶來高收益。
同時，你還會發現，單元測試的實施過程還可以幫助開發工程師改善代碼的設計與實現，並能在單元測試代碼里提供函數的使用示例，因為單元測試的具體表現形式就是對函數以各種不同輸入參數組合進行調用，這些調用方法構成了函數的使用說明。
如何做好單元測試？要做好單元測試，你首先必須弄清楚單元測試的對象是代碼，以及代碼的基本特征和產生錯誤的原因，然后你必須掌握單元測試的基本方法和主要技術手段，比如什么是驅動代碼、樁代碼和 Mock 代碼等。
代碼的基本特征與產生錯誤的原因
開發語言多種多樣，程序實現的功能更是千變萬化，我可以提煉出代碼的基本特征，並總結出代碼缺陷的主要原因么？答案是肯定，你靜下心來思考時，會發現其中是有規律可尋的。
因為無論是開發語言還是腳本語言，都會有條件分支、循環處理和函數調用等最基本的邏輯控制，如果拋開代碼需要實現的具體業務邏輯，僅看代碼結構的話，你會發現所有的代碼都是在對數據進行分類處理，每一次條件判定都是一次分類處理，嵌套的條件判定或者循環執行，也是在做分類處理。
如果有任何一個分類遺漏，都會產生缺陷；如果有任何一個分類錯誤，也會產生缺陷；如果分類正確也沒有遺漏，但是分類時的處理邏輯錯誤，也同樣會產生缺陷。
可見，要做到代碼功能邏輯正確，必須做到分類正確並且完備無遺漏，同時每個分類的處理邏輯必須正確。
在具體的工程實踐中，開發工程師為了設計並實現邏輯功能正確的代碼，通常會有如下的考慮過程：
如果要實現正確的功能邏輯，會有哪幾種正常的輸入；
是否有需要特殊處理的多種邊界輸入；
各種潛在非法輸入的可能性以及如何處理。
講到這里，你有沒有回想起我跟你分享的“等價類”。沒錯，這些開發工程師眼中的代碼“功能點”，就是單元測試的“等價類”。
單元測試用例詳解在實際工作中，你想做好單元測試，就必須對單元測試的用例設計有深入的理解。
通常來講，單元測試的用例是一個“輸入數據”和“預計輸出”的集合。你需要針對確定的輸入，根據邏輯功能推算出預期正確的輸出，並且以執行被測試代碼的方式進行驗證，用一句話概括就是“在明確了代碼需要實現的邏輯功能的基礎上，什么輸入，應該產生什么輸出”。
但是，對於單元測試來講，測試用例的“輸入數據”和“預計輸出”可能遠比你想得要復雜得多。
首先，讓我來解釋一下單元測試用例“輸入數據”都有哪些種類，如果你想當然的認為只有被測試函數的輸入參數是“輸入數據”的話，那就大錯特錯了。這里我總結了幾種“輸入數據”，希望可以幫助你理解什么才是完整的單元測試“輸入數據”：
被測試函數的輸入參數；
被測試函數內部需要讀取的全局靜態變量；
被測試函數內部需要讀取的成員變量；
函數內部調用子函數獲得的數據；
函數內部調用子函數改寫的數據；
嵌入式系統中，在中斷調用時改寫的數據；
…
后續，這篇文章的作者茹炳晟老師也深入分析了“預計輸出”的幾大分類，驅動代碼，樁代碼和 Mock 代碼三者之間的異同點及不同功能，真的值得一讀。但由於篇幅的限制，我就不分享太多了，大家可以掃描下方的二維碼進入專欄，可試讀《軟件測試 52 講》的前三篇文章。即使不購買，前三篇文章也值得你去看一看。
驅動代碼，樁代碼和 Mock 代碼三者的邏輯關系
4 今日福利即日起至 8 月 18 日 24 點：《軟件測試 52 講》限時團購優惠價 79 元 / 人（原價 99 元），掃描下圖二維碼或點擊閱讀原文。
訂閱專欄后，每邀請一位好友訂閱專欄，立享 24 元返現，上不封頂， 極客時間 App/ 服務號立即提現。
79 元，52 篇好文，點擊“閱讀原文”，支持原創，支持極客時間上值得一看的專欄。
趕緊了，這福利只有 2 天了。
本文來自大風號，僅代表大風號自媒體觀點。 