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

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