【轉載】如何對軟件測試方法分類

　　軟件測試方法種類繁多，記憶起來混亂，若是把軟件測試方法進行分類，就會清晰不少。我參考一些書籍和網上的資料，把經常使用的軟件測試方法列出來，讓你們對軟件測試行業有個整體的見解。

　　1、從測試設計方法分類

測試名稱	測試內容
Black   box黑盒測試	把軟件系統看成一個「黑箱」，沒法瞭解或使用系統的內部結構及知識。從軟件的行爲，而不是內部結構出發來設計測試.
White   box白盒測試	設計者能夠看到軟件系統的內部結構，而且使用軟件的內部知識來指導測試數據及方法的選擇。
Gray box  灰盒測試	介於黑盒和白盒之間

　　總結：實際工做中，對系統的瞭解越多越好。目前大多數的測試人員都是作黑盒測試，不多有作白盒測試的。由於白盒測試對軟件測試人員的要求很是高，須要有不少編程經驗。作.NET程序的白盒測試你要能看得懂.NET代碼。作JAVA程序的測試，須要你能看懂JAVA的代碼。

　　2、從測試是手動仍是自動上分類

 

測試名稱	測試內容
Manual   Test 手動測試	測試人員用鼠標去手動測試 （測試GUI）
Automation 自動化測試	用程序測試程序 （測試API）

　　對於項目來講，手動測試和自動化測試同等重要，都是保障軟件質量的方法。目前大部分的項目組都是手動測試和自動化測試相結合。由於不少測試沒法作成自動化，不少複雜的業務邏輯也很難自動化，因此自動化測試沒法取代手動測試。對於軟件測試人員我的發展來講，作自動化測試是個挑戰，也是測試人員發展的一個方向，須要測試人員學習大量的開發知識。從長遠角度來看，自動化測試確定是愈來愈吃香的。而手動測試比較適合剛工做不久的人，手動測試最大的缺點就是技術含量低，單調乏味，容易使新入行的人感到測試沒有前途。總的來講，手工測試勝在測試業務邏輯，而自動化測試勝在測試底層架構。

　　若是被測試的程序可測試性比較好，或者說是被測對象是個研發產品性質的，不是一次性的項目，就頗有必要作自動化測試。能作自動化的儘可能作成自動化，下面這些情形是能夠作自動化的：

　　① 測試存儲過程。例如用C#去測試存儲過程

　　② 測試Webservies。例如：用SoupUI工具，或者C#，Java去測試Webservies。

　　③ 界面和業務邏輯分離的系統。例如：MVC，MVP架構，或者WPF程序。能夠用測試腳本去測試這些程序的API。

　　3、從測試的目的分類

• 　　功能測試

　　　　測試的範圍從小到大，從內到外，從程序開發人員（單元測試）到測試人員，到通常用戶Alpha/Beta測試

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

• 　　非功能測試

　　　　一個軟件除了基本功能以外，還有不少功能以外的特性，這些叫「Quality of Service requirement」服務質量需求。沒有軟件的功能，這些特性都無從表現出來，所以，咱們要在軟件開發的適當階段（基本功能完成後）作這些測試。

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

• 　　性能測試

　　　　性能測試要求測試人員熟練性能測試工具，好比Rational Performance Test，LoadRunner，Jmeter。VisualStudio也提供了不少性能測試的工具。要求測試人員對底層協議很是理解和編寫腳本能力。性能測試很是有技術含量，頗有發展前途，是軟件測試人員的一個職業發展方向。

• 　　安全性測試

　　　　安全性測試的內容很廣，很是有難度啊。如XSS（跨站腳本攻擊）和SQL注入攻擊。安全性測試很是有技術含量，也是軟件測試人員的一個職業發展方向

　　4、按測試的時機和做用分類

　　在開發軟件的過程當中，很多測試起着「烽火臺」的做用，它們告訴咱們軟件開發的流程是否暢通。

測試名稱	測試內容
Smoke Test	「冒煙」–若是測試不經過，則不能進行下一步工做
Build Verification Test（BVT）	驗證構建是否經過基本測試。
Acceptance   Test	驗收測試，爲了全面考覈某功能/特性而作的測試

　　BVT測試是一種Smoke Test，指Build生成好以後，自動運行的自動化測試腳原本檢查這個Build的基本功能。若是BVT測試失敗了，須要開發人員立刻修改，從新生成Build。

　　5、按測試測策略分類

測試名稱	測試內容
Regression   Test 迴歸測試	對一個新的版本，從新運行以往的測試用例，看看新版本和已知的版本相比是否有退化 (regression)
Ad hoc Test   探索性測試	隨機進行的，探索性的測試。
Santiy Test	粗略的測試，   只須要執行部分的測試用例

　　Regression Test 迴歸測試：對軟件測試人員來講就是重複測試，因此迴歸測試最好是自動化的，不然測試人員就要一遍又一遍地重複測試。

　　① 開發人員作些小改動，就須要測試人員作迴歸測試。確保現有的功能沒有被破壞

　　② Bug Fix 也須要回歸測試，確保新的代碼修復了Fix，也確保現有的功能沒有被破壞

　　③ 項目後期，須要作一個完整迴歸測試，確保全部的功能都是好的。

　　「Ad Hoc」 測試：Ad Hot原意是指 「特定的，一次性的」；就是爲了某一個特定目的進行的測試，就這一次，之後通常也不會重複測試或是嘗試性測試某種狀況，來檢測是否有問題，因此並不是像許多測試人員所講的是「猴子測試」，誤理解了什麼是Ad Hoc Testing；正確的測試應是在測試過程當中， 「ad hoc」 測試能夠用來衡量當前測試用例的完備性，設計某些特定的，一次性的測試用例，去檢查在現有測試用例以外的問題，假如測試時，未發現什麼問題，說明現有的測試用例是比較完備的，反之，則不是。

　　「Ad-Hoc」 原意是指「特定的，一次性的」，這裏專指「隨機的，自由的」測試。在軟件測試中除了根據測試樣例和測試說明書進行測試外，還須要進行隨機測試(Ad-hoc testing)，主要是根據測試者的經驗對軟件進行功能和性能抽查。隨機測試是根據測試說明書執行樣例測試的重要補充手段，是保證測試覆蓋完整性的有效方式和過程。隨機測試主要是對被測軟件的一些重要功能進行復測，也包括測試那些當前的測試樣例(Test Case)沒有覆蓋到的部分。另外，對於軟件更新和新增長的功能要重點測試。重點對一些特殊點狀況點、特殊的使用環境、併發性、進行檢查。尤爲對之前測試發現的重大Bug，進行再次測試，能夠結合迴歸測試(Regression testing)一塊兒進行。理論上，每個被測軟件版本都須要執行隨機測試，尤爲對於最後的將要發佈的版本更要重視隨機測試。隨機測試最好由具備豐富測試經驗的熟悉被測軟件的測試人員進行測試。對於被測試的軟件越熟悉，執行隨機測試越容易。只有不斷的積累測試經驗，包括具體的測試執行和對缺陷跟蹤記錄的分析，不斷總結，才能提升。
　　關於Ad-hoc測試的簡短問答。

　　問：什麼叫「特定」測試？或者「探索式」的測試？
　　答：就是爲了某一個特定目的進行的測試，就這一次，之後通常也不會重複測試。在軟件工程的實踐中，「ad hoc」大部分是指隨機進行的，探索性的測試。好比：測試人員阿毛拿到了一個新的Build，按計劃是進行模塊A的功能測試，可是他靈機一動，想看看另外一個功能B作得如何，或者想看看模塊A在某種邊界條件下會出現什麼問題，因而他就「ad hoc」一把，竟然在這一功能模塊中發現了很多Bug。 「ad hoc」也意味着測試是嘗試性的，「我來試試，在這個對話框中一通亂按，而後隨意改變窗口大小，看看會出什麼問題…」， 若是沒問題，那麼之後也不會再這麼作了。通常狀況下，測試人員不會花不少時間進行特定測試，可是在一些缺少管理的團隊中，不少時候測試人員不知道本身此時應該作什麼，只好作一些看似「ad hoc」 的測試，好比隨機測試各個功能的各個方面。這些測試理論上都應該由測試管理人員規劃好屬於各個功能模塊的測試用例中。 在一個團隊中，「ad hoc」太可能是一個管理很差的標誌，由於「ad hoc」是指那些一時想到要作，可是之後也沒有計劃常常重複的測試計劃。

　　問：我據說有人是「ad hoc」測試的高手，這是什麼意思？
　　答：有不少測試人員會循序漸進地進行測試，可是還有一些人頭腦比較靈活，喜歡另闢蹊徑，測試一些通常人不會想到的場景，這些人每每會發現更多的Bug。開發人員對這樣的「ad hoc」高手是又愛又恨。

　　問：同時看問題要分兩方面，有些「ad hoc」發現的Bug在正常使用軟件中幾乎不會出現，咱們要不要花時間「ad hoc」？
　　答：如今一些成功的通用軟件的用戶以百萬計，循序漸進的測試計劃很難包括不少實際的場景，這時，「ad hoc」測試可以發現重要的問題；另一些風險很大的領域，例如安全性，一旦出了問題，威脅就會至關大，這時要多鼓勵一些「ad hoc」測試，以彌補普通測試的不足。從這個意義上說，「ad hoc」測試能夠用來衡量當前測試用例的完備性，若是你探索了半天，都沒有發現什麼在現有測試用例以外的問題，那就說明現有的測試用例是比較完備的。 「ad hoc」測試的測試流程是不可重複的，由於它的測試都是「特定」測試，無法重複。因爲這一緣由，「ad hoc」測試不能自動化，就這一點而言，還達不到CMM的第二級–可重複級。做爲管理人員來講，若是太多Bug是在「ad hoc」出來的，那咱們就要看看測試計劃是否基於實際的場景，開發人員的代碼邏輯是否完善，等等。同時，要善於把看似「ad hoc」的測試用例抽象出來，包括到之後的測試計劃中。

　　問：作好「ad hoc」測試有什麼竅門？ 隨機測試有些小竅門，能夠幫助測試人員更有效的發現bug。
　　答：竅門一，在發現不少bug的地方，必定能夠發現更多的bug。咱們在作隨機測試的時候，每每會先統計一下，上週哪些模塊被發現的bug最多，那麼這周必定要狠狠的在那個模塊裏發掘一下。

　　竅門二，作到知己知彼。知己就是要了解本身在哪些方面有特長，多發揮這些特長；知彼主要是瞭解兩方面，一是程序自己哪些地方最複雜，最薄弱，這些地方最容易發生什麼錯誤，二是程序員最容易在哪些地方犯哪些錯誤。前者經過對程序的熟悉能夠比較好的掌握，後者能夠經過CQ(BUG管理工具)分析獲得。
　　竅門三，多和程序員溝通。在和程序員溝通的過程當中，你能夠知道不少你前所未知的東西，你能夠經過驗證這些東西，來發現未知的bug，而且能夠激發你運用更多的測試手段來測試。
【注】Ad Hot 測試內容來自CSDN博客，轉載請標明出處：http://blog.csdn.net/wayne_ran/archive/2008/01/08/2030915.aspx