軟體測試方法種類繁多，記憶起來混亂， 如果把軟體測試方法進行分類, 就會清晰很多。 這裡參考一些書籍和網上的資料， 把常用的軟體測試方法列出來， 讓大家對軟體測試行業有個總體的看法。

從測試設計方法分類

1. 測試名稱：黑盒測試（Black Box）
   測試內容：黑盒測試是把測試物件看做一個黑盒子，利用黑盒測試法進行動態測試時，需要測試軟體產品已經實現的功能是否符合功能設計要求，不需測試軟體產品的內部結構和處理過程。
   黑盒測試注重於測試軟體的功能性需求，也即黑盒測試使軟體工程師派生出執行程式所有功能需求的輸入條件。黑盒測試並不是白盒測試的替代品，而是用於輔助白盒測試發現其他型別的錯誤。
   黑盒測試更多內容請檢視之前的一篇博文:
   黑盒測試用例設計
2. 測試名稱：白盒測試（White Box）
   測試內容：設計者可以看到軟體系統的內部結構，並且使用軟體的內部知識來指導測試資料及方法的選擇。
   白盒測試通常被認為是單元測試與整合測試，期中有六種測試方法：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋。
   更多白盒測試的內容請檢視此處連結
3. 測試名稱：灰盒測試（Gray Box）
   測試內容：介於黑盒和白盒之間，是一種綜合測試的方法，他將白盒測試和黑盒測試結合在一起，構成一種無縫測試技術。
   灰盒測試是基於程式執行時的外部表現又結合程式內部邏輯結構來設計測試用例，執行程式並採集程式路徑執行資訊和外部使用者介面結果的測試技術。灰盒測試法旨在驗證軟體滿足外部指標以及軟體的所有通道或路徑都進行了檢驗。
   
   更多關於灰盒測試的詳細內請點選此處檢視

總結：   實際工作中，對系統的瞭解越多越好。目前大多數的測試人員都是做黑盒測試，很少有做白盒測試的。 因為白盒測試對軟體測試人員的要求非常高，需要有很多程式設計經驗。做.NET程式的白盒測試你要能看得懂.NET程式碼。做JAVA程式的測試，需要你能看懂JAVA的程式碼。 如果你都能看懂了，你還會做測試麼

從測試是手動還是自動上分類

1. 測試名稱：手動測試（Manual Test）
   測試內容：測試人員用滑鼠去手動測試 （測試GUI），用滑鼠各種點點點，手工測試更能容易發現軟體的Bug。
2. 測試名稱：自動化測試（Automation Test）
   測試內容：用程式測試程式 （測試API），由測試人員根據手工測試的Case來決定自動化測試的Case，再編寫程式或者指令碼來替代手工做自動化測試。
   

總結：對於專案來說， 手動測試和自動化測試同等重要，都是保障軟體質量的方法。 目前大部分的專案組都是手動測試和自動化測試相結合。因為很多測試無法做成自動化，很多複雜的業務邏輯也很難自動化， 所以自動化測試無法取代手動測試。
對於軟體測試人員個人發展來說， 做自動化測試是個挑戰，也是測試人員發展的一個方向，  需要測試人員學習大量的開發知識（開發的知識真是學無止境啊）。 從長遠角度來看，自動化測試肯定是越來越吃香的。
而手動測試比較適合剛工作不久的人，手動測試最大的缺點就是技術含量低，單調乏味，容易廢人。
總的來說，手工測試勝在測試業務邏輯，而自動化測試勝在測試底層架構。
如果被測試的程式可測試性比較好， 很有必要做成自動化測試。 能做自動化的儘量做成自動化， 比如下面這些情形是可以做自動化的：

•  測試儲存過程。  例如用C#去測試儲存過程
• 測試Web servies. 例如： 用SoupUI工具，或者C#,Java 去測試Web servies。
• 介面和業務邏輯分離的系統，比如，MVC，MVP架構， 或者WPF 程式。 可以用測試指令碼去測試這些程式的API。
  
• 編寫程式或者指令碼語言去自動監控Web UI，GUI等比較穩定的內容。

關於手工測試和自動化測試的比較請檢視另一篇博文：手工測試與自動化測試比較

從測試的目的分類

1. 測試名稱：功能測試
   測試內容：測試的範圍從小到大，從內到外， 從程式開發人員（單元測試）到測試人員，到一般使用者Alpha/Beta測試
   

   測試名稱	測試內容
   Unit Test 單元測試	在最低的功能/引數上驗證程式的準確性,比如測試一個函式的正確性(開發人員做的)
   Functional Test 功能測試	驗證模組的功能  （測試人員做的）
   Integration Test 整合測試	驗證幾個互相有依賴關係的模組的功能 （測試人員做的）
   Scenario Test  場景測試	驗證幾個模組是否能完成一個使用者場景 （測試人員做的）
   System Test  系統測試	對於整個系統功能的測試 （測試人員做的）
   Alpha 測試	軟體測試人員在真實使用者環境中對軟體進行全面的測試 （測試人員做的）
   Beta 測試	真實的使用者在真實的使用者環境中進行的測試, 也叫公測   （終端使用者做的）

2. 測試名稱：非功能測試
   測試內容：一個軟體除了基本功能之外，還有很多功能之外的特性，這些叫“Quality of Service requirement”服務質量需求。沒有軟體的功能，這些特性都無從表現出來，因此，我們要在軟體開發的適當階段-基本功能完成後做這些測試。
   

   測試名稱	測試內容
   Stress test 壓力測試	驗證軟體在超過負載設計的情況下仍能返回正確的結果，沒有崩潰
   Load test 負載測試	測試軟體在負載情況下能否正常工作
   Performance test效能測試	測試軟體的效能，是否提供滿意的服務質量
   Accessibility test	軟體輔助功能測試-測試軟體是否向殘疾使用者提供足夠的輔助功能
   Localization/Globalization	本地化/全球化測試
   Compatibility Test	相容性測試
   Configuration Test	配置測試-測試軟體在各種配置下能否正常工作
   Usability Test	可用性測試 –測試軟體是否好用
   Security Test	軟體安全性測試

   效能測試
   效能測試要求測試人員熟練效能測試工具，比如QTP, LoadRunner, Jmeter。  Visual Studio也提供了很多效能測試的工具. 要求測試人員對低層協議非常理解和編寫指令碼
   效能測試非常有技術含量， 很有發展前途， 是軟體測試人員的一個職業發展方向。
   效能測試推薦看一本書：《軟體效能測試過程詳解與案例剖析》
   
   安全性測試
   安全性測試的內容很廣， 非常有難度啊。 我只接觸過XSS（跨站指令碼攻擊）和SQL注入攻擊。
   安全性測試非常有技術含量， 我認為也是軟體測試人員的一個職業發展方向
   

按測試的時機和作用分類

在開發軟體的過程中，不少測試起著“烽火臺”的作用，它們告訴我們軟體開發的流程是否暢通。

BVT測試是一種Smoke Test, 指Build生成好之後，自動執行的自動化測試指令碼來檢查這個Build的基本功能。 如果BVT測試失敗了，需要開發人員馬上修改，重新生成Build

按測試測策略分類

Regression Test 迴歸測試：　　
對軟體測試人員來說就是重複測試，所以迴歸測試最好是自動化的，否則測試人員就要一遍又一遍地重複測試：　

1. 開發人員做些小改動，就需要測試人員做迴歸測試。確保現有的功能沒有被破壞
2. Bug Fix 也需要回歸測試，確保新的程式碼修復了Fix, 也確保現有的功能沒有被破壞
3. 專案後期，需要做一個完整迴歸測試，確保所有的功能都是好的