Jmeter：實例（測試報告）

 

 

 

 

PX**APP

性能測試報告V1.0

 

 

 

編寫人： JLL    編寫時間： 2018年2月10日

審覈人：           審覈時間： 2018年   月   日

 

 

 

 

 

PXZC管理有限公司（**運營中心）

二零一八年二月十日

 

 

修訂記錄

版本號	修訂章節號	修訂人	修訂日期
V1.0	新建	JLL	2018.2.10

目錄

1      項目概述... 1

1.1      項目標識... 1

2      測試範圍... 1

2.1      測試內容... 1

2.2      測試類型... 1

2.3      測試目標... 1

2.3.1    產品列表查詢... 1

2.3.2    註冊及實名認證... 2

2.3.3    查看產品詳情及預定產品... 3

3      測試準備... 3

3.1      測試依據... 3

3.2      測試資源... 4

3.2.1    硬件配置... 4

3.2.2    軟件配置... 5

3.2.3    網絡配置... 5

3.3      測試工具... 5

3.4      人員配置... 5

3.5      人員分工... 6

3.6      測試執行... 6

4      執行結果... 6

4.1      產品列表... 6

4.1.1    併發用戶數分析... 8

4.1.2    響應時間分析... 9

4.1.3    吞吐量分析... 10

4.2      註冊及實名認證... 11

4.2.1    併發用戶數分析... 12

4.2.2    響應時間分析... 14

4.2.3    吞吐量分析... 16

4.3      產品預定... 17

4.3.1    併發用戶數分析... 18

4.3.2    響應時間分析... 19

4.3.3    吞吐量分析... 21

4.4      風險告警... 22

5      測試結果分析... 22

 

1       項目概述

1.1     項目標識

被測項目：PX**APP V1.0.0（如下簡稱：**APP）。

2       測試範圍

2.1     測試內容

本次測試主要對**APP進行全面功能測試、兼容性測試和性能測試。本報告僅描述對**APP性能的測試結果，功能測試和兼容性測試結果詳見：《**APP-功能測試報告V1.1.docx》。

測試組於2017年12月14至2017年12月22日在聯調環境下進行了性能測試準備和執行；於2017年12月25日至2017年12月27日在聯調環境下進行了第二輪性能測試，於2018年1月16日至2018年1月19日對**APP再次進行了性能確認測試。

2.2     測試類型

性能測試：性能測試是經過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。驗證系統在規定條件下，執行特定功能可提供的適當性能的能力。

關於**App對手機流量和系統資源的影響、對服務器性能的影響的測試暫不考慮。

2.3     測試目標

根據公司現狀（內部用戶：3000+，客戶：5w+）和實際狀況，本次針對登陸和產品預定操做進行性能測試。性能目標同測試計劃階段有所調整。

2.3.1      產品列表查詢

在1000個用戶同時進行產品列表查詢的狀況下，請求的90%line的響應時間＜1000ms，且錯誤率控制在0.01%之內。

• 併發用戶量：可以支持1000人同時進行產品列表頁面查看
• 響應時間90% Line：＜1000ms
• 錯誤率：＜0.01%

測試場景	查看**App中的產品列表頁面
場景描述	獲取任一投資分類的產品列表
測試數據	l  預計併發登陸的人數爲1000人 l  需提早準備產品記錄
性能目標	一、  併發用戶量：可以支持1000人同時進行產品列表頁面查看 二、  響應時間90% Line：＜1000ms 三、  錯誤率：＜0.01%

2.3.2      註冊及實名認證

在800個用戶同時註冊並進行身份驗證的狀況下，請求的90%line的響應時間＜1500ms，且錯誤率控制在0.01%之內。

• 併發用戶量：可以支持800人同時註冊
• 響應時間90% Line：＜1500ms
• 錯誤率：＜0.01%

測試場景	註冊**App並實名認證
場景描述	進入註冊頁面->輸入手機號->獲取驗證碼->開啓財富之旅->實名認證
測試數據	l  用戶：爲**app成功註冊足夠多個帳戶，預計併發登陸的人數爲800人 l  需提早準備通用驗證碼
性能目標	一、 併發用戶量：可以支持800人同時註冊 二、 響應時間90% Line：＜1500ms 三、 錯誤率：＜0.01%

 

2.3.3      查看產品詳情及預定產品

在500個用戶同時進行產品詳情查看和預定的狀況下，請求的90%line的響應時間＜2000ms，且錯誤率控制在0.01%之內。

• 併發用戶量：可以支持500人同時進行產品詳情查看和預定操做
• 響應時間90% Line：＜2000ms
• 錯誤率：＜0.01%

測試場景	查看**App中的產品詳情及預定產品操做
場景描述	點擊任一產品名稱->進入產品詳情頁面->預定產品
測試數據	l  用戶：爲**app成功註冊足夠多個帳戶，預計併發登陸的人數爲500人 l  用戶需已身份驗證、已綁定內部用戶、已風險測評爲最高級、已確認爲合格投資者且已登陸 l  需提早準備通用驗證碼、產品記錄
性能目標	一、  併發用戶量：可以支持500人同時進行產品詳情查看和預定 二、  響應時間90% Line：＜2000ms 三、  錯誤率：＜0.01%

 

3       測試準備

3.1     測試依據

• 性能測試對象
• 性能測試目標
• 測試計劃：《**app測試計劃V1.0.docx》

 

3.2     測試資源

3.2.1      硬件配置

本次測試服務器配置和PC端以下：

用途	CPU	內存	硬盤	操做系統	備註 (瀏覽器)
服務器-測試環境	E5-2620 v4 @ 2.10GHz   4核	8G	100G	centos7.3 虛擬機	無
數據庫 服務器-測試環境	E5-2620 v4 @ 2.10GHz   2核	4G	100G	centos7.3 虛擬機	無
服務器-聯調	Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz 4核	6G	200G	centos7.3 虛擬機	無
數據庫 服務器-聯調	Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz 16核	64G	2T	CentOS7.3	無
控制機- JLL	Intel(R)Core(TM)i5-6440HQ CPU @2.60GHz 2.59GHz	8G	500G	Win10
執行機- GX	Intel(R)Core(TM)i5-6200 CPU @2.3GHz 2.4Hz	8G	500G	Win10
執行機- ZC	Intel(R)Core(TM)i5-6440HQ CPU @2.60GHz 2.59GHz	8G	500G	Win10
執行機- ZYF	Intel(R)Core(TM)i5-6440HQ CPU @2.60GHz 2.59GHz	8G	500G	Win10
執行機- ZL	Intel(R)Core(TM)i5-6300U CPU @2.40GHz 2.5GHz	8G	256G	Win10

 

3.2.2      軟件配置

本次測試軟件配置以下：

軟件名稱	軟件文件名	所在硬件
數據庫	MySQL5.6.29	Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz 16核/64G/2T
中間件	Tomcat 8.5.23	Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz 4核/6G/200G
Java	1.8.0_77	Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz 4核/6G/200G

 

3.2.3      網絡配置

單獨的無線網絡：jinfu_test_5G

3.3     測試工具

工具	名稱	版本
Bug管理工具	Jira	7.3.8
用例管理工具	Testlink	1.9.16
性能測試工具	Jmeter	3.1

 

3.4     人員配置

角色	職責	對應人員	備註
測試組長	測試小組的成立 組織測試 測試方案的編寫 測試報告的編寫 測試執行、其餘工做	JLL
測試成員	測試用例設計 測試執行、其餘工做	JLL
項目經理		ZL
開發負責人		ZYH

 

3.5     人員分工

針對**APP的性能測試由JLL進行測試腳本的編寫和執行。

3.6     測試執行

測試階段	測試工做	實際 開始日期	實際 結束日期	執行人	備註
測試準備	測試腳本編寫，測試數據準備	2017/12/14	2017/12/19	JLL
測試執行	第一輪	2017/12/20	2017/12/22	JLL
測試執行	第二輪	2017/12/25	2017/12/27	JLL
測試執行	第三輪	2018/1/16	2018/1/19	JLL
測試報告	測試報告編寫	2018/2/10	2018/2/10	JLL

4       執行結果

本次測試使用工具爲Jmeter，由1臺機器控制其餘5臺機器併發執行測試。如500併發，即爲每臺併發100線程。最終，性能測試達到產品預約目標，詳情以下闡述。

4.1     產品列表

產品列表測試結果以下：

 

 

 

 

圖 1產品列表：併發測試結果

產品列表性能測試目標：在1000個用戶同時進行產品列表查詢的狀況下，請求的90%line的響應時間＜1000ms，且錯誤率控制在0.01%之內。

從上表中能夠看出：該系統在當前測試環境下，在目標範圍內的併發量1000時，錯誤率爲0，且最大響應時間爲456ms，遠均小於目標設定，能夠很好地支持1000個用戶併發進行產品列表的訪問，已經達到了原定的性能測試目標。

當併發增長到1100個用戶時，錯誤率爲0，且最大響應時間爲543ms，當其仍小於性能目標中1000ms，當併發增長到1250個用戶時，錯誤率爲0.22%，99%的響應時間爲420ms，最大響應時間爲1174ms。由此能夠看出產品列表在併發量增長到1250時會影響請求的訪問成功率。

4.1.1   併發用戶數分析

 

 

 

圖 2：產品列表：性能指標隨併發量增長的變化圖

從上圖能夠看出，該接口在當前性能測試環境下，能夠很好地支撐併發1000用戶進行產品列表查看操做。吞吐量隨着併發用戶數量的增長而增長，並未出現降低現象，證實1000用戶的併發依然未達到吞吐量的瓶頸；但隨着併發用戶量增長到1250時錯誤率爲0.22%；99%line響應時間雖然隨着併發用戶量的增長而增長，併發量爲1000時，99%line響應時間但依然在300ms之內；而偶發性的最大響應時間因爲受限於當時測試網絡狀況的影響並不隨着併發量的增長表現出穩定增加，但當併發量爲1000時，最大值響應時間但依然在500ms之內。綜上所述，該接口已達到測試經過標準。

4.1.2      響應時間分析

 

 

 

圖 3：產品列表：併發用戶數1000請求響應時間波動圖（每秒採集結果）

從上圖能夠看出，當併發用戶達到1000時，總體來看響應時間的波動，雖然中間有部分響應時間突出，但總體基本處於一種穩定且有規律的狀態，波動範圍在30%左右，且突出的響應時間依然500ms，因此該響應時間波動狀況視爲正常現象。

4.1.3      吞吐量分析

 

 

 

圖 4：產品列表：併發用戶數1000吞吐量波動圖（每秒採集結果）

從上圖能夠看出，當併發用戶達到1000時，去掉首尾吞吐量波動，中間的吞吐量基本處於一種穩定且有規律的狀態，，該吞吐量波動狀況視爲正常現象。

4.2     註冊及實名認證

註冊及實名認證測試結果以下：

 

 

 

圖 5註冊及實名認證：併發測試結果

註冊及實名認證性能測試目標：在800個用戶同時註冊並進行身份驗證的狀況下，請求的90%line的響應時間＜1500ms，且錯誤率控制在0.01%之內。

從上表中能夠看出：該系統在當前測試環境下，在目標範圍內的併發量800時，錯誤率爲0，且90%line的響應時間爲127ms，遠小於目標所限定的1500ms，能夠很好地支持800個用戶併發進行註冊及實名認證的操做，已經達到了原定的性能測試目標。

當併發增長到1000個用戶時，錯誤率爲0.94%，99%的響應時間爲1044ms，最大響應時間爲60057ms。由此能夠看出註冊及實名認證在併發量增長到1000時會影響請求的訪問成功率及響應時間。

4.2.1   併發用戶數分析

 

圖 6：註冊及實名認證：性能指標隨併發量增長的變化圖（100~1000）

 

圖 7：註冊及實名認證：性能指標隨併發量增長的變化圖（100~800）

 

從上圖能夠看出，該接口在當前性能測試環境下，能夠很好地支撐併發800用戶進行註冊及實名認證查看操做。吞吐量隨着併發用戶數量的增長而增長，到併發量爲1000時出現降低現象，證實800用戶的併發已達到吞吐量的瓶頸；隨着併發用戶量增長到1000時錯誤率爲0.94%；偶發性的最大響應時間因爲受限於當時測試網絡狀況的影響並不隨着併發量的增長表現出穩定增加，當併發量爲800時，最大值響應時間在1713ms，但90%line響應時間雖然隨着併發用戶量的增長而增長，併發量爲800時，90%line響應時間但依然在150ms之內。綜上所述，該接口已達到測試經過標準。

4.2.2      響應時間分析

圖 8：註冊及實名認證：併發用戶數800請求響應時間波動圖（每秒採集結果）

從上圖能夠看出，當併發用戶達到800時，總體來看響應時間除開始波動較大外，以後的波動均處於一種穩定且有規律的狀態，波動範圍在15左右到150左右之間，波動範圍大於30%，但考慮到增長了3秒的思考時間，因此綜合考慮該響應時間波動狀況視爲正常現象。

4.2.3      吞吐量分析

圖 9：註冊及實名認證：併發用戶數800吞吐量波動圖（每秒採集結果）

從上圖能夠看出，當併發用戶達到800時，去掉首尾吞吐量波動，中間的吞吐量一直處於一種穩定且有規律的狀態，在40左右至200左右波動，波動幅度大於30%，但考慮到增長了3秒的思考時間，因此綜合考慮該吞吐量波動狀況視爲正常現象。

4.3     產品預定

產品預定測試結果以下：

 

圖 10產品預定：併發測試結果

產品預定性能測試目標：在500個用戶同時進行產品詳情查看和預定的狀況下，請求的90%line的響應時間＜2000ms，且錯誤率控制在0.01%之內。

從上表中能夠看出：該系統在當前測試環境下，在目標範圍內的併發量500時，錯誤率爲0，且90%line的響應時間爲66ms，遠小於目標所限定的2000ms，能夠很好地支持500個用戶併發進行產品預定的操做，已經達到了原定的性能測試目標。

當併發增長到800個用戶時， 99%的響應時間爲246ms，最大響應時間爲1517ms，錯誤率爲12.5%。經確認該錯誤率是因爲預定單號形成的，非性能bug。預定單號生成規則：產品編號+年月日+順序碼，如：PXZCGL1100121708090001，其中最後是四位順序碼，當單個產品預定量查過四位數字（1w筆）時根據該規則會生成重複的預定單號，預定單號在庫中是惟一的，因此會報預定單號重複錯誤。

 

4.3.1   併發用戶數分析

 

圖 11：產品預定：性能指標隨併發量增長的變化圖

 

從上圖能夠看出，該接口在當前性能測試環境下，能夠很好地支撐併發500用戶進行產品預定操做。吞吐量隨着併發用戶數量的增長而增長，未出現降低現象，證實500用戶的併發未達到吞吐量的瓶頸；隨着併發用戶量增長到800時錯誤率雖然爲12.5%但非性能bug而是因爲預定單號生成規則形成的；偶發性的最大響應時間因爲受限於當時測試網絡狀況的影響並不隨着併發量的增長表現出穩定增加，當併發量爲500時，最大值響應時間在1606ms，但90%line響應時間雖然隨着併發用戶量的增長而增長，併發量爲500時，90%line響應時間在66ms之內；綜上所述，接口已達到測試經過標準。

4.3.2      響應時間分析

 

圖 12：產品預定：併發用戶數500請求響應時間波動圖（每秒採集結果）

從上圖能夠看出，當併發用戶達到500時，總體來看響應時間除開始波動較大外，以後的波動均處於一種穩定且有規律的狀態，波動範圍基本控制在30%，因此綜合考慮該響應時間波動狀況視爲正常現象。

4.3.3      吞吐量分析

 

圖 13：產品預定：併發用戶數500吞吐量波動圖（每秒採集結果）

 

從上圖能夠看出，當併發用戶達到500時，去掉首尾吞吐量波動，中間的吞吐量一直處於一種穩定且有規律的狀態，在20左右至200左右波動，波動幅度大於30%，但考慮到增長了3秒的思考時間，因此綜合考慮該吞吐量波動狀況視爲正常現象。

4.4     風險告警

關於本次性能測試具備如下風險：（已同產品經理和項目經理確認）

1. 產品列表雖然已達到原定性能目標，但當併發增長到1250個用戶時，錯誤率爲0.22%，最大響應時間爲1174ms。由此能夠看出產品列表在併發量增長到1250時會影響請求的訪問成功率。
2. 註冊及實名認證雖然已達到原定性能目標，但當併發增長到1000個用戶時，錯誤率爲0.94%，99%的響應時間爲1044ms，最大響應時間爲60057ms。由此能夠看出註冊及實名認證在併發量增長到1000時會影響請求的訪問成功率及響應時間。
3. 產品預定雖然已達到原定性能目標，但當併發增長到800個用戶時，因爲預定單號生成規則形成錯誤率爲12.5%，致使測試沒法對併發量≥800沒法進行測試。所以產品預定併發量爲800或之上的性能結果沒法知悉。
4. 受限於測試機自己配置影響，如測試產品列表併發持續訪問時，當併發量爲800~1500，持續時間超過1min，測試控制機會由於內存超過70%而卡死。測試持續時間僅可爲1min，所以超過測試的持續時間的性能狀況沒法知悉。
5. 雖然對需求中的接口進行了屢次測試，但測試結果依然受限於測試機、測試當時網絡影響，不做爲必定的結果。

5       測試結果分析

3個接口均已達到測試目標。

產品列表：達到測試目標

 

 

 

註冊及實名認證：達到測試目標

 

 

 

產品預定：達到測試目標