有人说:我现在已经会录制脚本了,会运行脚本了,那然后呢?看不懂测试报告还是没用啊!到底怎么反应网站的性能呢?
好吧,现在我们就来说说如何看懂LR的性能测试报告。
1. 首先,你运行完脚本后,点击如图所示的按钮,就可生成分析概要
2. 如图
当然,我们在看分析报告的时候,要搞清楚测试的目的是什么?
例如,我此次想要测试一个网页在10个用户同事访问的情况下,每15秒增加2个用户,看会不会出现问题。
3. 结果摘要
LoadRunner进行场景测试结果收集后,首先显示的该结果的一个摘要信息,如下图所示。概要中列出了场景执行情况、“Statistics Summary(统计信息摘要)”、“Transaction Summary(事务摘要)”以及“HTTP Responses Summary(HTTP响应摘要)”等。以简要的信息列出本次测试结果。
4. 场景执行情况
该部分给出了本次测试场景的名称、结果存放路径及场景的持续时间,如图所示。从该图我们知道,本次测试从10:15开始,到10:21结束,共历时6分31秒。与我们场景执行计划中设计的时间基本吻合。
5. Statistics Summary(统计信息摘要)
该部分给出了场景执行结束后并发数、总吞吐量、平均每秒吞吐量、总请求数、平均每秒请求数的统计值,如图所示。从该图我们得知,本次测试运行的最大并发数为10,总吞吐量为3,383,990,935字节,平均每秒的吞吐量为8,632,630字节,总的请求数为110,810,平均每秒的请求为282,679,对于吞吐量,单位时间内吞吐量越大,说明服务器的处理能越好,而请求数仅表示客户端向服务器发出的请求数,与吞吐量一般是成正比关系。
6. Transaction Summary(事务摘要)
该部分给出了场景执行结束后相关Action的平均响应时间、通过率等情况,如图所示。从该图我们得到每个Action的平均响应时间与业务成功率。
7. HTTP Responses Summary(HTTP响应摘要)
该部分显示在场景执行过程中,每次HTTP请求发出去的状态,是成功还是失败,都在这里体现,如图所示。从图中可以看到,在本次测试过程中LoadRunner共模拟发出了107730+3080=1108810次请求(与“统计信息摘要”中的“Total Hits”一致),其中“HTTP 200”的是107730次,而“HTTP 302”则有3080,说明在本次过程中,经过发出的请求大部分都能正确响应了,但还是有部分失败了,但未影响测试结果,“HTTP 200”表示请求被正确响应,而“HTTP 302”表示可能会有URL规范化及网址劫持的问题,可能被搜索引擎判为可疑转向,甚至认为是作弊。
比如说测试别人的网址时发现:
别人的导航链接是这样的:http://www.xxx.com/xx/
而我的是这样的:http://www.xxx.com/xx 就是少了“/” 于是修改后,问题得以解决。
8. 并发数分析
“Running Vusers(运行的并发数)”显示了在场景执行过程中并发数的执行情况。它们显示Vuser的状态、完成脚本的Vuser的数量以及集合统计信息,将这些图与事务图结合使用可以确定Vuser的数量对事务响应时间产生的影响。图显示了在网页性能测试过程中Vusers运行情况,从图中我们可以看到,Vusers的运行趋势与我们场景执行计划中的设置是一样,表明在场景执行过程中,Vusers是按照我们预期的设置运行的,没有Vuser出现运行错误,这样从另一个侧面说明我们的参数化设置是正确的,因为使用唯一数进行参数化设置,如果设置不正确,将会导致Vuser运行错误。
————————————————
版权声明:本文为CSDN博主「MTbaby」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/MTbaby/article/details/52316122
9. 因为这里没有使用集合点,所以先不讲。
10. Hits per Second 每秒点击数
反映了客户端每秒钟向服务器端提交的请求数量,如果客户端发出的请求数量越多,与之相对的“Average Throughput (bytes/second)”也应该越大,并且发出的请求越多会对平均事务响应时间造成影响,所以在测试过程中往往将这三者结合起来分析。
从图中可以看出,两种图形的曲线都正常并且基本一致,说明服务器能及时的接受客户端的请求,并能够返回结果。如果“Hits per Second”正常,而“Average Throughput (bytes/second)”不正常,则表示服务器虽然能够接受服务器的请求,但返回结果较慢,可能是程序处理缓慢。如果“Hits per Second”不正常,则说明客户端存在问题,那种问题一般是网络引起的,或者录制的脚本有问题,未能正确的模拟用户的行为。具体问题具体分析,这里仅给出一些建议。
11. Transaction Summary 业务成功率
从图中可以看出,Aciton是绿色的,即表示为Passed,Aciton是橘色的,说明Failed,同时除了vuser_init与vuser_end两个事务,Action事务通过数为3076,也就表明在6分钟的时间里,共完成了3076次网址访问操作。那么根据这些可以判断本次测试登录业务与考勤业务的成功率是3076/3080=99.8%。
12. Average Transaction Reponse Time 平均事务响应时间
13. 最后,打开 Analysis 中 Report 菜单下的 Report Templates(for cross session),单击Generate Report 生成报告。
这里Analysis 会将整个测试得到的所有数据按照模板规则生成一份文档报告,稍等片刻,一份漂亮的性能测试报告展现在你的眼前,通过Save 功能可以将这份报告保存为各种形式。
版权声明:本文为CSDN博主「MTbaby」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/MTbaby/article/details/52316122