黑盒：
對於一段程式，對其測試時，不需要知道內部結構和特性，在輸入介面處輸入激勵，觀察輸出是否正確。
主要用於軟體介面和功能測試。
實際應用中，由於輸入為無窮個，不僅要測試所有合法的輸入，也要測試不合法但是可能發生的輸入。
白盒：
白盒測試也稱結構測試和邏輯驅動測試，知道程式內部結構，驗證內部每條通路是否能正常工作。
也就是窮舉路徑測試，從檢查程式的邏輯出發。主要用於軟體驗證。
但是，第一，窮舉路徑測試決不能查出程式違反了設計規範，即程式本身是個錯誤的程式。
第二，窮舉路徑測試不可能查出程式中因遺漏路徑而出錯。
第三，窮舉路徑測試可能發現不了一些與資料相關的錯誤。
灰盒：
介於白盒和黑盒之間的測試，結合外部介面、功能和內部邏輯、路徑，根據程式實際情況，進行測試。
本文**：
在fpga驗證技術中：
黑盒驗證
如果驗證人員對於設計的細節缺乏認識，那麼黑盒驗證是一種合適的方式。因為驗證環境只需要將激勵給入設計的外部介面，而檢查設計的另一側輸出就夠了。而測試的成功與否只是根據乙個輸入是否得到乙個正確的輸出，驗證環境本身不會關注設計的內部。
從上面這張圖可以看到，激勵生成器（stimulator）只負責給設計灌入激勵，監視器（monitor）和檢查器（checker）也只檢視和比較輸出訊號。
黑盒驗證的乙個缺點是它缺少設計的透明度和激勵的可控度，而由此帶來的一些問題包括：
當測試失敗以後，無法更深層次地定位問題。對於驗證人員而言，他只能判斷是測試是否成功，但無法將報告進一步定位到缺陷所在的位置，與設計人員完成深度協作。
這種方式對於發現一些較深的缺陷比較困難，因為驗證人員無法根據設計本身給出更窄的隨機約束來定向生成一些激勵。同時，這也對設計內部功能點的功能覆蓋率收斂沒有太多的幫助。
當一些設計的介面採用標準介面時，圖中的激勵生成器或者匯流排功能模型可以使用復用性高的驗證ip。這些驗證ip一般由第三方公司提供，有時候公司內部也有這樣的ip，它們的特點是像標準介面一樣易於在驗證環境中插拔，易於控制且介面時序嚴格按照匯流排文件定義。同時對於監測器而言，它也來自於驗證ip，這也減少了驗證人員的工作量。所以當模組的介面標準化時，驗證環境也可以復用一些驗證ip。
由於黑盒驗證本身不包含設計的內部邏輯資訊，所以當設計由於缺陷做了更新或者新增新的特性之後，原有的測試列表仍然較穩定，驗證人員只需要對新新增的特性考慮新的測試場景。黑盒驗證有利於保持測試環境的穩定，在後續專案中一旦更新了設計，新的驗證人員也只需要很少的力氣來維護繼承的驗證環境。
白盒驗證
相比黑盒驗證，白盒驗證可以彌補一些不足。由於驗證人員了解設計的內部工作邏輯、層次、訊號等，他就可以對更底層的設計細節進行測試。由於對於設計中各種元件和邏輯細節都瞭如指掌，這種驗證方式可以驗證設計是否更嚴格地遵循功能描述文件，而且一旦測試發生失敗也可以更快速地定位到缺陷。
對於白盒驗證的環境，我們的參考模型邏輯非常簡略，甚至不需要參考模型，而只需要植入監視器和斷言來檢查各個內部邏輯。這種環境配置背後的原則是說，當我們充分檢查各個邏輯驅動和結構以後，就不需要測試它的整體功能，因為白盒驗證是窮舉邏輯路徑的方法。
使用白盒驗證也面臨一些方法學上的缺陷：
由於本身專注於設計內部邏輯檢查而忽略整體功能的測試，在設計本身違反規範的情況下，白盒驗證難以發現缺陷。
在資料一致性檢查的方面，白盒驗證難以從整體入手給出實際測試用例。
由於白盒驗證的測試用例很多都是從設計的細節入手，所以一旦設計發生更新，那麼對於驗證環境的維護成本就偏高。這一點在專案間復用方面帶來的影響更多，甚至新接手驗證環境的人要付出很大的成本去理解設計細節和驗證環境的細節。這時候白盒驗證環境的低復用性缺點就暴露出來了。
灰盒驗證
監視器和斷言可以有著更好的透明度來著重檢查設計的一些重要內部邏輯。
參考模型由於已經有了斷言檢查區域性邏輯的幫助，會減少很大一部分精確度，而主要專注在輸入和輸出的資料比較上。
而從復用性角度考慮，灰盒驗證也有著靈活地變動方式：
對於新的設計，我們的驗證人員需要更深入地理解設計本身，而採用灰盒驗證一開始通過監視器和斷言來進行區域性驗證。待設計初步完善和趨向穩定時，驗證人員此時也有了對設計更全域性的理解來構建參考模型。又因為前期監視器和斷言保證區域性邏輯的正確，那麼參考模型的構建不需要完全精確，只需要較少的精力來實現。
如果該設計移植到別的專案，儘管難免設計需要進行區域性修改，對於驗證環境而言，灰盒驗證的復用性優勢就體現出來了。即便是新的驗證人員接手這個驗證環境，好的灰盒環境也可以清晰地將黑盒和白盒的部分劃分開來。在設計本身復用的專案中，我們首先建議開啟黑盒開關，這對於新的驗證人員來講是較低的測試成本，也無需對設計和驗證環境了解太多。同時，這麼做也可以第一時間保證原有功能的穩定性，並反饋給設計人員新的改動造成的影響。緊接著，應該驗證人員可以針對新的特性建立特定的黑盒測試序列，由於設計本身的穩定，新的黑盒測試序列不需要關注與設計內部太多。
當黑盒環節進行完畢以後，我們可以在時間允許的情況下，有序引入白盒的開關。首先，我們應該考慮先建立新的白盒斷言點或者是功能檢查點，來專注在新的功能部分。其次，在完成了新的功能點白盒覆蓋以後，我們再考慮逐個開啟原有的白盒功能檢查開關，逐次開啟白盒檢查開關的方式我們也遵循著每次新增盡可能少的開關來跑遞迴測試，這便於發現問題以後可以快速定位到新開啟的開關一側；並且，白盒檢查點的開關也有邏輯重要性的優先順序，如果之前驗證人員足夠專業的話，在他的**或者文件中也應該對這些不同白盒開關給出說明和重要性的排列，這種說明會有助於新的驗證人員先開高優先順序的開關，而依次按照優先順序的降序來開啟不同的開關。
所以灰盒驗證不但可以繼承黑盒驗證和白盒驗證的優勢，同時也對於驗證環境在新專案中的復用有著明顯優勢。
無論對於設計人員還是驗證人員也都需要從各自的角度考慮復用性，將設計的整個流程全盤考慮，也只有可以讓使用設計交付包的專案可以有更好的「使用者體驗」，縮短整合時間（設計和驗證），才是好的設計和驗證環境。
測試知識之 黑盒白盒和灰盒測試
黑盒測試 黑盒測試也稱功能測試，它是在已知產品所應具有的功能上，通過測試來檢測是否每個功能是否能夠按照需求規格說明書的規定正常使用。我們通過程式的介面進行測試，看程式能否適當的接收輸入資料而產生正確的輸出資訊，並且保持外部資訊 如資料庫或者檔案 的完整性。常見的黑盒測試方法有 等價類劃分法 邊界值 ...
測試之白盒測試 黑盒測試和灰盒測試簡介
什麼是白盒測試？白盒測試是依據被測軟體分析程式內部構造，並根據內部構造設計用例，來對內部控制流程進行測試，可完全不顧程式的整體功能實現情況。白盒測試是基於程式結構的邏輯驅動測試。白盒又可以被稱為玻璃盒測試 透明盒測試 開放盒測試 結構化測試 邏輯驅動測試。為什麼要進行白盒測試？白盒測試一般在測試前期...
黑盒測試 白盒測試
黑盒測試 black box testing，又稱為功能測試或資料驅動測試 是把測試物件看作乙個黑盒子。利用黑盒測試法進行動態測試時，需要測試軟體產品的功能，不需測試軟體產品的內部結構和處理過程。黑盒測試注重於測試軟體的功能性需求，也即黑盒測試使軟體工程師派生出執行程式所有功能需求的輸入條件。黑盒測...