C/C++單元測試問答(摘要)

爲何要進行單元測試?  
單元測試保證局部代碼的質量
單元測試改良項目代碼的總體結構
單元測試下降測試、維護升級的成本
單元測試使開發過程適應頻繁變化的需求
單元測試有助於提高程序員的能力程序員

由誰進行測試?開發部門仍是測試部門?
應該由開發部門進行單元測試!
由測試部門進行單元測試的問題:代價高,人手不足,耽誤了測試部門對其餘測試的準備工做。
由開發部門進行單元測試的問題:擔憂影響開發進度,程序員不習慣作單元測試,測試本身編寫的代碼,難於保證測試的效果。
不管由哪一個部門作單元測試,都要面對一些問題,但開發部門所面對的問題能夠藉助工具來解決,而由測試部門進行單元測試,要麼沒法真正實施,要麼代價昂貴。數據庫

由測試部門進行單元測試爲何成本昂貴?
需屢次重複理解程序
反覆溝通須要大量時間成本
不利於發揮單元測試對代碼結構的約束機制
耽誤測試部門對其餘測試的準備工做
即便測試部門人手充裕,僅僅從效益來考慮,也不該該由測試部門進行單元測試。若是測試部門原本就人力不充裕(進行單元測試的人員需具有編碼能力),勉強由測試部門進行單元測試,結果每每是----沒有結果。編程

由開發部門進行單元測試能保證測試效果嗎?
程序員測試本身編寫的代碼,每每只考慮「正常情況」,這固然會影響測試效果。但若是所用的單元測試工具可以統計各類白盒覆蓋率,就能檢查測試效果。固然,只作到這一點仍是不夠的,由於白盒覆蓋具備逾後逾難的特色,達到必定的覆蓋率後,覆蓋率的提高會很困難。若是測試工具功能足夠強大,能提供工具幫助用戶快速地設計測試用例,達到完整的白盒覆蓋,那麼測試效果就能獲得徹底的保證。
實際上,若是沒有充分的統計數據,沒有達到足夠的測試完整性,那麼由誰作單元測試,效果都不能保證。網絡

邊編碼邊測試會影響編碼進度嗎?
傳統的單元測試是很費時費力的工做,主要時間消耗在於:編寫測試代碼、設計測試用例,若是開發工具能自動生成測試代碼,而且具備快速設計測試用例的功能,那麼測試費時就不多;另外一方面,若是測試工具還能提供數據,幫助程序員整理編程思路、快速發現錯誤,更高效地調試,那麼就能大量提升開發效率,抵銷測試所消耗的時間,不但不會影響編碼進度,甚至加快編碼進度。架構

實施單元測試須要改變開發流程嗎?
邊開發邊測試,單元測試是編碼行爲而不是測試行爲,測試代碼看做是項目代碼的一部分,程序員提交產品代碼時也要提交測試代碼和測試報告,其餘流程能夠不做任何改變。
另外一方面,在充分單元測試的基礎上,因爲具備高質量的局部代碼,良好的總體代碼結構,保證了代碼的可擴展性和可複用性,同時,自動迴歸測試支持對代碼的頻繁修改而不用擔憂引入新的錯誤,所以,開發流程天然會變得敏捷,能夠適應頻繁變化的需求,使系統分析、架構設計和後期測試的壓力減輕,天然而有效地改進了開發流程。函數

單元測試測試哪些代碼?
單元測試一般不測試很簡單的代碼,通常也不測試「邊界代碼」。很簡單的代碼容易理解,例如Get/Set函數,這裏解釋一下「邊界代碼」。「邊界代碼」是指用於與外部系統交互的代碼,例如用於處理用戶界面的代碼。數據庫、文件、網絡均可以看做是外部系統,用於讀寫數據庫或文件、或訪問網絡的代碼也能夠看做是「邊界代碼」,這類代碼應該獨立出來,能夠進行單元測試,但對這些代碼的單元測試一般不能自動驗證預期輸出,而是須要人工察看。編程時,不要把普通代碼與「邊界代碼」混在一塊兒,例如,不要把各類運算直接寫在界面類中,作到了這一點,絕大多數代碼均可以進行單元測試。工具

實際工做中,單元測試能實現什麼程度的測試覆蓋?
單元測試的最低要求是100%語句覆蓋,這個覆蓋率仍是不夠的,最好實現多種覆蓋的組全,比較理想的覆蓋率組合是:100%的語句、條件、分支、路徑覆蓋,另外,測試工具最好還能自動生成邊界測試用例捕捉未處理特殊輸入造成的錯誤。在達到這種覆蓋以後,殘留的編碼錯誤能夠幾乎說沒有了(設計方面的錯誤除外,這些屬於集成或系統測試的範疇)。單元測試

單元測試如何改良項目代碼的總體結構?
具備良好總體結構的代碼,應該符合「低耦合」的特性,即具備「可測性」。測試不具備「可測性」的代碼時通常會產生編譯錯誤,或者須要打樁才能測試,從而將問題暴露出來。發現問題後,重構代碼、消除不當耦合通常不難,這種簡單的重構將有效地改良代碼的總體結構。開發工具

我但願依賴全自動的工具來完成單元測試,這一想法現實嗎?
徹底自動化是一個美妙的願望,但因爲單元測試的基本特性,徹底自動化的單元測試是不現實的。
與其餘不一樣,單元測試是「隔離」的測試,要求代碼具備可測性,一個項目甚至一個文件中,不免會有些影響可測性的代碼,編譯到這些代碼時經常會產生編譯錯誤,所以,全自動的單元測試工具每每只能測試小部分代碼,即便使用某種技術手段屏蔽掉編譯錯誤,也得不償失,由於同時也屏蔽掉了改良代碼總體結構的寶貴機會。若是採用自底向上的方式,一個一個文件測試,測試一個文件前,先將該文件加入測試工程並編譯,沒有編譯錯誤時再測試,這樣能夠及時發現並消除不當耦合,使代碼具備可測性,這種非全自動的方式,能夠測試絕大多數代碼,也保證了代碼具備良好的總體結構。
另外一方面,主要由測試工具自動生成測試用例來進行測試每每沒有實際意義,由於測試工具沒法自動了解程序的功能,所以,自動測試用例一般只能發現異常之類的極端錯誤,大多數通常錯誤都是沒法發現的。測試工具最重要的不是自動生成測試用例,而是能提供快速創建和編輯測試用例的工具。測試

若是由開發部門實施單元測試,那麼測試部門要作哪些工做?推進、組織單元測試的實施。單元測試既然叫作「測試」,開發部門經常認識不到其重要性和必要性,須要由測試部門推進和協助組織實施。制定單元測試規範,培訓單元測試技術。檢查、審覈單元測試結果,保證單元測試的有效性。

相關文章
相關標籤/搜索