性能測試-性能指標的分析 & 定義

目錄結構

一、性能測試需求分析與定義
    1.性能需求關注的常規量化指標項
    2.分析確定業務測試點，提取性能指標的策略
二、性能指標分析與定義
    1.並發數
    2.響應時間
    3.吞吐量
    4.系統資源耗用
    5.業務成功率
    6.TPS
三、綜合分析：測試需求&指標分析

 

一、性能測試需求分析與定義

通過前文性能測試需求分析對性能測試的必要性評估之后，敏捷開發團隊確定利用開源工具JMeter實施性能測試工作。根據被測對象的應用特性，首先需要獲取具體的性能測試需求。

1.性能需求關注的常規量化指標項

一般而言，被測對象的性能需求，會在用戶SRS（需求規格說明書）中給出，如：單位時間內的訪問量需達到多少、業務響應時間不超過多少、業務成功率不低於多少、硬件資源耗用要在一個合理的范圍中，性能指標以量化形式給出。

對於相對規范的產品，產品團隊一般會給出相對明確量化的性能測試要求，如下表所示：

測試項	響應時間	業務成功率	並發數	CPU使用率	內存使用率
隨機購買商品	≤5s	100%	100	≤80%	≤80%

可以看出，上表給出的性能指標比較明確。性能測試活動實施過程中，測試工程師只需收集隨機購買商品的 [響應時間、訪問成功率、並發數、CPU使用率、內存使用率] 等相關指標的監測數據，與表中的量化指標比對即可。滿足相關指標，則測試通過；若未滿足，則需要進行問題分析定位，最終進行調優與回歸，直至達到性能測試需求。

2.分析確定業務測試點，提取性能指標的策略

在有明確性能需求時，測試活動相對來說較為容易開展，但實際工作中，經常會碰到沒有明確的性能需求的測試要求。因此，測試工程師需要具備根據不同輸入（業務用戶視角、終端用戶調研、項目團隊視角、運營團隊視角、公司未來發展視角）分析，獲取性能需求的能力。

以本次項目為例，產品團隊並未指明性能測試需求，那么測試工程師如何分析提取量化的性能指標呢？
從用戶應用角度考慮，若被測對象常用的業務的性能存在瓶頸，則很可能引起客戶的反感。以登錄功能為例，輸入用戶名和密碼，點擊登錄按鈕到顯示成功登錄信息，若耗時1min，用戶絕對無法忍受。用戶不常用的功能，如年度報表匯總功能，一個季度甚至是一年才使用一次，等幾分鍾or更長時間也有可能被接受。

So，不同的應用頻率，決定了用戶的使用感受，也決定了測試的需求。

針對本次ECShop電商系統而言，商城用戶經常使用的功能，且存在大量用戶使用的業務有：用戶注冊、登錄、隨機瀏覽商品、購買業務等，而其他功能則相對用戶較少。若電商系統已經正式運營，則可從系統運營日志中分析具體的數據。若尚未上線運營，則需要調研用戶or根據自身經驗進行分析獲取。
根據[JPT_01]性能測試需求分析中的描述，分析哪些是用戶常用or交易占比超過80%的業務；從運營及項目組角度分析，哪些業務相對重要，然后確定為業務測試點。

綜合分析，本次項目實踐以用戶登錄、隨機瀏覽並購買商品為測試點。確定業務測試點后，即可進行詳細的業務需求分析，從而明確性能測試指標。

 

二、性能指標分析與定義

通常情況下，性能測試關注被測對象的時間特性、資源利用特性、穩定性。

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

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

1.並發數

並發數：①廣義而言，是單位時間內同時發送給服務器的業務請求數，不限定具體業務類型；②狹義而言，是單位時間內同時發送給服務器的相同的業務請求數，需限定具體的業務類型。（在性能測試過程中需要區分二者）

• 服務端視角
  並發，即同時出發，從應用系統架構層面來看，並發數為單位時間內服務端接收到的請求數。

• 客戶端視角
  客戶端的某個具體業務行為包括多個請求，並發數可被抽象理解為客戶端單位時間內發送給服務器端的請求數。

• 用戶行為視角
  客戶端的業務請求一般為用戶操作行為，並發數也可理解為並發用戶數，而這些用戶是虛擬的，又可稱為虛擬用戶數。

2.響應時間

目前，大多數軟件系統客戶端與服務器交互的過程，如下：

 

 

	過程	處理時間
①	用戶通過客戶端向服務端發出業務請求	t1
②	服務端接收到請求，處理該請求	t2
③	服務端根據處理模型返回數據給客戶端	t3
④	客戶端接收到響應數據，處理數據呈現給用戶	t4

• 系統視角
  在整個處理流程中，系統的響應時間：T_s = t1+t2+t3。該時間沒有包括客戶端對數據處理並呈現的時間t4。
• 用戶視角
  從用戶角度看，用戶通過客戶端發出業務請求，到客戶端展現相應的請求結果，這個過程的時間越短越好。此時用戶視角的響應時間：T_u = t1+t2+t3+t4。
• 服務器視角
  從服務器角度看，服務器接收到客戶端發送的請求，並給出結果的響應，這個過程所消耗的時間，記錄為響應時間，即服務器僅關注t2的處理時間。

因此，不同的視角，衡量的響應時間指標也各不相同。實際測試過程中，需明確以什么視角驗證被測對象的性能。
大多數情況下，性能測試響應時間主要以客戶端發出請求，直至接收到服務端的響應數據過程中所消耗的時間作為參考。

嚴格來講：響應時間=呈現時間+網絡傳輸時間+服務器端響應時間+應用延時時間

Tips：
不建議嘗試在公網進行性能測試，原因如下：
①可能影響現網用戶。實施性能測試過程中，可能產生大量壓力與垃圾數據，從而破壞生產環境，導致缺陷的產生，影響實際的業務。
②壓力模擬可能無法體現真實場景。實施性能測試時，利用壓測工具模擬大並發數，會產生大量業務數據。因負載生成器與服務器所在的網絡不同，or服務器特定的網絡安全設置，導致壓力數據無法達到被測服務器，整個網絡環境不可控，從而導致測試失敗。
有一種情況除外，模擬固定帶寬網絡訪問的場景，可在局域網中使用限制帶寬的手段進行測試。

總之，需要遵循一個原則：在測試過程中，任何資源都必須可控。

3.吞吐量

吞吐量：單位時間內系統處理用戶請求的數量。吞吐量指標直接體現了軟件系統的業務處理能力，尤其適用於系統架構選型時做對比測試。

衡量方式：

• 請求數 / 單位時間
• 點擊數 / 單位時間
• 字節數 / 單位時間

其中，[字節數 / 單位時間] 的計算方式，與當前的網絡帶寬比較，可找出網絡方面的問題。

吞吐量計算：例如1分鍾內系統可以處理1000次轉賬交易，則吞吐量為1000/60=16.7 (次/秒)

4.系統資源耗用

系統資源耗用：客戶端與服務端系統各項硬件資源的耗用情況，如CPU使用率、內存使用率、網絡帶寬占用率、磁盤I/0輸入輸出量等。

一個系統的高效運行，除了軟件性能要求外，還需要對硬件資源進行監控。若用戶需求、項目組or其他利益相關方均未提出性能指標要求，則可參考行業經驗，CPU使用率≤80%、內存使用率≤80%、網絡帶寬占用≤50% ...

• CPU使用率
  1）當CPU使用率超過80%時，表明CPU應用繁忙，如果持續維持在90%甚至更高，很可能導致機器響應慢、死機等問題
  2）當CPU使用率過低時，說明CPU比較空閑，可能存在資源浪費的問題

• 內存使用率
  對於內存，同樣存在類似以上的問題

PS：
80%只是作為一個經驗參考值，最終的性能測試指標需要經過項目相關各方評審才能確定

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

測試項	響應時間	業務成功率	業務量	並發數	CPU使用率	內存使用率
登錄	≤5s	100%	50000次/2h	100	≤80%	≤80%
隨機購買商品	≤5s	100%	50000次/2h	100	≤80%	≤80%

5.業務成功率

業務成功率：用戶發起了多筆業務請求中，成功筆數所占的比率。業務成功率展示了在特定壓力or負載情況下，服務器正確、穩定處理業務請求的能力。

例如，測試銀行營業系統的並發處理性能，有100個網點，上午10:00-11:00的一個小時高峰期里，要求能支持50000筆開戶業務，其中成功率不低於98%，也就是需要成功開戶49000筆，其他的1000筆可能是超時，或者其他錯誤導致未能開戶成功。

6.TPS

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

 

三、綜合分析：測試需求&指標分析

根據上述各指標，結合被測對象本身的業務情況，進行測試需求及指標分析：

1. ECShop是一個面向廣大網絡用戶的電子商務系統，大部分用戶會在某個時間段對平台訪問、網購。
2. 確定用戶訪問的峰值時間段：若新系統沒有上線，沒有歷史數據可以依據，可通過競品分析，獲取友商系統的運營數據作為參考。
   如業務峰值時間段：15:00-17:00、21:00-23:00，業務峰值期持續2h。若要測試穩定性，則需根據實際業務情況模擬用戶應用場景。

 

 

3. 確定在業務峰值時間段完成的業務量：需要統計有多少人在峰值時間段使用ECShop電商系統。
   根據產品團隊的業務規划、產品設計給出一個參考值，比如系統初期設計規模在單天15w業務量，峰值交易5000筆，最高並發100用戶（如秒殺業務）。

通過對預設業務目標的分析，可得出以下數據：

-峰值持續時間：2h
-單天訪問業務量：15w
-峰值交易筆數：5000
-最高並發數：100

4. 在滿足以上需求的同時，還需要考慮業務的響應時間。被測對象的響應時間，作為一個很直觀的用戶體驗數據，可很好的衡量被測對象是否讓用戶體驗良好，當然還需要把“體驗良好”轉換為量化的指標。

• Apdex聯盟-響應時間經驗值
  響應時間在業內的一個經驗值，采用Apdex聯盟的建議值：3s、3-12s，12s以上。0-3s的業務處理響應時間是非常理想的，而3-12s則是普遍可容忍的時間，但超過12s的響應時間，用戶一般不會接受，可能選擇刷新，甚至放棄操作。

• “258原則”-響應時間參考值
  1）當用戶能夠在2s以內得到響應時，會感覺系統的響應很快
  2）當用戶在2-5s內得到響應時，會感覺系統的響應速度還可以
  3）當用戶在5-8s內得到響應時，會感覺系統的響應速度很慢，但還可以接受
  4）當用戶在超過8s后仍然無法得到響應時，會感覺系統糟透了，or認為系統已經失去響應，而選擇離開這個Web站點，or發起第二次請求

5. 響應時間還應該根據業務類型確定，而不能僅從用戶的主觀感覺考慮。本次項目測試采用常規的5s為目標，也就是說ECShop平台處理登錄、商品隨機瀏覽購買等業務的服務器響應時間均不超過5s。

6. 單天15w業務量，表明在一天內的總業務量為15w，但未明確是哪些業務的數據量疊加，還是每項業務都是此要求（假定單項業務每天都有15w的業務量）。
   從上圖 [訪問時間-訪問用戶量] 坐標圖中可以看出，用戶訪問並非是均分在24h內。在沒有歷史數據可依據的情況下，可利用經濟學中的“28原則”進行分析，即80%的業務量集中在20%的時間段內完成。而單天峰值時間段共有2個：15:00-17:00、21:00-23:00。

計算業務量的分解數據：

80%的業務量：15w*80% = 12w
20%的時間段：24h*20% = 4.8h
單天峰值時間：2+2 = 4h
全天峰值時間 / 20%時間：4h/4.8h = 83.3%

以15:00-17:00、21:00-23:00為考察時間段，則預期業務量為：
12w*(4h/4.8h) = 10w

以15:00-17:00為考察時間段，則預期業務量為：
12w*(2/4.8) = 5w

綜上，需要測試ECShop電商平台在2h內支持5w用戶登錄、隨機瀏覽商品進行購買的業務。

作者：Fighting_001
鏈接：https://www.jianshu.com/p/9f5d10f5e938
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。