白盒測試和黑盒測試(白盒測試和黑盒測試的概念)

作者:測試奇譚

出處:https://gmentfault.com/a/1190000038989816

對于黑盒、白盒與灰盒測試方法的理解，幾年前我在某乎做過一個概念性的回答，當時提問者詢問：如何跟非技術人員解釋黑盒、白盒、灰盒測試的區別？

我的回答原文如下：

既然是對非技術人員解釋，就不能用專業術語。

這樣說吧，有個打孔機，類似這樣。

紙條從盒子左方插入，從右方出來時，分別打出圓形、正方形、三角形三個樣式的孔。

某天，打出來的紙條，只有一種圖形。

黑盒測試員只能說：“這個打孔機壞了！”

灰盒測試員把打孔機的蓋子掀開，發現打孔機的造型原來是這樣的。

于是他說：“機器仍能打孔，說明主機沒壞；三個樁子也都是好的；但只打印出了圓形，可能因為連接正方形和三角形樁子的地方有問題。”

白盒測試員把機器拆開，查看內部的電線、電路、控制器等等，發現連接正方形和三角形的電線燒壞了，于是說：“原因找到了，換根電線吧。”

彼時，我還是一位測試小鳥，在研習了不少理論知識后，回答了這個問題。現在，我算不上測試老鳥，但能算個測試大鳥，在工作中，越發頻繁地接觸這三種測試方法。

如果你要問我哪種測試方法更好，我不置評價， 每個人的口味不一樣，別人適合的不一定自己適合。

對于黑盒測試方法來說，是每一位測試的必備技術，沒有誰不會：發現問題，拋出問題。

簡單、輕松、快速，是黑盒測試的優點，特別是在項目特別趕，測試時間無限被壓縮的時候——只需要拋給開發問題，剩下的讓開發自個兒玩去吧。

但黑盒測試人員常常被人詬病只知道點點點，拋開此類“鄙視”不談，接著上面繼續，我們是不是忽略了一個事實：項目既然趕，那開發的時間亦不充足，如果恰好遇上稍稍復雜的bug，并搭配不靠譜的開發，一個bug的生命周期可能會拉得極長，效率特別低下。

這么說，那用白盒測試方法唄，看代碼，查原因，丟給開發后，留下一個高大帥氣的背影，讓開發心里默念——這個測試不簡單。

白盒測試可以，但使用它時，你需要盤算盤算：

白盒是一種選擇，但同樣是一個難題。更別說白盒對于測試技術的高要求。

廢話了這么多，你一定會說：風風，你不就是拐彎抹角地推薦灰盒測試嘛。

我不知道該怎么回答你，就像剛開始說的， 每個人的口味不一樣，適合自己的測試方法，最醇最香。

但說實話，日常工作中我使用灰盒測試方法的場景相對較多，總結來說，就這么一個流程：

發現問題-->我大概知道你是怎么玩的-->初步定位問題原因-->同開發確定問題-->接下來呢？

會分成兩類：

1、我定位的原因并不是真正的原因。但我能通過這個過程學習到新知識、新業務，積攢個人經驗（很多人往往棄步于此）

2、我定位的問題是真正的原因。就此打住嗎？并不是。你能提出問題的解決建議嗎？你的建議是否比開發的修改 or 產品給的方案更好，更具有可實施性？

合理地提出解決問題的建議，這才是你關注的重點，而不是因為找到問題原因而沾沾自喜，迷失于他人的贊許中。

作者:測試奇譚

出處:https://gmentfault.com/a/1190000038989816