單元測試和回歸測試(3)

　　單元測試應該產生可重復、一致的結果。

　　如果單元測試的結果是錯的，那一定是程序出了問題，而且這個錯誤一定是可以重復的。

　　問：如果用隨機數以增加測試的真實性，好么?

　　答：一般情況下不好，如果某個隨機數導致程序出錯，但是下一次運行又不能重復這一錯誤，于事無補。要注意我們還是要用隨機數等辦法“增加測試的真實性”，但是不是在單元測試中。單元測試不能解決所有問題，所以也不必期望它會發現所有的缺陷。

　　獨立性，單元測試的運行/通過/失敗不依賴于別的測試，可以人為構造數據，以保持單元測試的獨立性。

　　程序中的各個模塊都是互相依賴的，否則它們就不會出現在一個程序中。一般情況下，單元測試中的模塊可以直接引用其他的模塊，并期待其他的模塊能返回正確的結果。

　　如果其他的模塊很不穩定，或者其他模塊運行比較費時(如進行網絡操作)，而且對于本模塊的正確性并不起關鍵的作用，這時可以人為地構造數據以保證這個單元測試的獨立性。

　　單元測試應該覆蓋所有代碼路徑，包括錯誤處理路徑，為了保證單元測試的代碼覆蓋率，單元測試必須測試公開的和私有的函數/方法。

　　單元測試必須覆蓋所測單元的所有代碼路徑。

　　問：啊!這樣豈不是要寫很多啰里啰唆的測試方法?

　　答：對，因為程序中很多缺陷都是從這些啰里啰唆的錯誤處理中產生的。如果你的模塊中某個錯誤處理路徑很難到達，那你也許要想想是否可以把這個錯誤處理拿掉。

　　大栓：這對于那些愛寫復雜代碼的人是一個很好的懲罰，不對，是一個很好的鍛煉。

　　阿超：對，把單元測試的責任和代碼作者綁定在一起后，代碼作者就能更真切地體會到復雜代碼的副作用，因為驗證復雜代碼的正確性要困難得多。要注意的一點是：100%的代碼覆蓋率并不等同于100%的正確性。

　　單元測試應該集成到自動測試的框架中。

　　另一個重要的措施是要把單元測試自動化，這樣每個人都能很容易地運行它，并且可以使單元測試每天都運行。每個人都可以隨時在自己的機器上運行。團隊一般是在每日構建中運行單元測試的，這樣每個單元測試的錯誤就能及時被發現并得到修改。

　　單元測試必須和產品代碼一起保存和維護。

　　單元測試必須和代碼一起進行版本維護。如果不是這樣，過了一陣，代碼和單元測試就會出現不一致，而且所有代碼的作者要花時間來確認哪些是程序出現的錯誤，哪些是由于單元測試更新滯后造成的錯誤。這樣就失去了單元測試的意義，同時又給大家增加了負擔。如此折騰多次以后，大家就會覺得維護單元測試是一件很費時費力的事。

　　3、回歸測試

　　在單元測試的基礎上， 我們就能夠建立關于這一模塊的回歸測試 (Regression Test).

　　Regress 的英語定義是： return to a worse or less developed state。是倒退、退化、退步的意思。

　　在軟件項目中，如果一個模塊或功能以前是正常工作的，但是在一個新的構建中出了問題，那這個模塊就出現了一個“退步”(Regression)，從正常工作的穩定狀態退化到不正常工作的不穩定狀態。

　　在一個模塊的功能逐步完成的同時，與此功能有關的測試用例也同樣在完善中。一旦有關的測試用例通過，我們就得到了此模塊的功能基準 (Baseline) ， 一個模塊的所有單元測試就是這個模塊最初的Baseline。

　　假如，在3.1.5版本，模塊A的測試用例125是通過的，但是測試人員發現在新的版本3.1.6，這個測試用例卻失敗了，這就是一個“倒退”。在新版本上運行所有已通過的測試用例以驗證有沒有“退化”情況發生，這個過程就是一個“Regression Test”。如果這樣的“倒退”是由于模塊的功能發生了正常變化(由于設計變更的原因)引起的，那么測試用例的基準就要修改，以便和新的功能保持一致。

　　針對一個Bug Fix， 我們也要作Regression Test。

　　(1)驗證新的代碼的確把缺陷改正了。

　　(2)同時要驗證新的代碼沒有把模塊的現有功能破壞，沒有Regression。

　　所以對于“回歸測試”中的“回歸”，我們可以理解為“回歸到以前不正常的狀態”。

　　回歸測試最好要自動化，因為這樣就可以對于每一個構建快速運行所有回歸測試，以保證盡早發現問題。單元測試是回歸測試的基礎.

原文轉自：http://www.anti-gravitydesign.com