一、
LoadRunner测试结果分析之我见
LoadRunner生成测试结果并不代表着这次测试结果的结束，相反，这次测试结果的重头戏才刚刚开始。如何对测试结果进行分析，关系着这次测试的成功与否。网上关于LoadRunner测试结果如何分析的介绍相当匮乏，在总结他人的观点和自己的实验体会基础上来介绍如何进行LoadRunner测试结果分析。
1. LoadRunner测试结果分析的第一步应该是查看分析综述（Analysis Summary），其包括统计综述（Statistics Summary）、事务综述（Transaction Summary）、HTTP 响应综述（HTTP Responses Summary）三部分。在统计综述中查看Total Errors的数量，HTTP 响应综述中查看HTTP 404数量，若数值相对较大（HTTP 404则相对于HTTP 200），则说明系统测试中出错较多，系统系能有问题；另外查看事务的平均响应时间和其90%的事务平均响应时间，若时间过长，超过测试计划中的要求值，则说明系统的性能不满足我们的要求。
2. 第二步对LoadRunner测试结果图进行分析，首先对事务综述（Transaction Summary）进行分析，该图可以直观地看出在测试时间内事务的成功与失败情况，所以比第一步更容易判断出被测系统运行是否正常。
3. 接着分析事务平均响应时间（Average Transaciton Response Time），若事务平均响应时间曲线趋高，则说明被测系统处理事务的速度开始逐渐变慢，即被测系统随着运行时间的变化，整体性能不断下降。当系统性能存在问题时，该曲线的走向一般表现为开始缓慢上升，然后趋于平稳，最后缓慢下降。原因是：被测系统处理事务能力下降，事务平均响应时间变长，在曲线上表现为缓慢上升；而并发事务达到一定数量时，被测系统无法处理多余的事务，此时曲线变现为趋于平稳；当一段时间后，事务不断被处理，其数量减少，在曲线上表现为下降。如果被测系统没有等待机制，那么事务响应时间会越来越长，最后系统崩溃。
4. 再分析每秒通过事务数（Transactions per Second/TPS），该曲线表示被测系统在运行的任意时刻，每个事务通过、失败的情况，其是考查系统性能的一个重要参数。若随着压力的增加，曲线如果开始变化缓慢或有平稳的趋势，则有可能是服务器开始出现瓶颈。
[5]. 分析每秒通过事务总数（Total Transactions per Second），该曲线显示在任意时刻被测系统通过的事务总数、失败的事务总数。该曲线走向和TPS曲线走向一致。
[6]. 事务性能摘要（Transaction Performance Sunmmary）该曲线表示被测系统中所有事务的最小、最大和平均事务响应时间。
[7]. 事务在负载情况下的响应时间（Transaction Response Time Under Load），该曲线表示在不同数量的虚拟用户情况下的事务响应时间情况。该图对分析具有渐变负载的测试场景比较有用。
[8]. 事务响应时间（百分比）（Transaction Response Time（Percentile）），该曲线可以容易地分析出在给定的响应时间范围内事务量的百分比重。
[9]. 事务响应时间（分布）（Transaction Response Time(Distribution)），该图可以容易地分析出在给定响应时间范围内的事务量情况。
其实，若并不是十分详细地分析测试结果，第4步与第5步选其一分析，第6步、第7步、第8步为可选项，因为在第1步就在一定程度上分析了，而第9步又与第8步功能相识。LoadRunner生成测试结果图在很大的程度上具有一定的重复性，只不过是在不同情况下的具体显示。
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
二、
LoadRunner测试结果分析之我见
上述测试过程的重点在于事务，而LoadRunner生成的测试结果图并不局限于事务上，其中还有是关于Vusers、Errors、Web Resources、Web Page diagnostics的测试图。
1. 对于Vusers的测试图有3种：Running Vusers、Vusers Summary、Rendezvous，其中Running Vusers是关于虚拟用户加压、施压、减压的情况图；
Vusers Summary是用户运行结果的综述图；Rendezvous是虚拟用户的集合点情况图。这三种图单独分析没有多大的价值，一般都是和其他图合并分析。
2. 对于Errors的分析，若是在上述测试中发现被测系统运行中有很多错误，则Errors测试结果有分析的必要，否则，就不必发费时间在Errors上了。其主要包括Error Statistics、Error Statistics（by description）、Errors per Second（by description）、Errors per Second、Total Errorss per Second，Error Statistics是带有错误代码编号的饼状图，Error Statistics（by description）不仅有错误代码编号，而且带有错误消息，Errors per Second是每秒错误数的曲线图，Errors per Second与Errors per Second（by description）的区别也是在于是否带有错误消息。Total Errorss per Second是被测系统每秒错误总数的曲线图。
若要对系统进行错误分析，则Error Statistics与Error Statistics（by description）、Errors per Second（by description）与Errors per Second择其一即可，不过带有错误描述的图更加具体。
3. Web Resources测试主要是对Web服务器性能的分析。
3.1每秒点击次数（Hits per Second）是Vusers每秒向Web服务器提交的HTTP请求数。查看其曲线情况可以判断被测系统是否稳定，曲线呈下降趋势表明Web服务器的响应速度在变慢，当然其原因可能是服务器瓶颈问题，但是也有可能是
Vusers数量减少，访问服务器的请求减少。
点击数：不是根据用户的鼠标点击次数计算，而是根据客户端向服务器发起的请求次数计算。例如：若一个页面里包含10张图片，那么在访问该页面时，鼠标仅点击1次，但是服务器收到的请求数却为1+10（每张图片都会向服务器发出请求）。此时其点击次数为11。
3.2吞吐量（Throughput）度量单位是字节，另外也有兆字节，其是度量服务器性能的重要指标，表示服务器在任意时间的吞吐能力，即任意时间服务器发送给Vusers的流量。
吞吐率=吞吐量/测试时间，单位时间里服务器发送给Vusers的流量。
点击率=吞吐量/测试时间，单位时间里Vusers发送给服务器的HTTP请求数。
[3.3]状态代码概要（HTTP Status Code Summary）表示从服务器返回的带有HTTP状态的数量分布。其HTTP状态有HTTP 200、HTTP 302、HTTP404等。该图可以容易看出HTTP响应状况。
[3.4] 每秒HTTP响应数（HTTP Responses per Second）表示每秒从服务器返回的HTTP状态的曲线图。其和 HTTP Status Code Summary不同在于后者是总体数量分布，而它是分布在时间段上的平均分布状况。
[3.5] 每秒重试次数（Retries per Second）表示单位时间内服务器尝试的连接次数。服务器重试连接的情况：初始连接未经授权、要求代理服务器身份验证、服务器关闭了初始连接、初始连接无法连接到服务器、服务器最初无法解析负载生成器的IP地址。重试次数概要（Retries Summary）是表示服务器重试连接次数量的饼图。
[3.6]连接数（Connections）显示任意时间点的TCP/IP连接数。借助此图，分析应该何时添加其他连接。每秒连接数（Connections Per Second）显示单位时间里新建或关闭的TCP/IP连接数。该图呈下降趋势，就表明每秒连接数减少，也即服务器性能下降。
对于页面资源的测试结，3.1步和3.2步应该分析，3.3步和3.4步在分析综述（Analysis Summary）中已经做了一定的分析，没有特定需求可以不做分析，若是想了解在什么时间出现何种HTTP（如错误HTTP 404），则要分析3.4步。至于3.5步可以了解在何时进行了重新连接，是什么原因导致。3.6步分析恰当的时间添加连接。
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
三、
LoadRunner测试结果分析之我见
前面分析的Web Resource（网络资源）的测试情况，其主要关注的是服务器性能，而系统本身和环境都有可能存在问题，页面诊断（Web Page Diagnostics）主要就是关注这方面的问题。页面诊断可以很好地定位环境问题，如客户端问题、网络问题等，也可以很好的分析系统本身的问题，如网页问题。
1．Web Page Diagnostics （网页诊断）对测试过程中所有的页面进行一个
信息汇总，可以很容易地观察出哪个页面下载耗时，然后选择该页面得其页面分解图，分析耗时原因。Web Page Diagnostics是一个汇总图，选择要分析的页面，可得到其4张图：Download Time、Component（Over Time）、Download Time（Over Time）、Time To First Buffer（Over Time）。
Download Time分析页面不同组件在不同阶段的所需时间，其阶段主要包括：
DNS Resolution：DNS域名解析所需的时间；
Connect：与Web服务器建立初始连接所需的时间；
SSL Handshaking：建立SSL连接所用的时间；
FTP Authentication：认证客户端所需的时间；
First Buffer：初始HTTP请求至WEB服务器响应成功所需的时间；
Receive Time：浏览器从服务器接受字节并完成下载所经时间；
Client Time：因思考时间或其它客户端问题导致的请求发生延迟所经时间；Error：从发出HTTP请求到接收到错误消息所需的时间。
这样就可以分析出时间花费在哪里，进而定位问题。
Component（Over Time）页面上不同组件在不同时间的平均下载时间曲线图。
Download Time（Over Time）不同组件在不同时间的平均下载时间面积图。
Time To First Buffer（Over Time）不同组件不同时间第一次缓冲时间面积图。
2. Page Component Breakdown 不同组件的平均响应时间占整个页面平均响应时间的百分比，此为饼状图，可以很容易的分析出页面的那个组件耗时较多。
3. Page Component Breakdown(Over Time) 任意时间不同组件的响应时间曲线图，和步骤2有异曲同工之处。
4. Page Download Time Breakdown 页面中不同组件在不同阶段的柱状图，容易看出不同阶段所占面积大小。
5. Page Download Time Breakdown(Over Time) 任意时间不同组件在不同阶段响应时间曲线图。
6. Time to First Buffer Breakdown 不同页面第一次缓冲并下载完成所需时间的柱状图，此图在分析测试结果时十分重要，其不仅能分析出哪个页面耗费时间长，而且能分析出之所以耗时是网络问题还是服务器问题。First Buffer Time分为Network Time和Server Time，客户端发出http请求并接收到服务器端的应答报文（ACK）所经时间为Network Time，客户端从接收到ACK到完成下载所经时间为Server Time。若Server Time明显大于Network Time且是其几倍，此时服务器性能是问题关键。
7. Time to First Buffer Breakdown (Over Time) 不同页面在任一时间点的Network Time和Server Time分布曲线图。
[8]. Download Comonent Size（KB）不同页面在载整个下载量所占百分比例图。
在对于页面诊断的分析中，应先查看2. Page Component Breakdown，分析哪个页面所占比例较大，然后分析其是不是造成耗时的原因。若是，再查看6. Time to First Buffer Breakdown，分析出其是网络问题，还是服务器问题。再分析7. Time to First Buffer Breakdown (Over Time) 中的曲线，进一步分析原因。可以进一步查看1．Web Page Diagnostics做具体分析。