單元測試通常不測試很簡單的代碼，一般也不測試“邊界代碼”。很簡單的代碼容易理解，例如Get/Set函數，這里解釋一下“邊界代碼”�！斑吔绱a”是指用于與外部系統交互的代碼，例如用于處理用戶界面的代碼。數據庫、文件、網絡都可以看作是外部系統，用于讀寫數據庫或文件、或訪問網絡的代碼也可以看作是“邊界代碼”，這類代碼應該獨立出來，可以進行單元測試，但對這些代碼的單元測試通常不能自動驗證預期輸出，而是需要人工察看。編程時，不要把普通代碼與“邊界代碼”混在一起，例如，不要把各種運算直接寫在界面類中，做到了這一點，絕大多數代碼都可以進行單元測試。
實際工作中，單元測試能實現什么程度的測試覆蓋?
單元測試的最低要求是100%語句覆蓋，這個覆蓋率還是不夠的，最好實現多種覆蓋的組合，比較理想的覆蓋率組合是：100%的語句、條件、分支、路徑覆蓋，另外，測試工具最好還能自動生成邊界測試用例捕捉未處理特殊輸入形成的錯誤。在達到這種覆蓋之后，殘留的編碼錯誤可以幾乎說沒有了(設計方面的錯誤除外，這些屬于集成或系統測試的范疇)。
單元測試如何改良項目代碼的整體結構?
具有良好整體結構的代碼，應該符合“低耦合”的特性，即具有“可測性”。測試不具有“可測性”的代碼時一般會產生編譯錯誤，或者需要打樁才能測試，從而將問題暴露出來。發現問題后，重構代碼、消除不當耦合一般不難，這種簡單的重構將有效地改良代碼的整體結構。
我希望依賴全自動的工具來完成單元測試，這一想法現實嗎?
完全自動化是一個美妙的愿望，但由于單元測試的基本特性，完全自動化的單元測試是不現實的。
與其他不同，單元測試是“隔離”的測試，要求代碼具有可測性，一個項目甚至一個文件中，難免會有一些影響可測性的代碼，編譯到這些代碼時常常會產生編譯錯誤，因此，全自動的單元測試工具往往只能測試小部分代碼，即使使用某種技術手段屏蔽掉編譯錯誤，也得不償失，因為同時也屏蔽掉了改良代碼整體結構的寶貴機會。如果采用自底向上的方式，一個一個文件測試，測試一個文件前，先將該文件加入測試工程并編譯，沒有編譯錯誤時再測試，這樣可以及時發現并消除不當耦合，使代碼具有可測性，這種非全自動的方式，可以測試絕大多數代碼，也保證了代碼具有良好的整體結構。
另一方面，主要由測試工具自動生成測試用例來進行測試往往沒有實際意義，因為測試工具無法自動了解程序的功能，因此，自動測試用例通常只能發現異常之類的極端錯誤，大多數一般錯誤都是無法發現的。測試工具最重要的不是自動生成測試用例，而是能提供快速建立和編輯測試用例的工具。
如果由開發部門實施單元測試，那么測試部門要做哪些工作?
●推動、組織單元測試的實施。單元測試既然叫做“測試”，開發部門常常認識不到其重要性和必要性，需要由測試部門推動和協助組織實施。
●制定單元測試規范，培訓單元測試技術。
●檢查、審核單元測試結果，保證單元測試的有效性。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
