通信軟件白盒測試的三種境界(3)

　　不間斷的代碼修改與階段化的白盒測試明顯不協調，這問題表面看起來并不嚴重，解決起來卻遠沒想象的簡單，該問題可以上升到操作模式問題，解決這個問題，必然要引入一種時時測試的模式，很自然，大家馬上猜得出用什么模式?就是持續集成!

　　或許有人會覺得，為讓白盒測試在版本周期內堅持做下去，不見非得引入持續集成吧?試想一下，從編碼到版本進入維護，開發人員獨立無干擾的編碼時間有多少?而從兩兩開始集成之后，又占去多少時間?無疑后者占去大部分時間。如果開始集成后的每次版本修改都有測試跟進，大家豈非天天寫測試用例，這不是持續集成是什么?如果不想天天補充用例，隔周、隔月，或隔一個版本補充用例，怎知你增補的用例會覆蓋全部變動過的代碼?

　　通信領域的代碼普遍很龐大、很復雜，一個版本周期通常是 30~40星期，從開始編碼到第一次兩兩合版本，通常是2~3周時間，之后就進入持續集成測試的階段，該階段會延續很長時間，通常10周以上，所以，如果堅持階段性測試，必然導致白盒測試難以為繼，每個人寫的用例難以維護，寫一次用一次，然后就扔了。

　　為清晰起見，我們將階段性測試稱作一次測試，與之相對的持續集成方式下的測試稱作持續測試。盡管很多人不認為階段性測試的用例只用一次，但現實情況好不到哪兒去，集中一段時間寫的用例，當源碼有較多修改后，再集中一段時間維護舊用例會很痛苦。

　　每個研發階段結束，嘗試將每個人的用例合并起來

　　合并測試用例是一次測試思維的自然延續，其出發點是為了讓測試集能更好的維護，但事與愿違，越是合并的用例越是無法維護，除非被測系統非常簡單，也很少去變更，當然，如果系統很少變更，維護用例的需求也不強烈了。

　　合并之前的腳本尚有明確的維護責任人，但合并之后測試腳本該由誰去維護?況且按照經驗，一次充分的單元測試，測試腳本的規模應與被測代碼相當，各人編寫用例的運行環境又千差萬別，如此龐大的體系合起來并不容易，合起來后也無法維護。所以，合并用例是企業處于有序狀態特定階段才做的事，通常只做幾次，達不到效果就不會反復去做了。事實上，遵循一次測試模式的組織內，大家自己管自己，用例不合并都已經很難維護了。

　　仍有員工試著要上單板做單元測試

　　嵌入式產品的單元測試該不該上單板?這個問題更多的可歸結為實踐上可不可行，從理論上講沒人規定單元測試就不能上單板。但現實操作中，通信產品上單板做單元測試大部分都失敗，失敗的情形筆者見過的不是兩三個，而是十數個，尤其是大公司，每個產品組中總有一些自信滿滿的員工，都愿意相信上單板做UT才是正道。

　　當然，本文并不否定上單板做UT就不能成功，而是說成功的機率比較低，況且，是否成功的定義也是因人而異，見仁見智的。打個比方說，一個開發人員寫一天代碼，然后用一天時間就把新寫的代碼測試完了，這種情況下，白盒測試是可維持的，做得下去的，而當種種條件限制(比如上單板每次下載都要消耗很長時間，單元測試面對初始代碼，沒測幾分鐘板上程序就會跑飛)，寫1天的代碼要用10天才能測完，這種測試是很難維持的。

　　上單板做單元測試的致命因素是測試效率，試想一下，主流通信軟件使用C語言，想把純軟件C語言工程的白盒測試做好，相對java、C++等工程已屬不易，上單板在實時操作系統下把UT做成功，更是難上加難。所以，依據實踐的推論，通信軟件的單元測試應在仿真環境下按純軟件的方式去做，集成測試倒是可以上單板，在真實環境下去做。

　　任何事物都有3種發展方向：前進、原地踏步、倒退，上面我們描述了白盒測試在有序境界下的行為特征，字里行間還點出了各種行為的改進方向，有針對性的改進了，白盒測試就不斷前進，反之出現倒退，回到混沌狀態。比如在推行初期，白盒測試能否成功很大程度受項目組的執行力度影響，改進這一點須要優化組織結構與流程方法，若任其自然，在個別項目已成功的白盒實踐仍無法拷貝到其它項目。

　　有序狀態介乎混沌狀態與自發狀態之間，因其時間跨度較長，我們還可經細分出有序初期階段與有序后期階段，在有序初期階段什么都不規范，白盒測試也常在成功與不成功之間晃動，而在有序后期階段，應該具備某些自發狀態的表現特征了。具體而言，有序狀態向自發狀態發展，要跨越兩大考驗，其一，要解決一次測試的問題，要向持續測試過渡，其二，要在組織運作層面解決“機械測試”的問題，上面提到不同員工做測試效果差別很大，有差別是正常的(否則優秀員工無法稱之為優秀)，但能否將能力差異對結果影響縮小到系統測試那樣呢?

原文轉自：http://www.uml.org.cn/Test/200709172.asp