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

MILY: 宋體; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'">通信軟件被普遍認為是白盒測試最難實施的領域，一方面，通信軟件以C語言為主體語言，先進的白盒測試技術尚未有效滲透到這個區域，另一方面，通信軟件通常是嵌入式實時系統，搭建測試環境非常復雜，又加上通信軟件通常體積龐大、結構復雜，把通信軟件的單元測試或集成測試做好確非易事。

筆者有幸在通訊領域工作多年，近些年又因為咨詢的關系與國內眾多企業打交道，感觸頗多。國內企業普遍對白盒測試沒感覺也不重視，少數比較注重質量的公司努力嘗試了，但處處碰壁，不是缺少方法就是缺少合適的測試工具，或者因為管理不善白盒測試最終做不起來。當然，想做沒做成，找不著道的企業不在少數，許多公司一開始就走錯方向了，在叉路上徘徊很久而混然不覺。

國內通信企業在單元測試與集成測試方面做得好與不好的，差別很大，我們劃分三種境界：混沌、有序、自發，這三種境界指的就是三種發展階段。當然，這里分門別類的意義并不在于區分出高低上下，而在于嘗試指出白盒測試的發展方向，另外，對歷史經驗作一次總結，通信軟件因其復雜性，白盒測試無法一蹴而就，某些特定階段必須要親身經歷，我們劃分三種發展境界同時，也嘗試說明在各種境界下如何實施白盒測試？重點在哪？要規避哪些問題？

境界之一：混沌狀態

混沌狀態是剛實施或從未實施白盒測試的發展階段，在這個階段，一個企業內只有零星的單元測試或集成測試實踐，缺少成功案例，該階段最典型的特征是：每一個人都很忙，整天忙于市場救火。

企業上上下下誰都在忙，本該在實驗室做測試的測試人員被趕到市場一線，在客戶的機房上跳下躥，低頭忙于調測，抬頭忙于跟客戶掩飾問題。本該呆在家編碼的開發骨干也時不時被逮到現場，架調試環境，使出混身解數來定位問題，遇到棘手些問題通常要耗上數天才能定位，也有許多時候現場定位不了，就偷偷地復位一下設備，謊稱問題解決了，然后趕緊溜回公司，一行行翻閱代碼通宵達旦的繼續定位。

混沌狀態最大的特點是大家都忙于救火，系統測試的投入尚無保障，更別說代碼級的測試投入了。該階段會造就眾多“救火英雄”，而“縱火犯”的責任難以追究，按照通信業界的通行規律，一個產品60%的BUG應在白盒階段曝露，當公司尚充斥著眾多“救火英雄”時，白盒階段發現的BUG通常不到20%，甚至個別公司是零。

混沌狀態還有一個重要特點，公司成員普遍對白盒測試缺少概念，大致知道代碼審查、單元測試、集成測試該怎么去做，但一涉及具體場景，對某模塊實施單元測試或跨模塊、跨子系統實施集成測試時，通常茫無頭緒，不知從何下手。處于混沌狀態的組織，還可能流行一種觀點：產品不穩定是測試人員的責任。因為許多人認為，盡管單元測試與集成測試沒做，或做少了，只要系統測試做好總能發現所有問題的。其實這種觀點早已謬之千里了，令人費解的是，持這種觀點不在少數，為什么會這樣？就像該階段出現的特有現象，明明某個開發人員水平很差，寫的代碼老出問題，但他在市場上救過幾次大火，其兢兢業業的態度、忘我的投入，又為公司挽回多少多少損失，所以領導們毫不猶豫的將他評為“功臣”。

境界之二：有序狀態

一個企業實施過多次單元測試或集成測試，數次成功后進入到有序狀態。這個階段盡管個別項目的白盒活動不成功，但多數項目稍見成效，也有個別項目效果顯著。此時，企業內會有特定的組織負責推動白盒測試，白盒測試過程也逐漸融入研發流程，典型的例如：將白盒測試發現的問題納入統計，研發過程中會以缺陷密度（每千行代碼發現多少BUG）作為衡量白盒測試是否充分的指標，另外還會以覆蓋率指標作為檢查個人是否充分測試的依據。將白盒測試納入流程監控，主要控制一個項目是否做白盒測試，實施過程是否規范，實施結果是否合乎預期，對于不符合流程要求的行為QA有權要求返工。

進入有序狀態須滿足兩個條件：一是白盒測試在少數項目獲得成功，成為可拷貝的活動；二是實施白盒測試有組織與流程保證。如果這兩個條件無法同時滿足，說明單元測試或集成測試在這個企業中仍缺少保障，即使有人偶爾做成功了，也是不可靠的，個體行為難以轉化為組織行為。

有序狀態是通信企業白盒測試必經歷階段，多數比較漫長，快則一、兩年，慢則十余年，要有長時間技術積累，以及組織與流程的優化。另外，從有序狀態轉向自發狀態，會涉及白盒測試理念的大幅轉型，從現實操作角度考慮，這些是很難在一兩個項目周期就能跨越過去的。

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

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

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

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

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

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

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

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

4.       會有白盒測試無用論產生

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

通常，白盒測試能力強的員工編碼能力也強，測試能力差的編碼能力也差，極少聽說測試能力很強但編碼很差。所以，要讓白盒測試做得更深入、更有效，重點是解決思維方式問題，通過培訓、日常鍛煉也能起到一定效果，但終歸不明顯，畢竟項目組內個個都是得道高僧比較少見。根據實踐經驗，解決這個問題的最有效的措施是測試先行，如果編碼之前就寫用例，只能依據規格做測試設計了，這對能力強的與能力弱的都一樣，思維方式強行改變，其測試無疑是最徹底、最見效的。

從有序前期階段過渡到有序后期階段，如何看待測試代碼也有很大變化，在前期，開發是開發，測試是測試，測試操作連同測試代碼是附加的，可選的，到有序后期階段，大家會把測試代碼也看成一種產品代碼，是必需的，也自然而然納入產品維護。

境界之三：自發狀態

自發狀態是白盒測試的共產主義境界，此時生產力高度發達，設計用例的效率提高了，做測試不再是沉重負擔。所謂自發，就像共產主義社會里勞動是個人意愿而非生存手段，開發人員自測也上升到個人意愿，即使領導不強制，流程也不限定白盒測試必須要做，開發人員仍自愿去做測試。自發狀態是白盒測試的最高境界，它的典型表現特征是：白盒測試已成員工的普遍行為與自發行為。

白盒測試進入自發狀態，必須經歷兩大轉變，一是測試效率要有數倍提高，這是基礎，二是測試實踐能夠深入，能有效發現各種問題。目前已有一些公司經歷過這兩種轉變，前者測試效率提高主要依賴于在線測試、持續測試、黑盒調測等理念（詳情請見《第4代白盒測試方法概述》中拉通測試小循環、拉通研發大循環、調試轉化為測試等章節），而后者有效發現問題，測試先行（TDD）已接受廣泛的實踐檢驗。當上述兩大轉變完成了，白盒測試就成為每位員工的必須行為，就像調試操作，每位員工寫完代碼，正常都要“調一調”，在自發境界下，隨時“測一測”是每位員工自然而然要做的事。自發境界下的一個組織，實際操作中“測一測”很大程度上代替了“調一調”，這時，員工數月不開調試器是常見的現象，因為“測一測”對開發人員來說是讓程序跑起來最經濟實惠的手段，也是查錯、檢錯最便利的方式，使用調試器并非必需。

在自發境界下，時時測試、持續測試已成一種風氣。另一方面，員工從領導層到基層，都普遍對白盒測試有著深入認識，知道白盒測試應該“有所為有所不為”，企業培養了一批白盒測試專家，他們很清楚哪些被測對象是可以做白盒測試的，哪些不大容易做。即使處于白盒測試最高境界，也并非所有系統都適合完整的做測試，尤其那些嚴重依賴特定硬件環境的軟件層，當白盒專家識別出哪些模塊不宜做單元測試或集成測試后，他會考慮替代方案，比如加強代碼審查、加強同行評審、為特定接口追加模擬器設計等。

總結

本文描述了通信業界的白盒測試三種境界：混沌、有序、自發，這三種境界反映了通信企業在白盒測試領域的一般發展過程。從混沌狀態升級到有序狀態，核心焦點是要解決測試效率的問題，只要效率提高了，一個組織是很容易從混沌狀態進階到有序狀態的初級階段，接著通過組織結構與流程措施的優化，鞏固已有成果，然后著重解決持續測試與深入測試的問題，解決好了就升級到有序的高級階段，升級的關鍵在于“持續測試”這個理念的轉型。從有序狀態進階到自發狀態，涉及測試效率與測試質量的全面提升，操作模式會有很大變化，測試工具是關鍵，工具不僅方便易用、測試效率奇高，而且要方便讓大家從“調一調”向“測一測”轉變。

上述企業白盒測試三種境界，可與孔夫子的人生境界相比擬，孔夫子說：吾十有五，而志于學，三十而立，四十而不惑，五十而知天命，六十而耳順，七十從心所欲，不逾矩。

“十有五而志于學”，這是混沌境界，“志于學”三字點出該階段要做的事，對于白盒測試來說，處于混沌狀態下的企業要勇于嘗試，否則永遠是原地踏步，沒有進步；“三十而立，四十而不惑”對應于有序境界，此時白盒測試已找到門道，“不惑”是堅定自己的信仰，持續做下去，持續優化下去，所以，處于有序狀態的企業貴在堅持；“七十從心所欲，不逾矩”，這是自發境界，老夫子的從心所欲，并非無限制的為所欲為（要不，孔圣人不該叫圣人，而應該叫神人），關鍵是“不逾矩”，知道規矩在哪才能不逾矩，才能從心所欲，所以，自發境界下的白盒測試還要“有所為有所不為”。我們概括一下：企業白盒測試處在混沌狀態貴在嘗試，處在有序狀態貴在堅持，處在自發狀態貴在自知。

原文轉自：http://www.kjueaiud.com