转:LoadRunner响应时间与用户体验时间不一致问题的深入分析
2017-03-25 16:42
519 查看
在新一代一期项目非功能测试过程中,我们发现了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
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
相关文章推荐
- 转:LoadRunner响应时间与用户体验时间不一致问题的深入分析
- LoadRunner:Controller及结果分析 一、性能测试概述 1、关于性能测试目标: ①TPS ②一定并发用户数下功能点的响应时间 ③一定响应时间内功能点的并发用户数 性能测试不是
- LR_问题_平均响应时间解释,summary与analysis不一致
- Loadrunner做性能测试:为什么100个用户的响应时间反而比50个用户的响应时间更短?
- glusterfs modify time(mime) 修改时间不一致问题分析
- 关于Web事务响应时间的细分以及深入分析
- 深入分析Tomcat无响应问题及解决方法
- mysql5.7.17日志时间戳(log_timestmaps)与系统时间不一致问题以及日志报Got an error reading communication packets情况分析
- mysql5.7日志时间戳(log_timestmaps)与系统时间不一致问题以及日志报Got an error reading communication packets情况分析
- loadrunner结果分析中的响应时间理解
- 深入分析Tomcat无响应问题及解决方法
- loadrunner压测分析的两个重要指标:平均响应时间和TPS
- 关于Web事务响应时间的细分以及深入分析
- loadrunner 压力测试 平均响应时间20秒 100用户并发 jquery.easyui.min.js 和jquery.js占用时间最长
- loadrunner:并发用户90%的响应时间的用法
- 软件测试工具LoadRunner结果分析中的响应时间
- CSDN博客与ITEYE博客网站深入比较分析(三)——用户体验对比分析
- 使用spotligh+sqltuning+loadrunner对数据库性能问题进行定位和分析
- 网站用户需求分析基本问题
- 用户登录域时间过久问题解决案例