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

我的回答原文如下：

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

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

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

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

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

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

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

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

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

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

對于黑盒測試方法來說，是每一位測試的必備技術，沒有誰不會：發現問題，抛出問題。簡單、輕松、快速，是黑盒測試的優點，特别是在項目特别趕，測試時間無限被壓縮的時候——隻需要抛給開發問題，剩下的讓開發自個兒玩去吧。

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

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

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

是否有充足的時間研究代碼以及和代碼相關的環境部署、配置設置等？

付出和産出是否成正比，如同自動化測試，能達到高性價比嗎？

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

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

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

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

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

會分成兩類：

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

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

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

實踐是檢驗真理的唯一标準。恰好，我最近遇到一個問題，并且剛好使用到灰盒測試方法，分享給大家窺其一二。

先描述下業務：

我測試的X系統會從配置系統拉取幾條數據，并保存在數據庫A（讀寫庫）中，數據庫A又會将新數據實時同步到數據庫B（讀寫庫）中。業務上：a類用戶從數據庫A中讀數據，b類用戶從數據庫B中讀數據。

再說下bug：

我在配置系統删除了一條數據，結果a類用戶沒有讀到該條數據（預期結果），b類用戶卻讀到了該條數據（非預期結果）。去數據庫查看，A庫沒有被删除的數據，B庫仍然存在被删除的數據。

按理說，走到這一步，便可以到bug系統提交一條bug指給開發解決。不過我想到開發最近天天晚上加班，并且我之前提的幾個bug反複修改，開發效率很低，加之臨近上線，時間被壓縮，于是乎，我額外抽出一點時間，簡單定位下問題。

這個問題看起來簡單，無非是同步導緻兩個庫的數據不一緻，可以得出兩個猜測：

一 同步沒有觸發。

二 同步觸發了，但數據沒有在B庫落庫。

接着，我做了一個實驗：在配置系統修改了一條數據，結果A庫和B庫的數據保持一緻。據此，猜測一不成立。

緊接着，我又做了一個實驗：進入A庫，在數據庫内删除一條數據，奇怪的是，B庫的數據被删除了，猜測二也不成立。

兩種猜測同時被證明無效，那問題究竟出在哪裡呢？

于是，我上到服務器，重新在配置系統删掉一條數據，并觸發了一次同步操作，我在日志上找到了兩條sql：

truncate table xxtable;

insert into xxtable……;

到此，我恍然大悟。

原來因為這個業務的數據不多，開發可能是這樣處理的：從配置系統拉取數據時，先清空A庫的xxtable，再向A庫的xxtable插入數據，以此簡化數據增删改的邏輯。但我司DBA做過處理，不允許數據庫級别之間進行truncate table的同步。

最後找開發讨論，果真是這個問題。

怎麼解決呢，将truncate table xxtable換成delete from xxtable即可。

這算是一次我所理解的完整的灰盒測試，也是我一直推薦給組内人員的高效率的一種工作方式：我大概知道你是怎麼實現業務的，實踐定位問題，達到快速解決問題的目的。

最後，一如既往地做個總結吧：

• 測試時，特别簡單的bug建議直接抛出，讓開發去玩，沒必要浪費精力定位問題
• 複雜問題多總結，定位問題時頭腦要清晰且靈活，證實或否定每一個猜測
• 和開發打好關系（或強制要求），讓他們在解決bug的時候注明bug産生的原因
• 多花時間在業務上，絕對物超所值

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!