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

標籤：style   blog   http   color   java   使用   io   strong   

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

　　一、從測試設計方法分類

測試名稱	測試內容
Black   box黑箱測試	把軟體系統當作一個“黑箱”，無法瞭解或使用系統的內部結構及知識。從軟體的行為，而不是內部結構出發來設計測試.
White   box白盒測試	設計者可以看到軟體系統的內部結構，並且使用軟體的內部知識來指導測試資料及方法的選擇。
Gray box  灰盒測試	介於黑盒和白盒之間

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

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

 

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

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

　　如果被測試的程式可測試性比較好，或者說是被測對象是個研發產品性質的，不是一次性的項目，就很有必要做自動化測試。能做自動化的盡量做成自動化，下面這些情形是可以做自動化的：

　　① 測試預存程序。例如用C#去測試預存程序

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

　　③ 介面和商務邏輯分離的系統。例如：MVC，MVP架構，或者WPF程式。可以用測試指令碼去測試這些程式的API。

　　三、從測試的目的分類

• 　　功能測試

　　　　測試的範圍從小到大，從內到外，從程式開發人員（單元測試）到測試人員，到一般使用者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注入攻擊。安全性測試非常有技術含量，也是軟體測試人員的一個職業發展方向

　　四、按測試的時機和作用分類

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

測試名稱	測試內容
Smoke Test	“冒煙”–如果測試不通過，則不能進行下一步工作
Build Verification Test（BVT）	驗證構建是否通過基本測試。
Acceptance   Test	驗收測試，為了全面考核某功能/特性而做的測試

　　BVT測試是一種Smoke Test，指Build產生好之後，自動啟動並執行自動化測試指令碼來檢查這個Build的準系統。如果BVT測試失敗了，需要開發人員馬上修改，重建Build。

　　五、按測試測策略分類

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

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

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

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

　　③ 項目後期，需要做一個完整迴歸測試，確保所有的功能都是好的。

　　“Ad Hoc” 測試：Ad Hot原意是指 “特定的，一次性的”；就是為了某一個特定目的進行的測試，就這一次，以後一般也不會重複測試或是嘗試性測試某種情況，來檢測是否有問題，所以並非像許多測試人員所講的是“猴子測試”，誤理解了什麼是Ad Hoc Testing；正確的測試應是在測試過程中， “ad hoc” 測試可以用來衡量當前測試案例的完備性，設計某些特定的，一次性的測試案例，去檢查在現有測試案例之外的問題，假如測試時，未發現什麼問題，說明現有的測試案例是比較完備的，反之，則不是。
【注】如果你想瞭解更多關於Ad Hoc Testing請查看這個連結中的介紹: http://www.testingcraft.com/ad_hoc_testing.pdf 關於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