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