灰盒測試

灰盒(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“good ness”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、程序員應該避免檢查自己的程序，測試工作應該由獨立的專業的軟體測試機構來完成。

3、設計測試用例時應該考慮到合法的輸入和不合法的輸入以及各種邊界條件，特殊情況要製造極端狀態和意外狀態，比如網路異常中斷、電源斷電等情況。

4、一定要注意測試中的錯誤集中發生現象，這和程序員的編程水平和習慣有很大的關係。

5、對測試錯誤結果一定要有一個確認的過程，一般有A測試出來的錯誤，一定要有一個B來確認，嚴重的錯誤可以召開評審會進行討論和分析。

6、制定嚴格的測試計劃，並把測試時間安排的盡量寬鬆，不要希望在極短的時間內完成一個高水平的測試。

7、回歸測試的關聯性一定要引起充分的注意，修改一個錯誤而引起更多的錯誤出現的現象並不少見。

8、妥善保存一切測試過程文檔，意義是不言而喻的，測試的重現性往往要靠測試文檔。

軟體測試並不等於程序測試。軟體測試應該貫穿整個軟體定義與開發整個期間。因此需求分析、概要設計、詳細設計以及程序編碼等各階段所得到的文檔，包括需求規格說明、概要設計規格說明、詳細設計規格說明以及源程序，都應該是軟體測試的對象。在對需求理解與表達的正確性、設計與表達的正確性、實現的正確性以及運行的正確性的驗證中，任何一個環節發生了問題都可能在軟體測試中表現出來。

黑盒測試也稱功能測試或數據驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程序看作一個不能打開的黑盆子，在完全不考慮程序內部結構和內部特性的情況下，測試者在程序介面進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數鋸而產生正確的輸出信息，並且保持外部信息（如資料庫或文件）的完整性。黑盒測試方法主要有等價類劃分、邊值分析、因果圖、錯誤推測等，主要用於軟體確認測試。“黑盒”法著眼於程序外部結構、不考慮內部邏輯結構、針對軟體界面和軟體功能進行測試。“黑盒”法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際 上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。

白盒測試也稱結構測試或邏輯驅動測試，它是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行，按照程序內部的結構測試程序，檢驗程序中的每條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用於軟體驗證。

“白盒”法全面了解程序內部邏輯結構、對所有邏輯路徑進行測試。“白盒”法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯著手，得出測試數據。貫穿程序的獨立路徑數是天文數字。但即使每條路徑都測試了仍然可能有錯誤。第一，窮舉路徑測試決不能查出程序違反了設計規範，即程序本身是個錯誤的程序；第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯；第三，窮舉路徑測試可能發現不了一些與數據相關的錯誤。