軟件測試中的單元測試的重要性
說到單元測試，這次負責的這個項目中這方面表現的很讓我傷心。帶得這幾個成員都是有兩年多的經驗了，為什么連代碼寫完了都不知道要測試，更不要說單元測試了。
一天小X很牛B的發給我一封郵件，標題：考試王已經砌底OK。內容也是簡單的兩句話，還是“考試王已經砌底OK�。。。。�！”一堆的“！”號還怕我看不見，還把郵件抄送給部門老大，表示他很厲害�？吹接谐蓡T做完模塊，當然是很高興了，合入到工程中一測試，kao，只是簡單的測試，就發現十來處BUG，而且還不包括操作方面的，我狂暈，這是什么程序啊，做為一個程序員，連最基本的程序寫好之后要測試都不知道，更不要說做單元測試了。返回修改之后，給我發了第二個版本，我要吐血，我一測，發現的新BUG只比第一次少一個，一個小小的改動，竟然引出新的問題出來。唉，我不知道是深圳的環境這樣，還是人的問題。當然這方面我也有責任，做功能開發過程中，沒有對他們的代碼進行檢視。導致在最后才發現問題。
沒多久小L也提供了他的代碼，我發現小X的問題之后，還特意招集團隊成員開個會說明這件事，結果測試一下他的功能，“不是我不明白，是世界變化快！”，也許是我老了吧，現在的軟件是不需要測試的。當時只想說一句話：“TMD，什么狗屁！”，既然有十幾處BUG，很多都是最基本的，只要稍微測試一下就能發現了。他是成員里面最拽的了，每次說什么，都要說：這個誰不知道。而且每次就他問題最多了。
發了堆牢騷，言歸正傳。要進行單元測試，模塊化代碼的能力要很強，能把代碼分解成一個函數只做一件事。這樣對于這個函數就可以專門對它做測試了，你寫測試代碼的時候就有的放矢了。CPPUnit/JUnit提供的測試柜架是個很好的東西，它把程序代碼和測試代碼分開來，不會出現像以前那樣，在代碼中添加好多用宏包含起來的測試代碼，閱讀和維護代碼的時候造成很大的困難。
采用單元測試的時候，每添加一個特性點，就要加入一組針對這一特性的測試函數。這要求對類或是函數（文件）要熟悉。不然添加的測試函數會不全面，或者測試函數本身就是錯的。再者對于修改了某一功能項/函數，要相應的去改它的測試代碼，而且每做一次BUG修改，就要加入對這一BUG的針對性測試函數。而且要運行一遍測試代碼，看這一改動有沒影響到其它函數。當然做單元測試，可以只對比較特別的函數做測試，不然隨著類成員函數的增加，測試代碼增加的速度比代碼本身還快。
做單元測試，其優點有：首先，在開發的時候，就對代碼做針對性的測試，這樣可以少出現問題，而且一出現就可以修改了，這可以省下好多調試時間，相信有好多程序員遇到就因為一個小小的問題，比如一個符號或一個數字，整整調試了一兩天時間。寫單元測試代碼可以很早的把錯誤定位出來。其次，寫程序最恐怖的就是修改BUG了，一不小心就會引入新的BUG，特別是對于代碼寫法不規范或者代碼邏輯很亂的程序，就像這次項目組中的兩位。
總結：在做項目時，如果有條件，就是時間充足（不然很多人會偷工減料），團隊成員有一定的實力，就可以考慮采用單元測試。雖然說單元測試使用對于項目哪一方面都是有好處的，但是如果條件不足，就會事倍功半的。對于能力較強的程序員，要自己養成寫測試代碼的習慣。還有一條跟單元測試沒什么關系的話題，在程序進行中，要抽出時間對成員的代碼進行檢視，問題越早發現越好。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
