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个接口均已达到测试目标。
产品列表：达到测试目标
注册及实名认证：达到测试目标
产品预约：达到测试目标
