軟件測試方法種類繁多，記憶起來混亂，如果把軟件測試方法進行分類,就會清晰很多。我參考一些書籍和網上的資料，把常用的軟件測試方法列出來，讓大家對軟件測試行業有個總體的看法。
從測試設計方法分類
測試名稱 | 測試內容 |
Black box黑盒測試 | 把軟件系統當作一個“黑箱”，無法了解或使用系統的內部結構及知識。從軟件的行為，而不是內部結構出發來設計測試. |
White box白盒測試 | 設計者可以看到軟件系統的內部結構，并且使用軟件的內部知識來指導測試數據及方法的選擇。 |
Gray box. 灰盒測試 | 介于黑盒和白盒之間 |
總結：實際工作中，對系統的了解越多越好。目前大多數的測試人員都是做黑盒測試，很少有做白盒測試的。因為白盒測試對軟件測試人員的要求非常高，需要有很多編程經驗。做.NET程序的白盒測試你要能看得懂.NET代碼。做JAVA程序的測試，需要你能看懂JAVA的代碼。如果你都能看懂了，你還會做測試么
從測試是手動還是自動上分類
測試名稱 | 測試內容 |
Manual Test 手動測試 | 測試人員用鼠標去手動測試 （測試GUI） |
Automation 自動化測試 | 用程序測試程序 （測試API） |
對于項目來說，手動測試和自動化測試同等重要，都是保障軟件質量的方法。目前大部分的項目組都是手動測試和自動化測試相結合。因為很多測試無法做成自動化，很多復雜的業務邏輯也很難自動化，所以自動化測試無法取代手動測試。
對于軟件測試人員個人發展來說，做自動化測試是個挑戰，也是測試人員發展的一個方向，需要測試人員學習大量的開發知識（開發的知識真是學無止境啊）。從長遠角度來看，自動化測試肯定是越來越吃香的。
而手動測試比較適合剛工作不久的人，手動測試最大的缺點就是技術含量低，單調乏味，容易廢人。
總的來說，手工測試勝在測試業務邏輯，而自動化測試勝在測試底層架構。
如果被測試的程序可測試性比較好，很有必要做成自動化測試。能做自動化的盡量做成自動化，下面這些情形是可以做自動化的
1、測試存儲過程。例如用C#去測試存儲過程
2、測試Webservies.例如：用SoupUI工具，或者C#，Java去測試Webservies。
3、界面和業務邏輯分離的系統，比如，MVC，MVP架構，或者WPF程序。可以用測試腳本去測試這些程序的API。
從測試的目的分類
功能測試
測試的范圍從小到大，從內到外，從程序開發人員（單元測試）到測試人員，到一般用戶Alpha/Beta測試
測試名稱 | 測試內容 |
Unit Test 單元測試 | 在最低的功能/參數上驗證程序的準確性,比如測試一個函數的正確性(開發人員做的) |
Functional Test 功能測試 | 驗證模塊的功能 （測試人員做的） |
Integration Test 集成測試 | 驗證幾個互相有依賴關系的模塊的功能 （測試人員做的） |
Scenario Test 場景測試 | 驗證幾個模塊是否能完成一個用戶場景 （測試人員做的） |
System Test 系統測試 | 對于整個系統功能的測試 （測試人員做的） |
alpha 測試
| 軟件測試人員在真實用戶環境中對軟件進行全面的測試 （測試人員做的） |
Beta 測試 | 真實的用戶在真實的用戶環境中進行的測試, 也叫公測 （最終用戶做的） |
|
測試名稱 | 測試內容 | | Stress test 壓力測試 | 驗證軟件在超過負載設計的情況下仍能返回正確的結果，沒有崩潰 | | Load test負載測試 | 測試軟件在負載情況下能否正常工作 | | Performance test性能測試 | 測試軟件的效能，是否提供滿意的服務質量 | | Accessibility test | 軟件輔助功能測試-測試軟件是否向殘疾用戶提供足夠的輔助功能 | | Localization/Globalization | 本地化/全球化測試 | | Compatibility Test | 兼容性測試 | | Configuration Test | 配置測試-測試軟件在各種配置下能否正常工作 | | Usability Test | 可用性測試 –測試軟件是否好用 | | Security Test | 軟件安全性測試 |
性能測試 性能測試要求測試人員熟練性能測試工具，比如QTP，LoadRunner，Jmeter。VisualStudio也提供了很多性能測試的工具。要求測試人員對低層協議非常理解和編寫腳本 性能測試非常有技術含量，很有發展前途，是軟件測試人員的一個職業發展方向。 安全性測試 安全性測試的內容很廣，非常有難度啊。我只接觸過XSS（跨站腳本攻擊）和SQL注入攻擊。 安全性測試非常有技術含量，我認為也是軟件測試人員的一個職業發展方向 按測試的時機和作用分類 在開發軟件的過程中，不少測試起著“烽火臺”的作用，它們告訴我們軟件開發的流程是否暢通。 | 測試名稱 | 測試內容 | | Smoke Test | “冒煙”–如果測試不通過，則不能進行下一步工作 | | Build Verification Test（BVT） | 驗證構建是否通過基本測試。 | | Acceptance Test | 驗收測試，為了全面考核某功能/特性而做的測試 | BVT測試是一種Smoke Test，指Build生成好之后，自動運行的自動化測試腳本來檢查這個Build的基本功能。如果BVT測試失敗了，需要開發人員馬上修改，重新生成Buil 按測試測策略分類 | 測試名稱 | 測試內容 | | Regression Test 回歸測試 | 對一個新的版本，重新運行以往的測試用例，看看新版本和已知的版本相比是否有退化 (regression) | | Ad hoc Test 探索性測試 | 隨機進行的，探索性的測試。 | | Santiy Test | 粗略的測試， 只需要執行部分的測試用例 | Regression Test 回歸測試： 對軟件測試人員來說就是重復測試，所以回歸測試最好是自動化的，否則測試人員就要一遍又一遍地重復測試。 1、開發人員做些小改動，就需要測試人員做回歸測試。確保現有的功能沒有被破壞 2、Bug Fix 也需要回歸測試，確保新的代碼修復了Fix，也確保現有的功能沒有被破壞 3、項目后期，需要做一個完整回歸測試，確保所有的功能都是好的 Ad hoc Test 探索性測試： 平常我最喜歡做隨機測試了，拋開test case，自己按照自己的思路，隨便點點。如果測試GUI，Ad hoc能發現大量的bug。 |
非功能測試
一個軟件除了基本功能之外，還有很多功能之外的特性，這些叫“Quality of Service requirement”服務質量需求。沒有軟件的功能，這些特性都無從表現出來，因此，我們要在軟件開發的適當階段-基本功能完成后做這些測試。