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 需提前准備產品記錄 |
| 性能目標 |
1、 並發用戶量：能夠支持1000人同時進行產品列表頁面查看 2、 響應時間90% Line：＜1000ms 3、 錯誤率：＜0.01% |
2.3.2 注冊及實名認證
在800個用戶同時注冊並進行身份驗證的情況下，請求的90%line的響應時間＜1500ms，且錯誤率控制在0.01%以內。
- 並發用戶量：能夠支持800人同時注冊
- 響應時間90% Line：＜1500ms
- 錯誤率：＜0.01%
| 測試場景 |
注冊**App並實名認證 |
| 場景描述 |
進入注冊頁面->輸入手機號->獲取驗證碼->開啟財富之旅->實名認證 |
| 測試數據 |
l 用戶：為**app成功注冊足夠多個賬戶，預計並發登錄的人數為800人 l 需提前准備通用驗證碼 |
| 性能目標 |
1、 並發用戶量：能夠支持800人同時注冊 2、 響應時間90% Line：＜1500ms 3、 錯誤率：＜0.01% |
2.3.3 查看產品詳情及預約產品
在500個用戶同時進行產品詳情查看和預約的情況下，請求的90%line的響應時間＜2000ms，且錯誤率控制在0.01%以內。
- 並發用戶量：能夠支持500人同時進行產品詳情查看和預約操作
- 響應時間90% Line：＜2000ms
- 錯誤率：＜0.01%
| 測試場景 |
查看**App中的產品詳情及預約產品操作 |
| 場景描述 |
點擊任一產品名稱->進入產品詳情頁面->預約產品 |
| 測試數據 |
l 用戶：為**app成功注冊足夠多個賬戶，預計並發登錄的人數為500人 l 用戶需已身份驗證、已綁定內部用戶、已風險測評為最高級、已確認為合格投資者且已登錄 l 需提前准備通用驗證碼、產品記錄 |
| 性能目標 |
1、 並發用戶量：能夠支持500人同時進行產品詳情查看和預約 2、 響應時間90% Line：＜2000ms 3、 錯誤率：＜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 風險告警
關於本次性能測試具有以下風險：（已同產品經理和項目經理確認）
- 產品列表雖然已達到原定性能目標，但當並發增加到1250個用戶時，錯誤率為0.22%，最大響應時間為1174ms。由此可以看出產品列表在並發量增加到1250時會影響請求的訪問成功率。
- 注冊及實名認證雖然已達到原定性能目標，但當並發增加到1000個用戶時，錯誤率為0.94%，99%的響應時間為1044ms，最大響應時間為60057ms。由此可以看出注冊及實名認證在並發量增加到1000時會影響請求的訪問成功率及響應時間。
- 產品預約雖然已達到原定性能目標，但當並發增加到800個用戶時，由於預約單號生成規則造成錯誤率為12.5%，導致測試無法對並發量≥800無法進行測試。因此產品預約並發量為800或之上的性能結果無法知悉。
- 受限於測試機本身配置影響，如測試產品列表並發持續訪問時，當並發量為800~1500，持續時間超過1min，測試控制機會因為內存超過70%而卡死。測試持續時間僅可為1min，因此超過測試的持續時間的性能情況無法知悉。
- 雖然對需求中的接口進行了多次測試，但測試結果依然受限於測試機、測試當時網絡影響，不作為一定的結果。
5 測試結果分析
3個接口均已達到測試目標。
產品列表：達到測試目標
注冊及實名認證：達到測試目標
產品預約：達到測試目標
