俺在忽悠某個技術領域的玩意兒之前，通常先要分析一下優缺點——這樣才能調動大伙兒的積極性。所以，本系列第1帖先分析一下灰盒測試的優缺點。

　　★幾個基本概念?
　　首先，把一些基本概念，簡單通俗地說一下。如果覺得俺解釋得不夠好，不夠細，可以自己去查維基百科的詞條：洋文的在“這里?”，中文的詞條在“這里?”（可惜中文詞條不夠全，偏偏缺了“灰盒測試”這一節）。

　　◇黑盒測試
　　通俗來說：黑盒測試不關注軟件內部的實現細節。他僅僅把被測試的軟件當成一個整體來處理，只關注軟件的外在表現，不關注內部細節。典型的黑盒測試，就是光拿著鼠標操作一下用戶界面，看看功能是否滿足要求。

　　◇白盒測試
　　白盒測試與黑盒測試相反，重點關注軟件內部的實現細節（比如代碼覆蓋率等）。

　　◇灰盒測試
　　如果你是從事開發或者測試的行當，應該已經聽過黑盒測試與白盒測試這2個概念。但對灰盒測試，或許比較耳生。單純從名稱上來看，灰盒測試是介于黑盒測試與白盒測試之間的一種測試方式。
　　這種測試方式，主要用于多模塊構成的稍微復雜的軟件系統。在灰盒測試中，重點關注軟件系統的各個組成模塊之間的互動。這里所說的"互動"，包括模塊之間的互相調用、數據傳遞、同步/互斥、等等。

　　◇灰盒測試與黑盒測試的區別
　　如果某軟件包含多個模塊，當你使用黑盒測試時，你只要關心整個軟件系統的邊界，無需關心軟件系統內部各個模塊之間如何協作。而如果使用灰盒測試，你就需要關心模塊與模塊之間的交互。這是灰盒測試與黑盒測試的區別。

　　◇灰盒測試與白盒測試的區別
　　但是，在灰盒測試中，你還是無需關心模塊內部的實現細節。對于軟件系統的內部?模塊，灰盒測試依然把它當成一個黑盒來看待。而白盒測試則不同，還需要再深入地了解內部?模塊的實現細節。所以，這是灰盒測試與黑盒測試的區別。

　　◇灰盒測試與單元測試的區別
　　剛才看到有網友在評論中問到此問題，俺補充一下。
　 　首先，在進行單元測試時，需要寫一些測試代碼（行話叫“樁代碼”，洋文叫stub）。通常測試代碼和被測試代碼通常是同種語言（比如Java的單元測試 通常也用Java來寫），且測試代碼和被測試代碼的耦合很緊密。因此，單元測試通常由開發人員來完成的，測試人員的能力未必能勝任。
　　其次，單元測試的顆粒度會更細（會細到類一級、函數一級），而灰盒測試僅僅到模塊一級。

　　★相對于黑盒測試的優點?
　　灰盒測試相對黑盒測試的優點，其實有不少，俺挑幾個重要的來說說。

　　◇測試可以及早介入
　　由于黑盒測試把整個軟件系統當成一個整體來測試。如果系統的某個關鍵模塊還沒有完工，那測試人員就無法對整個系統進行測試，只好閑著沒事干。而灰盒測試是針對模塊的邊界進行，模塊開發完一個就測試一個。

　　◇有助于測試人員理解系統結構
　　為了進行灰盒測試，測試人員首先要熟悉內部模塊之間的協作機制。在熟悉的過程中，“順便”也就對整個系統（及其結構）有一個初步的、宏觀的認識。這有助于測試人員發現一些系統結構方面的Bug。
　　而對于黑盒測試來說，由于測試人員不清楚軟件系統的內部結構，難以發現一些結構性的缺陷。

　　◇有助于管理層了解真實的開發進度
　　一些復雜的大系統，經常會發生開發進度失控的情況。因為很多開發人員有報喜不報憂的傾向。當某個開發人員號稱自己的工作已經完成了90%，往往意味著他/她還要花同樣多的時間來完成剩下的10%。這導致負責項目管理的人，無法了解開發的真實進度。
　　由于灰盒測試針對對每一個模塊進行，而且測試人員會從一個客觀的角度來反饋模塊的完成情況，這非常有利于管理層了解整個系統的真實完成情況。

　　◇可以構造更好的測試用例
　　如果僅僅用黑盒的方式測試系統的外部邊界（通常是用戶界面），有很多軟件缺陷是不容易發現的。俺分別以B/S系統和C/S系統來舉例。
　 　假設開發一個復雜的（Windows環境下的）C/S軟件。那么，這個軟件通常不會僅僅只有一個EXE文件。它可能會有若干個EXE文件以及若干個 DLL文件。假如某個DLL提供的導出函數，沒有按照約定對輸入參數進行有效性判斷（比如指針是否為空），那你用黑盒測試的方式，難以暴露出這種缺陷。而 灰盒測試就容易發現此類問題（具體如何發現，后續的帖子會細說）。
　　假如你開發的是一個Web應用系統，那么，這種系統的服務端多半會提供若干 個Web接口用于被客戶端調用。假如某個Web接口存在安全性問題/并發性問題/健壯性問題/XX問題，你單純用黑盒測試的手段，同樣難以發現，而灰盒測 試就可以搞定（灰盒測試是如何搞定的，后續帖子會細說）。

　　◇利于提升測試人員能力
　　很多公司搞的黑盒測試，就是讓測試人員用鼠標（鍵盤都難得用）操作用戶界面。在這種的環境里，測試人員干的活，很多都是重復性的體力勞動，技術能力難以得到提高。
　　而如果搞灰盒測試，測試人員就需要多懂一點技術背景知識，必要時還得寫點測試腳本，對測試人員的能力提升很有好處。

　　★相對于白盒測試的好處?
　　灰盒測試相對白盒測試的好處，比較容易概括。簡單來說，就是白盒測試較費錢（研發成本較高）。這多出來的研發成本，體現在如下幾個方面。

　　◇首先，招聘成本較高
　　在人才市場上，100個應聘的測試人員中，未必能夠找到一個合適的白盒測試人員。至少從俺及周圍同事的面試經歷來看，難得碰到具備白盒測試能力的人。所以，你可能要花很長時間才能找到合適的人，時間成本浪費掉了。

　　◇其次，培訓成本較高
　　可能有同學會說，招不到就內部培養唄。這個說起來容易，但是培訓也是有成本的。而且周期還不短，同樣要耗費時間成本。

　　◇再其次，人力成本較高
　　物以稀為貴是一條普遍的經濟學規律。由于能搞白盒測試的家伙是稀有動物，你自然不能給他/她開太低的薪水。否則人家待不了多久就跑路了。薪水開得高了，人力成本自然也就提高了。

　　★其它的一些好處?
　　前面拿灰盒測試分別跟黑盒/白盒進行了對比，列舉了一些優點。還有另外一些優點，和黑盒/白盒沒啥關系，單獨列在這里。

　　◇順便強化開發文檔
　　對于一個復雜的軟件系統，模塊之間的接口是很重要的，因此捏，接口文檔也是很重要滴。而開發人員不愛寫文檔/不愛更新文檔，（在軟件業內）已經是臭名昭著了。很多軟件開發到后期，模塊之間的接口文檔要么沒有，要么和代碼實現嚴重脫節。
　　但是，如果引入測試人員對模塊之間的接口進行測試，就可以有效防止此種弊端。因為測試人員在測試前，首先要看模塊間的接口文檔，然后再根據接口文檔設計測試用例，最后再執行用例。因此，一旦接口文檔和代碼實現不符，立馬就露餡了。

　　◇順便搞搞自動化
　　灰盒測試如果落實到位，還可以跟自動化測試相結合。從此可以大大提升測試的效率，進而大大提升軟件的質量。（如何進行自動化的灰盒測試，后面的帖子會細談）

　　★灰盒測試有啥缺點？?
　　當然，凡事都有優點和缺點，灰盒測試自然也不例外。下面列舉它的主要缺點。

　　◇不適用于簡單的系統
　　所謂的簡單系統，就是簡單到總共只有一個模塊。由于灰盒測試關注于系統內部模塊之間的交互。如果某個系統簡單到只有一個模塊，那就沒必要進行灰盒測試了。

　　◇對測試人員的要求比黑盒測試高
　　從上面的介紹來看，灰盒測試要求測試人員清楚系統內部由哪些模塊構成，模塊之間如何協作。因此，對測試的要求就提高了。因此，會帶來一定的培訓成本。不過捏，依照俺的經驗，培訓難度不大。稍微有點基礎的測試人員，都可以在短期培訓之后勝任。

　　◇不如白盒測試深入
　　顯然，灰盒不如白盒那么深入。不過捏，考慮到灰盒測試相比白盒測試有顯著的成本優勢，該缺點不是太明顯。

　　★總結?
　　總而言之，言而總之，灰盒測試是一個很不錯的東東，其優點明顯而缺點容易克服。另外，俺前后在兩家公司的研發部門推行過，效果不錯的說。大伙兒值得去嘗試一下。今天光說了優缺點對比，在管理層面和技術層面，具體該如何落實捏？請看下一個帖子。

轉載于:https://www.cnblogs.com/cwfsoft/archive/2010/12/04/1896199.html

總結

以上是生活随笔為你收集整理的如何开展灰盒测试[1]：灰盒测试优缺点分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。