第一章 單元測試的必要性和效益
1.1 什麼是單元測試？
工廠在組裝一台電視機前，會先測試所有元器件，與此類似，軟體開發過程中也要對各個**單元進行單獨的隔離的測試，這就是單元測試。
"**單元"一般是指類或函式，流行的看法是以類為"單元"，但在實際工作中，以類為測試單元並不實用，即使是比較簡單的類，例如只有三五個成員變數、十幾個成員函式的類，如果作為乙個整體來測試，做起來也過於複雜，因此，本文主張以函式為測試單元。
1.2 單元測試的必要性
缺少單元測試是專案質量不符要求，工期超時，預算超支的主要原因之一。如果缺少單元測試，編碼完成後看到的往往不是勝利的曙光，而是噩夢般的泥潭。不說別的，僅僅"對**的修改很可能會引入新的錯誤"這一點，就足於導致專案失敗。
缺少單元測試，**就會遺留大量的細小的錯誤，整合後就算能把這些錯誤找出來，總要修改吧？這就可能陷入修改，引入新的錯誤，測試，再修改，再引入新的錯誤的怪圈。
需求的變化幾乎是不可避免的，因為很多功能都是做出來、試用過才知道有沒有用、好不好用。需求的變化必然導致大範圍的**修改，於是又可能陷入修改，引入新的錯誤，測試，再修改，再引入新的錯誤的怪圈。
有了單元測試，情況就完全不同，首先單元測試使**中的錯誤減至最少，其次任何修 改都可以通過自動回歸測試來發現所引入的錯誤，從而消除修改所造成的破壞。
如果要保證專案質量，避免工期超時、預算超支，那麼，實施單元測試就是完全必要的。
1.3 單元測試的效益
保證區域性**的質量：單元測試在隔離的前提下，分別對各個**單元進行測試，能夠達到其他測試不可能達到的測試完整性，從而保證了區域性**的質量。只有區域性**的質量得到了保證，軟體產品的質量才可能得到保證。
改良專案**的整體結構：要對**進行單元測試，最起碼的前提是**能夠隔離，也就是說，要具有一定的可測性，因此，單元測試是一種有效的約束機制，這種機制將有效地改良**的整體結構。例如，如果把業務**直接寫在介面類中，將很難進行單元測試，隨意的不合理的緊耦合也會造成難於測試，單元測試使這些不好的特性得於及時發現，從而很容易進行修正。可測性是高質量**的首要特性，不具有可測性，也就無法衡量**的正確性，有了可測性，也就基本上保證了**的可擴充套件性、可復用性。
降低測試、維護公升級的成本：錯誤越早發現，修復的代價越小，另一方面，如果**經過了充分的單元測試，整合測試和系統測試就只需要關注設計方面的問題。自動回歸測試也大量降低公升級維護成本。
使開發過程適應頻繁變化的需求：單元測試自然地使開發流程變得"敏捷"，這是因為，整體結構良好的**具有較好的可擴充套件性，自動回歸測試又能保證修改不會引入新的錯誤，因此可以適應頻繁變動的需求，降低系統分析、架構設計和後期測試的壓力。
提公升程式設計師的能力：對程式設計師來說，單元測試有利於養成縝密的思維習慣，提高編寫健壯**的能力，並提高設計能力
單元測試技術
1.模組新建乙個libs包 2.導包我用的是junit 4.9 3.add as library 4.編寫測試類 注意 測試類不用寫main 方法 被測試的方法必須是 公共的 無引數的 無返回值的 執行沒有異常則綠 有異常則紅 public class mathcaltest test public...
單元測試 單元測試文章收藏
前言 前段時間公司計畫做自動化測試，自己也打算圍繞幾個點做相關調研，現在想想呢？其實對自動化測試的概念都還不是十分清晰，當時主要還是圍繞 單元測試 向qa小夥伴學習了一段時間，現由於公司重組，學習中斷，這裡簡單記錄一些單元測試好文，留待後續參考.什麼叫自動化測試？自動化測試覆蓋率？覆蓋率如何做到的？...
單元測試之Django單元測試
每個應用，自帶tests.py 整合在django的專案檔案裡，更多是開發人員寫django自動的測試執行 3.1 前後置方法執行特點 django.test.testcase類主要由前 後置處理方法和test開頭的方法組成 特點 繼承於django.test.testcase 測試用例都是test...