前幾天我在微博上發出了一個STB-010（
軟件測試在線公益課程系列）報名通知的帖子，這一講的題目是“軟件測試黒盒技術與應用 - 狀態轉換測試方法”，立即引來了一些討論。
比如朱少民老師就指出：“人們喜歡將軟件測試分為白盒、黑盒方法，雖然方法論上是成立的，從完全不同的方式去看待SUT，有其不同的應用場景，但是這種劃分越來越感覺不合適，如將等價類劃分、邊界值分析...等歸為黑盒方法，而它們完全可在代碼測試上*透明*應用，如針對參數傳遞、內部變量等進行測試，是時候重新審視測試方法體系了。”
我個人對上述觀點總體上是表示認同的。不過細微之處還可以深究下。
比如，“將等價類劃分、邊界值分析等歸為
黑盒測試技術”與“它們完全可在代碼測試上*透明*應用”，我并不認為這二者前后矛盾！“黑盒”是一種思想，將當前正在考慮的問題看作一個黑匣子，忽略其內部實現的細節，從外部考慮其行為表現。換句話說，此時我們正站在更高一級別的抽象層次上看待問題。
這個黑匣子可能很大，比如是整個被測系統；它也可以很小，比如對應到一個函數。因此，我們可以將各種黑盒
測試技術應用到整個系統層面，也可以在代碼層面應用他們。實際上，“等價類劃分、邊界值分析”等只是一些測試技術，如何使用這些測試技術，完全取決于上下文，這個觀點也是“上下文驅動測試學派（Context-Driven Testing School）”所倡導的。
有不少人仍然認為“只要在代碼層面做測試，一定指的就是
白盒測試”。我們首先來看看一些白盒測試的定義。
ISTQB定義White-box Testing為“Testing based on an analysis of the internal structure of the component or system.”該定義認為，不論是在
單元測試階段還是
系統測試階段，只要關注的是被測對象內部的結構，就歸為白盒測試。比如關心某段代碼的各種測試覆蓋情況（分支覆蓋、條件覆蓋等），屬于白盒測試的范疇，這點相信大多數人能夠理解。但是另外一些情況也許就不那么容易理解了，比如在GUI測試中，測試人員檢查菜單調用的是否正確（主菜單和各層子菜單的嵌套調用情況），而不關心每個菜單內容的正確性與否時，就是在做白盒測試了。
我個人覺得這樣理解白盒測試有些牽強。菜單的調用結構是否正確，也不妨認為是系統
功能測試的一部分，此時也是把系統當做黑盒來測試的。如果測試人員通過閱讀分析代碼來判斷這種菜單調用的具體實現是否正確時，這倒可以歸為白盒測試。當然，不論黑盒、白盒，只是個概念而已，重要的是想清楚在什么時候應該做什么樣的測試，應該完成哪些具體的測試活動。
再回到前面的問題，“只要在代碼層面做測試，一定指的就是白盒測試”嗎？答案是否定的。原因有二：如果是通過閱讀代碼來了解SUT，那么代碼只是一種
學習的手段，就像有時需要通過閱讀文檔來了解被測系統一樣，看過代碼之后自然可以做黑盒測試；對于任何一個函數或者類，如果把它作為一個黑匣子，考慮它實現的主要功能時，使用等價類或邊界值等測試技術對它進行分析，那么我們自然是在做黑盒測試。
可見，是做黑盒還是白盒測試，與是否閱讀代碼沒有直接的關系。假如黑盒測試是把被測對象當作一個黑匣子來看，那么白盒測試就是打開這個黑匣子，深入內部挖掘細節的測試過程。當然，由于代碼內部包含很多實現細節，基于代碼做測試的時候，往往比純粹的基于需求文檔做測試想到更多的測試點，也有人把這稱為介于黑盒與白盒之間的所謂灰盒測試。
“黑盒”與“白盒”的抽象層次
既然“黑盒”與“白盒”分屬于不同的抽象層次，而抽象又是分很多層的，那么當我們討論某測試是黑盒還是白盒時，就離不開具體的測試上下文了，因為所謂的“黑盒”與“白盒”是相對而言的。這就像當我們討論“集成測試”時，此“集成測試”非彼“集成測試”，一個系統中從單元、模塊、子系統、系統等各個層次的接口很多，討論的雙方一定要先明確是在哪個層次上討論“集成測試”的問題，這樣討論的結果才有意義。
“黑盒”與“白盒”分屬于不同的抽象層次上，測試人員應該更多關注黑盒測試，還是更多關注白盒測試，或者二者都應給予足夠的關注？
朱老師的另外一個帖子：“當系統復雜時有必要簡化問題，減少內部干擾，把系統看作一個整體（黑盒），搞清楚系統邊界、接口、環境。只有此時(宏觀層面上)黑盒方法是有意義的。而我們不能認識系統、無法理解系統/業務結構的時代可以過去了，我們應能夠徹底搞清楚代碼、數據、業務及其結構、控制流等，軟件測試才是有效、充分的。”
如果這段話中的“我們”泛指的是“測試團隊”，我深表認同。對于每一個測試人員是否也要黑盒白盒通吃，可能要根據具體的測試上下文（產品和項目復雜度、人員技能水平等）來確定了，這屬于一個測試項目具體的測試策略的問題。但是這并不妨礙每個測試人員把掌握黑盒與白盒測試技術作為自己努力的目標和方向。
為什么說“同時做好黑盒與白盒測試，軟件測試才是有效、充分的呢？”舉個例子來說明。
有這樣一段代碼，輸出0~99共100位數字：
int x;
for(x=0; x<100; x++);
cout<<x;
結果由于程序員粗心，多加了一個分號，導致實際輸出的只是100而已。這種錯誤是比較常見的，如果把這一小段代碼呈現在我們面前，我們用代碼review的方式很容易就能找出這個bug。但是現在試想一下，把這段代碼放到一個有幾百萬行代碼甚至更大的一個系統中，通過代碼review找出這個bug，無異于大海撈針！
況且，增加一個多余的分號并沒有違反什么語法規則，編譯器也只是會認為這是一個循環體為空的循環語句而已，并不會有錯誤提示。
您可能會說，這簡單，用黑盒測試的方法運行一遍基本功能，很容易就發現了。但是，誰又能保證黑盒測試可以覆蓋所有的bug呢？畢竟，測試是無窮無盡的，永遠也執行不完，而漏測是必然的。
可見，單單用白盒或者黑盒的方法都不是絕對保險的，并且黑盒測試和白盒測試由于他們的視角不一樣、所處的抽象層次不一樣，能夠發現的缺陷類型、發現缺陷的難易程度、發現缺陷的成本多少、對測試人員的技能要求等都不一樣，有效地將二者結合起來使用、互為補充，才能使測試效果最優。
結論
不必太在意“黑盒測試”與“白盒測試”具體的定義，他們只是輔助我們做好實際測試工作的一些概念而已（您甚至可以有自己的一套定義、一套術語）；
“黑盒”與“白盒”體現的是測試人員思考問題的一種方式，“黑盒”將被測對象當作一個黑匣子，考慮其整體表現；“白盒”將一個個黑匣子打開，深入內部探索細節。
大體上，“黑盒測試”與“白盒測試”分屬于不同的抽象層次，黑盒更偏重于概括一些，白盒更偏重于具體一些；
“黑盒”與“白盒”的抽象層次是相對的，一個系統可能有多層的抽象；
“黑盒測試”與“白盒測試”二者結合起來使用，互為補充，測試才更充分。