LoadRunner响应时间与用户体验时间不一致问题的深入分析

LoadRunner响应时间与用户体验时间不一

致问题的深入分析在新一代一期项目非功能测试过程中，我们发现了LoadRunner测试响应时间与客户端实际用户体验时间不一致的现象。例如员工渠道上线后，客户体验时间远远超过了LoadRunner测试响应时间。本文针对这一现象深入研究了导致二者不一致的原因并提供了意见和建议，现与大家分享。1、用户体验时间用户通过浏览器访问Web服务器时，体验时间可以细化。如下图所示，体验时间包括用户感应时间、浏览器处理时间、网络传输延时和后端服务器处理时间。・fl*(■:*汨迅*E・fl*(■:*汨迅*E口•益tl■甜吳住邑対琳建片in叩mIlliJS增握挥lt'i■iitii衣工灯亡也址-玛叮13?=祎制吋；.tdE-.+4f.St理ninerfi■-■2、LoadRunner单次事务响应时间度量我们通常将核心业务操作定义为事务，在LoadRunner脚本中具体为web_url()、web_submit_data()等函数调用。下面举例计算单个事务响应时间，定义一次web_url()调用为事务，web_url函数中请求4个文件。艾件S称HTML描述文档sndex,htnrilCSS样式文件contenImageS：^OgirkjpgJS文件jqueryjsLoadRunner获取每个资源都要经过反应、第一次缓冲和接收三个阶段，反应阶段包括DNS解析、建立初始连接、SSL握手、FTP认证；第一缓冲时间是显示从初始HTTP请求(通常为GET)到成

功收到Web服务器返回的第一次缓冲所经过的时间；接收时间显示在服务器发出的最后一个字节到达，即下载完成之前所有的时间；客户端时间显示由于浏览器反应时间或其他客户端相关延迟而导致请求在客户机上延迟的平均时间。T-.''I也京loirjiivaif!客户摘更丑克

rtDNSR.t3OkniunTimeCuniieiliiinlirrt-ImEiUFfsfff伽口T-.''I也京loirjiivaif!客户摘更丑克

rtDNSR.t3OkniunTimeCuniieiliiinlirrt-ImEiUFfsfff伽口b5LHandshakingrime-=TpAurhfrirkJiilcnTIiyis千宫戶.咕U：■:时饵弘■U牧Wf{f，LoadRunner执行web_url()语句时，请求资源的先后顺序不依赖代码书写顺序，导致很难直接确定执行web_url()的开始时间，但可以借助LoadRunner的分析工具模块页面诊断器(WebPageDiagnostics)获取事务开始时刻和结束结束。在WebPageDiagnostics中可以获取资源下载完成时刻(ScenarioElapsedTime)和花费时间(PageComponent'sDownloadTime)，二者之差即为资源下载的开始时刻，资源开始下载的最小时刻为事务的开始时刻；在WebPageDiagnostics中资源下载完成时刻(ScenarioElapsedTime)最大值为事务的结束时刻。结束时刻与开始时刻之差为单次事务响应时间。LoadRunner单次事务响应时间取决于资源下载时间的最大值，下载时间包括第一次缓冲时间、接收时间等。3、结论与建议综上所述，LoadRunner测试响应时间不包括用户浏览器的JS文件解析执行、渲染、布局、绘制和人眼识别所需时间，只包括网络延时和后端服务时间。这也从侧面说明LoadRunner主要用来测试后端服务器性能和处理能力。LoadRunner测试时间与用户体验时间的差异如下表：EZZ.>llJUi|EKT务时IB时下載资人眼暂jg解布局绘制渲染用户寸VJV；：LR7XXXXX一般情况下LoadRunner测试的响应时间小于用户实际体验时间。针对后续非功能测试，本文提出以下测试建议：(1)如果测试目的要求获取用户体验时间，需要在LoadRunner测试响应时间的基础上考虑添加误差因子；如果用户实际体验的时间远大于LoadRunner测试响应时间，需要重点分析排查JS解释执行、渲染等问