性能測試需求調研分析方法

1、測試背景和目的

    在需求調研開始，測試人員須要明確的測試目的，那麼首先得清楚項目自己狀況，針對不一樣的項目狀況也會有不一樣的目的，根據項目狀況通常能夠分爲如下六種狀況：

一、徹底新建系統

     徹底新建系統意味着被測試系統沒有業務數據做爲參考，也沒有業務人員能進行有效的進行預估業務量，就不能轉換出業務指標值（TPS/QPS）,那麼咱們一般的測試目的以下：

1. 測試應用系統最佳處理能力和極限處理能力,供需求方和開發進行評估。
2. 測試應用系統是否穩定
3. 測試應用系統是否可靠
4. 測試應用系統瓶頸，並提供擴容意見等

 二、改造新系統

　　改造新系統通常能夠經過老系統業務量進行分析，再結合業務人員根據業務發展狀況進行評估。一般的測試目的以下：

1. 測試應用系統是否知足當前業務量需求。
2. 測試應用系統是否知足N年後業務量需求
3. 測試應用系統是否穩定
4. 測試應用系統是否可靠
5. 測試應用系統瓶頸，並提供擴容意見等

三、版本升級系統

　  版本升級系統有多是針對缺陷修復升級，也有多是針對業務需求變動升級。如以前未作過性能測試，按照改造新系統方式目的設置。如已作過性能測試一般測試目的以下：

1. 測試應用系統最佳或極限處理能力與以前測試結果對比分析。
2. 測試應用系統是否穩定

四、線上運行系統

     線上運行系統要求進行非功能測試，通常是線上遇到非功能測試缺陷，很難復現。一般測試目的以下：

1. 模擬生產環境運行狀況，找出非功能測試缺陷配合開發進行優化複測。

五、採購型系統

     採購型系統要求進行非功能測試，通常是對多家廠商的產品進行測試，給出對比測試結果，一般測試目的以下：

     獲取固定併發用戶數下，各廠商的指標對比狀況（TPS，響應時間，CPU使用率，錯誤率等）

六、軟硬件選取

     軟硬件選取進行非功能測試，主要式在保持其餘狀況一致的狀況下，性能狀況對比。

     獲取在不一樣軟硬件處理能力，根據業務狀況，選擇性價比最高的軟硬件。

 

2、測試範圍的確認

　　測試範圍主要是在調研過程當中，確認被測系統與周邊系統關係以圖形的方式展示，並以明顯的標記標註被測系統和文字的方式說明被測交易具體與哪些系統進行交互。

 

3、被測系統架構分析

       架構分析的目的主要是須要確認被測試系統使用的開發語言/開發框架、通訊機制/協議、中間件、數據庫、是否採用應用集羣、是否採用數據庫集羣、是否存在備份機制（熱備/冷備）、負載均衡機制等。爲後續設置具體的測試策略，環境部署，監控手段作鋪墊。

 

4、業務模型分析

       業務模型分析主要是爲了獲得更加真實模擬線上運行場景，保證測試的覆蓋率。經過根據系統狀況分爲有業務數據參考（生產運行日誌）和無業務數據參考兩種狀況

 

 5、有業務數據參考

        有業務數據參考系統可按照以下方式進行分析提取業務模型：

 

實例

案例編號	接口名稱	交易佔比
1	create_instant_trade（即時到帳）	6%
2	create_ensure_trade（擔保交易）	5%
3	create_split_trade（分帳）	3%
4	create_settle（結算）	5%
5	create_refund（退款）	0.5%
6	query_trade（交易查詢）	80.5%

 

6、無業務數據

       經過與業務人員或者開發人員溝通，引導業務人員根據業務使用狀況，進行業務模型的大概預估。具體方法以下

• 確認被測業務交易，業務交易選取規則以下：

1. 使用比較頻繁的交易（業務人員根據使用狀況提供）
2. 使用不是特別頻繁可是交易涉及數據量比較大的交易（業務人員根據使用狀況配合開發人員提供）
3. 交易邏輯複雜比較高的交易（開發人員根據代碼邏輯提供）

•  確認各業務交易佔比：

1. 業務人員根據使用狀況進行各選取交易比例預估
2. 若是沒有業務使用的話，能夠參考同行（非功能測試人員根據相關進行建議並讓業務確認）

 

7、用戶分析

需求類別	需求要點	性能需求描述規範說明
用戶分析	用戶數量需求	本系統各種別用戶的數量分析
	用戶類別需求
	系統支持併發操做最大用戶數量	併發用戶數指在同一時刻內，登陸系統並進行業務操做的用戶數量。
	系統支持的最大用戶鏈接數量	系統可以同時接入（或登陸）的最大鏈接用戶數。 通常而言，並非全部接入（或登陸）的真實用戶都在實時進行操做，部分用戶接入（或登陸）系統後，暫時不作業務操做，這樣的用戶操做習慣要求被測系統提供額外的系統併發接入能力。

 

8、 測試指標

        性能測試經常使用指標確認以下：

大類	指標項	指標量值	備註
業務類	系統處理能力(TPS)	二八法則	高峯期TPS
	通常交易響應時間	<3秒	端到端的響應時間
	複雜交易響應時間	<5秒	針對大表查詢交易
	交易成功率	>=99.9%
系統資源	CPU使用率	<=80%
	內存使用率		無明顯上升趨勢。
穩定性	運行時間	24小時	CPU使用率、內存使用率、磁盤繁忙率等比較平穩，無明顯波動。

 

• 系統處理能力（TPS分析）分析方法：

溝通並估算出高峯日交易量爲S1（單位：筆），獲取到高峯時間段S2(單位：小時)，若是須要知足N年後業務處理能力，須要給出業務遞增百分百S3。

知足當前時間業務處理能力T1（單位：筆/秒）=(S1*0.8)/（S2*0.2*36000）；

知足N年後業務處理能力T2（單位：筆/秒）=T1*(1+S3)^N；

• 響應時間獲取：

響應時間指標一般根據系統方式分爲接口類、客戶端訪問類，具體時間指標客戶端訪問類和是由業務人員根據業務狀況，指定響應時間，

一般標準爲：1-3秒能夠經過；3-5秒謹慎經過；5秒以上不能經過。接口類響應時間一般標準爲：記帳類：200毫秒  單筆查詢：500毫秒 

 

 9、預埋數據量分析

  預埋數據量的目的是根據生產業務量狀況和數據庫表數據存儲方式進行預埋數據，驗證在必定數據量狀況下，數據庫性能對自己業務交易性能的影響。通常分爲從生產導入數據和本身構造數據。

  生產導數主要是把生產數據脫敏導入測試庫中，這樣的數據更加真實。

  本身構造數主要是根據天天交易量乘以該表存儲的時間或者統計線上數據量的方式（須要瞭解該交易涉及表數據存儲），  基礎數據構造，應知足數據類型以及量級的要求，避免數據熱點

query_balance

能	服務	數據庫	數據表	操做	線上數據量	當前測試環境
下單	mag
	ma-web	member庫	m_member_identity 會員查詢 member_account 會員帳戶信息表	query	5320w	3053w
	dpm	dpm庫	dpm_outer_account 外部戶	query	10450w	5735w
	vouch	vouch庫	trade_vouch 交易憑證	insert	11559w	2722w
	tss	tss庫	trade_order 交易訂單 acq_trade_order_ext 收單交易擴展 split_party分帳信息表	insert	9152w 10670w 3181w	2491W 3200W 3260w