企業化的性能測試簡述---如何設計性能測試方案

   

性能測試簡介：

性能測試包括的範圍很是普遍， 簡單來講能夠分爲後臺性能測試（Linux服務器，mysql服務器，文件服務器等等）， 客戶端性能測試（WEB前端，移動端等）

通常企業的性能測試指的是狹義的後臺性能測試，性能測試整個流程以下:

1.  性能測試需求與調研

2.  設計性能測試方案，並出具文檔

3.  審覈方案，肯定後準備性能測試數據， 測試環境

4.  按照測試方案執行性能測試

5.  出具性能測試報告

 

性能測試須要測試具有的能力（後續博客會持續更新）：

1.  常規性能測試工具的使用（Jmeter，Zabbix，jvisualvm，Monyog 等等）

2.  對性能測試的各層進行測試的能力（通常指的是： OS層，應用層，DB層）

3.  設計合理的測試方案的能力（熟悉性能基準指標驗證， 逐步加壓原則， 混合壓測穩定性驗證等方法）

4.  Linux等後臺系統獨立搭建後臺測試環境的能力

 

 

 

下面是一個性能測試方案的實例： 

 

 

 

 

目錄

1       概述... 3

1.1         測試目的... 3

1.2         適用範圍... 3

1.3         參考資料... 3

2       測試需求... 4

2.1測試架構... 4

2.2測試範圍... 4

2.3相關人員... 5

2.4計劃安排... 5

3       測試方案... 6

3.1         測試策略... 6

3.1.1           壓測策略... 6

3.1.2           測試監控策略... 7

3.2         測試用例... 8

3.3測試準備... 8

3.3.1           測試環境... 8

3.3.2           相關工具... 9

3.3.3           測試腳本... 9

3.3.4           測試數據... 9

3.4達標出口... 10

3.4.1           軟件達標出口... 10

3.4.2           閾值要求... 11

3.5過程準則... 12

4 附錄... 13

4.1相關術語... 13

4.3其餘... 13

 

 

 

 

1     概述

1.1   測試目的

本方案用以描述 XXX系統 的性能測試過程內容，用以指導測試人員準備並執行性能測試，發現系統中可能存在的性能問題，提出優化建議並解決，以下降或避免因爲性能問題帶來的系統風險，爲系統的穩定運行提供保證。主要關注點以下：

• 明確測試範圍和目標。
• 確認測試過程細則：測試環境、測試場景、測試策略、過程關注等。
• 性能出口要求及風險預估。

1.2   適用範圍  

本文檔適用於參與 XXXX系統 性能測試項目的相關人員。

1.3   參考資料

 

2     測試需求

2.1測試架構

• 生產環境物理架構：未提供架構圖，架構保證測試環境部署與生產一致（區別僅在機器的數量）

 

• 壓測環境架構：單機環境

 

 

2.2測試場景

 

本次測試包含6個場景，對應場景和TPS指標以下：

場景 編號	接口名稱	接口描述	協議類型	生產指標 TPS/RT	測試指標 TPS/RT	備註
S01	/XXX-info	獲取會話	Http	112/0.3s	47/0.3s
S02	/XXX	獲取XXX	Http	112/0.3s	47/0.3s
S03	/XXX	獲取當前用戶信息	Http	112/0.3s	47/0.3s
S04	/XXX/all?userId=123456	獲取全部應用列表	Http	112/0.3s	47/0.3s
S05	/XXX/app/fixed	獲取經常使用應用	Http	112/0.3s	47/0.3s
S06	home	訪問首頁	Http	112/0.5s	47/0.5s

Tips：本次生產集羣指標TPS=5萬/3600秒x8倍係數=112tps；

單機環境測試指標TPS=112/（3x0.8）=47tps；

2.3相關人員

 

角色	姓名	備註
架構
項目經理
開發
測試

2.4計劃安排

序號	階段	執行人	時間計劃
1	性能調研和確認
2	性能方案產出
3	腳本和數據準備
4	執行性能壓測
5	性能測試報告產出

 

3     測試方案

3.1   測試策略

3.1.1        壓測策略   

本次測試將採用Jmeter工具，經過控制線程數來模擬用戶併發。

• 壓測策略說明：

　　一、指標驗證： 驗證被測交易在測試環境中是否能達到指標要求的TPS/RT，每一個輪次持續10分鐘。

　　（單接口指標驗證，若是單接口都沒法達到指標，無需再進行負載和穩定性測試，不知足最基礎的交付目標，須要重點優化。）

　　  注：如接口性能較差時，在壓測指標前，先使用1個併發(不加thinktime)壓測3分鐘，得出一組基準數據，可做爲參考依據。

　　二、負載測試：在指標驗證基礎至上，對每一個接口逐步增大併發，每一個輪次持續10分鐘。（階梯性的加壓測試，找出性能拐點，壓測出當前系統下最大的處理能力，便於對後續容量和風險預估。）

　　三、穩定性測試：對核心場景按照指標要求進行併發配比後壓測，持續時長5-10小時。（混合場景穩定性測試，驗證系統總體的資源使用狀況、處理能力是否平穩。）

• 測試執行策略以下：

                                                                

一、拿到基準數據後，先進行指標驗證測試，查看是否能夠達到目標TPS；

二、在達標基礎之上，使用不一樣併發，進行屢次階梯性負載驗證，找到性能拐點；

三、針對重點場景進行混合，進行穩定性驗證。

 

 

3.1.2        測試監控策略

監控層面	監控工具	說明
OS層	Zabbix/top命令	關注硬件的實時使用狀況
應用層	Zabbix/jvisualvm	關注java應用線程和堆內存狀況
DB層	Monyog	關注mysql在壓測過程當中出現的慢查詢和鎖

 

 

3.2   測試用例

 

所屬 策略	用例 編號	用例名稱	併發 配置	重點關注
指標 驗證	C01	session-info	47	47併發，配置thinktime（控制QPS），壓測結果知足47/0.3s。
	C02	appkey	47
	C03	getUserCurrent	47
	C04	list all	47
	C05	fixed	47
	C06	home	47	47併發，配置thinktime（控制QPS），壓測結果知足47/0.5s。
負載 測試	C01	session-info	逐步增長併發	基於指標驗證用例，進行階梯性併發壓測（如50、100、150），每一個階梯壓測10分鐘，關注系統在各個併發下實際處理能力。
	C02	appkey
	C03	getUserCurrent
	C04	list all
	C05	fixed
	C06	home
穩定性	M01	C01-C06，6個場景，各47併發	282	根據指標要求將全部場景進行混合，持續壓測10小時，關注整個壓測過程當中系統的穩定性和資源使用狀況。

 

 

3.3測試準備   

3.3         

3.3.1        測試環境

測試環境佈局以下：(同測試架構圖)，測試環境硬件信息以下：

類型	生產環境配置	測試環境配置	備註
應用1	x4	4C4G x1	Nginx，
應用2	x3	4C8G x1	IT門戶
應用3	x4	4C8G x1	應用服務
應用4	x4	4C8G x1	租戶服務
中間件	x1	4C8G x1	Redis
DB	x1	24C32G x1	Mysql
網絡環境	公網	內網環境	全部測試應用在同一網段

Tips：應用配置相同，機器數量不一樣狀況下，測試環境單機指標折算公式爲

T測單=T生集/(N生產 x 0.8折算係數)

 

3.3.2        相關工具

性能測試工具：Jmeter

資源監控工具：APP--ZIBBIX、資源監控器（windows自帶的）、Jmeter工具

 

3.3.3        測試腳本

這次測試的接口均爲Http協議的（get方式），故採用Jmeter http請求sampler設計測試腳本。

• 檢查點配置：在腳本中設置合理的檢查點，保證接口返回的正確性（事務成功率的統計）。
• QPS控制（加thinktime）：使用JMeter插件Throughput Shaping Timer控制QPS（LR的話配置pacing time），便於進行併發壓測。

 

3.3.4        測試數據

 

類型	庫名	表名	測試 數據量	預估生產 數據量	是否 須要鋪底	說明
Mysql	XXX-service-XXXX-auth	XXX_user	1	20萬	是	壓測前鋪底數據20萬
		XXX_app	18	18萬	否	配置表無需鋪底
		XXX_user	1	15萬	是	壓測前鋪底數據15萬
		XXX_user	1	15萬	是	壓測前鋪底數據15萬
	XXX-service-user	user_info	1	15萬	是	壓測前鋪底數據15萬

 

3.4達標出口

3.4         

3.4.1        軟件達標出口

一、 指標驗證：壓測持續10分鐘，達到目標TPS指標且成功率達到100%(成功率可根據實際業務場景調整)，實際響應時間<=指標要求RT；

二、 負載驗證：每一個階梯壓測持續10分鐘，成功率>=99.9%。

　　n  指標閾值：指標響應時間要求內的最大處理能力，也是最優處理能力；

　　n  資源閾值：資源佔用（cpu/IO/mem）在80%左右時的處理能力；

　　n  性能拐點值：隨着併發增長TPS沒法增長甚至出現降低時的點。

　　（負載壓測目的就是至少能夠獲得以上3個值中的某1個。）

三、 穩定性測試：運行5-10hours+，事務成功率要高於99.9%，硬件資源佔用在閾值要求內。

 

 

3.4.2        閾值要求

監控類型	監控指標	閾值要求
資源監控	Load average	<CPU核數*2
	CPU利用率	物理機<80%，虛機/容器<75%
	系統內存使用	佔用<80%
	磁盤Util%	佔用<80%
	網絡帶寬	佔用<70%
Java 進程監控	Younggc	Younggc頻率不超過1s
		Younggc時間不超過200ms
	Fullgc	FullGC的頻率不大於1小時，FullGC時間不超過2s。
	線程狀態	大量的線程blocked
		currentThreadsBusy監控
數據庫	慢查詢	出現慢查詢語句
	死鎖	出現死鎖
中間件	Redis	Redis操做耗時<1ms
	Memcache	緩存命中率>80%
日誌監控	錯誤日誌	出現嚴重級別的Error或Exception
業務指標	響應時間	測試結果RT<=指標要求
	TPS	測試結果TPS>=指標要求
	成功率	測試結果成功率>=99.99%

 

3.5過程準則

過程	條件
准入準則	壓測環境和機器準備完成（壓測機、待測應用服務和數據庫、網絡環境等）
	待測流程的功能測試經過，版本穩定。
	待測流程的測試數據和測試腳本準備完畢。
暫停準則	測試中發現問題，須要項目組修改代碼或更換版本；
	測試中發現服務規劃及部署問題，須要從新調整部署方案；
	須要調整測試環境資源配置，如加減CPU數目，增長存儲等等。
	測試環境使用受到干擾，如服務器被臨時徵用或非壓測流量進入性能環境
準出準則	全部測試場景完成執行，對應各場景的測試過程數據和監控數據均已保存和記錄。
	性能指標達到《性能測試方案》的要求，無遺留性能問題（或評估後可暫時遺留）
	測試報告完成。

 

 

 

4 附錄

4.1相關術語

 

術語簡寫	說明
TPS/QPS	每秒事務數或每秒請求數，指服務器在單位時間內能處理的請求的數量。 如100tps，表示系統1秒處理了100個請求。
響應時間	指一個用戶的從發起請求到收到響應所用的時間。
併發數	指某一時刻同時發起的請求數量（通常以秒爲時間粒度）。
RT	響應時間英文簡寫，咱們所說的RT都是指平均響應時間
PV	page view，即頁面瀏覽量。用戶對網站中的某個網頁訪問1次均被記錄1PV。用戶對同一頁面的屢次訪問，訪問量累計。通常對web測試時關注。

 

4.2其餘

無