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

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

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

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

　　境界之一：混沌狀態

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

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

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

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

　　境界之二：有序狀態

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

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

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

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