灰盒測試通俗解釋(灰盒測試方法有哪些)
一：怎樣開展灰盒測試⓵:灰盒測試優缺點剖析
俺在忽悠某個技術范疇的玩意兒之前，通常先要剖析一下優缺點——如此才能調動大夥兒的積極性。所以，本系列第一帖先剖析一下灰盒測試的優缺點。 ★幾個基本概念 first of all，把一些基本概念，簡單通俗地說一下。假如覺得俺解釋得不夠好，不夠細，可以自己去查維基百科的詞條：洋文的在“這裡 ”，中文的詞條在“這裡 ”（可惜中文詞條不夠全，唯獨缺瞭“灰盒測試”這一節）。 ◇黑盒測試 通俗來說：黑盒測試不關註軟件內部的實現細節與關鍵。他僅僅把被測試的軟件當成一個整體來處理，隻關註軟件的外在表現，不關註內部細節與關鍵。典型的黑盒測試，就是光拿著鼠標操作一下用戶界面，看看功能是否滿足要求。 ◇白盒測試 白盒測試與黑盒測試相反，重點關註軟件內部的實現細節與關鍵（打比方說代碼覆蓋率等）。 ◇灰盒測試 假如你是從事開發或者測試的行當，應該已經聽過黑盒測試與白盒測試這2個概念。不過對灰盒測試，或許比較耳生。單純從名稱上來看，灰盒測試是介於黑盒測試與白盒測試之間的一種測試方式。 這種測試方式，主要用於多模塊構成的稍微復雜的軟件系統。在灰盒測試中，重點關註軟件系統的各個組成模塊之間的互動。這裡所說的"互動"，包括模塊之間的互相調用、數據傳遞、同步/互斥、等等。 ◇灰盒測試與黑盒測試的不同 假如某軟件蘊含多個模塊，當你使用黑盒測試時，你隻要關心整個軟件系統的邊界，無需關心軟件系統內部各個模塊之間怎樣協作。而假如使用灰盒測試，你就需要關心模塊與模塊之間的交互。這是灰盒測試與黑盒測試的不同。 ◇灰盒測試與白盒測試的不同 不過，在灰盒測試中，你還是無需關心模塊內部的實現細節與關鍵。對於軟件系統的內部 模塊，灰盒測試依然把它當成一個黑盒來看待。而白盒測試則不同，還need再深入地瞭解內部 模塊的實現細節與關鍵。所以，這是灰盒測試與黑盒測試的不同。 ◇灰盒測試與單元測試的不同 剛才見到有網民朋友在評論中問到此問題，俺補充一下。 first of all，在進行單元測試時，需要寫一些測試代碼（行話叫“樁代碼”，洋文叫stub）。通常測試代碼和被測試代碼一般是同種語言（打比方說Java的單元測試通常也用Java來寫），且測試代碼和被測試代碼的耦合很緊密。於是，單元測試通常由開發人員來完成的，測試人員的能力未必能勝任。 其次，單元測試的顆粒度會更細（會細到類一級、函數一級），而灰盒測試僅僅到模塊一級。
二：白盒測試，灰盒測試和黑盒測試的不同
白盒測試要看流程的運算過程，黑盒測試隻看最終，灰盒測試介於兩者之間
三：灰度測試究竟是什麼?
白色的叫牛奶，黑色的叫巧克力，棕色的叫咖啡
奶茶
珍珠
……
最簡單就直接叫咪咪
四：何謂灰盒測試?
灰盒測試，是介於白盒測試與黑盒測試之間的，可以這樣理解，灰盒測試關註輸出對於輸入的正確性，並且也關註內部表現，但這種關註不象白盒那樣詳細、完整，隻是通過一些表征性的現象、事件、標志來推測斷定內部的運行狀態，偶爾輸出是正確的，但內部其實也就是說已經錯誤瞭，這樣的狀況很多很多，假如每次都通過白盒測試來操作，效率會很低，因此需要采取如此的一種灰盒的方式方法。
五：黑盒測試，白盒測試和灰盒測試的不同是什麼?
任何工程產品（註意和提防是任何工程產品）都應該使用以下兩種方法之一進行測試。
黑盒測試：已知產品的功能設計規格，可以進行測試證明每個實現瞭的功能是否符合要求。
白盒測試：已知產品的內部工作過程，可Yi經過測試證明每種內部操作是否符合設計規格要求，所有內部成分是否以經過檢查。
黑盒測試
軟件的黑盒測試象征著測試要在軟件的接口處進行。這一個方法是把測試對象看做一個黑盒子，測試人員完全不考慮流程內部的邏輯結構和內部特性，隻根據流程的需求規格說明書，檢查流程的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數據驅動測試。
黑盒測試著重是為瞭發現以下幾類錯誤：
1。是不是有不正確或遺漏的功能？
2。在接口上，輸入是否能正確的接受？能否輸出正確的結果？
3。是不是有數據結構錯誤或外部信息（例如數據文件）訪問錯誤？
4。性能上是否能夠滿足要求？
5。是不是有初始化或終止性錯誤？
白盒測試
軟件的白盒測試是對軟件的過程性細節與關鍵做細致的檢查。這一個方法是把測試對象看做一個打開的盒子，它允許測試人員利用流程內部的邏輯結構及相關信息，設計或選擇測試用例，對流程所有邏輯路徑進行測試。通過在不同點檢查流程狀態，確定實際狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。
白盒測試著重是想對流程模塊進行如下檢查：
1。對流程模塊的所有單獨的執行路徑至少測試一遍。
2。對所有的邏輯判定，取“真”與取“假”的兩種情況皆能至少測一遍。
3。在循環的邊界和運行的界限內執行循環體。
4。測試內部數據結構的有效性，等等。
以上事實說明，軟件測試有一個致命的缺陷，即測試的不完全、不徹底性。因為任何流程隻能進行少量（相比於窮舉的巨大數量來講）的有限的測試，在未發現錯誤時，不可以說明流程中沒有錯誤。
灰盒測試
灰盒測試，是介於白盒測試與黑盒測試之間的，可以這樣理解，灰盒測試關註輸出對於輸入的正確性，並且也關註內部表現，但這種關註不象白盒那樣詳細、完整，隻是通過一些表征性的現象、事件、標志來推測斷定內部的運行狀態，偶爾輸出是正確的，但內部其實也就是說已經錯誤瞭，這樣的狀況很多很多，假如每次都通過白盒測試來操作，效率會很低，因此需要采取如此的一種灰盒的方式方法。
六：軟件測試方法的分類有哪些
1）依照測試技術劃分
黑盒測試：功能測試，必須
白盒測試：邏輯結構測試，代碼的邏輯、算法、結構是否正確，要求必須明 白代碼，需要編寫測試用例，可選
灰盒測試：介於中間
註意和提防：在單元測試時，白盒應用相對較多，在集成測試時，灰盒測試應用相對較多，在系統、驗收測試時一般就不會使用白盒測試和灰盒測試瞭。
2）按是否需要運行代碼劃分
靜態測試：界面測試，文檔測試，代碼測試【重點關註代碼的規范性，一般檢查變量的命名，註釋的頻率，編程的規范性，不需要寫測試用例，一般僅需要有代碼審查單】
註意和提防：一般經常把白盒測試和靜態測試的要素結合在一起，形成靜態白盒測試
動態測試：運行流程進行檢查，檢查實際輸出結果和預期結果是否相符
3）按軟件特性分類
功能測試
性能測試