性能測試從零開始實施指南——測試計劃篇

最近有些同窗找我諮詢關於性能測試計劃相關的問題，緣由是他們公司要作性能測試，Leader要求寫一份性能測試計劃，苦於以前沒作過相關工做，無從下手。

這篇博客，結合我我的的一些經驗和總結，聊聊如何制定一份較爲全面的性能測試計劃。。。

 

1、測試背景

首先要闡述本次性能測試的背景，即被測系統類型，面向哪些用戶，具有什麼特色，爲何要進行性能測試，預期的一些指標等等。

好比：爲了保證「雙十一」大促期間，系統能穩定運行且保障業務的高可用，進行性能測試。

核心：評估系統性能、分析性能變化趨勢、定位系統瓶頸風險、協助規劃系統容量。

 

2、測試目的

測試的目的要根據測試背景來分析設定，好比：

一、線上服務因爲流量太高某部分應用掛了，那測試目的就是：定位瓶頸、分析調優驗證；

二、運營作了拉新和新的渠道拓展，那測試目的就是：評估系統性能是否知足新的線上業務；

三、系統架構由集羣技改成微服務，那測試目的就是：驗證穩定性、可用性、單實例容量，爲線上服務擴容提供容量規劃數據；

 

3、測試範圍

經過需求調研，分析用戶使用場景，對業務數據量增加變化趨勢及峯值活躍用戶等數據作定量分析，肯定被測系統的應用範圍，好比訂單+購物車+商品+支付服務。

業務歸屬模塊	業務涉及場景
訂單	建立訂單
	取消訂單
購物車	添加購物車
	刪除購物車
商品	商品列表
	商品詳情
支付	餘額支付
	支付寶支付
	微信支付

 

4、術語約定

這裏的術語指的是：涉及本次性能測試相關的一些專業術語說明，目的是統一口徑，作解釋說明，便於參與本次性能測試的相關人員理解。常見術語以下：

術語名稱	術語釋義
併發	單位時間內（S）模擬客戶端發起的請求數量
穩定性	驗證系統在長時間（24h/48h）負載狀況下的性能表現
高可用	驗證系統在一部分服務宕機後可否正常提供服務以及服務恢復速率
TPS	每秒事務數，即系統單位時間內（S）的請求處理能力
RT	響應時間，及系統處理一筆請求所耗費的時間
請求成功率	在測試過程當中，系統成功處理請求佔總請求數的百分比

PS：術語約定以實際狀況爲準，還要考慮性能測試計劃的受衆對於性能測試的瞭解程度，本約定旨在統一描述的口徑，下降溝通成本。

 

5、環境說明

通常來講，進行性能測試的環境都是在UAT或者獨立的性能測試環境，但爲了準確描述環境類型和配置，以及測試環境和生產環境的區別，建議對生產環境和測試環境進行對比說明。

一、生產環境

①、系統架構

PS：上圖只是一個簡略的微服務類型系統架構，只作示意，理解便可。

②、服務配置

服務名稱	數量	配置	備註
gateway server	10	2C3G	網關服務，身份驗證和請求轉發
web server	3	2C3G
app server	5	2C3G
Redis	3	4G	哨兵模式，一主兩從
DB	2	8C16G	一主一從

二、測試環境

①、系統架構

②、服務配置

服務名稱	數量	配置	備註
gateway server	5	2C3G	網關服務，身份驗證和請求轉發
web server	2	2C3G
app server	2	2C3G
Redis	2	4G	哨兵模式，一主一從
DB	2	8C16G	一主一從

三、負載機配置

負載機（machine）即模擬客戶端發送請求的機器，通常狀況下，說明負載機的硬件配置，數量，IP，發壓策略便可。

四、網絡

即負載機和性能測試環境的網絡情況，好比國內公網/同一VPC內網，防火牆策略等。

 

6、需求分析

需求分析通常有這幾個階段：需求接入→需求收集→需求分析，主要內容以下：

一、業務模型

以下是一個典型的電商平臺核心業務鏈路圖，涉及到登陸、首頁、商品、購物車、支付、分享等模塊。

二、性能指標

這裏的性能指標包含以下兩項：

①、業務性能指標

即預期的TPS、RT、請求成功率（通常默認請求成功率≥99.99%）。

②、硬件性能指標

即服務端資源耗用指標，常規的資源監控指標有：CPU使用率、Memory使用率、系統IO、網絡IO等。

 

7、測試策略

本次性能測試所採用的測試策略，好比：

探測系統性能拐點，須要階梯式壓測；

探測系統在可接受的性能指標下最大的處理能力，須要採用負載、容量測試策略；

驗證系統的穩定性和高可用，須要採用穩定性、高可用測試策略；

驗證系統在不一樣配置下的性能表現，通常採用配置測試策略；

一、測試策略及場景

①、容量測試

場景名稱	01_登陸 02_首頁
執行時間	10min
業務配比	100%
測試策略	容量測試
測試目的	不斷增長負載，驗證系統單節點的最大性能表現

②、穩定性測試

場景名稱	混合場景
執行時間	24h
業務配比	按生產業務配比，等比縮放
測試策略	穩定性測試
測試目的	驗證系統長期運行的穩定性以及是否存在OOM之類的問題

PS：如上表格描述，依然做爲一個示例來講明，主要內容包括：場景編號、測試類型、涉及業務場景、業務配比、執行時間、測試目的。

二、測試監控策略

監控對象	指標範圍	監控工具
CPU	≤90%	nmon、zabbix
Memory	≤70%
網絡IO	無明顯IO瓶頸
JVM	無頻繁FGC狀況	jmap、jstat

 

8、準備工做

準備工做主要包含以下幾項：

準備事項	準備內容	責任人	預計完成時間
工具準備	負載工具、監控工具、分析工具	測試/運維	0.5工做日
腳本準備	測試腳本	測試	0.5工做日
環境準備	機器配置、服務部署聯調、腳本調試	運維/開發	1工做日
數據準備	鋪底數據、測試數據、參數化數據、緩存數據	DBA/開發/測試	1工做日

 

9、組織架構

組織架構即本次性能測試涉及到的團隊各角色成員，主要包含這些：PM角色、測試、開發、運維、DBA、網絡、基礎架構。示例：

 

10、風險分析

羅列開始執行前會影響本次性能測試工做開展的風險項以及應對方案，好比：

風險類型	風險描述	風險級別	應對方案
交付風險	UAT階段發現較嚴重的功能缺陷	高	測試時間順延，或增長對應人員
變動風險	臨時需求變動、新增需求	高	需求評審是否加入本次測試範圍，階段性交付
數據風險	數據脫敏耗時較長、測試數據不可用	中	從新擬定數據準備方案，小範圍數據驗證
環境風險	部署出現問題，聯調進度緩慢、網絡帶寬瓶頸	中	更換環境、增長資源配置、擴展帶寬

 

11、交付清單

在性能測試計劃中，須要說明本次性能測試各階段的交付物，主要包含這幾項：性能測試計劃&方案、測試腳本、性能缺陷統計、輪次小節、性能測試報告。

 

12、階段進度

這裏主要指的是從需求階段到結束，各個階段的工做進展以及資源安排，建議採用看板的方式，及時更新進度，方便推動工做的開展。示例以下：

階段	事項	開始時間	結束時間	狀態	責任人
需求階段	需求評審			完成	多方參與
	系統架構圖			完成	開發
	需求調研			完成	性能測試人員
準備階段	環境交付			完成	運維、開發
	應用部署			完成	運維、開發
	數據準備			完成	開發、DBA、測試
	腳本開發			完成	性能測試人員
實施階段	執行壓測			未完成	性能測試人員
	服務監控			未完成	運維、測試
	數據收集			未完成	性能測試人員
結束	報告評審			未完成	多方評審

 

如上，就是一個較爲完整的性能測試計劃內容，固然，完成性能測試計劃並評審經過後，就能夠進入測試執行階段了。。。