Jmeter性能測試系列-指標分析與定義

通常情況下，性能測試關注被測對象的時間與資源利用特性及穩定性。時間特性，即被測對象實現業務交易過程中所需的處理時間，從用戶角度來說，越短越好。資源利用特性，即被測對象的系統資源佔用情況，一般Web系統不關注客戶端的資源佔用情況，僅關注伺服器端，通常為伺服器端的CPU、內存、網路帶寬、磁碟等（根據被測對象架構設計，還可分為Web伺服器、中間件、資料庫、負載均衡等）。穩定性，關注被測對象在一定負載情況下，持續穩定提供服務的能力。

不同的被測對象，不同的業務需求，可能有不同的指標需求，但大多數測試需求中都包含以下幾個性能指標：

l 並發數

並發，即為同時出發，從應用系統架構層面來看，並發意為單位時間內伺服器接受到的請求數。客戶端的某個具體業務行為包括了若干個請求，因此，並發數被抽象理解為客戶端單位時間內發送給伺服器端的請求，而客戶端的業務請求一般為用戶操作行為，因此，並發數，也可理解為並發用戶數，而這些用戶是虛擬的，又可稱為虛擬用戶。

並發數，廣義來講，是單位時間內同時發送給伺服器的業務請求，不限定具體業務類型，狹義來看，是單位時間內同時發送給伺服器的相同的業務請求，需限定具體業務類型。在性能測試實施過程中需注意二者的區別。

l 響應時間

目前大多數的軟體系統客戶端與伺服器交互過程如圖7- 1所示，用戶通過客戶端（如瀏覽器）發出業務請求（網路傳輸時間T1），伺服器接收並處理該請求（伺服器處理時間T2），然後根據實際的處理模型返回結果（網路返回數據時間T3），客戶端接收請求結果（客戶端處理展示時間T4）。在這個處理流程中，涉及到的各個業務節點的處理時間總和T1+T2+T3即為系統響應時間。這個時間的計算忽略了用戶端數據呈現的時間T4。從用戶角度來講，用戶應用客戶端發出業務請求，到客戶端（通常為瀏覽器）展現相應的請求結果，這個時間越短越好，即用戶視角的響應時間為T1+T2+T3+T4。從伺服器角度來講，伺服器接收到客戶端發來的請求，並給出結果的響應，這個過程所消耗的時間，記錄為響應時間，即伺服器僅關注T2的處理時間。因此，不同的視角，衡量的響應時間指標也不同。

通過上述兩個不同視角的描述不難發現，用戶與伺服器所理解的響應時間存在明顯的差異。用戶關注的是發出請求至看到響應結果的時間，而伺服器關注的是接受請求到返回結果的時間，對於用戶而言，忽略了瀏覽器展示的時間，對於伺服器而言，則忽略了瀏覽器展示、網路傳輸等時間。因此，在實際測試過程中，需明確以什麼視角驗證被測對象的性能。

大多數情況下，性能測試主要是以用戶視角進行，因此在實際測試過程中，通常關注用戶行為，所以，響應時間一般指客戶端發出請求到接收到伺服器端的響應數據所消耗的時間。

需注意的是，性能測試工作中，客戶有時可能需要測試公網的系統來驗證性能指標，從測試經驗來看，最好不要嘗試在公網進行性能測試，原因有二：

第一、 可能影響現網用戶。實施性能測試過程中，可能產生大量的壓力與垃圾數據，從而破壞生產環境，導致缺陷的產生，影響實際的業務。

第二、 壓力模擬可能無法真實體現。性能測試工程師實施性能測試時，利用測試工具，模擬了大量的並發數，產生了大量的業務數據，但因負載生成器所在的網路與伺服器所在網路不同，或者伺服器的網路安全設置，導致壓力數據無法達到被測伺服器，整個網路環境不可控，從而導致測試失敗。

有一種情況除外，模擬固定帶寬網路訪問的場景，可在區域網中使用限制帶寬的手段進行測試。遵循一個原則，測試過程中，任何資源都必須可控。

l 吞吐量

單位時間內系統處理用戶請求的數量，可以用請求數/單位時間或者點擊數/單位時間，或者位元組數/單位時間等方式來衡量，其中通過位元組數/單位時間的計算方式，與當前的網路帶寬比較，可以找出網路方面的問題。例如，1分鐘內系統可以處理1000次轉賬交易，則吞吐量為1000/60=16.7。吞吐量指標直接體現了軟體系統的業務處理能力，尤其適用於系統架構選型，做對比測試。

l 系統資源耗用

系統資源耗用，客戶端與伺服器系統各項硬體資源的耗用情況，如CPU使用率、內存使用率、網路帶寬佔用率、磁碟I/O輸入輸出量等。一個系統的高效運行，除了軟體資源外，硬體資源也是不可缺少的部分，因此在性能測試過程中，需關注系統資源的耗用。

l 業務成功率

業務成功率意為用戶發起了多筆業務請求，成功的比率有多少。例如，測試銀行營業系統的並發處理性能，全北京100個網點，中午12:30到13:30一個小時的高峰期里，要求能支持50000筆開戶業務，其中成功率不少於98%，也就是需要成功開戶49000筆，其他的1000筆可能是超時，或者其他錯誤導致未能開戶成功。業務成功率展示了在特定壓力或負載情況下，伺服器正確穩定處理業務請求的能力。

l TPS

單位時間內伺服器處理的事務數，該指標值越大越好。一般情況下，用戶業務操作過程可能細分為若干個事務，單位時間處理的事務數越多，說明伺服器的處理能力越強。

根據上述各個指標的概念，結合被測對象本身的業務情況，做出如下測試需求及指標分析。

ECShop是一個面向廣大網路用戶的電子商務系統。大部分用戶會在某個時間段訪問該電商平台，進行網路購物，但如何確定用戶訪問的時間段呢？

新系統沒有上線時，沒有歷史數據可以依據，這種情況下，測試工程師可以通過競品分析，獲取友商系統的運營數據作為參考。以淘寶運營數據為例，通過運營團隊統計，大部分消費者集中在如圖7- 2所示的時間段訪問電商平台。

通過上圖分析，業務峰值幾乎在15點-17點及21點-23點左右，業務峰值期持續2個小時左右，若要測試穩定性，則需根據實際業務情況模擬用戶應用場景。

確定性能測試評估的時間段後，需確定在該時間段內需完成的業務量，這就需要統計有多少人在這個時間段使用ECShop電商系統。統計這個數據比較難，因為各個公司運營規模不一樣。這種情況下，測試工程師需根據產品團隊的業務規劃、產品設計給出一個參考值，比如系統初期設計規模在單天15萬業務量，峰值交易5000筆、最高並發100用戶（如秒殺業務）等。通過對預設業務目標的分析，可得出以下幾個數據：

1. 峰值時間段2個小時；

2. 單天15萬業務量訪問；

3. 峰值交易5000筆；

4. 最高並發100個用戶。

接著分析，滿足上述需求的同時，還需要考慮業務的響應時間。被測對象的響應時間，作為一個很直觀的用戶體驗數據，可很好的衡量被測對象是否讓用戶感受好，但感受好並沒有一個量化的指標，只是個相對的概念。響應時間在業內一個經驗值，採用Apdex聯盟的建議值：3秒、3秒-12秒，12秒以上。0-3秒的業務處理響應時間是非常理想的，而3秒-12秒則是普遍可容忍的時間，但超過12秒的響應時間，用戶一般不會接受，可能選擇刷新，甚至放棄操作。這樣的經驗值在實際測試中對確定響應時間有很高的參考價值，當然響應時間還應該根據業務類型確定，而不能僅從用戶的感官考慮。本次項目測試採用常規的5秒為目標，也就是說ECShop平台處理登錄、商品隨機瀏覽購買等業務的伺服器響應時間均不超過5秒。

單天15萬業務量，表明在一天時間內總的業務量為15萬，但未明確是哪些業務的數據量疊加，還是每項業務都是此要求。此處假定單項業務每天有15萬的數據量。

從圖7- 2得知，用戶訪問並非是均分在24個小時內，因此，在沒有歷史數據可依據的情況下，利用經濟學中的「二八原則」進行分析，80%的業務量集中在20%的時間段內。單天峰值時間段共有2個：15點-17點，21點-23點，可得如下業務量分解數據：

15萬*80%=12萬

24個小時*20%=4.8小時

4小時/4.8小時=83%

以15點-17點，21點-23點為總考察時間段，則期望業務量值為：

12萬*83%=9.96萬

以15點-17點為測試考察段，則期望業務量值為：

12萬*（2小時/4.8小時）=5萬

通過上述分析，需測試ECShop平台在2小時內支持5萬用戶登錄及商品隨機瀏覽購買。

除了軟體性能要求外，還應該對硬體資源進行監控，比如伺服器CPU使用率、內存使用率、網路帶寬等。如果用戶需求、項目組或其他利益相關方未提出性能指標要求，則可按照行業經驗，CPU使用率不超過80%、內存使用率不超過80%、網路帶寬佔用不超過50%等。CPU使用率超過80%表明CPU應用繁忙，如果持續維持在90%甚至更高，很可能導致機器響應慢、死機等問題。當然，過低也不好，說明CPU比較空閑，可能存在資源浪費的問題。對於內存存在同樣的問題。當然，80%只是一個經驗值，最終的性能測試指標需經過評審才能最終確定。

通過上述業務數據分析，最終得到本次測試的性能需求指標如下圖所示

得出本次測試的性能參考指標後，測試工程師即可進行性能測試模型的建立