為什么要進行單元測試?  

單元測試保證局部代碼的質量

單元測試改良項目代碼的整體結構

單元測試降低測試、維護升級的成本

單元測試使開發(fā)過程適應頻繁變化的需求

單元測試有助于提升程序員的能力

由誰進行測試？開發(fā)部門還是測試部門？

應該由開發(fā)部門進行單元測試！

由測試部門進行單元測試的問題：代價高，人手不足，耽誤了測試部門對其他測試的準備工作。

由開發(fā)部門進行單元測試的問題：擔心影響開發(fā)進度，程序員不習慣做單元測試，測試自己編寫的代碼，難于保證測試的效果。

無論由哪個部門做單元測試，都要面對一些問題，但開發(fā)部門所面對的問題可以借助工具來解決，而由測試部門進行單元測試，要么無法真正實施，要么代價昂貴。

由測試部門進行單元測試為什么成本昂貴？ 

需多次重復理解程序

反復溝通需要大量時間成本

不利于發(fā)揮單元測試對代碼結構的約束機制

耽誤測試部門對其他測試的準備工作

即使測試部門人手充裕，僅僅從效益來考慮，也不應該由測試部門進行單元測試。如果測試部門本來就人力不充裕(進行單元測試的人員需具備編碼能力)，勉強由測試部門進行單元測試，結果往往是----沒有結果。

由開發(fā)部門進行單元測試能保證測試效果嗎？ 

程序員測試自己編寫的代碼，往往只考慮“正常狀況”，這當然會影響測試效果。但如果所用的單元測試工具能夠統(tǒng)計各種白盒覆蓋率，就能檢查測試效果。當然，只做到這一點還是不夠的，因為白盒覆蓋具有逾后逾難的特點，達到一定的覆蓋率后，覆蓋率的提升會很困難。如果測試工具功能足夠強大，能提供工具幫助用戶快速地設計測試用例，達到完整的白盒覆蓋，那么測試效果就能得到完全的保證。

實際上，如果沒有充分的統(tǒng)計數(shù)據(jù)，沒有達到足夠的測試完整性，那么由誰做單元測試，效果都不能保證。

邊編碼邊測試會影響編碼進度嗎？ 

傳統(tǒng)的單元測試是很費時費力的工作，主要時間消耗在于：編寫測試代碼、設計測試用例，如果開發(fā)工具能自動生成測試代碼，并且具有快速設計測試用例的功能，那么測試費時就很少；另一方面，如果測試工具還能提供數(shù)據(jù)，幫助程序員整理編程思路、快速發(fā)現(xiàn)錯誤，更高效地調試，那么就能大量提高開發(fā)效率，抵銷測試所消耗的時間，不但不會影響編碼進度，甚至加快編碼進度。

實施單元測試需要改變開發(fā)流程嗎？ 

邊開發(fā)邊測試，單元測試是編碼行為而不是測試行為，測試代碼看作是項目代碼的一部分，程序員提交產(chǎn)品代碼時也要提交測試代碼和測試報告，其他流程可以不作任何改變。

另一方面，在充分單元測試的基礎上，由于具有高質量的局部代碼，良好的整體代碼結構，保證了代碼的可擴展性和可復用性，同時，自動回歸測試支持對代碼的頻繁修改而不用擔心引入新的錯誤，因此，開發(fā)流程自然會變得敏捷，可以適應頻繁變化的需求，使系統(tǒng)分析、架構設計和后期測試的壓力減輕，自然而有效地改進了開發(fā)流程。

單元測試測試哪些代碼？

單元測試通常不測試很簡單的代碼，一般也不測試“邊界代碼”。很簡單的代碼容易理解，例如Get/Set函數(shù)，這里解釋一下“邊界代碼”。“邊界代碼”是指用于與外部系統(tǒng)交互的代碼，例如用于處理用戶界面的代碼。數(shù)據(jù)庫、文件、網(wǎng)絡都可以看作是外部系統(tǒng)，用于讀寫數(shù)據(jù)庫或文件、或訪問網(wǎng)絡的代碼也可以看作是“邊界代碼”，這類代碼應該獨立出來，可以進行單元測試，但對這些代碼的單元測試通常不能自動驗證預期輸出，而是需要人工察看。編程時，不要把普通代碼與“邊界代碼”混在一起，例如，不要把各種運算直接寫在界面類中，做到了這一點，絕大多數(shù)代碼都可以進行單元測試。

實際工作中，單元測試能實現(xiàn)什么程度的測試覆蓋？

單元測試的最低要求是100%語句覆蓋，這個覆蓋率還是不夠的，最好實現(xiàn)多種覆蓋的組全，比較理想的覆蓋率組合是：100%的語句、條件、分支、路徑覆蓋，另外，測試工具最好還能自動生成邊界測試用例捕捉未處理特殊輸入形成的錯誤。在達到這種覆蓋之后，殘留的編碼錯誤可以幾乎說沒有了（設計方面的錯誤除外，這些屬于集成或系統(tǒng)測試的范疇）。

單元測試如何改良項目代碼的整體結構？

具有良好整體結構的代碼，應該符合“低耦合”的特性，即具有“可測性”。測試不具有“可測性”的代碼時一般會產(chǎn)生編譯錯誤，或者需要打樁才能測試，從而將問題暴露出來。發(fā)現(xiàn)問題后，重構代碼、消除不當耦合一般不難，這種簡單的重構將有效地改良代碼的整體結構。

我希望依賴全自動的工具來完成單元測試，這一想法現(xiàn)實嗎？

完全自動化是一個美妙的愿望，但由于單元測試的基本特性，完全自動化的單元測試是不現(xiàn)實的。

與其他不同，單元測試是“隔離”的測試，要求代碼具有可測性，一個項目甚至一個文件中，難免會有些影響可測性的代碼，編譯到這些代碼時常常會產(chǎn)生編譯錯誤，因此，全自動的單元測試工具往往只能測試小部分代碼，即使使用某種技術手段屏蔽掉編譯錯誤，也得不償失，因為同時也屏蔽掉了改良代碼整體結構的寶貴機會。如果采用自底向上的方式，一個一個文件測試，測試一個文件前，先將該文件加入測試工程并編譯，沒有編譯錯誤時再測試，這樣可以及時發(fā)現(xiàn)并消除不當耦合，使代碼具有可測性，這種非全自動的方式，可以測試絕大多數(shù)代碼，也保證了代碼具有良好的整體結構。

另一方面，主要由測試工具自動生成測試用例來進行測試往往沒有實際意義，因為測試工具無法自動了解程序的功能，因此，自動測試用例通常只能發(fā)現(xiàn)異常之類的極端錯誤，大多數(shù)一般錯誤都是無法發(fā)現(xiàn)的。測試工具最重要的不是自動生成測試用例，而是能提供快速建立和編輯測試用例的工具。

如果由開發(fā)部門實施單元測試，那么測試部門要做哪些工作？

推動、組織單元測試的實施。單元測試既然叫做“測試”，開發(fā)部門常常認識不到其重要性和必要性，需要由測試部門推動和協(xié)助組織實施。

制定單元測試規(guī)范，培訓單元測試技術。

檢查、審核單元測試結果，保證單元測試的有效性。