黑盒：
對於一段程序，對其測試時，不需要知道內部結構和特性，在輸入接口處輸入激勵，觀察輸出是否正確。
主要用於軟件界面和功能測試。
實際應用中，由於輸入為無窮個，不僅要測試所有合法的輸入，也要測試不合法但是可能發生的輸入。
白盒：
白盒測試也稱結構測試和邏輯驅動測試，知道程序內部結構，驗證內部每條通路是否能正常工作。
也就是窮舉路徑測試，從檢查程序的邏輯出發。主要用於軟件驗證。
但是，
第一，窮舉路徑測試決不能查出程序違反了設計規范，即程序本身是個錯誤的程序。
第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。
第三，窮舉路徑測試可能發現不了一些與數據相關的錯誤。
灰盒：
介於白盒和黑盒之間的測試，結合外部接口、功能和內部邏輯、路徑，根據程序實際情況，進行測試。
本文轉自：http://www.eetop.cn/blog/html/28/1561828-438324.html
在FPGA驗證技術中：
黑盒驗證
如果驗證人員對於設計的細節缺乏認識，那么黑盒驗證是一種合適的方式。因為驗證環境只需要將激勵給入設計的外部接口，而檢查設計的另一側輸出就夠了。而測試的成功與否只是根據一個輸入是否得到一個正確的輸出，驗證環境本身不會關注設計的內部。
從上面這張圖可以看到，激勵生成器（stimulator）只負責給設計灌入激勵，監視器（monitor）和檢查器（checker）也只查看和比較輸出信號。
黑盒驗證的一個缺點是它缺少設計的透明度和激勵的可控度，而由此帶來的一些問題包括：
-
當測試失敗以后，無法更深層次地定位問題。對於驗證人員而言，他只能判斷是測試是否成功，但無法將報告進一步定位到缺陷所在的位置，與設計人員完成深度協作。
-
這種方式對於發現一些較深的缺陷比較困難，因為驗證人員無法根據設計本身給出更窄的隨機約束來定向生成一些激勵。同時，這也對設計內部功能點的功能覆蓋率收斂沒有太多的幫助。
當一些設計的接口采用標准接口時，圖中的激勵生成器或者總線功能模型可以使用復用性高的驗證IP。這些驗證IP一般由第三方公司提供，有時候公司內部也有這樣的IP，它們的特點是像標准接口一樣易於在驗證環境中插拔，易於控制且接口時序嚴格按照總線文檔定義。同時對於監測器而言，它也來自於驗證IP，這也減少了驗證人員的工作量。所以當模塊的接口標准化時，驗證環境也可以復用一些驗證IP。
由於黑盒驗證本身不包含設計的內部邏輯信息，所以當設計由於缺陷做了更新或者添加新的特性之后，原有的測試列表仍然較穩定，驗證人員只需要對新添加的特性考慮新的測試場景。黑盒驗證有利於保持測試環境的穩定，在后續項目中一旦更新了設計，新的驗證人員也只需要很少的力氣來維護繼承的驗證環境。
白盒驗證
相比黑盒驗證，白盒驗證可以彌補一些不足。由於驗證人員了解設計的內部工作邏輯、層次、信號等，他就可以對更底層的設計細節進行測試。由於對於設計中各種組件和邏輯細節都了如指掌，這種驗證方式可以驗證設計是否更嚴格地遵循功能描述文檔，而且一旦測試發生失敗也可以更快速地定位到缺陷。
對於白盒驗證的環境，我們的參考模型邏輯非常簡略，甚至不需要參考模型，而只需要植入監視器和斷言來檢查各個內部邏輯。這種環境配置背后的原則是說，當我們充分檢查各個邏輯驅動和結構以后，就不需要測試它的整體功能，因為白盒驗證是窮舉邏輯路徑的方法。
使用白盒驗證也面臨一些方法學上的缺陷：
-
由於本身專注於設計內部邏輯檢查而忽略整體功能的測試，在設計本身違反規范的情況下，白盒驗證難以發現缺陷。
-
在數據一致性檢查的方面，白盒驗證難以從整體入手給出實際測試用例。
-
由於白盒驗證的測試用例很多都是從設計的細節入手，所以一旦設計發生更新，那么對於驗證環境的維護成本就偏高。這一點在項目間復用方面帶來的影響更多，甚至新接手驗證環境的人要付出很大的成本去理解設計細節和驗證環境的細節。這時候白盒驗證環境的低復用性缺點就暴露出來了。
灰盒驗證
從黑盒驗證和白盒驗證來看，他們各自都有着優勢和劣勢。在實際驗證中，我們更傾向於將黑盒和白盒兩種方法摻雜在一起，讓監視器、斷言、參考模型一同來完善驗證。這種糅合的方式帶來的好處包括：
-
監視器和斷言可以有着更好的透明度來着重檢查設計的一些重要內部邏輯。
-
參考模型由於已經有了斷言檢查局部邏輯的幫助，會減少很大一部分精確度，而主要專注在輸入和輸出的數據比較上。
而從復用性角度考慮，灰盒驗證也有着靈活地變動方式：
-
對於新的設計，我們的驗證人員需要更深入地理解設計本身，而采用灰盒驗證一開始通過監視器和斷言來進行局部驗證。待設計初步完善和趨向穩定時，驗證人員此時也有了對設計更全局的理解來構建參考模型。又因為前期監視器和斷言保證局部邏輯的正確，那么參考模型的構建不需要完全精確，只需要較少的精力來實現。
-
如果該設計移植到別的項目，盡管難免設計需要進行局部修改，對於驗證環境而言，灰盒驗證的復用性優勢就體現出來了。即便是新的驗證人員接手這個驗證環境，好的灰盒環境也可以清晰地將黑盒和白盒的部分划分開來。在設計本身復用的項目中，我們首先建議打開黑盒開關，這對於新的驗證人員來講是較低的測試成本，也無需對設計和驗證環境了解太多。同時，這么做也可以第一時間保證原有功能的穩定性，並反饋給設計人員新的改動造成的影響。緊接着，應該驗證人員可以針對新的特性創建特定的黑盒測試序列，由於設計本身的穩定，新的黑盒測試序列不需要關注與設計內部太多。
當黑盒環節進行完畢以后，我們可以在時間允許的情況下，有序引入白盒的開關。首先，我們應該考慮先創建新的白盒斷言點或者是功能檢查點，來專注在新的功能部分。其次，在完成了新的功能點白盒覆蓋以后，我們再考慮逐個打開原有的白盒功能檢查開關，逐次打開白盒檢查開關的方式我們也遵循着每次添加盡可能少的開關來跑遞歸測試，這便於發現問題以后可以快速定位到新打開的開關一側；並且，白盒檢查點的開關也有邏輯重要性的優先級，如果之前驗證人員足夠專業的話，在他的代碼或者文檔中也應該對這些不同白盒開關給出說明和重要性的排列，這種說明會有助於新的驗證人員先開高優先級的開關，而依次按照優先級的降序來打開不同的開關。
所以灰盒驗證不但可以繼承黑盒驗證和白盒驗證的優勢，同時也對於驗證環境在新項目中的復用有着明顯優勢。
無論對於設計人員還是驗證人員也都需要從各自的角度考慮復用性，將設計的整個流程全盤考慮，也只有可以讓使用設計交付包的項目可以有更好的“用戶體驗”，縮短集成時間（設計和驗證），才是好的設計和驗證環境。