作為一個合格的程序員白华，寫相關代碼的單元測試是最基本的要求媳板，但是提到測試，又有多少程序員知道各種測試的區(qū)別和 怎么寫好一個單元測試捌朴，為什么要寫單元測試呢，這篇文章就是這些問題的一個掃盲吧张抄，參考相關人員的文章砂蔽，作為自己學習的一個筆記。
一.先普及一下測試方法 常用測試方法：
（一）署惯、按是否查看程序內部結構分為：
1左驾、黑盒測試（Black Box Testing）：
黑盒測試是根據軟件的規(guī)格對軟件進行的測試，這類測試不考慮軟件內部的運作原理极谊，因此軟件對用戶來說就像一個黑盒子诡右。簡單來說，這種測試只關心輸入和輸出的結果轻猖，并不考慮程序的源代碼帆吻。黑盒測試分為功能測試和性能測試：
1)功能測試（function testing），是黑盒測試的一方面咙边，它檢查實際軟件的功能是否符合用戶的需求猜煮。包括邏輯功能測試、界面測試败许、易用性測試和兼容性測試友瘤。
2)性能測試（performance testing），軟件的性能主要有時間性能和空間性能兩種檐束。其中辫秧，時間性能主要指軟件的一個具體事務的響應時間，而空間性能主要指軟件運行時所消耗的系統資源被丧。
2盟戏、白盒測試（White Box Testing）：
白盒測試是把測試對象看作一個打開的盒子。利用白盒測試法進行動態(tài)測試時甥桂，需要測試軟件產品的內部結構和處理過程柿究，不需測試軟件產品的功能。與黑盒測試相反黄选，這種測試就要研究程序里面的源代碼和程序結構蝇摸。
（二）婶肩、按是否運行程序分為
1、靜態(tài)測試（static testing）：
靜態(tài)測試指測試不運行的部分貌夕，只是靜態(tài)地檢查程序代碼律歼、界面或文檔可能存在的錯誤的過程。例如測試產品說明書啡专，對此進行檢查和審閱.险毁。
2、動態(tài)測試（dynamic testing）：
動態(tài)測試是指通過運行軟件來檢驗軟件的動態(tài)行為和運行結果的正確性们童。具體操作就是輸入相應的測試數據畔况，檢查輸出結果和預期結果是否相符的過程。
（ 三）慧库、按階段分為：
1跷跪、單元測試（Unit Testing）：
單元測試是最微小規(guī)模的測試，測試的是某個功能或代碼塊齐板。典型地由程序員而非測試員來做域庇，因為它需要知道內部程序設計和編碼的細節(jié)知識。
2覆积、集成測試（Integration Testing）：
集成測試是指一個應用系統的各個部件的聯合測試听皿，以決定他們能否在一起共同工作并沒有沖突。部件可以是代碼塊宽档、獨立的應用尉姨、網絡上的客戶端或服務器端程序佩番。這種類型的測試尤其與客戶服務器和分布式系統有關促绵。一般集成測試以前，單元測試需要完成稻励。
3椎瘟、系統測試（System Testing）：
系統測試是將整個軟件系統看做一個整體進行測試覆致，包括對功能、性能肺蔚，以及軟件所運行的軟硬件環(huán)境進行測試
4煌妈、驗收測試（Accept Testing）：
驗收測試是基于客戶或最終用戶的規(guī)格書的最終測試，或基于用戶一段時間的使用后宣羊，看軟件是否滿足客戶要求璧诵。一般從功能、用戶界面仇冯、性能之宿、業(yè)務關聯性進行測試。
5苛坚、回歸測試（Regression testing）：
回歸測試是指在發(fā)生修改之后重新測試先前的測試以保證修改的正確性比被。理論上色难，軟件產生新版本，都需要進行回歸測試等缀，驗證以前發(fā)現和修復的錯誤是否在新軟件版本上再次出現枷莉、、项滑、
二 單元測試詳解
單元測試與其他測試不同，單元測試可看作是編碼工作的一部分涯贞，應該由程序員完成枪狂，也就是說，經過了單元測試的代碼才是已完成的代碼宋渔，提交產品代碼時也要同時提交測試代碼州疾。測試部門可以作一定程度的審核。對于程序員來說最關心的就是單元測試了皇拣，下面我們詳細的說一下單元測試严蓖。
1. 基本概念：
單元測試應該僅僅依賴輸入，不依賴多余的環(huán)境氧急，如果你的單元測試依賴很多環(huán)境颗胡，那么你可能需要的是集成測試。
2. 相關聯
經常與單元測試聯系起來的另外一些開發(fā)活動包括代碼走讀吩坝，靜態(tài)分析（Static analysis)和動態(tài)分析（Dynamic analysis)毒姨。靜態(tài)分析就是對軟件的源代碼進行研讀，查找錯誤或收集一些度量數據钉寝，并不需要對代碼進行編譯和執(zhí)行弧呐。動態(tài)分析就是通過觀察軟件運行時的動作，來提供執(zhí)行跟蹤嵌纲，時間分析俘枫，以及測試覆蓋度方面的信息。
3. 什么時候進行單元測試
什么時候測試逮走？單元測試越早越好鸠蚪，早到什么程度？極限編程(Extreme Programming,或簡稱XP)講究TDD师溅，即測試驅動開發(fā)邓嘹，先編寫測試代碼，再進行開發(fā)险胰。在實際的工作中汹押，可以不必過分強調先什么后什么，重要的是高效和感覺舒適起便。從經驗來看棚贾，先編寫產品函數的框架窖维，然后編寫測試函數，針對產品函數的功能編寫測試用例妙痹，然后編寫產品函數的代碼铸史，每寫一個功能點都運行測試，隨時補充測試用例怯伊。所謂先編寫產品函數的框架琳轿，是指先編寫函數空的實現，有返回值的直接返回一個合適值耿芹，編譯通過后再編寫測試代碼崭篡，這時，函數名吧秕、參數表琉闪、返回類型都應該確定下來了，所編寫的測試代碼以后需修改的可能性比較小砸彬。
如果他們首先寫好一個詳細的規(guī)格說明颠毙，測試能夠以規(guī)格說明為基礎。代碼就能夠針對它的規(guī)格說明砂碉，而不是針對自身進行測試蛀蜜。這樣的測試仍然能夠抓住編譯器的Bug，同時也能找到更多的編碼錯誤增蹭，甚至是一些規(guī)格說明中的錯誤涵防。好的規(guī)格說明可以使測試的質量更高，所以最后的結論是高質量的測試需要高質量的規(guī)格說明沪铭。
4. 一個好的單元測試用例設計
單元測試用例的設計方法有很多壮池，（它揭示了單元測試的一個基本結構：準備輸入數據、調用被測函數杀怠、斷言輸出結果椰憋。任何單元測試都可以遵循這樣一個骨架，它是我們常說的 given-when-then 三段式赔退。）橙依。
- 這里講講單元測試用例的設計原則。
a.控制每個用例的檢查點數目硕旗，最好是一個用例檢查一個點;
b.用例之間杜絕數據依賴窗骑，或者關聯影響;
c.用例不僅要覆蓋正確情況，還要測試異常情況漆枚，檢查函數健壯性;
d.拒絕無謂的斷言;
e.用例要盡可能覆蓋到較多的邏輯路徑创译，（主要有三種：正常輸入，邊界輸入墙基，非法輸入）
f.用例要做到對檢查點敏感软族，在功能失效時候能立即反饋刷喜。
g 將test類和產品類代碼剝離分開進行。建立測試類
h 將要測試的方法和組件 封裝起來 抽離出來會降低測試的難度立砸，尤其是可以提供代碼封裝性
i 測試代碼中不要包含邏輯掖疮。不然你咋知道是實現掛了還是你的測試掛了呢？
編碼實現單元測試用例的過程中颗祝，需要注意一下問題：
a.編碼規(guī)范性浊闪。為了提高程序可讀性
b.合適的注釋。注釋不是越多越好螺戳，好的注釋旨在提供有用的信息搁宾，要清楚明了，避免縮寫温峭。建議在函數頭加上注釋猛铅，統一列出函數的功能字支，輸入輸出參數凤藏，返回值，調用場景等;
c.確保代碼和注釋的一致性堕伪。如果有注釋揖庄，請在代碼變動的同時，維護相應的注釋欠雌；否則不如沒有注釋;
d.減少重復代碼蹄梢。比如每個case中都進行數據初始化，檢查數據正確性的操作富俄，就可以把這些提取為輔助函數禁炒，便于修改和維護;
e.充分使用斷言。在用例中霍比，如果對某一點的數據狀態(tài)不清楚幕袱，請用assert.一來，如果有數據異常悠瞬，可以第一時間定位到们豌；二來，可以避免因為數據問題造成用例崩潰;
f.數據邏輯隔離浅妆⊥可以考慮把用例中的數據和邏輯驗證分割開來，既可以方便維護凌外，又使得各個用例清晰易讀辩尊。
5. 單元測試用例的價值
單測的價值遠不止于這種一次性的測試，我們可以：
a.一般性用途：定位問題康辑，驗證bug ;
b.回歸運行：自動測試对省，減少手工回歸;
c.持續(xù)集成：通過累積單測蝗拿，并在每一次代碼變更時，自動運行單測蒿涎。達成對代碼的實時監(jiān)控和自動測試;
d.擴大覆蓋：持續(xù)積累單測哀托，可以逐步擴大對當前項目的測試覆蓋度;
e.策略參考：每一個case的檢查點都是對策略的解讀，讀懂白盒case劳秋，也就明了了代碼策略仓手。
