性能测试结果分析基础教程(图文并茂)

Loadrunner结果分析基础教程Loadrunner测试结果分析如下：1、AnalysisSummary结果及分析如下：此次测试我用了30个用户，但有1个failed，5个error。所以实际参与测试的虚拟用户总共有24个。其中，总的吞吐量为3448691bytes，平均吞吐量为12965bytes，总的请求量为720，平均每秒请求量为2.707。从该图可以看出，该系统存在一定的问题，在失败和错误的数量来看占到了总虚拟用户的20%，该比例还是挺大的，所以从这个方面可以看出在系统登录方面还存在一定问题。2、RunningVusers结果及分析如下：通过上面图形结果可知，在刚开始虚拟用户为0，30秒多时突然达到24个用户访问，一直到4：17秒将为16个用户，到4：25秒24个用户全部访问结束。3、HitsperSecond结果及分析如下：该图为每秒点击次数，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请数。通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。由上图不难看出：分别在0s、40s、1：12s三个时间点点击数最大，到后面基本处于稳定状态。4、Througput结果分析如下：该图和上面第三个图恰好相识，由上图不难看出：分别在0s、40s、1：12s三个时间点吞吐量最大，到后面基本处于稳定状态，这不难看出是由于点击数引起的。5、TransactionSummary结果分析如下：有该图不难看出，该系统处于正常运行状态。6、VuserSummary结果分析如下：由该图不难看出：虚拟用户通过的占96%，失败的占4%。所以，从整体上来看，大部分用户运行正常。7、ErrorStatistics结果分析如下：从上图不难看出:错误数据只有1个，所以也可以看出系统基本运行正常。8、ErrorperSecond结果分析如下：从上图不难看出：在刚开始时出现错误，在8秒以后无错误出现，从而也反映系统运行基本正常。9、AverageTransactionResponseTime结果分析如下：从上图不难看出：在评价反应时间里面，只有订票和付款时时间比较长，其他都比较短。10、TransactionperSecond结果分析如下：从上图不难看出：系统执行速度基本正常。11、TotalTransactionperSecond结果分析如下：由上图不难看出：失败的6个用户没有响应，而正常用户分别在32s、1：35、2：00、4：00、4：25时有响应，其他时间没有响应。12、TransactionPerformanceSummary结果分析如下：从上图可以看出各个页面请求的最大、最小、平均响应时间。13、TransactionResponseTime结果分析如下：从上图不难看出：响应时间排序如下：Action_Transaction付款订票Vuser_init_Transaction登陆选择航班Vuser_end_Transaction。14、TransactionResponseTime结果分析如下：该图和第13个图功能基本差不多，但通过该图可以看出该服务器性能是否在可以接受的范围内。15、HTTPResponsesperSecond结果分析如下：该图显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其他各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。通过该图不难看出：其和HitperSecond以及Throughput图形基本一致，所以可以判断系统运行基本稳定。16、PagesDownloadperSecond结果分析如下：该图显示场景或会话步骤运行的每一秒内从服务器下载的网页数。使用此图可依据下载的页数来计算Vuser生成的负载量。和吞吐量图一样，每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。但是吞吐量考虑的各个资源极其大小（例，每个GIF文件的大小、每个网页的大小）。而每秒下载页面数只考虑页面数。从上图不难看出：平均每秒的页面下载量为一个页面。17、Connection结果分析如下：该图显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。从该图可以看出，在前两分钟里连接数为48，从2：00到3：52里连接数为24，在3：52到4：16里连接数为48，在4：16到4：30里连接数为32个。18、PageComponentBreakdown结果分析如下：该图显示选定网页的页面组件随时间变化的细分图。通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。19、PageDownloadTimeBreakdown结果分析如下：该图显示每个页面组件下载时间的细分，可以根据它确定在网页下载期间事务响应时间缓慢是由网络错误引起还是由服务器错误引起。“页面下载时间细分”图根据DNS解析时间、连接时间、第一次缓冲时间、SSL握手时间、接收时间、FTP验证时间、客户端时间和错误时间来对每个组件的下载过程进行细分。从该图不难看出：其平均时间不到1秒，所以确定在网页下载期间事务响应时间缓慢是由网络错误引起的。20、TimetoFirstBufferBreakdown结果分析如下：该图显示成功收到从Web服务器返回的第一次缓冲之前的这一段时间内的每个页面组件的相关服务器/网路时间。如果组件的下载时间很长，则可以使用此图确定产生的问题与服务器有关还是与网络有关。网络时间：定义为第一个HTTP请求那一刻开始，直到确认为止所经过的平均时间。服务器时间：定义为从收到初始HTTP请求确认开始，直到成功收到来自Web服务器的一次缓冲为止所经过的平均时间。从该图不难看出：其时间最长的就是1秒多一点，平均不到1秒，所以可以看出产生的问题与服务器有关而与网络无关。21、综述通过以上20个图形结果分析可以大概知道，该系统在登陆时还是存在一定的问题的，在失败和错误的数量来看占到了总虚拟用户的20%，该比例还是挺大的，所以从这个方面可以看出在系统登录方面还存在一定问题。但总体来看，系统运行过程中基本正常，所以该系统还是比较稳定的。同时，也说明了该应用程序能够很快地响应用户的要求，能处理预期的用户负载并具有盈余能力，能处理业务所需的事务数量，在预期和非预期的用户负载下，应用程序是稳定的，用户在真正使用软件时能够极的体验。