一、文檔目的
- 幫助大家瞭解性能測試流程
- 提高性能測試意識，識別、排查性能隱患
二、性能測試簡介
1、概念
模擬併發用戶訪問系統，根據監控的指標來評估系統的性能。
2、目的
- 驗證上線功能點是否滿足性能指標
- 找出服務器的承壓能力，作爲優化和擴展的評估資料
- 減少宕機風險，提高用戶體驗
3、分類
|
類別 |
含義 |
|
壓力測試 |
模擬大量用戶向服務器產生負載，使服務器資源處於極限狀態並長時間運行 |
|
容量測試 |
一定用戶數，測試數據在不同數量級的情況下，系統承受的最佳容量 |
|
負載測試 |
測試服務器在滿足用戶要求的範圍內，能承載的最大用戶數 |
如上表格是根據不同的測試目的來劃分性能測試，我認爲更簡單的概括應該是：前端性能和後端性能
前端性能：主要表現在頁面加載，一般會通過優化加載方式，減少數據傳輸量來進行。
後端性能：主要涉及到接口的處理邏輯優化、服務器參數配置、硬件資源消耗等。
三、性能需求
1、需求來源
性能需求一般是在需求評審會議上由產品、架構師、開發一起討論決定的，可以從以下兩個點來展開：
- 新系統
- 產品、架構師在前期需求調研時，預估出可能造成大併發的點（大量用戶同時請求，大量計算型任務、頻繁操作數據庫等場景）；
- 舊系統
- 根據生產環境日誌（ELK），統計出高頻訪問接口（動態資源），以此確定對應的業務場景
- 線上曾經出現過性能問題的點，可作爲參考
- 大型活動，例如搶紅包，直播，秒殺活動等
- 主觀感受，功能測試時請求時間較長的點
2、併發量
- 名詞解釋
TPS：服務器每秒處理的事務數，在大多數情況下和QPS可以等同；
併發數（VU）：系統同時處理的請求/事務數
響應時間（RT）：等於網絡傳輸時間+應用服務器處理時間+數據庫服務器處理時間，一般取90%時間
思考時間（TT）：從業務角度來看，用戶在進行操作時，每次請求之間的時間間隔
- 計算公式
經常會遇到“設置多大併發用戶數合適”的問題，在沒有任何思考時間（TT）的情況下，這裏有個公式：
VU（併發壓測用戶數） = TPS（每秒執行事務數） × RT（響應時間）
TPS計算方法（兩種）：
1、ELK中kibana組件可以實時統計出線上接口訪問情況，選取三個月內訪問量最大的一天，然後縮小時間範圍，精確到半小時以內，進而計算出每秒最大峯值訪問量
2、 以半年或者三個月爲區間，提取某一天中接口的峯值訪問量，根據現網網卡的流量，分析一天中用戶的活躍時間段，然後採用二八原則（即80%的訪問是在20%的時間內完成），隨後計算出每秒的訪問量，即TPS
舉例：
假設理財社區半年內瀏覽帖子的日訪問量峯值是500萬（從日誌中提取）；
現網網卡流量來看，每天社區活躍時間區間爲早上八點到晚上十點（08:00-22:00），共計14小時。
根據二八原則，400萬（500*80%）的訪問量是在2.8小時（14*0.2）內完成的，轉化成秒，
即TPS = 4000000/（2.8*3600) = 396
假設用戶每次打開帖子的響應時間是2秒，那麼此時併發數爲792
注：實際測試過程中，爲了模擬更多用戶，會在腳本中加大思考時間，這樣得到的併發用戶數就會變大，也更加仿真。
第一種方法更爲精確（推薦使用），第二種可能會有一定誤差。
3、接口文檔
在確定了具體的業務場景後，開發人員需要提供該業務的接口文檔，以便測試人員預估腳本的開發難度，準備測試數據等；
四、性能指標
- 響應時間，理想情況，單個接口響應時間低於1秒，最多不能超過3秒
- TPS是否達到預期值
- 事務成功率不能低於98%
- 服務器資源利用率
|
指標 |
閾值 |
備註 |
|
CPU |
<70% |
過高會導致系統服務不穩定 |
|
內存使用率 |
<70% |
同上 |
|
磁盤使用率 |
<70% |
同上 |
|
網絡帶寬 |
<70% |
過高會導致網絡延遲，響應時間變長 |
五、系統架構
後端性能測試是基於接口來進行，瞭解系統架構，有利於我們知道接口的處理邏輯、數據流向，大概知道哪些地方可能會有瓶頸，因此也會在相應的地方添加監控。
graph TD
A[客戶端]-->B[HTTP服務器]
B -->C[應用服務器]
C -->D[緩存]
D -->E[數據庫]
六、測試計劃
性能測試是一個團隊協作完成的項目，需要各個部門配合，因此在測試前充分溝通、做好排期非常重要。
|
任務 |
具體內容 |
責任人 |
開始時間 |
完成時間 |
目前進展 |
備註 |
|
測試方案 |
||||||
|
測試環境 |
||||||
|
測試數據 |
||||||
|
腳本開發 |
||||||
|
執行測試 |
||||||
|
分析調優 |
||||||
|
測試報告 |
七、測試方案
根據具體的需求分爲單場景和混合場景，單場景主要是測試某個接口的性能極限，混合場景主要是更加仿真，盡最大可能模擬真實環境。
1、單場景
對單個業務場景進行基準測試，採用壓力逐步遞增的方式，找到性能拐點。
舉例：
|
場景 |
併發數 |
加壓時間（分） |
平均時間（秒） |
90%時間（秒） |
TPS |
|
瀏覽帖子 |
10 |
10 |
1 |
1.5 |
10 |
|
瀏覽帖子 |
20 |
10 |
|||
|
瀏覽帖子 |
30 |
2、混合場景
對所有業務場景進行階梯式壓力發起，得到最佳處理能力（需要保持背景壓力和實時業務壓力不變）。
舉例：
|
場景 |
併發數 |
加壓時間（分） |
平均時間（秒） |
90%時間（秒） |
TPS |
|
瀏覽帖子 |
10 |
10 |
1 |
1.5 |
10 |
|
發帖 |
20 |
10 |
|||
|
回覆帖子 |
20 |
舉例：一個系統除了瀏覽帖子這個場景外，還有其他的訪問壓力（發帖，回帖），在逐步對瀏覽帖子這個場景施壓的時候，需要把其他的壓力加上
3、穩定性測試
以混合場景，日常交易量的壓力對系統進行長時間（24小時以上）的穩定性測試，考察系統長期穩定運行情況。
八、評審
測試計劃、測試指標、測試方案需要拿出來讓各個部門共同討論決定，如果通過則可以進行下一步。
以上就是實際工作中的性能測試流程,可供參考。