分析灰盒測試優(yōu)點和缺點
灰盒測試是一種綜合測試法，它將“黑盒”測試、“白盒”測試結合在一起，構成一種無縫測試技術。“灰盒” 測試以程序的主要性能和主要功能為測試依據(jù)，測試方法主要根據(jù)程序的程序圖、功能說明書以及測試者的實踐經(jīng)驗來設計。下面從灰盒測試的優(yōu)缺點開始說起。
一、幾個基本概念
首先，把一些基本概念，簡單通俗地說一下。
1、黑盒測試
通俗來說：黑盒測試不關注軟件內部的實現(xiàn)細節(jié)。他僅僅把被測試的軟件當成一個整體來處理，只關注軟件的外在表現(xiàn)，不關注內部細節(jié)。典型的黑盒測試，就是光拿著鼠標操作一下用戶界面，看看功能是否滿足要求。
2、白盒測試
白盒測試與黑盒測試相反，重點關注軟件內部的實現(xiàn)細節(jié)（比如代碼覆蓋率等）。
3、灰盒測試
如果你是從事開發(fā)或者測試的行當，應該已經(jīng)聽過黑盒測試與白盒測試這2個概念。但對灰盒測試，或許比較耳生。單純從名稱上來看，灰盒測試是介于黑盒測試與白盒測試之間的一種測試方式。
這種測試方式，主要用于多模塊構成的稍微復雜的軟件系統(tǒng)。在灰盒測試中，重點關注軟件系統(tǒng)內部模塊的邊界（接口）。這里所說的“接口”是廣義的，包含有各種形式。對于進程內的模塊，其接口可能是動態(tài)庫的導出函數(shù)；對于進程級的模塊，其接口可能是各種IPC（進程間通訊）機制；對于涉及數(shù)據(jù)庫的軟件系統(tǒng)，其接口可能是數(shù)據(jù)庫的表結構。
4、灰盒測試與黑盒測試的區(qū)別
如果某軟件包含多個模塊，當你使用黑盒測試時，你只要關心整個軟件系統(tǒng)的邊界，無需關心軟件系統(tǒng)內部各個模塊之間如何協(xié)作。而如果使用灰盒測試，你就需要關心模塊與模塊之間的交互。這是灰盒測試與黑盒測試的區(qū)別。
5、灰盒測試與白盒測試的區(qū)別
但是，在灰盒測試中，你還是無需關心模塊內部的實現(xiàn)細節(jié)。對于軟件系統(tǒng)的內部 模塊，灰盒測試依然把它當成一個黑盒來看待。而白盒測試則不同，還需要再深入地了解內部 模塊的實現(xiàn)細節(jié)。所以，這是灰盒測試與黑盒測試的區(qū)別。
6、灰盒測試與單元測試的區(qū)別
剛才看到有網(wǎng)友在評論中問到此問題，俺補充一下。
首先，在進行單元測試時，需要寫一些測試代碼（行話叫“樁代碼”，洋文叫stub）。一般來說，測試代碼與被測試代碼采用同種語言（比如Java的單元測試通常也用Java來寫），且測試代碼和被測試代碼之間的耦合很緊密。因此，單元測試通常由開發(fā)人員來完成的——測試人員的能力未必能勝任。
其次，單元測試的顆粒度會更細（會細到模塊內部的類一級、函數(shù)一級），而灰盒測試僅僅到模塊一級。
#p#
二、相對于黑盒測試的優(yōu)點
灰盒測試相對黑盒測試的優(yōu)點，其實有不少，俺挑幾個重要的來說說。
1、測試可以及早介入
由于黑盒測試把整個軟件系統(tǒng)當成一個整體來測試。如果系統(tǒng)的某個關鍵模塊還沒有完工，那測試人員就無法對整個系統(tǒng)進行測試，只好閑著沒事干。而灰盒測試是針對模塊的邊界進行，模塊開發(fā)完一個就測試一個。
2、有助于測試人員理解系統(tǒng)結構
為了進行灰盒測試，測試人員首先要熟悉內部模塊之間的協(xié)作機制。在熟悉的過程中，“順便”也就對整個系統(tǒng)（及其結構）有一個初步的、宏觀的認識。這有助于測試人員發(fā)現(xiàn)一些系統(tǒng)結構方面的Bug。
而對于黑盒測試來說，由于測試人員不清楚軟件系統(tǒng)的內部結構，難以發(fā)現(xiàn)一些結構性的缺陷。
3、有助于管理層了解真實的開發(fā)進度
一些復雜的大系統(tǒng)，經(jīng)常會發(fā)生開發(fā)進度失控的情況。因為很多開發(fā)人員有報喜不報憂的傾向。當某個開發(fā)人員號稱自己的工作已經(jīng)完成了90%，往往意味著他/她還要花同樣多的時間來完成剩下的10%。這導致負責項目管理的人，無法了解開發(fā)的真實進度。
由于灰盒測試針對對每一個模塊進行，而且測試人員會從一個客觀的角度來反饋模塊的完成情況，這非常有利于管理層了解整個系統(tǒng)的真實完成情況。
4、可以構造更好的測試用例
如果僅僅用黑盒的方式測試系統(tǒng)的外部邊界（通常是用戶界面），有很多軟件缺陷是不容易發(fā)現(xiàn)的。俺分別以B/S系統(tǒng)和C/S系統(tǒng)來舉例。
假設開發(fā)一個復雜的（Windows環(huán)境下的）C/S軟件。那么，這個軟件通常不會僅僅只有一個EXE文件。它可能會有若干個EXE文件以及若干個 DLL文件。假如某個DLL提供的導出函數(shù)，沒有按照約定對輸入?yún)?shù)進行有效性判斷（比如指針是否為空），那你用黑盒測試的方式，難以暴露出這種缺陷。而灰盒測試就容易發(fā)現(xiàn)此類問題。
假如你開發(fā)的是一個Web應用系統(tǒng)，那么，這種系統(tǒng)的服務端多半會提供若干個Web接口用于被客戶端調用。假如某個Web接口存在安全性問題/并發(fā)性問題/健壯性問題/XX問題，你單純用黑盒測試的手段，同樣難以發(fā)現(xiàn)，而灰盒測試就可以搞定。
5、利于提升測試人員能力
很多公司搞的黑盒測試，就是讓測試人員用鼠標（鍵盤都難得用）操作用戶界面。在這種的環(huán)境里，測試人員干的活，很多都是重復性的體力勞動，技術能力難以得到提高。
而如果搞灰盒測試，測試人員就需要多懂一點技術背景知識，必要時還得寫點測試腳本，對測試人員的能力提升很有好處。
#p#
三、相對于白盒測試的好處
灰盒測試相對白盒測試的好處，比較容易概括。簡單來說，就是白盒測試較費錢（研發(fā)成本較高）。這多出來的研發(fā)成本，體現(xiàn)在如下幾個方面。
1、首先，招聘成本較高
在人才市場上，100個應聘的測試人員中，未必能夠找到一個合適的白盒測試人員。至少從俺及周圍同事的面試經(jīng)歷來看，難得碰到具備白盒測試能力的人。所以，你可能要花很長時間才能找到合適的人，時間成本浪費掉了。
2、其次，培訓成本較高
可能有同學會說，招不到就內部培養(yǎng)唄。這個說起來容易，但是培訓也是有成本的。而且周期還不短，同樣要耗費時間成本。
3、再其次，人力成本較高
物以稀為貴是一條普遍的經(jīng)濟學規(guī)律。由于能搞白盒測試的家伙是稀有動物，你自然不能給他/她開太低的薪水。否則人家待不了多久就跑路了。薪水開得高了，人力成本自然也就提高了。
四、其它的一些好處
前面拿灰盒測試分別跟黑盒/白盒進行了對比，列舉了一些優(yōu)點。還有另外一些優(yōu)點，和黑盒/白盒沒啥關系，單獨列在這里。
1、順便強化開發(fā)文檔
對于一個復雜的軟件系統(tǒng)，模塊之間的接口是很重要的，因此捏，接口文檔也是很重要滴。而開發(fā)人員不愛寫文檔/不愛更新文檔，（在軟件業(yè)內）已經(jīng)是臭名昭著了。很多軟件開發(fā)到后期，模塊之間的接口文檔要么沒有，要么和代碼實現(xiàn)嚴重脫節(jié)。
但是，如果引入測試人員對模塊之間的接口進行測試，就可以有效防止此種弊端。因為測試人員在測試前，首先要看模塊間的接口文檔，然后再根據(jù)接口文檔設計測試用例，***再執(zhí)行用例。因此，一旦接口文檔和代碼實現(xiàn)不符，立馬就露餡了。
2、順便搞搞自動化
灰盒測試如果落實到位，還可以跟自動化測試相結合。從此可以大大提升測試的效率，進而大大提升軟件的質量。（如何進行自動化的灰盒測試，后面的帖子會細談）
五、灰盒測試有啥缺點？
當然，凡事都有優(yōu)點和缺點，灰盒測試自然也不例外。下面列舉它的主要缺點。
1、不適用于簡單的系統(tǒng)
所謂的簡單系統(tǒng)，就是簡單到總共只有一個模塊。由于灰盒測試關注于系統(tǒng)內部模塊之間的交互。如果某個系統(tǒng)簡單到只有一個模塊，那就沒必要進行灰盒測試了。
2、對測試人員的要求比黑盒測試高
從上面的介紹來看，灰盒測試要求測試人員清楚系統(tǒng)內部由哪些模塊構成，模塊之間如何協(xié)作。因此，對測試的要求就提高了。
因此，會帶來一定的培訓成本。不過捏，依照俺的經(jīng)驗，培訓難度不大。稍微有點基礎的測試人員，都可以在短期培訓之后勝任。
3、不如白盒測試深入
顯然，灰盒不如白盒那么深入。不過捏，考慮到灰盒測試相比白盒測試有顯著的成本優(yōu)勢，該缺點不是太明顯。
六、總結
總而言之，言而總之，灰盒測試是一個很不錯的東東，其優(yōu)點明顯而缺點容易克服。另外，俺前后在兩家公司的研發(fā)部門推行過，效果不錯的說。大伙兒值得去嘗試一下。今天光說了優(yōu)缺點對比，在本系列的下一個帖子 ，具體介紹一下，開展灰盒測試之前，管理上有哪些準備工作。
本文地址：http://program-think.blogspot.com/2010/11/grey-box-testing-1.html
【編輯推薦】
