測驗奇譚，BUG不見，
大家好，我是譚叔，
對于黑盒、白盒與灰盒測驗方法的理解，幾年前我在某乎做過一個概念性的回答，當時提問者詢問：如何跟非技術人員解釋黑盒、白盒、灰盒測驗的區別？
我的回答原文如下：
既然是對非技術人員解釋，就不能用專業術語，
這樣說吧，有個打孔機，類似這樣，
紙條從盒子左方插入，從右方出來時，分別打出圓形、正方形、三角形三個樣式的孔，
某天，打出來的紙條，只有一種圖形，
黑盒測驗員只能說：“這個打孔機壞了！”
灰盒測驗員把打孔機的蓋子掀開，發現打孔機的造型原來是這樣的，
于是他說：“機器仍能打孔，說明主機沒壞；三個樁子也都是好的；但只列印出了圓形，可能因為連接正方形和三角形樁子的地方有問題，”
白盒測驗員把機器拆開，查看內部的電線、電路、控制器等等，發現連接正方形和三角形的電線啥訓了，于是說：“原因找到了，換根電線吧，”
彼時，我還是一位測驗小鳥，在研習了不少理論知識后，回答了這個問題，現在，我算不上測驗老鳥，但能算個測驗大鳥，在作業中，越發頻繁地接觸這三種測驗方法，
如果你要問我哪種測驗方法更好，我不置評價，每個人的口味不一樣，別人適合的不一定自己適合，
對于黑盒測驗方法來說，是每一位測驗的必備技術，沒有誰不會：發現問題，拋出問題，簡單、輕松、快速，是黑盒測驗的優點，特別是在專案特別趕，測驗時間無限被壓縮的時候——只需要拋給開發問題，剩下的讓開發自個兒玩去吧，
但黑盒測驗人員常常被人詬病只知道點點點，拋開此類“鄙視”不談，接著上面繼續，我們是不是忽略了一個事實：專案既然趕，那開發的時間亦不充足，如果恰好遇上稍稍復雜的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即可，
這算是一次我所理解的完整的灰盒測驗，也是我一直推薦給組內人員的高效率的一種作業方式：我大概知道你是怎么實作業務的，實踐定位問題，達到快速解決問題的目的，
一如既往，做個總結
01 測驗時，特別簡單的bug建議直接拋出，讓開發去玩，沒必要浪費精力定位問題；
02 復雜問題多總結，定位問題時頭腦要清晰且靈活，證實或否定每一個猜測；
03 和開發打好關系（或強制要求），讓他們在解決bug的時候注明bug產生的原因，
04 多花時間在業務上，絕對物超所值，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/392067.html
標籤：其他
上一篇：10位高級測驗員撰寫的《完美測驗-軟體測驗最佳實踐》，真全面
下一篇：Git是什么