场景运行结束后，需针对测试结果进行性能分析。通常而言，Jmeter性能测试结果分析可从性能测试指标达成方面着手，然后再分析测试过程中出现的异常情况，逐一判断是否存在性能风险。
1.用户登陆并发测试结果分析
获取测试指标提取阶段获得的用户登陆并发性能指标数据，如表1所示。
测试项响应时间业务成功率并发测试CPU使用率内存使用率登陆<=5秒100%100<=80%<=80%
（1）响应时间
用户登陆响应时间目标指标<=5秒，结合Jmeter执行结果后的聚合报告分析，如图1所示。
从图中可以看到，每个请求的平均值为559.18毫秒、108毫秒、80毫秒，用户登陆过程中的每一个请求均<=5秒，故测试通过。在Average response time与90%、95%相差不大时，可采用90%采样数据填入测试结果对比表。
（2）Apdex
性能指数，Apdex(Application Performance Index)是一个国际通用标准，Apdex 是用户对应用性能满意度的量化值。它提供了一个统一的测量和报告用户体验的方法，把最终用户的体验和应用性能作为一个完整的指标进行统一度量。该指标在制定性能测试指标时可根据实际性能评价需求增加。
图2表示为通用用户满意度区域，0代表没有满意用户，1则代表所有用户都满意。实际业务系统开发过程中，1是团队的追求目标。
针对ECShop用户登陆业务，100个并发登陆的APDEX指标如图3所示。从图中可看出，所有请求的Apdex值都接近1，因此用户满意度优秀，也从侧面说明了服务器响应速度快。
（3）业务成功率
测试脚本中设置了断言，判断用户登陆后是否出现“登陆成功”字样，并设定了“断言结果”查看器，通过查看断言结果，全部通过，则说明登陆全部完成，业务成功率为100%。
（4）并发数
线程组设置为100个线程，运行过程中未出现任何异常，满足100个线程并发操作需求。
（5）系统资源使用
利用Jmeter监控系统资源，测试完成后结果如图5所示。
通过上图分析，CPU处于正常状态，因此次测试场景运行时间短，所以波峰及波谷明显，但均未持续超过80%，内存几乎无变化，被测服务器内存使用率维持在20%以内。因此测试结果符合预期目标指标。
（6）数据库监控
利用Spotlight监控到的服务器Mysql数据库在测试期间运行的SQL为SELECT,与被测登陆业务对数据库操作吻合，如图6所示。
通过上述测试指标分析，更新用户登陆并发测试结果表如表2所示。
测试项结果属性响应时间业务成功率并发测试CPU使用率内存使用率
登陆预期结果<=5秒100%100<=80%<=80%实际结果0.169秒100%100不超过80%20%通过/失败YYYYY
2.用户登陆业务量测试结果分析
提取用户登陆业务量测试的目标指标如表3所示
测试项响应时间业务成功率业务量CPU使用率内存使用率登陆<=5秒100%2小时5万次<=80%<=80%
（1）响应时间
测试完成，生成测试报告后，获取响应时间趋势图，如图7所示。
通过上图分析，采用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） 数据库监控
数据库执行过程监控正常，符合业务请求变化趋势，如图9所示。
通过上述测试指标分析，更新用户登陆业务量测试结果表如表4所示。
测试项结果属性响应时间业务成功率业务量CPU使用率内存使用率用户登陆预期结果<=5秒100%2小时5万<=80%<=80%实际结果0.131秒100%54961<40%20%通过/失败YYNYY
业务量测试存在一定差异，可进一步测试。
3.随机购物并发测试结果分析
提取随机购物并发测试的目标指标如表5所示。
测试项响应时间业务成功率并发测试CPU使用率内存使用率随机购买商品<=5秒100%100<=80%<=80%
（1）响应时间
测试完成后，根据生成的测试报告，获取随机购物100个并发响应时间如图10所示。
通过上图分析，随机购物100个线程并发执行时，平均响应时间分别为：631毫秒、105毫秒、588毫秒、748毫秒、246毫秒、288毫秒、786毫秒、2848毫秒、1934毫秒、2161毫秒、836毫秒、290毫秒、307毫秒，通过这些数据分析，每个请求所消耗的时间均未超过5秒，但90%采样数据中，“填写收货信息”请求响应时间为5395毫秒，严格来说，该请求测试不通过。更新测试目标指标表时可采用90%采样。
（2）Apdex指标
随机购物100个并发测试的Apdex指标信息如图11所示。
通过上图可以看出，填写收货信息、提交物流及付款方式、进入物流及付款方式设定页面三个请求用户满意度低于0.5，意味系统对这三个请求的响应时间较慢，尤其是收货信息、提交物流及付款方式这两个情况。测试工程师可针对这两个请求，给出性能测试不通过结论。通常而言，最低要求超过0.5，当然项目组可设定具体需求。
（3）业务成功率
测试结束后，检查系统后台订单信息，100个并发线程，每个线程循环1次，故生成100个订单，且运行过程中没有任何错误。故认为随机购物100并发测试业务成功率为100%。
（4）并发数
线程组设置为100个线程，运行过程中未出现任何异常，满足100个线程并发操作需求。
（5）系统资源使用
执行过程，通过Jmeter监控得到本次测试系统资源使用情况，如图12所示。
通过上图分析可知，CPU在测试过程中持续值维持在90%以上，有17秒时间几乎达到100%，因此从指标信息判断，本次CPU使用率超过预期80%的目标。
同时，内存使用率在25秒以后也呈现明显上升趋势，需分析这段时间什么业务导致资源使用率上升。总体内存使用率维持在30%-40%之间，低于预期目标不超过80%，故内存使用率通过。
基于CPU、内存使用率，分析响应时间图表，如图13所示。
通过上图分析，可知“填写收货信息”响应时间持续升高，需测试工程师报告此问题，联合研发同事分析“填写收货信息”涉及哪些具体操作，如是否操作数据库，是否需要大量缓存、是否调用第三方地址编辑控件等，从而确定响应时间升高原因，是否因此导致CPU及内存使用率升高。
（6）数据库监控
从Mysql数据库SQL语句执行速度来看，符合场景执行设计过程，但SQL中Inserts语句体现不明显，需关注原因，确定是监控本身问题，还是被测对象SQL语句设计问题。
通过上述测试指标分析，更新用户登陆并发测试结果表如表6所示。
测试项结果属性响应时间业务成功率并发测试CPU使用率内存使用率 随机购买商品预期结果<=5秒100%100<=80%<=80%实际结果2.302秒100%100>90%20%通过/失败NYYNY
综合测试数据分析，“填写收货信息”请求响应时间超过5秒，CPU使用率超过90%，故随机购物100并发场景测试不通过。需分析“填写收货信息”涉及哪些操作，导致响应时间变长的原因，是否对CPU及内存使用率造成了影响。
4.随机购物业务量测试结果分析
提取随机购物业务量测试指标如表7所示：
测试项响应时间业务成功率业务量CPU使用率内存使用率随机购买商品<=5秒100%2小时5万次<=80%<=80%
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 ('110775867', '2223', '0', '0', '0', 'hzdl00168', '1', '2', '37', '403', '北京东城区', '', '01088888888', '', 'hzdl00168@', '', '', '', '5', '申通快递', '2', '银行汇款/转帐', '等待所有商品备齐后再发', '', '', '', '1999', '15', '0', '0', '0', '0', '0', '0', '0', '0', '.00', '0', '本站', '1510050069', '0', '0', '0', '', '0', '0', '', '0', '0', '', '1510050069'))[2] => Array([error] => Duplicate entry '110775867' for key 'order_sn')[3] => Array([errno] => 1062))
系统资源趋势图：
上述所有场景，如时间、条件、资源允许，测试工程师应当多测试几次，根据平均值输出测试报告。
如果觉得《并发测试mysql_Jmeter性能测试系列——结果分析与报告输出》对你有帮助，请点赞、收藏，并留下你的观点哦！
