我曾經咨詢輔導過的一家企業，研發儀表產品，其嵌入式軟件不是很復雜，因此， 采用的CPU檔次不高，軟件的編譯環境不具備調試功能，每次代碼寫好、編譯、燒片后才能驗證軟件功能。通常，編好的軟件會埋藏一些bug，由于只能燒片后才能發現這些bug，而且編譯環境又沒有調試功能，工程師只好憑著猜測嘗試修改缺陷，然后再燒片把軟件下到設備中驗證來bug的修復情況，據估計有時他們一天要燒片三十多次，花掉了大量的時間。

最近，漢捷又遇到了一家產值近百億的高科技企業，他們的產品開發出現了軟、硬件相互等待的現象，即軟件需要硬件電路板先做好，讓軟件可以上板調試，而硬件又要求軟件先做好，才可以對硬件電路板進行硬件功能測試。這樣相互依戀的關系，導致彼此等待、相互沖突扯皮，最后項目延期。

上面兩個案例，估計很多企業都遇到類似的情況，有沒有什么方法可以解決呢？有，軟件單元測試。

在國內，鮮有企業的軟件開發人員做單元測試，不會做，更不想做。不想做的理由是：項目的進度這么緊張，哪里有時間做單元測試啊，或者，要做單元測試豈不是還要多招一些軟件工程師，不劃算！

真的是這樣嗎？十多年前，我在華為北研所帶領一個團隊負責一款產品的軟件開發工作，我本人也承擔了其實一部分底層驅動的開發工作。我們這個項目當時是北研所首批的IPD-CMM流程試點項目，從需求到設計再到編碼都是有條不紊地進行著，各個模塊的代碼編寫完成后，不僅要經過嚴格的代碼review，之后還要做單元測試。以底層驅動模塊為例，軟件和硬件有接口，最直接的接口就是兩個讀寫硬件寄存器的函數。驅動的單元測試，指的是在既不上硬件、也不跑上層應用的環境下，對驅動軟件模塊進行的獨立測試。我們在PC機的VC++集成開發環境下做驅動代碼的單元測試，把這兩個寄存器讀寫函數置換為樁（stub）函數（也就是形式上相同的假函數），并通過開一塊內存區或一個全局變量數組來模擬寄存器。通過VC++可視化編程的便利性生成圖形界面，非常方便地執行各項功能操作和查看單元測試結果。經過了單元測試，非常便捷地發現了許多軟件自身的bug，之后再和硬件進行集成測試，暴漏的更多的是軟硬件接口問題和硬件自身問題，大大縮短集成的周期，因為一是缺陷少，二是缺陷定位容易，減少了軟硬件溝通成本。單元測試雖然要花費一定的時間，然而它卻成倍地縮減了系統測試時間。該項目到系統測試階段，測試工程師測了不到一周時間，就很難能發現問題了，而以往沒有做過單元測試的項目，測上一個月都不放心。

從那個項目結束后，我開始愛上了軟件單元測試，特別是有與硬件有接口的驅動軟件，哪怕硬件電路板準備好，我也要求軟件工程師必須在方便快捷的PC機環境下先做好單元測試。在當時的華為北研所，越來越多的軟件工程師也漸漸由開始的抵觸造單元測試，到后來接受認可，因為有大量實際項目數據和案例證明，做單元測試不是延遲了項目進度，而是縮短了項目進度，同時也提升了產品質量。如，我們從實際項目統計數據來看，經過單元測試發現和解決一個缺陷所需要的工作量是單位1，則經過系統測試發現和解決一個缺陷需要的工作量是單位6。為什么單元測試會超人意料地高效呢？僅從一個方面來看好了，做過軟件的都知道，有時系統測試發現的問題，開發人員可能一個月還無法定位，而單元測試測的是各個函數，基本不存在定位問題，自然不存在耗費在定位缺陷的時間了。

如今軟件單元測試在華為早已成為一種如洗臉刷牙般的習慣。然而，我從事咨詢工作六年來，去過四十多家企業，很少能看到有哪家企業做且有效地做軟件單元測試，實為遺憾！不必說剛畢業的學生們，就是從業多年的軟件開發管理者也對單元測試存在著嚴重的誤解。如果能把單元測試有效做起來，案例中，做儀表的軟件工程師就不必每次寫完代碼，浪費大量時間去燒片測試，完全可以在PC機上把邏輯處理、計算等與硬件不相關的軟件實現進行充分地驗證。軟件開發人員寫完驅動代碼后，不必等待硬件電路板到位才讓你的代碼跑起來，通過單元測試的打樁方式，把軟件和硬件先剝離開，同樣可以讓代碼運行起來，而且更便捷，硬件很難發生的情況，在這樣的模擬環境卻很容易構造出了，因此，也就解決了軟、硬件互等的鎖死現象。

漢捷曾輔導軟件單元測試的一家臺灣企業，老總曾在美國TI工作，做IC出身，深知單元測試的重要性，他說：“IC每次流片就要花掉幾百萬、上千萬美金，因此IC工程師在流片前不得不做詳盡的單元測試，而做軟件的好像不必付如此大的代價，因而就不做單元測試了，理由是項目很緊張，可是大家卻有時間不斷地事后返工！”

我想，如果我們的企業老總、研發總監對于軟件單元測試認知程度如這家臺灣企業老總那般深刻，那么軟件單元測試就不會僅僅作為理論停留在軟件工程教科書上，它會鮮活地走進項目里，成為一種實實在在的讓項目進度加速的給力的實踐活動！