軟件測試基本概念

1、測試概述

本文徹底參考 https://www.cnblogs.com/lihou...

• 軟件測試是爲了發現錯誤而執行程序的過程
• 軟件測試的基本原則是儘早地和不斷地進行軟件測試
  

2、測試分類

一、根據測試方法劃分

1.1 黑盒測試

把被測的軟件看做是一個黑盒子，咱們不去關心盒子裏面的結構是什麼樣子的，只關心軟件的輸入數據和輸出結果。

它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息。黑盒測試着眼於程序外部結構，不考慮內部邏輯結構，主要針對軟件界面和軟件功能進行測試。

採用黑盒技術設計測試用例的方法有

• 等價類劃分
• 邊界值分析
• 錯誤推測
• 因果圖
• 綜合策略

1.2 白盒測試

把盒子蓋子打開，去研究裏面的源代碼和程序結果。

它是按照程序內部的結構測試程序，經過測試來檢測產品內部動做是否按照設計規格說明書的規定正常進行，檢驗程序中的每條通路是否都可以按預約要求正確工做。

1.3 灰盒測試

介於黑盒與白盒測試之間

能夠這樣理解，灰盒測試關注輸入對於輸出的正確性，同時也關注內部表現，但這種關注不像白盒那樣詳細、完整，只是經過一些表徵性的現象、事件、標誌來判斷內部的運行狀態。有時候輸出是正確的，但內部其實已經錯誤了，這種狀況很是多，若是每次都經過白盒測試來操做，效率會很低，所以須要採起這樣的一種灰盒方法。

二、根據測試流程/開發階段劃分

• 單元測試

  • 對軟件中的基本組成單位進行的測試
  • 目的是檢驗軟件基本組成單位的正確性

• 集成測試

  • 在系統集成過程當中所進行的測試
  • 目的是檢查軟件單位之間的接口是否正確

• 系統測試

  • 對已經集成好的軟件系統進行完全的測試
  • 目的是驗證軟件系統的正確性和性能等是否知足規約指定的要求

• 驗收測試

  • 部署軟件以前的最後一個測試操做
  • 目的是確保軟件準備就緒，向軟件購買者展現該軟件系統知足其用戶的要求

2.1 單元測試階段

模塊接口測試
經過所測模塊的數據流進行測試。調用所測模塊時的輸入參數與模塊的形式參數的個數、屬性和順序是否匹配。

局部數據結構測試
是爲了保證臨時存儲在模塊內的數據在程序執行過程當中完整、正確，模塊的局部數據結構每每是錯誤的根源。

路徑測試
是指對模塊中重要的執行路徑進行測試。

錯誤處理測試
比較完善的模塊設計要求能預見出錯的條件，並設置適當的出錯處理，以便一旦程序出錯時能對出錯程序從新安排，保證其邏輯上的正確性。

邊界條件測試
大量的錯誤是發生在輸入或輸出的邊界上。所以針對各類邊界狀況設計測試用例，能夠查出更多的錯誤。

2.2 集成測試階段

在集成測試中，咱們主要關注如下內容：

• 把各個模塊鏈接起來，穿越模塊接口的數據是否會丟失。
• 各個子模塊組合起來，可否達到預期要求的功能。
• 一個模塊的功能是否會對另外一個模塊的功能產生不利影響。
• 全局數據結構是否有問題。
• 單個模塊的偏差積累起來是否會被放大，從而達到不可接受的程度。

2.3 系統測試階段

通常系統的主要測試工做都集中在系統測試階段。根據不一樣的系統所進行的測試種類也不少，例如：

• 功能測試，是對產品的各功能進行驗證，以檢查是否知足需求的要求。
• 性能測試，是經過自動化測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能進行測試。
• 安全測試，檢查系統對非法入侵的防範能力。
• 兼容測試，主要是測試系統在不一樣軟硬件環境下可否正常的運行。

2.4 驗收測試階段

• 功能確認測試
• 安全可靠性測試
• 兼容性測試
• 易用性測試
• 可擴充性測試
• 資源佔用率測試
• 用戶文檔資料驗收

3. 根據測試的側重劃分

3.1 功能測試

功能測試檢查實際的功能是否符合用戶的需求。

功能測試又能夠細分爲不少種：邏輯功能測試、界面測試、易用性測試、安裝測試、兼容性測試等。

功能測試
在規定的一段時間內運行軟件系統的全部功能，以驗證這個軟件系統有無嚴重錯誤。

易用性測試
從使用的合理性和方便性等角度對軟件系統進行檢查，發現人爲因素或使用上的問題。

安裝測試
安裝測試的目的不是找軟件錯誤，而是找安裝錯誤。

兼容性測試
這類測試主要想驗證軟件產品在不一樣版本之間的兼容性。有兩類基本的兼容性測試：

• 向下兼容，測試軟件新版本保留它早期版本的功能
• 交錯兼容，驗證共同存在的兩個相關但不一樣的產品之間的兼容性

恢復測試
證明在克服硬件故障（包括掉電、硬件或網絡出錯等）後，系統可否正常地進行工做，並不對系統形成任何損害。爲此，可採用各類人工干預的手段，模擬硬件故障，並由此檢查：

• 錯誤探測功能（系統可否發現硬件失效或故障）
• 可否切換或啓動備用的硬件
• 在故障發生時可否保護正在運行的做業和系統狀態
• 在系統恢復後可否從最後記錄下來的無錯誤狀態開始繼續執行做業等

若是系統的恢復時自動的（由系統自身執行），則應對從新初始化、數據恢復、從新啓動等逐個進行正確性評價。若是恢復須要人工干預，就須要對恢復的平均時間進行評估以及判斷它是否在容許的範圍以內。

文檔測試
檢查用戶文檔（如用戶手冊）的清晰性和精確性。確保敘述正確無誤。

可支持性測試
驗證系統的支持策略對於公司與用戶方面是否切實可行。它所採用的方法是試運行支持過程（如對有錯部分打補丁的過程等），對其結果進行質量分析，評審診斷工具、維護或稱、內部維護文檔；衡量修復一個明顯錯誤所需的平均最少時間。還有一種經常使用的方法是，在發行前把產品交給用戶，向用戶提供支持服務的計劃，從用戶處獲得對支持服務的反饋。

互連測試
驗證兩個或多個不一樣的系統之間的互連性。這類測試對支持標準規格說明或承諾支持其餘系統互連的軟件系統有效。

3.2 性能測試

性能測試是經過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。

軟件的性能包括不少方面，主要有時間性能和空間性能兩種。

• 時間性能，主要是指軟件的一個具體的響應時間。好比一個登錄所需的時間，一個交易所須要的時間等。
• 空間性能，主要指軟件運行時所消耗的系統資源。好比硬件資源、CPU、內存、網絡帶寬消耗等。

性能測試方法是經過模擬生產運行的業務壓力量和使用場景組合，測試系統的性能是否知足生產性能要求。通俗地說，這種方法就是要在特定的運行條件下驗證系統的能力狀態。性能測試特色以下：

1. 主要目的是驗證系統是否有系統宣稱具備的能力
2. 要事先了解被測試系統經典場景，並具備肯定的性能目標
3. 要求在已經肯定的環境下運行。

也就是說，這種方法是對系統性能已經有了瞭解的前提並對需求有明確的目標，並在已經肯定的環境下進行的。

負載測試
經過在被測系統上不斷加壓，直到性能指標達到極限。

這種方法是對一個系統持續不斷地加壓，看你在何時已經超出「個人要求」或系統給崩潰。

1. 主要目的是找到系統處理能力的極限。
2. 須要在特定的測試環境下進行，一般也須要考慮北側是系統的業務壓力量和典型場景、使得測試結果具備業務上的意義。
3. 通常用來了解系統的性能容量或是配合性能調優來使用。

壓力測試
測試系統在必定飽和狀態下（例如cpu、內存在飽和狀況下）可以處理的會話能力，以及系統是否會出現錯誤。

也就是說，這種測試是讓系統處在很大強度的壓力之下，看系統是否穩定，哪裏會出問題。

1. 主要目的是檢查系統處於壓力性能下時，應有的表現。
2. 通常經過模擬負載等方法，使得系統的資源使用達到較高水平。
3. 通常用於測試系統的穩定性。

配置測試
配置測試方法經過對被測系統的軟硬件環境的調整，瞭解各類不一樣配置對系統性能影響的程度，從而找到系統各項資源的最優分配原則。

這種測試關注點是「微調」，經過對軟硬件的不斷調整，找出它們的最佳狀態，使系統達到一個最強的狀態。

1. 主要目的是瞭解各類不一樣因素對系統性能影響的程度，從而判斷出最值得進行的調優操做。
2. 通常在對系統性能情況有初步瞭解後進行。
3. 通常用於性能調優和規劃能力。

可靠性測試
在給系統加載必定業務壓力的狀況下，使系統運行一段時間，以此檢測是否穩定。

這種測試的關注點是「穩定」，不須要給系統太大壓力，只要系統可以長期處於一個穩定的狀態。

1. 主要目的是驗證是否支持長期穩定的運行。
2. 須要在壓力下持續運行一段時間（2~3天）。
3. 測試過程當中須要關注系統的運行情況。

測試容量
經過測試預先分析出反映軟件系統應用特徵的某項指標的極限值（如最大併發用戶數、數據庫記錄數等），系統在其極限值狀態下沒有出現任何軟件故障或還能保持主要功能正常運行。

併發測試
經過模擬用戶併發訪問，測試多用戶併發訪問同一個應用、同一個模塊或者數據記錄時是否存在死鎖或者其它性能問題。

這種測試關注點是多個用戶同時（併發）對一個模塊或操做進行加壓。

1. 主要目的是發現系統中可能隱藏的併發訪問時的問題。
2. 主要關注可能存在的併發問題，例如系統中的內存泄漏、線程死鎖和資源爭用方面的問題。
3. 能夠在開發的各個階段使用須要相關的測試工具的配合和支持。

四、根據測試是否使用自動化工具劃分

4.1 手工測試

手工測試就是由人去一個一個地去執行測試用例，經過鍵盤鼠標等輸入一些參數，查看返回結果是否符合預期結果。

4.2 自動化測試

自動化測試是把以人爲驅動的測試行爲轉化爲機器執行的一種過程。一般，在設計了測試用例並經過評審以後，由測試人員根據測試用例中描述的規程一步步執行測試，獲得實際結果與指望結果的比較。在此過程當中，爲了節省人力、時間或硬件資源，提升測試效率，便引入了自動化測試的概念。

自動化測試：又可分爲功能自動化測試與性能自動化測試。

咱們通常所說的自動化測試就是指功能自動化測試，經過相關的測試技術，經過編碼的方式用一段程序來測試一個軟件的功能，這樣就能夠重複執行程序來進行重複的測試。若是一個軟件一小部分發生改變，咱們只要修改一部分代碼，就能夠重複的對整個軟件進行功能測試。這樣就大大的提升了測試效率。

性能自動化測試，除了早期階段，如今的性能測試工做都是經過性能測試工具輔助完成的。能過工具能夠模擬成千上萬的用戶向系統發送請求，用來驗證系統的處理能力。

五、其它測試方法

5.1 冒煙測試

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

引入到軟件測試中，就是指測試小組在正規測試一個新版本以前，先投入較少的人力和時間驗證一個軟件的主要功能，若是主要功能都沒有實現，則打回開發組從新開發。這樣作的好處是能夠節省大量的時間成本和人力成本。

5.2 迴歸測試

是指修改了舊代碼後，從新執行測試以確認修改後沒有引入新的錯誤或致使其它代碼產生錯誤。

迴歸測試通常是在進行軟件的第二輪測試開始的，驗證第一輪中發現的問題是否獲得修復。固然，迴歸也是一個循環的過程，若是迴歸的問題通不過，則須要開發人員修改後再次進行迴歸，直到經過爲止。

5.3 隨機測試

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

隨機測試能夠發現一些隱蔽的錯誤，可是也有不少缺點。好比測試不繫統，沒法統計代碼覆蓋率和需求覆蓋率，發現的問題難以重現。通常是放在測試的最後執行。其實隨機測試更專業的升級版叫探索性測試。

探索性測試是一種測試思惟技術。它沒有不少實際的測試方法、技術和工具，可是倒是全部測試人員都應該掌握的一種測試思惟方式。探索性強調測試人員的主觀能動性，拋棄繁雜的測試計劃和測試用例設計過程，強調在碰到問題時及時改變測試策略。

5.4 安全性測試

安全測試是在IT軟件產品的生命週期中，特別是產品開發基本完成到發佈階段，對產品進行檢驗以驗證產品符合安全需求定義和產品質量標準的過程。

安全測試也在愈來愈受到企業的關注和重視，由於因爲安全性問題形成的後果是不可估量的。尤爲對於互聯網產品最容易遭受各類安全攻擊。

5.5 場景測試

針對用戶需求內容的測試，稱之爲場景測試。場景測試首先在系統測試階段測試經過，而後在用戶確認階段，由用戶執行場景測試來進行產品驗收。

要作到場景測試，實際上須要從需求開始作起。需求與用戶溝通，確認用戶的實際場景，而後分析這些場景，並據此設計出產品的解決方案，獲得用戶使用產品的應用場景，並排列出優先級；而後開發根據場景優先級開發出產品；最後測試根據場景優先級進行測試，並結合軟件實際狀況，給出拓展場景，給出使用說明，推薦給用戶使用。

5.6 輔助功能測試

軟件輔助功能測試是指軟件測試是否向殘疾用戶提供足夠的輔助功能。

5.7 本地化/全球化測試

確保應用程序的世界通用性須要三個測試階段：全球化測試、可本地化測試和本地化測試。

• 全球化測試

  • 確保應用程序在任何區域性或區域設置中都能正常運行

• 可本地化測試

  • 驗證能夠輕鬆地將程序的用戶界面翻譯成任何目標語言

• 本地化測試

  • 檢查特定目標區域性或區域設置的產品本地化的質量

3、中英文對照表

中文	英文
單元測試	Unit Test
集成測試	Intergration Test
系統測試	System Test
驗收測試	Acceptance Test
功能測試	Function Test
易用性測試	Usability Test
安裝測試	Installation Test
兼容性測試	Compatibility Test
恢復測試	Recovery Test
文檔測試	Documentation Test
可支持性測試	Supportability Test
互連測試	Interoperability Test
負載測試	Load Test
壓力測試	Stress Test
配置測試	Configuration Test
可靠性測試	Reliability Test
容量測試	Volume Test
併發測試	Concurrency Test
冒煙測試	Smoke Test
迴歸測試	Regression Test
隨機測試	Ad-hoc Test
安全性測試	Security Test
場景測試	Scenario Test
輔助功能測試	Accessibility Test
本地化/全球化測試	Localization/Globalization Test

4、參考連接

• 軟件測試經常使用術語總結