1. 程式人生 > >性能測試流程

性能測試流程

等於 兩種 模擬 能力 wrap 慢sql 時間區間 會議 ransac

一、文檔目的
  • 幫助大家了解性能測試流程
  • 提高性能測試意識,識別、排查性能隱患
  • 完善公司性能測試流程

二、性能測試簡介

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小時以上)的穩定性測試,考察系統長期穩定運行情況。

八、評審

測試計劃、測試指標、測試方案需要拿出來讓各個部門共同討論決定,如果通過則可以進行下一步。

九、被測環境

1、環境要求

  • 獨立

1、排除其他應用幹擾,防止資源競爭;最好是實體機,若是虛擬機需要保證壓測時,帶寬足夠,其他虛擬機最好停用。

2、壓測不能在生產上進行。

3、建立擋板,如若有涉及到外圍系統,可根據實際情況,考慮屏蔽或者使用mock接口來模擬

  • 和生產環境架構、軟件版本保持一致

1、現實情況中,測試環境很難和線上配置保持一致,此時應當保持測試環境的架構和生產上一樣,再按照環境配置的比例大致估算出性能差異。配置比例一般以機器數量、CPU核數、內存數作為衡量指標;

參考公式:n =公倍數((生產環境web服務器/測試環境web服務器),(生產環境app服務器/測試環境app服務器))*(生產服務器內存/測試服務器內存)

2、服務器軟件版本和生產環境保持一致(nginx,tomcat,jdk,redis,mysql等)

  • 壓測時限制條件去掉

1、為了模擬大並發,我們的請求全部都是從一臺機器上發送的,可能為了防止DDos攻擊,對訪問的IP的次數和頻率都有限制,此時應該從代碼層將限制去掉

2、短信、圖形驗證碼校驗需要屏蔽,(目前短信驗證通過工具無法繞過,簡單的圖形驗證可以通過OCR技術識別,復雜的可借助於深度學習)

2、部署環境

需要開發、運維、DBA協助來進行,部署最新的代碼(功能測試通過後的),並加上相應監控項。

3、環境清單

需要從運維那裏拿到生產環境和測試環境的配置信息。

舉例:

IP

機器用途

操作系統

軟件版本

機房

配置

192.168.1.100

數據庫

centos

mysql5.6

北京

CPU: E5-2620 2.0GHz 6核 *2 \

內存:8*24G \

硬盤:8*300G

192.168.1.101

...

...

...

...

...

...

...

九、壓力發起環境

1、壓力發起方式

  • 使用工具來發送大量HTTP請求,如Jmeter,Loadrunner,Locust
  • 依賴第三方的jar包或者庫,用Java或者Python編寫代碼
  • 實時拷貝線上流量,借助於TCPCopy、gor等,將線上流量導入到被測環境中

2、機器配置

  • 一臺機器的帶寬、最大文件句柄數都有系統級限制,為了能發起更大壓力,測試過程中可能需要多臺機器組建集群來同時施加壓力

壓測開始時中先使用一臺機器,如若壓測機cpu和內存被占滿、或者TPS上不去,則再考慮搭建集群,現在我們普遍用的配置是8核16G, windows2008操作系統。

  • 機器應當盡量和被測環境在同一網段內,這樣才能避免因網絡延遲導致並發壓力上不去的狀況。

3、搭建環境

  • 配置jdk
  • 安裝jmeter及其插件
  • 調整jvm參數
  • 部署集群

十、測試賬號和數據

1、測試賬號

壓測過程就是模擬大量用戶訪問系統的行為,因此必然涉及到用戶登錄的問題,那麽就需要足夠的測試賬號。

避免只使用一個賬號來模擬多用戶,一個用戶發送多次請求和多個用戶發送一次請求,因為緩存的原因,對系統壓力是不一樣的。

2、服務器賬號

在了解系統架構後,為了監控服務器的各項指標,需要找運維同事申請服務器賬號(操作系統、數據庫、redis等),如若因為權限問題不能給到賬號,則需要運維同事幫忙看監控。

3、數據

  • 測試數據

測試數據應當盡量模擬用戶的真實操作

舉例:用戶在論壇發帖,假設發帖的字數平均在100字左右,但是腳本中發送的卻只有10個字,那麽在數據傳輸過程中,對帶寬以及數據庫存儲空間的消耗是不一樣的。

腳本模擬的是多個用戶的操作,因此對於有些參數不是唯一的,就不應該寫死,而需要動態傳入不同的值

舉例:模擬用戶瀏覽帖子的接口(http://bbs.feidee.com/thread-718207-1-1.html),718207是帖子ID,

因為每個用戶看的帖可能不一樣,且社區帖子有很多個,那麽此處每次請求的參數應該是不同的帖子ID,可提前在數據庫中將帖子ID導出到本地文件中,然後每次請求時依次讀取。

  • 數據庫數據

數據庫中應該用足夠的數據,避免“空庫測性能”,可依據生產環境中的數據存量按照一定的縮小比例來決定數據量。

十一、測試腳本

分析完壓測需求後,拿到對應的壓測接口文檔,根據對應的Url、參數,通過工具來模擬大量用戶發送請求;本文中以jmeter舉例;

  • 搭建jmeter運行環境
  • 部署分布式壓測集群
  • 設置並發線程、腳本運行時間
  • 使用jmeter發送http請求
  • 添加監聽器(聚合報告、TPS)
  • 調試接口
  • 腳本試運行。

註:接口調試成功後,可以設置多個線程,運行時間設置為5分鐘,打開查看結果樹,運行腳本,看是否有報錯。沒有的話則壓測腳本編寫完成。

十二、服務端監控項

在實際壓測過程中,因測試人員沒有權限的問題,很多監控項是需要運維、DBA同事來協助,因此這個環節需要大量的溝通工作。

1、服務器硬件資源

1、使用監控系統:Zabbix,Cacti,NMON, jmeter-Agent,監控cpu,內存,IO,網絡等使用情況

2、使用命令行,top,iostat ,vmstat,sar

前端nginx作為高性能的反向代理服務器,一般很少有瓶頸,故此處不加監控

2、應用

1、tomcat連接池配置

2、jvm堆內存使用情況,fullGC次數以及時間

3、部署jvisualvm或者jprofiler

3、數據庫

1、慢sql

2、緩存命中率

3、全表掃描數

4、連接數

4、緩存

1、內存使用率

2、命令處理數

3、慢命令

4、連接數

十三、執行測試

運行測試腳本, 實時觀察聚合報告,如若出現大量錯誤,需要立即停止,並分析原因,重新調試;
特殊情況下,有些壓測時間需要在淩晨進行,那麽可以借助於jmeter的調度器定時啟動腳本;

十四、結果分析、調優

將測試結果與用戶預期指標進行對比,如果達到則測試通過;如果達不到,則需要提交bug,並進一步分析原因,待開發修復後,重新執行測試,直到符合指標為止。

1、接口響應時間

從jmeter的聚合報告中看平均時間和90%響應時間

2 TPS

1、jmeter聚合報告中的吞吐量

2、jmeter插件:Transactions per Second 看TPS的走勢

3、服務端資源利用率

從Zabbix監控上看服務器的資源利用率(包括應用、數據庫、緩存)

4、事務成功率

從聚合報告上看各個接口的錯誤率,不能超過2%

5、分析步驟

  • 如果響應時間過長,那麽可以按照下面的思路逐步分析:

1、查看tomcat和nginx日誌,如有報錯,分析錯誤原因

2、網絡原因,用sar命令或者Zabbix監控查看網絡出口、入口流量,排查是否是網絡延遲

3、查看數據庫慢sql日誌,看是否有耗時較長的sql

4、查看redis慢命令以及命令處理數,看是否有耗時較長的命令

5、查看jvm使用情況,看是否有fullGC情況

6、查看tomcat與nginx、redis、mysql的連接數是否設置足夠

7、使用jvisualvm、jprofiler的熱點分析(或者線程dump),找出耗時最長的代碼

8、各個服務器硬件資源是否達到瓶頸

  • 如果TPS上不去:

1、壓測機的資源消耗情況

2、查看壓測環境jmeter堆內存設置、最大文件句柄數

3、聚合報告中帶寬消耗是否達到瓶頸

4、考慮搭建集群

6、常見性能問題

1、數據庫過多調用

2、數據庫資源泄露

3、連接池太小

4、sql未加索引、鎖表

5、寫log影響IO性能

6、jvm參數設置不合理

7、服務端未啟用長連接

十五、性能測試流程

技術分享圖片

技術分享圖片

十六、測試報告

1、測試結論

根據結果分析的結論,得出此次壓測是否滿足用戶預期指標。

性能測試采用的測試策略是:在測試環境用腳本模擬用戶的操作,進而向服務器發起壓力,預估是否有性能問題。即使各個測試環節都正確,也和正式環境上用戶行為有一定誤差,因此很多情況下,測試結果只能作為參考,不能完全作為依據。

2、輸出報告

將以上性能測試的全流程(包括壓測結果、相應服務器截圖、發現的性能bug、遇到的問題)整理好文檔後,用郵件的方式發送給相對應開發、產品、運維、DBA、測試,並抄送上級領導。

性能測試流程