性能測試學習階段性總結

2關鍵詞

性能測試中的關鍵詞有響應時間、併發用戶數、吞吐量、性能計數器、思考時間，這是性能測試中經常使用的幾個概念，必需要有清晰的認識。

（1）響應時間

響應時間的定義能夠參考下圖，一般的響應時間是指從C1一直到C2所有的時間，這裏我想補充的一個知識點是，因爲前端性能這些年愈來愈受重視，用戶感覺到的時間並非「客戶端收到最後一個字節的時間」，而是愈來愈多的引入了「用戶感覺到的響應時間」。二者的區別在數據量龐大，頁面渲染須要花費大量時間的狀況下極爲明顯，即，咱們優化系統響應時間的一個方向是讓用戶感覺到的響應時間變短。

 

（2）併發用戶數

併發用戶數主要與在線用戶數、系統用戶總數區分。最簡單的認知就是被測系統是一個QQ羣，用戶老是就是全體羣成員，在線用戶數就是在線的成員，併發用戶數就是在聊天的成員。這麼一來就很明顯了，咱們都知道一個QQ羣裏真正活躍的每每是少數人，因此被測系統的併發用戶數也是遠小於系統用戶總數的。

如何肯定併發用戶數，這個問題常見的答案就是看具體狀況，或者用戶總數的10%~20%。事實上，確實沒有能夠適用於大部分軟件的肯定併發用戶數的方法。通常而言，針對於企業內部的信息系統而言，採用經驗公式選擇10%~20%的用戶總數做爲併發用戶數是比較合理的。

（3）吞吐量

吞吐量能直接反應系統的性能承載能力，反應的是系統在單位時間內處理請求的能力。常見的吞吐量衡量指標是請求數/秒或者字節數/小時，固然具體的系統能夠選擇不一樣的指標如頁面數/秒，處理業務數/小時，等等。

注意：要區分這裏的吞吐量與loadrunner的analysis的吞吐量概念並不徹底相同，loadrunner中的吞吐量是字節數/秒，並且引入了平均事務響應時間TPS的概念，分別從不一樣維度展現被測系統的吞吐量。

（4）性能計數器

性能測試的執行階段須要記錄服務器的資源佔用率，通常使用性能計數器來衡量被測系統當前的狀況而且進行性能測試的結果分析。

性能計數器包括不少種類，一般須要咱們關注的就是服務器的資源佔用率、內存使用率、磁盤I/O，固然還有其餘不少的性能計數器，這裏不詳細贅述。經過這些資源的佔用狀況咱們能獲得表徵，可是具體的性能瓶頸還須要深刻的分析。

因爲服務器使用操做系統不一樣，因此須要選擇不一樣的工具，對於Windows系統可使用系統自帶的資源監視器，對於Linux系統可使用nmon工具，這類的工具備不少選擇適用的就能夠。

（5）思考時間

關於思考時間，不少時候咱們都認爲設置成0是最合理的，由於這樣能夠模擬一種儘可能大的壓力，以研究系統在巨大壓力下的表現；可是若是要驗證系統具備預期的能力，則須要儘可能模擬真實用戶在處理業務時的思考時間。

2.3測試的方法

性能測試的方法主要包括驗收性能測試、負載測試、壓力測試、配置測試、併發測試、可靠性測試、失敗恢復測試。

（1）驗收性能測試

驗收性能測試的主要目的是驗證系統是否具備所宣稱的能力，這須要在被測系統有肯定的性能目標，以及肯定的被測環境。性能測試人員在肯定的條件下，經過模擬生產運行的業務壓力量和使用場景組合的方式來進行驗收性能測試。

（2）負載測試

負載測試指經過在被測系統上不斷增長壓力，直到性能指標例如響應時間超過預約指標或者某種資源已經達到飽和狀態。這種測試的目的是找到系統的處理能力極限，另外一方面這種方法能夠了解系統的容量，爲性能調優提供依據。

（3）壓力測試

壓力測試的主要目的是檢查系統在必定壓力下的性能表現。經過模擬負載等方法，使得系統資源佔用達到較高水平。壓力測試通常也用來驗證系統的穩定性

（4）配置測試

配置測試的目的是經過對系統軟硬件調整，瞭解不一樣配置對系統性能影響程度，從而找到最優分配原則。這種測試通常在對系統的性能表現有了必定了解後進行，用於系統的性能調優和規劃能力。

（5）併發測試

併發測試的主要目的是發現系統中可能隱藏的併發訪問問題，經過模擬用戶併發訪問實現，主要關注內存泄露、線程鎖、資源爭用等。併發測試能夠在開發的各階段針對不一樣的對象使用。

（6）可靠性測試

可靠性測試主要的目的是驗證系統可否支持長時間穩定運行。經過給系統加載必定的業務壓力（如資源在70%~90%使用率），讓應用持續運行一段時間，經過關注系統的運行狀態測試系統是否穩定。

這裏我認爲須要對負載測試、壓力測試、可靠性測試加以區分，經過測試的目的區分這三個概念是比較容易的，負載測試的目的在於發現系統的性能瓶頸；壓力測試的目的是在必定壓力下驗證系統性能表現，重點關注響應時間等內容；可靠性測試則是近乎破壞式地讓系統保持在業務的高峯期，關注的是系統可否正常工做，這時就不那麼關注系統的響應時間了。

（7）失效恢復測試

失效恢復測試針對有冗餘備份和載均衡的系統設計，能夠用來檢驗若是系統局部發生故障，用戶可否繼續使用系統，以及用戶將受多大程度的影響。通常只有對持續運行指標有明確需求的系統才須要這類性能測試。

2.4應用領域

性能測試的應用領域主要有能力驗證、規劃能力、性能調優、發現缺陷和性能基準比較五個領域。其中性能基準比較使用於敏捷開發過程當中，在這裏不作講述。下面主要講述經常使用的四個領域。

（1）能力驗證

能力驗證一般是對已部署系統的性能進行驗證。通常採用性能測試，可靠性測試，壓力測試，失效恢復測試

（2）規劃能力

規劃能力主要用於瞭解系統的性能而且得到擴展性能的方法，如系統可否支持將來一段時間內的用戶增加，是一種探索性測試。通常採用負載測試，配置測試和壓力測試

（3）性能調優

性能調優一般是肯定基準的環境和性能指標，經過調整環境和實現方式進行測試，進而發現性能優化的方式，通常採用配置測試，負載測試，壓力測試和失效恢復測試

（4）缺陷發現

這一領域的目的就是發現系統中可能存在的性能缺陷，沒有須要達到的性能指標，所以主要採用併發測試，若是須要關注壓力或者失效恢復過程當中的問題，也能夠採用壓力測試和失效恢復測試。

（5）性能測試應用領域和測試方法的關係

經過下方的表格，能夠幫助讀者更好地理解應用領域與測試方法的關係。

應用領域	主要用途	典型場景	特色	性能測試方法
能力驗證	關注在給定的軟硬件條件下，系統可否具備預期的能力表現	在要求平均響應時間小於2秒的前提下，如何判斷系統是否可以支持50萬用戶/天的訪問量？	a)要求在已肯定的環境下運行 b)須要根據典型場景設計測試方案和用例，包括操做序列和併發用戶量，須要明確的性能目標。	a)性能測試 b)壓力測試 c)可靠性測試 d)失效恢復測試
規劃能力	關注如何使系統具備咱們要求的性能能力	某某系統計劃在一年內獲客量在到xxx萬，系統到時候是否能支持這麼多用戶量？若是不能須要如何調整系統的配置？	a)它是一種探索性的測試 b)經常使用於瞭解系統性能和得到擴展性能的方法	a)負載測試 b)壓力測試 c)配置測試
性能調優	主要用於對系統性能進行調優	某某系統上線運行一段時間後響應速度愈來愈慢，此時應該如何辦？	每次只改變一個配置，切忌無休止的調優	a)負載測試 b)壓力測試 c)配置測試
缺陷發現	發現缺陷或問題重現、定位手段	某些缺陷只有在高負載的狀況下才能暴露出來，如線程鎖、資源競爭或內存泄露。	作爲系統測試的補充，用來發現併發問題，或是對系統已經出現的問題進行重現和定位	a)併發測試 b)壓力測試 c)失效恢復測試

 

 

 

3.性能測試過程模型（PTGM）

性能測試過程模型PTGM（Performance Testing General Model），將性能測試過程分爲測試前期準備、測試工具引入、測試計劃、測試設計與開發、測試執行和管理以及測試分析等6個步驟。另外一種模型是敏捷性能測試模型（APTM），一般敏捷開發的項目若是存在性能需求才會用到這樣的性能測試模型，因爲目前本人的性能測試經驗都是集中在系統或者驗收測試的階段展開，所以本文中只介紹性能測試過程模型PTGM。

 

2.1測試前期準備

前期準備工做主要完成的工做是確保系統穩定和創建性能測試團隊具體的活動包括以下的幾個方面：

（1）系統基礎功能驗證

這一步的目的是肯定系統功能可以正常使用，毫無疑問性能的基礎就是系統可使用，若是系統的正常使用都存在問題，那追求性能也不具有太大的意義。所以，性能測試展開的前提就是確保被測系統通過至少一輪的功能測試。一般接近驗收階段的項目的測試順序是功能測試→安全測試→性能測試，由於若是系統須要引入安全策略或者某些設備的話一樣會對被測系統的性能產生影響。

（2）組建測試團隊

一個性能測試團隊包括的角色以下表，組建性能測試團隊時能夠根據以下的表格，選擇具備相應能力的成員。

角色	職責	技能
測試經理	1.和用戶等項目干係人交互，確保測試的外部環境 2.制訂測試計劃 3.監控測試進度 4.發現和處理測試中的風險	1.計劃執行和監控能力 2.風險意識和能力 3.外交能力和靈活變通的能力
測試設計	1.定義性能規劃 2.識別用戶的性能需求 3.創建性能場景	1.業務把控能力 2.性能需求分析和識別能力
測試開發	1.實現已設計的性能場景 2.腳本開發，調試 3.肯定測試時須要監控的性能指標，性能計數器	1.腳本編碼和調試能力 2.理解性能指標和性能計數器
測試執行	1.部署測試環境 2.執行腳本和場景 3.根據監控要求記錄測試結果，記錄性能指標和性能計數器值	1.搭建測試環境的能力 2.測試工具使用的能力 3.性能指標和性能計數器值獲取和記錄能力
測試分析	1.根據測試結果，性能指標的數值，性能計數器值進行分析 2.能根據性能規劃，分析出系統性能瓶頸，或給出優化建議	1.掌握性能測試工具的使用方法 2.掌握應用系統性能領域相關知識，理解所採用的架構 3.熟悉經常使用的性能分析方法 4.具備必定的編碼經驗
系統支持	1.系統支持，協助解決測試工程師沒法解決的系統問題	1.處理系統問題的能力和技能，最好有專職的系統管理員擔任這個角色
網絡支持	1.網絡方面的支持，協助測試工程師解決網絡方面的問題，在必要時爲測試分析角色提供網絡方面的分析支持	1.網絡方面的能力和技能，最好有專職的網絡管理員擔任這個角色
數據庫支持	1.數據庫方面的支持，在必要時爲測試分析角色提供數據庫方面的支持	1.數據庫方面的能力和技能，最好由專職的DBA擔任這個角色

（3）測試工具選擇

關於性能測試使用的工具，本人想要向讀者說明，性能測試中工具並不會起到決定性的做用，一般在進行測試工具的選擇時，須要考慮被測系統的環境，如操做系統環境、應用服務器環境、數據庫環境、應用使用的協議、網絡環境等，只要性能測試工具知足這些環境的需求，不管是使用loadrunner或者是jmeter都是能夠的。

（4）性能預備測試

這一步是探索性的測試，是非正式的測試，其目的主要是用來對被測系統的性能表現創建初步印象，獲得的結論也是各有不一樣。固然，若是對被測系統已經有了初步的印象，這一步也是能夠跳過的。

2.2測試工具引入

（1）選擇工具

對於性能測試來講，沒有合適的工具配合簡直是不可能實現性能測試的，雖說選擇了好的測試工具也不必定就能作好性能測試，可是選擇一個適合的測試工具顯然是更利於測試活動的開展與實現的。一般是選定幾種測試工具，根據被測系統的環境來選擇最適合項目的測試工具。

（2）工具應用的技能培訓

工具使用方面的培訓主要是針對測試開發、測試執行、測試分析三類角色，目的是保證測試活動參與者具有測試所需的技能。

（3）肯定工具的應用過程

這個步驟主要是明確工具能夠完成的功能，測試工具使用過程當中出現了問題如何解決、測試腳本如何管理等各類相關的問題，這些問題是測試過程當中必須解決的問題。

2.3測試計劃

（1）性能測試領域分析

性能測試計劃就是爲了實現性能測試的目標，根據性能測試的目標咱們就能夠分析出本次性能測試的領域。不一樣應用領域的性能測試的性能測試目標和性能目標以下表

應用領域	性能測試目標	性能目標
能力驗證	驗證系統在給定環境中的性能能力	重點關注關鍵業務響應時間、吞吐量、資源等
規劃能力	驗證系統的性能擴展能力，找出系統能力擴充的關鍵點，給出改善其性能擴展能力的建議	業務的性能瓶頸
性能調優	提供系統的性能表現	重點關注關鍵業務的響應時間、吞吐量、資源等
發現缺陷	發現系統中的缺陷	無

（2）用戶活動剖析業務建模

用戶活動剖析的方法主要分爲系統日誌分析和用戶調查分析。

系統日誌分析是指經過應用系統的日誌瞭解用戶的活動，分析出用戶最關注、最經常使用的業務功能，以及達到業務功能的操做路徑；用戶調查分析是在不具有系統日誌分析條件的時候（例如，該系統還沒有交付用戶運行實際的業務）時採用的一種估算方法，能夠經過用戶調查問卷、同類型系統對比的方法獲取用戶最關注、最經常使用的業務功能等內容。

業務建模主要是採用流程圖畫出各進程之間的交互關係和數據流向，對業務複雜的系統來講，業務建模能夠清晰地呈現系統業務，爲性能測試提供指導做用

（3）肯定性能目標

性能測試目標根據性能測試需求和用戶活動分析結果來肯定，肯定性能測試目標的通常步驟是首先從需求和設計中分析出性能測試需求，結合用戶活動剖析與業務建模的結果，最終肯定性能測試的目標。

對於性能目標，不能是一句響應時間不能太慢，或是要能穩定運行就完了的，由於這樣的目標在測試執行時會遺留下無盡的麻煩。一個較爲詳細的性能目標以下：

系統在5秒響應時間內處理100個併發用戶對業務A的訪問，此時服務器的CPU佔用率小於75%，內存使用率小於70%。

固然客戶給出的需求可能只關注響應時間，或者關注其餘的某些場景下的性能指標，但都須要保證肯定的性能目標，這樣才能保證性能測試良性地進行下去。

（4）制定測試時間計劃

主要是給出性能測試的各個活動起止時間，爲性能測試的執行給出時間上的估算。

2.4測試設計與開發

（1）測試環境設計

測試環境設計是測試設計中不可缺乏的環節。性能測試的結果與測試環境之間的關聯性很是大，不管是哪一種領域內的性能測試，都必須首先肯定測試的環境。

對於「能力驗證」領域的性能測試來講，測試首先就已經明確了是在特定的部署環境上進行，所以不須要特別爲性能測試設計環境，只須要保證用於測試的環境與從此係統運行的環境一致便可。

對於「規劃能力」領域的性能測試來講，測試環境不特定，但也須要設計一個基準的環境。

對於「性能調優」領域的性能測試來講，須要有性能測試來衡量調優的效果，所以必須在開始就給出一個用於衡量的環境標準，並在整個調優過程當中，保證每次測試時的環境保持不變。

這裏的測試環境包括的不只僅是軟件環境和硬件環境，還有一個你們都容易忽略的數據庫環境，在一個幾乎爲空的數據庫和一個已有50000條數據庫的環境上，一樣執行查詢、增長和刪除數據的操做獲得的響應時間明顯是不一樣的。所以若是保證數據庫環境穩定，建議備份數據庫，每次性能測試開始時恢復相同的數據庫備份。

（2）測試場景設計

測試場景模擬的通常是實際業務運行的剖面，其包括業務、業務比例、測試指標的目標以及須要在測試過程當中進行監控的性能計數器。測試場景的示例以下：

場景名稱	場景業務及用戶比例分配	測試指標	性能計數器
用戶登陸	登陸業務，100%用戶 總用戶數200人	響應時間 （<5s）	服務器CPU Usage 服務器內存 Usage
標準平常工做	增長數據，40％用戶 查詢列表，30％用戶 統計分析，30％用戶 總用戶數200人	響應時間 （增長<6s） （查詢<5s） （統計<10s）	服務器CPU Usage 服務器內存 Usage

在性能測試執行中有時是執行單獨的某一功能的性能測試，這樣只能對某一功能驗證，也就是說，其餘業務幾乎不產生壓力的狀況下，某一功能具備什麼樣的性能表現，這顯然是不符合實際的運行環境的，體現的結果也沒法反映被測系統的性能表現。

（3）測試用例設計

測試用例是對測試場景的進一步細化，細化內容包括場景中涉及業務的操做序列描述、場景須要的環境部署等內容。

性能測試的測試用例與功能測試的用例類似，下面是一個登陸業務的測試用例。

一、用戶進入登陸頁面

二、用戶輸入正確的用戶名和口令

三、用戶點擊「登陸」按鈕

四、等待直到出現登陸成功的頁面，判斷該頁面成功顯示的方法是HTML頁面內容中的「歡迎」文本

（4）腳本開發

一個測試腳本通常包含一個業務操做，如登陸的腳本就包含上述測試用例中的登陸業務的程序化描述。測試腳本的開發一般基於「錄製」，依靠工具提供的錄製功能，能夠將須要性能測試關注的業務在工具的錄製下操做一遍，而後基於該錄製後的腳本，對其進行修改和調試，確保其能夠在性能測試中順利使用。最經常使用的腳本修改和調試技巧是「參數化」、「關聯」和「日誌輸出」等。

2.5測試執行和管理

（1）創建測試環境

該活動用於搭建須要的測試環境。在設計完成用例以後就會開始該活動，該活動是一個持續性的活動，在測試過程當中，可能會根據測試需求進行環境上的調整。

創建測試環境通常包括硬件、軟件系統環境的搭建，數據庫環境創建，應用系統的部署，系統設置參數的調整，以及數據環境準備幾個方面的工做內容。

測試環境的維護，指的是爲了測試結果的可比性，通常都須要在每次運行測試結束後恢復初始的測試環境。

（2）部署測試腳本和測試場景

在創建和合適的測試環境以後，接下來的工做是部署測試腳本和測試場景。部署測試腳本和測試場景活動經過測試工具自己提供的功能來實現。

部署活動最終須要保證場景與設計的一致性，保證須要監控的計數器都已經部署好了相應的監控手段。

（3）執行測試和記錄結果

準備好環境和部署好測試腳本以及場景後，就能夠執行測試並記錄測試結果了。在測試工具的協助下，測試執行是很是簡單的操做，通常只須要使用菜單或是按鈕就能夠完成；記錄測試結果也能夠依靠測試工具完成，經過測試工具的Monitor模塊，能夠獲取並記錄須要關注的性能計數器的值。

在測試工具自己不提供對須要關注的性能計數器進行監控的功能時，能夠用一些操做系統的工具，自行編制部分腳本解決這個問題，通常的方法是用腳本調用操做系統提供的工具，在腳本實現中將各性能計數器值分析出來並按照必定格式記錄在本地文件中。

2.6測試分析

測試分析過程用於對測試結果進行分析，根據測試的目的和目標給出測試結論。

性能測試的挑戰性很大程度上體如今對測試結果的分析上，能夠說，每次性能測試結果的分析都須要測試分析人員具備至關程度的對軟件性能的瞭解、對軟件架構的瞭解、對各性能指標的瞭解。

測試分析過程是一個靈活的過程，很難給出一種具體的、能適應各類性能測試須要的統一的過程活動列表。

性能分析的通用方法之一是「拐點分析」的方法。「拐點分析」方法是一種利用性能計數器曲線圖上的拐點進行性能分析的方法，該方法的基本思想是基於這個事實：性能產生瓶頸是因爲某個資源的使用達到了極限，此時的表現是隨着壓力增大系統性能表現急劇降低，所以，只要關注性能表現上的「拐點」，得到「拐點」附近的資源使用狀況，就可以定位出系統的性能瓶頸。