通常而言,Jmeter性能测试结果分析可从性能测试指标达成方面着手,然后再分析测试过程中出现的异常情况,逐一判断是否存在性能风险。
一、用户登录并发测试结果分析
1、提取测试指标
测试项 | 并发数 | 业务成功率 | 响应时间 | CPU使用率 | 内存使用率 |
---|---|---|---|---|---|
用户登录 | 100 | 100% | <=5秒 | <=80% | <=80% |
2、测试指标分析
1)并发数
线程组设置为100个线程,运行过程中未出现任何异常,满足100个线程并发操作需求。
2)业务成功率
测试脚本中设置了断言,判断用户登录后是否出现“登录成功”字样,并设定了“断言结果”查看器,通过查看断言结果,全部通过,则说明登录全部完成,业务成功率为100%。
3)响应时间
结合Jmeter执行结果后的聚合报告分析,用户登录响应时间目标指标<=5秒
性能指数Apdex(Application Performance Index)是一个国际通用标准,表示用户对应用性能满意度的量化值。
它提供了一个统一的测量和报告用户体验的方法,把最终用户的体验和应用性能作为一个完整的指标进行统一度量。
图7- 47表示为通用用户满意度区域,0代表没有满意用户,1则代表所有用户都满意。实际业务系统开发过程中,1是团队的追求目标。
针对ECShop用户登录业务,100个并发登录的APDEX指标如图7- 48所示。从图中可看出,所有请求的Apdex值都接近1,因此用户满意度优秀,也从侧面说明了服务器响应速度快。
4)系统资源使用
利用Jmeter监控系统资源,测试完成后结果如图所示
通过上图分析,CPU处于正常状态,因此次测试场景运行时间短,所以波峰及波谷明显,但均未持续超过80%,内存几乎无变化,被测服务器内存使用率维持在20%以内。因此测试结果符合预期目标指标。
5)数据库监控
利用Spotlight监控到的服务器Mysql数据库在测试期间运行的SQL为SELECT,与被测登录业务对数据库操作吻合
3、更新并发测试结果表
通过上述测试指标分析,更新用户登录并发测试结果表如表7- 13所示。
二、用户登录业务量测试结果分析
1、提取测试指标
2、测试指标分析
1)响应时间
测试完成,生成测试报告后,获取响应时间趋势图,如图7- 52所示。
通过上图分析,采用90%采样数据,分析整个请求,任何一个请求均未超过5秒,因此响应时间通过。
2)业务成功率
测试过程中所有断言通过,并且没有任何错误,登录成功率100%。“打开首页”、“打开用户登录页面”、“提交登录信息”与后面请求数据存在差异,是因为测试时间到达后部分请求立刻停止,故未能保证业务的完整性。
3)业务量
本次业务量测试,设置线程数为78个,2小时完成登录总数为8427次登录,其中包含了11秒操作停留时间,如果去除11秒停留时间,从数据理论计算,2*60*60/0.131=54961次,可达到预期2小时5万次登录操作,需进一步测试。
4)系统资源使用
通过Jmeter监控服务器CPU及内存使用率来看,CPU及内存使用率非常稳定,且维持在20%-30%之间,满足预期目标不超过80%,测试通过。
5)数据库监控
数据库执行过程监控正常,符合业务请求变化趋势,如图7- 54所示。
3、更新并发测试结果表
通过上述测试指标分析,更新用户登录业务量测试结果表如表7- 15所示。
测试项 | 结果属性 | 响应时间 | 业务成功率 | 业务量 | CPU使用率 | 内存使用率 |
---|---|---|---|---|---|---|
用户登录 | 预期结果 | <=5秒 | 100% | 2小时5万 | <=80% | <=80% |
实际结果 | 0.131秒 | 100% | 54961 | <40% | 20% | |
通过/失败 | Y | Y | N | Y | Y |
业务量测试存在一定差异,可进一步测试。
三、随机购物并发测试结果分析
1、提取测试指标
提取随机购物并发测试的目标指标如表7- 16所示。
2、测试指标分析
1)响应时间
测试完成后,根据生成的测试报告,获取随机购物100个并发响应时间如图7- 55所示。
通过上图分析,随机购物100个线程并发执行时,平均响应时间分别为:631毫秒、105毫秒、588毫秒、748毫秒、246毫秒、288毫秒、786毫秒、2848毫秒、1934毫秒、2161毫秒、836毫秒、290毫秒、307毫秒,通过这些数据分析,每个请求所消耗的时间均未超过5秒,但90%采样数据中,“填写收货信息”请求响应时间为5395毫秒,严格来说,该请求测试不通过。更新测试目标指标表时可采用90%采样。
2)Apdex指标
通过上图可以看出,填写收货信息、提交物流及付款方式、进入物流及付款方式设定页面三个请求用户满意度低于0.5,意味系统对这三个请求的响应时间较慢,尤其是收货信息、提交物流及付款方式这两个情况。测试工程师可针对这两个请求,给出性能测试不通过结论。通常而言,最低要求超过0.5,当然项目组可设定具体需求。
3)业务成功率
测试结束后,检查系统后台订单信息,100个并发线程,每个线程循环1次,故生成100个订单,且运行过程中没有任何错误。故认为随机购物100并发测试业务成功率为100%
4)业务量
线程组设置为100个线程,运行过程中未出现任何异常,满足100个线程并发操作需求。
5)系统资源使用
执行过程,通过Jmeter监控得到本次测试系统资源使用情况,如图7- 57所示。
过上图分析可知,CPU在测试过程中持续值维持在90%以上,有17秒时间几乎达到100%,因此从指标信息判断,本次CPU使用率超过预期80%的目标。
同时,内存使用率在25秒以后也呈现明显上升趋势,需分析这段时间什么业务导致资源使用率上升。总体内存使用率维持在30%-40%之间,低于预期目标不超过80%,故内存使用率通过。
基于CPU、内存使用率,分析响应时间图表,如图7- 58所示。
通过上图分析,可知“填写收货信息”响应时间持续升高,需测试工程师报告此问题,联合研发同事分析“填写收货信息”涉及哪些具体操作,如是否操作数据库,是否需要大量缓存、是否调用第三方地址编辑控件等,从而确定响应时间升高原因,是否因此导致CPU及内存使用率升高。
6)数据库监控
从Mysql数据库SQL语句执行速度来看,符合场景执行设计过程,但SQL中Inserts语句体现不明显,需关注原因,确定是监控本身问题,还是被测对象SQL语句设计问题。
3、更新并发测试结果表
通过上述测试指标分析,更新用户登录并发测试结果表如表7- 17所示。
4、结论
综合测试数据分析,“填写收货信息”请求响应时间超过5秒,CPU使用率超过90%,故随机购物100并发场景测试不通过。需分析“填写收货信息”涉及哪些操作,导致响应时间变长的原因,是否对CPU及内存使用率造成了影响。
四、随机购物业务量测试结果分析
1、提取测试指标
提取随机购物业务量测试指标如表7- 18所示:
100个线程持续执行2分钟后,出现大量业务错误,服务器CPU使用率持续维持在100%附近,因此利用100个线程进行2小时的随机购物业务量测试失败。可根据需要,利用折半验证法,验证系统稳定性测试的最佳线程数及服务器资源配置是否合理。
数据库报错如下:
<b>MySQL server error report:Array
(
[0] => Array
(
[message] => MySQL Query Error
)
[1] => Array
(
[sql] => INSERT INTO `ecshop`.`ecs_order_info` (order_sn, user_id, order_status, shipping_status, pay_status, consignee, country, province, city, district, address, zipcode, tel, mobile, email, best_time, sign_building, postscript, shipping_id, shipping_name, pay_id, pay_name, how_oos, card_message, inv_payee, inv_content, goods_amount, shipping_fee, insure_fee, pay_fee, pack_fee, card_fee, surplus, integral, integral_money, bonus, order_amount, from_ad, referer, add_time, pack_id, card_id, bonus_id, extension_code, extension_id, agency_id, inv_type, tax, parent_id, discount, lastmodify) VALUES ('2017110775867', '2223', '0', '0', '0', 'hzdl00168', '1', '2', '37', '403', '北京东城区', '', '01088888888', '', 'hzdl00168@qq.com', '', '', '', '5', '申通快递', '2', '银行汇款/转帐', '等待所有商品备齐后再发', '', '', '', '1999', '15', '0', '0', '0', '0', '0', '0', '0', '0', '2014.00', '0', '本站', '1510050069', '0', '0', '0', '', '0', '0', '', '0', '0', '', '1510050069')
)
[2] => Array
(
[error] => Duplicate entry '2017110775867' for key 'order_sn'
)
[3] => Array
(
[errno] => 1062
)
)
系统资源趋势图:
上述所有场景,如时间、条件、资源允许,测试工程师应当多测试几次,根据平均值输出测试报告。