灰盒測試

出自 MBA智库百科(https://wiki.mbalib.com/)

　　灰盒測試定義為將根據需求規範說明語言(RSL)產生的基於測試用例的要求(RBTC)，用測試單元的介面參數加到受測單元，檢驗軟體在測試執行環境控制下的執行情況。灰盒測試法的目的是驗證軟體滿足外部指標要求以及軟體的所有通道都進行了檢驗。通過該程式的所有路徑都進行了檢驗和驗證後，就得到了全面的驗證。完成功能和結構驗證後，就可隨機地一次變化一行來驗證軟體測試用例在軟體遇到違背原先驗證的不利變化時軟體的可靠性。灰盒測試法是在功能上驗證嵌入式系統軟體的一種10步驟法。

　　1999年，美國洛克希德公司發表了灰盒測試法的論文，提出了灰盒測試法。灰盒測試是一種綜合測試法，它將黑盒測試、白盒測試、回歸測試和變異(Mutation)測試結合在一起，構成一種無縫測試技術。它是一種軟體全壽命周期測試法，用於在功能上檢驗為嵌入式應用研製的Ada、C、FORTRAN和彙編語言軟體。該方法可自動生成所有測試軟體，從而降低了成本，減少了軟體的研製時間。初步研究表明過去要用幾天時間對一套軟體進行徹底測試，現在不到4小時就可完成，軟體測試時間減少75％。

　　灰盒測試方法是指結合白盒測試和黑盒測試的測試方法。

　　白盒測試，又稱結構測試，在測試過程中測試者可以看到被測的源程式，通過分析程式的內部結構，根據其內部結構設計測試用例J。黑盒測試，又稱功能測試，在測試過程中被測程式被視為黑盒，測試者在完全不考慮程式內部結構和內部特征(或對於上述信息無從獲知)的情況下，根據需求規格說明書設計測試用例和推斷測試結果的正確性。

　　顯然，這兩類測試方法是從完全不同的角度出發對軟體進行測試。實踐證明，兩類方法各有側重，在測試的實踐中都是有效和實用的，不能指望一類方法能夠完全代替另一類方法。但顯然二者又各具缺點，這些缺點不是通過在各自的測試方法內部進行完善就能夠解決的。只有通過將二者有效地結合，即進行所謂的“灰盒測試”，才能彌補任何一種方法的不足，使測試方法的機理更完善。

　　傳統意義上的軟體可靠性測試的實踐方法是根據用戶實際使用軟體的方式，即運行剖面生成測試數據，利用測試數據驅動軟體運行，獲得失效數據，利用現有的軟體可靠性模型進行評估，直到可靠性估計以某種形式收斂。軟體可靠性測試從概念上講採用的是黑盒測試方法，因為它是面向需求、面向使用的測試，它不需要瞭解程式的結構以及如何實現等問題，測試數據的生成和可靠性估計與測試中軟體如何運行沒有任何明確的關係。這種明確關係的缺乏，是我們反對用單純的“黑盒測試”方法估計軟體可靠性的出發點。

　　而且，這種傳統作法生成的測試數據中，很多是對程式結構的重覆執行，使得某些結構測試的密度高，某些結構測試的密度低，帶來了許多無用的測試代價。大量的測試數據需要花費大量的人力、物力和財力，在交貨期限緊張的情況下，往往不能滿足，導致獲得的可靠性估計值是不可信的。因此，需要結合“白盒測試”的信息，作為衡量測試質量和控制測試進程的手段。