對於黑盒、白盒與灰盒測試方法的理解，幾年前我在某乎做過乙個概念性的回答，當時提問者詢問：如何跟非技術人員解釋黑盒、白盒、灰盒測試的區別？
我的回答原文如下：
既然是對非技術人員解釋，就不能用專業術語。
這樣說吧，有個打孔機，類似這樣。
紙條從盒子左方插入，從右方出來時，分別打出圓形、正方形、三角形三個樣式的孔。
某天，打出來的紙條，只有一種圖形。
黑盒測試員只能說：「這個打孔機壞了！」
灰盒測試員把打孔機的蓋子掀開，發現打孔機的造型原來是這樣的。
於是他說：「機器仍能打孔，說明主機沒壞；三個樁子也都是好的；但只列印出了圓形，可能因為連線正方形和三角形樁子的地方有問題。」
白盒測試員把機器拆開，檢視內部的電線、電路、控制器等等，發現連線正方形和三角形的電線燒壞了，於是說：「原因找到了，換根電線吧。」
###@@@###華麗的分割線###
彼時，我還是一位測試小鳥，在研習了不少理論知識後，回答了這個問題。現在，我算不上測試老鳥，但能算個測試大鳥，在工作中，越發頻繁地接觸這三種測試方法。
如果你要問我哪種測試方法更好，我不置評價，每個人的口味不一樣，別人適合的不一定自己適合。
對於黑盒測試方法來說，是每一位測試的必備技術，沒有誰不會：發現問題，丟擲問題。
簡單、輕鬆、快速，是黑盒測試的優點，特別是在專案特別趕，測試時間無限被壓縮的時候——只需要拋給開發問題，剩下的讓開發自個兒玩去吧。
但黑盒測試人員常常被人詬病只知道點點點，拋開此類「鄙視」不談，接著上面繼續，我們是不是忽略了乙個事實：專案既然趕，那開發的時間亦不充足，如果恰好遇上稍稍複雜的bug，並搭配不靠譜的開發，乙個bug的生命週期可能會拉得極長，效率特別低下。
這麼說，那用白盒測試方法唄，看**，查原因，丟給開發後，留下乙個高大帥氣的背影，讓開發心裡默念——這個測試不簡單。
白盒測試可以，但使用它時，你需要盤算盤算：
是否有充足的時間研究**以及和**相關的環境部署、配置設定等？
付出和產出是否成正比，如同自動化測試，能達到高價效比嗎？
白盒是一種選擇，但同樣是乙個難題。更別說白盒對於測試技術的高要求。
我不知道該怎麼回答你，就像剛開始說的，每個人的口味不一樣，適合自己的測試方法，最醇最香。
但說實話，日常工作中我使用灰盒測試方法的場景相對較多，總結來說，就這麼乙個流程：
發現問題–>我大概知道你是怎麼玩的–>初步定位問題原因–>同開發確定問題–>接下來呢？
會分成兩類：
1、我定位的原因並不是真正的原因。但我能通過這個過程學習到新知識、新業務，積攢個人經驗（很多人往往棄步於此）
2、我定位的問題是真正的原因。就此打住嗎？並不是。你能提出問題的解決建議嗎？你的建議是否比開發的修改 or 產品給的方案更好，更具有可實施性？
合理地提出解決問題的建議，這才是你關注的重點，而不是因為找到問題原因而沾沾自喜，迷失於他人的讚許中。
如果你不想再體驗一次自學時找不到資料，沒人解答問題，堅持幾天便放棄的感受的話，可以關注我一起討論。
加油吧，測試人！路就在腳下，成功就在明天！
未來的你肯定會感謝現在拼命的自己！
願你我相遇，皆有所獲！
1.免費領取乙份216頁軟體測試工程師面試寶典文件資料。
測試知識之 黑盒白盒和灰盒測試
黑盒測試 黑盒測試也稱功能測試，它是在已知產品所應具有的功能上，通過測試來檢測是否每個功能是否能夠按照需求規格說明書的規定正常使用。我們通過程式的介面進行測試，看程式能否適當的接收輸入資料而產生正確的輸出資訊，並且保持外部資訊 如資料庫或者檔案 的完整性。常見的黑盒測試方法有 等價類劃分法 邊界值 ...
黑盒 白盒 灰盒測試的基本概念
黑盒 對於一段程式，對其測試時，不需要知道內部結構和特性，在輸入介面處輸入激勵，觀察輸出是否正確。主要用於軟體介面和功能測試。實際應用中，由於輸入為無窮個，不僅要測試所有合法的輸入，也要測試不合法但是可能發生的輸入。白盒 白盒測試也稱結構測試和邏輯驅動測試，知道程式內部結構，驗證內部每條通路是否能正...
測試之白盒測試 黑盒測試和灰盒測試簡介
什麼是白盒測試？白盒測試是依據被測軟體分析程式內部構造，並根據內部構造設計用例，來對內部控制流程進行測試，可完全不顧程式的整體功能實現情況。白盒測試是基於程式結構的邏輯驅動測試。白盒又可以被稱為玻璃盒測試 透明盒測試 開放盒測試 結構化測試 邏輯驅動測試。為什麼要進行白盒測試？白盒測試一般在測試前期...