常見的軟件測試方法及彙總

按測試設計方法分類

黑盒測試（Black Box）

　　測試內容：黑盒測試是把測試對象看作一個黑盒子，利用黑盒測試法進行動態測試時，須要測試軟件產品已經實現的功能是否符合功能設計要求，不需測試軟件產品的內部結構和處理過程。
　　黑盒測試注重於測試軟件的功能性需求，也即黑盒測試使軟件工程師派生出執行程序全部功能需求的輸入條件。黑盒測試並非白盒測試的替代品，而是用於輔助白盒測試發現其餘類型的錯誤。

黑盒測試具體說明連接：what's the 黑盒測試

 

白盒測試（White Box）

　　測試內容：設計者能夠看到軟件系統的內部結構，而且使用軟件的內部知識來指導測試數據及方法的選擇。
　　白盒測試一般被認爲是單元測試與集成測試，期中有六種測試方法：語句覆蓋、斷定覆蓋、條件覆蓋、斷定/條件覆蓋、條件組合覆蓋。

白盒測試具體說明連接：what's the 白盒測試

　　
灰盒測試（Gray Box）

　　測試內容：介於黑盒和白盒之間，是一種綜合測試的方法，他將白盒測試和黑盒測試結合在一塊兒，構成一種無縫測試技術。
　　灰盒測試是基於程序運行時的外部表現又結合程序內部邏輯結構來設計測試用例，執行程序並採集程序路徑執行信息和外部用戶接口結果的測試技術。灰盒測試法旨在驗證軟件知足外部指標以及軟件的全部通道或路徑都進行了檢驗。

灰盒測試具體說明連接：what's the 灰盒測試

總結

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

 

按測試是手動仍是自動上分類

手動測試（Manual Test）　　

　　測試內容：測試人員用鼠標去手動測試 （測試GUI），用鼠標各類點點點，手工測試更能容易發現軟件的Bug。

自動化測試（Automation Test）

　　測試內容：用程序測試程序 （測試API），由測試人員根據手工測試的Case來決定自動化測試的Case，再編寫程序或者腳原本替代手工作自動化測試

總結

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

 

按測試的目的分類

功能測試
　　測試內容：測試的範圍從小到大，從內到外， 從程序開發人員（單元測試）到測試人員，到通常用戶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：軟件安全性測試

性能測試
　　性能測試要求測試人員熟練性能測試工具，好比QTP, LoadRunner, Jmeter。  Visual Studio也提供了不少性能測試的工具. 要求測試人員對低層協議很是理解和編寫腳本
　　性能測試很是有技術含量， 頗有發展前途， 是軟件測試人員的一個職業發展方向。
　　性能測試推薦看一本書：《軟件性能測試過程詳解與案例剖析》

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

 

按階段分類

單元測試

　　是指對軟件中的最小可測試單元進行檢查和驗證。樁模塊（stud）是指模擬被測模塊所調用的模塊，驅動模塊（driver）是指模擬被測模塊的上級模塊，驅動模塊用來接收測試數據，啓動被測模塊並輸出結果。

集成測試

　　是單元測試的下一階段，是指將經過測試的單元模塊組裝成系統或子系統，再進行測試，重點測試不一樣模塊的接口部門。集成測試就是用來檢查各個單元模塊結合到一塊兒可否協同配合，正常運行。

系統測試

　　指的是將整個軟件系統看作一個總體進行測試，包括對功能、性能，以及軟件所運行的軟硬件環境進行測試。系統測試的主要依據是《系統需求規格說明書》文檔。

驗收測試

　　指的是在系統測試的後期，以用戶測試爲主，或有測試人員等質量保障人員共同參與的測試，它也是軟件正式交給用戶使用的最後一道工序。 驗收測試又分爲a測試和beta測試，其中a測試指的是由用戶、 測試人員、開發人員等共同參與的內部測試，而beta測試指的是內測後的公測，即徹底交給最終用戶測試。

按測試的時機和做用分類

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

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

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

 

按測試測策略分類

• Regression Test 迴歸測試：對一個新的版本，從新運行以往的測試用例，看看新版本和已知的版本相比是否有退化 (regression)
• Ad hoc Test 探索性測試：隨機進行的，探索性的測試。
• Sanity Test：粗略的測試， 只須要執行部分的測試用例（好比不少Web網頁，肯定比較重要以及經常使用的URL連接是活着的，能正常打開返回數據）

Regression Test 迴歸測試

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

• 開發人員作些小改動，就須要測試人員作迴歸測試。確保現有的功能沒有被破壞
• Bug Fix 也須要回歸測試，確保新的代碼修復了Fix, 也確保現有的功能沒有被破壞
• 項目後期，須要作一個完整迴歸測試，確保全部的功能都是好的

Ad hoc Test 探索性測試
　　日常我最喜歡作隨機測試了， 拋開test case.  本身按照本身的思路，隨便點點。 若是測試GUI，Ad hoc能發現大量的bug。這個主要是基於測試人員對軟件系統的瞭解以及測試人員本身我的的測試經驗積累，差很少行成了一種習慣性的操做

 

其餘測試類型

迴歸測試

　　是指對軟件的新的版本測試時，重複執行上一個版本測試時的用例。是指對軟件的新的版本測試時，重複執行上一個版本測試時的用例。

冒煙測試

　　是指在對一個新版本進行大規模的測試以前，先驗證一下軟件的基本功能是否實現，是否具有可測性。

隨機測試

　　是指測試中全部的輸入數據都是隨機生成的，其目的是模擬用戶的真實操做，並發現一些邊緣性的錯誤。

 

 

 

參考：https://blog.csdn.net/zbj18314469395/article/details/79853677