基本介紹
概念,定義,學術含義,目的任務,目的,衡量標準,任務,測試任務,目標,確認標準,標準,系統測試,原則對象,原則,對象,相關參考,黑盒測試,白盒測試,
概念
定義
學術含義
灰盒(Gray Box)是一種程式或系統上的工作過程被局部認知的裝置。灰盒測試，也稱作灰盒分析，是基於對程式內部細節有限認知上的軟體調試方法。測試者可能知道系統組件之間是如何互相作用的，但缺乏對內部程式功能和運作的詳細了解。對於內部過程，灰盒測試把程式看作一個必須從外面進行分析的黑盒。
灰盒測試
灰盒測試灰盒測試通常與web服務套用一起使用，因為儘管應用程式複雜多變，並不斷發展進步，網際網路仍可以提供相對穩定的接口。由於不需要測試者接觸原始碼，因此灰盒測試不存在侵略性和偏見。開發者和測試者間有明顯的區別，人事衝突的風險減到最小。然而，灰盒測試相對白盒測試更加難以發現並解決潛在問題，尤其在一個單一的套用中，白盒測試的內部細節可以完全掌握。 灰盒測試結合了白盒測試和黑盒測試的要素。它考慮了用戶端、特定的系統知識和操作環境。它在系統組件的協同性環境中評價套用軟體的設計。灰盒測試由方法和工具組成，這些方法和工具取材於應用程式的內部知識和與之互動的環境，能夠用於黑盒測試以增強測試效率、錯誤發現和錯誤分析的效率。灰盒測試涉及輸入和輸出，但使用關於代碼和程式操作等通常在測試人員視野之外的信息設計測試。
目的任務
軟體測試是軟體開發過程的重要組成部分，是用來確認一個程式的品質或性能是否符合開發之前所提出的一些要求。軟體測試就是在軟體投入運行前，對軟體需求分析、設計規格說明和編碼的最終複審，是軟體質量保證的關鍵步驟。軟體測試是為了發現錯誤而執行程式的過程。軟體測試在軟體生存期中橫跨兩個階段，通常在編寫出每一個模組之後就對它做必要的測試（稱為單元測試）。編碼和單元測試屬於軟體生存期中的同一個階段。在結束這個階段後對軟體系統還要進行各種綜合測試，這是軟體生存期的另一個獨立階段，即測試階段。
灰盒測試
灰盒測試目的
第一是確認軟體的質量，其一方面是確認軟體做了你所期望的事情（Do the right thing），另一方面是確認軟體以正確的方式來做了這個事件（Do it right）。
第二是提供信息，比如提供給開發人員或程式經理的反饋信息，為風險評估所準備的信息。
第三軟體測試不僅是在測試軟體產品的本身，而且還包括軟體開發的過程。如果一個軟體產品開發完成之後發現了很多問題，這說明此軟體開發過程很可能是有缺陷的。因此軟體測試的第三個目的是保證整個軟體開發過程是高質量的。
衡量標準
軟體質量是由幾個方面來衡量的：
一、在正確的時間用正確的的方法把一個工作做正確（Doing the right things right at the right time）。
三、質量本身就是軟體達到了最開始所設定的要求，而代碼的優美或精巧的技巧並不代表軟體的高質量（Quality is defined as conformance to requirements,not as“goodness”or“elegance”）。
灰盒測試
灰盒測試四、質量也代表著它符合客戶的需要（Quality also means“meet customer needs”）。作為軟體測試這個行業，最重要的一件事就是從客戶的需求出發，從客戶的角度去看產品，客戶會怎么去使用這個產品，使用過程中會遇到什麼樣的問題。只有這些問題都解決了，軟體產品的質量才可以說是上去了。
任務
測試任務
1、尋找Bug；
2、避免軟體開發過程中的缺陷；
3、衡量軟體的品質；
4、關注用戶的需求。
目標
1、確保軟體的質量；
2、提高軟體質量功能。
確認標準
標準
1、確認測試標準
實現軟體確認要通過一系列墨盒測試。確認測試同樣需要制訂測試計畫和過程，測試計畫應規定測試的種類和測試進度，測試過程則定義一些特殊的測試用例，旨在說明軟體與需求是否一致。無是計畫還是過程，都應該著重考慮軟體是否滿足契約規定的所有功能和性能，文檔資料是否完整、準確人機界面和其他方面（例如，可移植性、兼容性、錯誤恢復能力和可維護性等）是否令用戶滿意。確認測試的結果有兩種可能，一種是功能和性能指標滿足軟體需求說明的要求，用戶可以接受；另一種是軟體不滿足軟體需求說明的要求，用戶無法接受。項目進行到這個階段才發現嚴重錯誤和偏差一般很難在預定的工期內改正，因此必須與用戶協商，尋求一個妥善解決問題的方法。
灰盒測試
灰盒測試2、配置複審
確認測試的另一個重要環節是配置複審。複審的目的在於保證軟體配置齊全、分類有序，並且包括軟體維護所必須的細節。
系統測試
系統測試應該由若干個不同測試組成，目的是充分運行系統，驗證系統各部件是否都能正常工作並完成所賦予的任務。下面簡單討論幾類系統測試：
1、恢複測試恢複測試主要檢查系統的容錯能力。當系統出錯時，能否在指定時間間隔內修正錯誤並重新啟動系統。恢複測試首先要採用各種辦法強迫系統失敗，然後驗證系統是否能儘快恢復。對於自動恢復需驗證重新初始化（reinitialization）、檢查點(check pointing mechanisms)、數據恢復(data recovery)和重新啟動(restart)等機制的正確性；對於人工干預的恢復系統，還需估測平均修復時間，確定其是否在可接受的範圍內。
2、安全測試
安全測試檢查系統對非法侵入的防範能力。安全測試期間，測試人員假扮非法入侵者，採用各種辦法試圖突破防線。例如，①想方設法截取或破譯口令；②專門定做軟體破壞系統的保護機制；③故意導致系統失敗，企圖趁恢復之機非法進入；④試圖通過瀏覽非保密數據，推導所需信息，等等。理論上講，只要有足夠的時間和資源，沒有不可進入的系統。因此系統安全設計的準則是，使非法侵入的代價超過被保護信息的價值。此時非法侵入者已無利可圖。
3、強度測試
強度測試檢查程式對異常情況的抵抗能力。強度測試總是迫使系統在異常的資源配置下運行。例如，①當中斷的正常頻率為每秒一至兩個時，運行每秒產生十個中斷的測試用例；②定量地增長數據輸入率，檢查輸入子功能的反映能力；③運行需要最大存儲空間（或其他資源）的測試用例；④運行可能導致虛存作業系統崩潰或磁碟數據劇烈抖動的測試用例等等。
4、性能測試
對於那些實時和嵌入式系統，軟體部分即使滿足功能要求，也未必能夠滿足性能要求，雖然從單元測試起，每一測試步驟都包含性能測試，但只有當系統真正集成之後，在真實環境中才能全面、可靠地測試運行性能系統性能測試是為了完成這一任務。性能測試有時與強度測試相結合，經常需要其他軟硬體的配套支持。
原則對象
原則
軟體測試從不同的角度出發會派生出不同的測試原則，從用戶的角度出發，是希望能看到一個正常工作的軟體。從測試人員的角度，就是希望通過軟體測試能充分暴露軟體中存在的問題和缺陷，，從開發者的角度出發，就是希望測試能表明軟體產品不存在錯誤，已經正確地實現了用戶的需求，確立人們對軟體質量的信心。
為了達到上述的原則，那么需要注意以下幾點：
1、應當把“儘早和不斷的測試”作為開發者的座右銘2、程式設計師應該避免檢查自己的程式，測試工作應該由獨立的專業的軟體測試機構來完成。
灰盒測試
灰盒測試4、一定要注意測試中的錯誤集中發生現象，這和程式設計師的編程水平和習慣有很大的關係。
5、對測試錯誤結果一定要有一個確認的過程，一般有A測試出來的錯誤，一定要有一個B來確認，嚴重的錯誤可以召開評審會進行討論和分析。
6、制定嚴格的測試計畫，並把測試時間安排的儘量寬鬆，不要希望在極短的時間內完成一個高水平的測試。
7、回歸測試的關聯性一定要引起充分的注意，修改一個錯誤而引起更多的錯誤出現的現象並不少見。
8、妥善保存一切測試過程文檔，意義是不言而喻的，測試的重現性往往要靠測試文檔。
對象
軟體測試並不等於程式測試。軟體測試應該貫穿整個軟體定義與開發整個期間。因此需求分析、概要設計、詳細設計以及程式編碼等各階段所得到的文檔，包括需求規格說明、概要設計規格說明、詳細設計規格說明以及源程式，都應該是軟體測試的對象。在對需求理解與表達的正確性、設計與表達的正確性、實現的正確性以及運行的正確性的驗證中，任何一個環節發生了問題都可能在軟體測試中表現出來。
相關參考
黑盒測試
黑盒測試也稱功能測試或數據驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程式看作一個不能打開的黑盆子，在完全不考慮程式內部結構和內部特性的情況下，測試者在程式接口進行測試，它只檢查程式功能是否按照需求規格說明書的規定正常使用，程式是否能適當地接收輸入數鋸而產生正確的輸出信息，並且保持外部信息（如資料庫或檔案）的完整性。黑盒測試方法主要有等價類劃分、邊值分析、因果圖、錯誤推測等，主要用於軟體確認測試。“黑盒”法著眼於程式外部結構、不考慮內部邏輯結構、針對軟體界面和軟體功能進行測試。“黑盒”法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程式中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。
灰盒測試
灰盒測試