在新一代一期项目非功能测试过程中，我们发现了LoadRunner测试响应时间与客户端实际用户体验时间不一致的现象。例如员工渠道上线后，客户体验时间远远超过了LoadRunner测试响应时间。本文针对这一现象深入研究了导致二者不一致的原因并提供了意见和建议，现与大家分享。
1、用户体验时间
用户通过浏览器访问Web服务器时，体验时间可以细化。如下图所示，体验时间包括用户感应时间、浏览器处理时间、网络传输延时和后端服务器处理时间。
2、LoadRunner单次事务响应时间度量
我们通常将核心业务操作定义为事务，在LoadRunner脚本中具体为web_url()、web_submit_data()等函数调用。下面举例计算单个事务响应时间，定义一次web_url()调用为事务，web_url函数中请求4个文件。
LoadRunner获取每个资源都要经过反应、第一次缓冲和接收三个阶段，反应阶段包括DNS解析、建立初始连接、SSL握手、FTP认证；第一缓冲时间是显示从初始HTTP请求（通常为GET）到成功收到Web服务器返回的第一次缓冲所经过的时间；接收时间显示在服务器发出的最后一个字节到达，即下载完成之前所有的时间；客户端时间显示由于浏览器反应时间或其他客户端相关延迟而导致请求在客户机上延迟的平均时间。
LoadRunner执行web_url()语句时，请求资源的先后顺序不依赖代码书写顺序，导致很难直接确定执行web_url()的开始时间，但可以借助LoadRunner的分析工具模块页面诊断器（Web Page Diagnostics）获取事务开始时刻和结束结束。在Web Page Diagnostics中可以获取资源下载完成时刻（Scenario Elapsed Time）和花费时间（Page Component‘s Download Time），二者之差即为资源下载的开始时刻，资源开始下载的最小时刻为事务的开始时刻；在Web Page Diagnostics中资源下载完成时刻（Scenario Elapsed Time）最大值为事务的结束时刻。结束时刻与开始时刻之差为单次事务响应时间。LoadRunner单次事务响应时间取决于资源下载时间的最大值，下载时间包括第一次缓冲时间、接收时间等。
3、结论与建议
综上所述，LoadRunner测试响应时间不包括用户浏览器的JS文件解析执行、渲染、布局、绘制和人眼识别所需时间，只包括网络延时和后端服务时间。这也从侧面说明LoadRunner主要用来测试后端服务器性能和处理能力。LoadRunner测试时间与用户体验时间的差异如下表：
一般情况下LoadRunner测试的响应时间小于用户实际体验时间。
针对后续非功能测试，本文提出以下测试建议：
（1）如果测试目的要求获取用户体验时间，需要在LoadRunner测试响应时间的基础上考虑添加误差因子；
（2）如果用户实际体验的时间远大于LoadRunner测试响应时间，需要重点分析排查JS解释执行、渲染等问题；
（3）如果LoadRunner测试响应时间较长，可以借助First Buffer Time、Client Time、Receive Time等分析确认网络问题、后端服务问题和页面元素问题。
原文：http://www.tansun.com.cn/tyhy/96249/97930/index.html