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

　　有序狀態的發展過程中，多數企業會遇到如下問題或現象：

　　開始認識到單元測試該由開發人員去做

　　多數尚處于混沌境界的企業會認為，單元測試應由測試人去做，可能會覺得開發人員自己編碼又自己測試會陷入慣性思維，測試效果不佳。但讓測試人員現實操作幾次，又會冒出幾個難以逾越的問題，首先是測試效率，測試人員不熟悉代碼，他上手把源碼讀懂然后想辦法做測試，要知道，單元測試面對眾多瑣碎的函數，隨意一個開發人員一天就能寫一堆新函數，所以，測試人員若把單元測試做好，通常要比開發人員自測多付10倍的精力，這一情況很致命，單元測試必然難以為繼。其次，測試人員做單元測試，經常不能斷定某種現象是不是問題，還得找相應開發人員去定位，問題定位了，修正問題又是個麻煩，測試人員不擁有給產品編碼的權限，大量時間又浪費在反復溝通上。

　　所以碰過幾次壁后，多數企業都會回到這種操作方式：每個開發人員自己寫代碼，自己做單元測試(主要是模塊級白盒測試)。這是主流運作方式，非主流的，還可能間或讓兩個互相熟悉對方代碼的開發人員，交叉一下做單元測試，這也是比較有效的方式。

　　會發現只拿覆蓋率評估測試是否充分是不夠的

　　引入業界工具實施覆蓋率測試，當一個企業白盒測試做到一定程度時，會陷入一個困惑：拿覆蓋率評估測試充分與否是否足夠?為覆蓋率而覆蓋率，目標太容易達成，運行一兩個高層次的業務調用，覆蓋率很快就上去了，也即，如果有人想作弊，他完全可以只寫很少用例就讓覆蓋率滿足要求。有人就這個問題進一步思考，又產生另一個困惑：白盒測試到底測什么?測看得到的代碼嗎?代碼覆蓋率直觀的表達了可見代碼是否跑到，但如果規格有要求又忘實現了，覆蓋率能說明什么?

　　不同員工做白盒測試，效果差別巨大

　　這種現象是每個公司都會遇到的，在白盒測試推行初期表現尤為明顯。能力強的就是很少漏測，很少遺漏問題到后續階段，能力差的，盡管他很努力的想把每件事做好，漏測總還很多。

　　會有白盒測試無用論產生

　　產生白盒測試無用論，多半不是從理論上反對白盒測試，而是實踐走不通，做了不少單元測試，效果不佳，發現問題留于表面，深層次邏輯問題或接口問題發現不了，所以就認定白盒測試沒多大用處。

　　也常見一種情況，發現白盒測試沒效果會認為自己沒掌握測試方法，所以想方設法尋求“見血封喉”的致命武器，幾經努力后，仍無特效藥可買，這種情形繼續發展，白盒測試無用論很可能就產生了。

　　白盒測試沒效果的本質是難以突破“機械測試”的盲區，所謂機械測試，是指依據可得見的代碼做測試，典型的比如，被測代碼有“1+1=2”語句，所以設計用例，結果也驗證“1+1”必然是等于2的，測試用例總數、覆蓋率都達標了，就是發現不了多少問題。突破“機械測試”盲區的法寶是“按規格去設計用例”，但這么一條簡單的規則說起來容易，做起來很難，能力強的會不自覺得遵守這條規則，能力弱的常想不起來，想起來也經常無處著手，思維被條條框框禁錮住了。所以，許多時候個體很見效的白盒測試難以上升到組織行為。

　　白盒測試能否成功很大程度上依賴于牛人經理或牛人QA

　　這一點也是白盒測試推行初期經常出現的，執行力強一些的經理或QA，白盒測試可以推行成功，執行力弱一些的就不成功。不少企業因為嘗試幾次單元測試都失敗了，就全盤放棄白盒，只做黑盒測試了。

　　有一些企業堅持下來，在一兩個項目組取得成功，然后針對性的優化組織機構，比如設置專門工作推動組，建設白盒測試專家資源池，為各個項目提供測試引導人員，進一步優化流程，把白盒測試的監控點納入流程來控制。當一個企業的組織機構與流程逐步完善，白盒測試能否成功就較少依賴于個別牛人了。

　　階段化實施白盒測試，測試用例無法維護

　　集中一段時間編碼，編碼完了再集中一段時間做單元測試，單元測試完了開始集成，這時又集中時間做一次集成測試，這是多數企業實施白盒測試的模式。這一模式下，單元測試或集成測試只是特定時間段內(比如一個版本周期內的一兩星期中)才實施的活動，但產品修改代碼卻是時時刻都在進行的，毫無疑問的會帶來一個深刻問題：用例維護與產品代碼維護不同步!所以，大家就經常會看到，某個產品的第一個版本可以把單元測試完整實施一遍，而此后時不時為解決問題改代碼，或為追加功能改代碼，單元測試很難繼續，常導致單元測試只在V1版本做一遍，其后V2、V3等版本無法再做。

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