性能测试—接口压测指标分析

原文地址：https://zhuanlan.zhihu.com/p/36587675

通常而言，Jmeter性能测试结果分析可从性能测试指标达成方面着手，然后再分析测试过程中出现的异常情况，逐一判断是否存在性能风险。

一、用户登录并发测试结果分析

1、提取测试指标

表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所示。

表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))

系统资源趋势图：

上述所有场景，如时间、条件、资源允许，测试工程师应当多测试几次，根据平均值输出测试报告。