明晰單元測試

最近，身邊的一位朋友由於須要在其單位與同事分享單元測試（Unit Test，UT）方面的知識，邀我對他所準備的PPT進行審閱。在審閱的過程當中我發現，他在PPT中指出：「實際工做中，寫好程序後對程序功能的調試就是一種單元測試」。因爲我知道這位朋友並無運用單元測試的經驗，因此我問到：「你的這一認識是從哪裏得到的？」，朋友答曰：「從網上搜來的」。無獨有偶，這兩天我在微博上看到了對單元測試類似的理解：「寫好程序，編譯完，跑一跑，看看寫得對不對，這就是最簡單的UT啊！」

 

對於我這混跡於軟件行業超十載，且在工做中能常常嫺熟運用單元測試的「老鳥」來講，看到這樣的理解實在是hold不住了，以爲頗有必要寫一篇文章以正視聽（但願後面的人能「搜」到這篇文章）。

 

之因此要作「以正視聽」這件事，是由於我擔憂上面的解釋讓新人或沒有單元測試經驗的人產生一種幻覺 ——「哇，好贊誒，原來我天天都在作單元測試！」這種幻覺帶的後果，是這些人不去作真正的單元測試，且別人在說單元測試如何如什麼時候，他殊不知所云。

 

若是要用不會產生爭議的文字解釋單元測試，我想我不必定能寫得比維基百科上的好（點擊 這裏 ，或許參考個人《 專業嵌入式軟件開發 》一書更好），那請容許我從特色的角度對之加以解釋。首先，單元測試必定要寫測試代碼。測試代碼並不會最終成爲軟件產品的一部分，測試代碼經過實現各類不一樣測試用例的方式，檢查被測代碼（最終成爲軟件產品的一部分）的行爲是否如程序員所但願的那樣。讀者不難想象，測試用例中須要構建大量被測代碼所需的參數、環境等（體力活）。

 

其次，爲了簡化單元測試程序中測試用例的編寫，單元測試必定須要使用必定的測試框架，好比cxxtest、CppUnit、JUnit等等。固然，使用本身設計的測試框架也是一種選擇。

 

再次，單元測試一般（我原本想寫成「必定」，但又怕被指太絕對）須要經過獲取代碼覆蓋報告這一形式以瞭解測試效果，來自開源社區的gcov和lcov相信被很多人所知。「代碼覆蓋」是一個不小的「×××」，乃至有的人會選擇性地將其當作是「形式主義」。對於有這樣反應的人，我相信是由於他們吃過了「代碼覆蓋」這「鳥」的苦頭，由於那幫丫領導將百分百的代碼覆蓋率當成了考覈目標，結果可想而知。

 

代碼覆蓋報告的真正做用，是幫助程序員瞭解被測代碼的哪些「角落」沒有「掃過」，從而指導測試用例的編寫。若是一味地以百分百的代碼覆蓋率做爲目標，這會讓程序員承擔巨大的工做壓力。Parasoft（C++ Test工具的開發商）的一份研究報告中指出，覆蓋率超過大約80%時，團隊所承擔的工做壓力就很重了，這一報告可做爲制定具體覆蓋率的參考。

 

另外，即便以百分百的代碼覆蓋率爲實施目標，很遺憾，仍是達不到徹底保證代碼質量的目的，由於測試用例是能夠「僞造」的。在軟件行業，不論有多麼好的軟件開發方法，都依賴於程序員的專業精神，不然其效果將大打折扣，這一點對於單元測試也不例外。與其追求百分百的覆蓋率，強調測試用例的質量更具意義（OMG，如何保證測試用例的質量？）。還有，千萬不要將單元測試看成是「銀彈」。

 

抱有「我天天都在作單元測試」幻想的程序員在幻想破滅之後，又會產生另外一種錯覺 —— 「單元測試是測試人員的事」。我得對這類程序員說：「你不負責任」。程序員編寫程序後驗證其中沒有任何缺陷是理所固然的事。什麼？你沒有遺留缺陷？怎麼證實？單元測試！

 

當幻覺與錯覺都遠離咱們之後，或許有的同仁會想：「單元測試就是一種測試！管它什麼測試，目的都是爲了保證軟件質量的，那麼在乎其具體含義幹嘛呢？」不，精確掌握各詞的具體含義是爲了咱們能更高效地溝通！想想，咱們還有集成測試、系統測試，爲何要造出這些新詞？

 

後注：做者正在準備《軟件企業成功實施單元測試的關健因素研究》這一論文，現需進行問卷調查。我寫文章給您看，您參與個人問卷調查，算是禮尚往來，如何？問卷位於：

http://www.sojump.com/jq/1423894.aspx 。萬分感謝您的參與！