單元測試知識問答[2] 軟件測試
邊編碼邊測試會影響編碼進度嗎?
傳統的單元測試是很費時費力的工作，主要時間消耗在于：編寫測試代碼、設計測試用例，如果開發工具能自動生成測試代碼，并且具有快速設計測試用例的功能，那么測試費時就很少;另一方面，如果測試工具還能提供數據，幫助程序員整理編程思路、快速發現錯誤，更高效地調試，那么就能大量提高開發效率，抵銷測試所消耗的時間，不但不會影響編碼進度，甚至加快編碼進度。
實施單元測試需要改變開發流程嗎?
邊開發邊測試，單元測試是編碼行為而不是測試行為，測試代碼看作是項目代碼的一部分，程序員提交產品代碼時也要提交測試代碼和測試報告，其他流程可以不作任何改變。
另一方面，在充分單元測試的基礎上，由于具有高質量的局部代碼，良好的整體代碼結構，保證了代碼的可擴展性和可復用性，同時，自動回歸測試支持對代碼的頻繁修改而不用擔心引入新的錯誤，因此，開發流程自然會變得敏捷，可以適應頻繁變化的需求，使系統分析、架構設計和后期測試的壓力減輕，自然而有效地改進了開發流程。
單元測試測試哪些代碼?
單元測試通常不測試很簡單的代碼，一般也不測試“邊界代碼”。很簡單的代碼容易理解，例如Get/Set函數，這里解釋一下“邊界代碼”�！斑吔绱a”是指用于與外部系統交互的代碼，例如用于處理用戶界面的代碼。數據庫、文件、網絡都可以看作是外部系統，用于讀寫數據庫或文件、或訪問網絡的代碼也可以看作是“邊界代碼”，這類代碼應該獨立出來，可以進行單元測試，但對這些代碼的單元測試通常不能自動驗證預期輸出，而是需要人工察看。編程時，不要把普通代碼與“邊界代碼”混在一起，例如，不要把各種運算直接寫在界面類中，做到了這一點，絕大多數代碼都可以進行單元測試。
實際工作中，單元測試能實現什么程度的測試覆蓋?
單元測試的最低要求是100%語句覆蓋，這個覆蓋率還是不夠的，最好實現多種覆蓋的組全，比較理想的覆蓋率組合是：100%的語句、條件、分支、路徑覆蓋，另外，測試工具最好還能自動生成邊界測試用例捕捉未處理特殊輸入形成的錯誤。在達到這種覆蓋之后，殘留的編碼錯誤可以幾乎說沒有了(設計方面的錯誤除外，這些屬于集成或系統測試的范疇)。
單元測試如何改良項目代碼的整體結構?
具有良好整體結構的代碼，應該符合“低耦合”的特性，即具有“可測性”。測試不具有“可測性”的代碼時一般會產生編譯錯誤，或者需要打樁才能測試，從而將問題暴露出來。發現問題后，重構代碼、消除不當耦合一般不難，這種簡單的重構將有效地改良代碼的整體結構。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
