性能测试工具 性能测试工具之的 web 动态请求仿真度对比测评分析报告
1. 概述
在《虚拟用户的 web 静态请求仿真度对比测评分析报告》报告中，我们了解到无论被测对象的请求模型是什么样的，Jmeter 工具的虚拟用户请求的并发模型都是串行的，LoadRunner11 工具的虚拟用户请求模型都两个两个并发的，而对于 LoadRunner12 版本就具有了有很高的是相似度。
本文在《虚拟用户的 web 静态请求仿真度对比测评分析报告》一文本的基本上进一步比较 WEB 动态请求仿真度。WEB 的 http 请求分为静态请求和动态请求，所谓动态请求，就是由浏览器执行相关代码而动态产生的 http 请求，如：javaScript
2. 概述
在《虚拟用户的 web 静态请求仿真度对比测评分析报告》报告中，我们了解到无论被测对象的请求模型是什么样的，Jmeter 工具的虚拟用户请求的并发模型都是串行的，LoadRunner11 工具的虚拟用户请求模型都两个两个并发的，而对于 LoadRunner12 版本就具有了有很高的是相似度。
本文在《虚拟用户的 web 静态请求仿真度对比测评分析报告》一文本的基本上进一步比较 WEB 动态请求仿真度。WEB 的 http 请求分为静态请求和动态请求，所谓动态请求，就是由浏览器执行相关代码而动态产生的 http 请求，如：javaScript
在 T1 时刻，只有虚拟用户 1 在运行，在 T2 时刻有虚拟用户 1-3 在运行。用户 1、用户 2、用户 3 之间的并行关系是虚拟用户并发模型。一般的性能测试工具的场景配置的就是虚拟用户并发模型，即虚拟用户之间的，而虚拟用户请求并发模型是在制作脚本的时候确定的。
虚拟用户请求的并发模型与浏览器的相似程度越高，我们就认为虚拟用户请求仿真度越高。虚拟用户请求仿真度的高低，对性能测试工具的测试结果影响非常的大具大。
3. 浏览器的请示并发模型
打开浏览器，在地址栏输入 URL 地址，浏览器就会显示我们平时看到的图形界面。浏览器与 WEB 服务端之间的交互，如下图所示。
浏览器与 WEB 服务器之间是协议通信交互，而与使用者之间是图形界面，在浏览器内部对协议通信的内容作了相应的图形转换，使普通的使用者能够看懂。如下所示的一个页面，图形界面显示的是一个用户登录界面，要求输入帐号、密码、验证码，还提从了一个登录按钮。对于通信层面，却有 7 个请求。
注：打开浏览器按 F12 键，并切换到 Network 或网络 页签，即可看到浏览器与 WEB 服务器之间的交互。上图的时间线，就是浏览器与 web 服务端之间请求的并发模型。对于性能测试工具的虚拟用户请求并发模型要与浏览器相一致。
4. 测试环境
4.1.测试环境配置
4.2.测试工具
4.3.测试环境组网
图 4-3-01
4.4.被测试对象
http://59.110.158.28/Example/
图 4-4-01
5. HTTP 请求仿真度对比
5.1.测试思路
步骤 1：Loadrunner、kylinPET 具录制同一个网页
步骤 2:建立测试计划，各自运行脚本一次，运行的过程通过（wireShark 抓包）
步骤 3：通过对 wireShark 网络抓包结果分析 HTTP 请求的顺序，然后和浏览器产生的请求并发模型对比。
注：kylinPET 工具能够记录录制和执行过程中的 HTTP 请求顺序，但 loadrunner 无此功能需要通过抓包分析。
5.2.对比基线
5.3.Microsoft Edge 浏览器的请求并发模型
使用 Edge 浏览器单独方问题 Web 服务器并记录并发请求模型，如下所示，通过打开主页输入用户名称、密码、验证码登录后，浏览器记录的请求并发模型。
用户操作时间是用户在输入帐号、密码、验证码以及点击登录按钮时花费的界面操作时间。
在以上请求中，最后 6 个请求为动态请求，其余为静态请求。后续的请求并发模型比较，我们重点关注后面的动态请求。
注：上图中时长为 0 的请求，通过 wireshark 抓包看，没有相应的请求包。
5.4.KylinPET 仿真度分析
5.4.1.kylinPET 脚本录制：Edge 浏览器代理录制
通过浏览器模型进行脚本录制获得如下的脚本
5.4.2. 执行性能测试任务
5.4.3. 测试结果分析
kylinPET 的性能测试计划执行获得用户登录事务时间与预期时间相符（预期时间在 2 秒-3 秒之间），同时它的 HTTP 请求瀑布图与浏览器单独访问 URL 得到的请求并发模型相一致。
5.5.LoadRuner12 仿真度分析
5.5.1.脚本录制：基于 HTML 的脚本
5.5.2.执行测试计划
下图是任务执行通过 wireShark 抓包绘制得到请求并发模型图（loadRunner 本身不提供虚拟用户请求并发模型图）
5.5.3.测试结果分析
1、 用户登录事务时间为 12 秒，远超事务的实际时间
2、 通过抓包分并绘制请求瀑布模型分析看，用户登录事务的 6 个动态请求 loadrunner 处理为串行模式（实际为并行），导致事务时间拉长。（并发请求时事务时间取决于最大请求的时间，串行时间事务时间为所有请求时间的累加值）
5.HTTP 请求仿真度对比总结
KylinPET 可以正确处理 web 的动态请求模型，并获得正确的事务时间。LoadRunner 在处理 web 动态请求时，把并行请求错误的处理为串行，导致事务时间拉长，获得错误事务时间，如果同样我们在使用 loadRuner 测试系统的压力测试时，相同样的的在线虚拟用户数，对系统的压力就会小 6 倍,导致测试不准，得出错误的系统允许最大在线用户数。
看了下，文章想说的应该是 LR 和 KylinPET 两者的录制能力差异吧，LR 录制后默认是串行，而 KylinPET 则是和浏览器的发送情况基本保持一致。确实从这个角度来说，LR 的录制能力不够 “拟真”
不过有个疑问，一般什么场景下的性能测试，会要求并发模型和单个用户浏览器访问的时候保持一致呢？而且用这个评估最大在线用户数，也有点说不过去？
“最大在线用户数” 这个概念本身就比较模糊，如果按 token 保持有效就算在线的话，那 token 最大存储个数本身就等价于最大在线用户数了。如果要加上服务处理性能，那得看这些用户在干嘛，用到哪部分接口，这个还得细分典型场景（大多数人用的场景）、特殊场景（预估压力会特别大但又真实存在的场景，比如大 V 直播啥的）啥的，很难一个 “最大在线用户数” 直接概括。
陈恒捷
回复
1、文章通过单一个虚拟用户在线操作，分析了虚拟用户的行为特征。如果单个虚拟用户在线操作的行为失真，同样，多用户操作的影响也是一样。在任何时间任任何场景，都要求虚拟用户本身的行为（虚拟用户的请求瀑布模型）必须真实的浏览器保持一致，否则会就会导致测试结果失真。
文章最后说系统允许的最大线用户数，是指最大在线操作用户数。要操作哪些要看系统的需求。比如：系统需求是最大线操作用户数 100，且 100 个用户同时在线操作下，系统的性能满足指标要求。那么你需要测试 100 个用户同时登录，并对一些关键的事务（如：系统支付功能等）进行并发操作（这里的并发是指虚拟用户间的并发）。如果这时每一个虚拟用户的行为都与浏览器的行为是相同的，那么整体测试的结果是也是可信的。假定我们测试的是在线支付功能，100 个用户同时点击支付（点击支付我们假定每个用户需要发送 6 个请求，并且是并行的），如果性能工具处理把每个虚拟用户处理成串行的 6 个请求，那么 100 个虚拟用户同时点击，对被系统的压力最大是 100 个并发请求，如果虚拟用户处理为并行的，那么对被测系统的压力就是 600 个并发请求。
陈恒捷
回复
性能测试的并发模型有两种：
1）虚拟用户间的并发模型。也就虚拟用户之间是按什么样的递增或递减的方式并发。
如：有 100 个虚拟用户，按每秒新增 5 个在线用户数的方式递增，直到在线用户数达到 100，保持不变。
2）虚拟用户请求的并发模型。性能测试工具模拟虚拟用户，都是通过一个脚本的方式模似的，性能脚本执行一次相当于完成一次虚拟用户的操作。性能脚本包含多个请求，而这此请求之间的并发关系，就是虚拟用户请求的并发模型。
SagacitySea
回复
受教了
我们这边服务端服务 app 为主，大部分场景需要请求多接口的话，没有依赖关系的都是直接并行访问，不大会串行。所以很少特意关注这里提到的用户请求的并发模型。
一开始看还懵了一下，按照面向接口压测的思路，一般不会把用户在浏览器上请求的模式拎出来说，而是直接按照业务链路的思维去梳理。后来看完之后就理解了，本质上工具的核心卖点是 UI 操作化与录制，录制功能做到和多用户用浏览器一样的访问模式，对用户的要求更低（甚至不用具备链路业务梳理的能力）。
不过这样做压力测试会有局限性的：
- 没有办法把后端链路拆分开来进行压测，除非后端很简单，不然压测粒度太粗也就不好定位问题；
- 不是所有系统都会有前端页面，就没法录制了（不过工具本身应用定位就不是在这个场景，可以理解）
- 个人感觉会有一些问题无法触达，因为不是所有流量都是由前端的用户访问直接产生的，有时候在链路内部会流量放大的机制（如内部的失败重试），极端场景下需要额外考虑
王稀饭
回复
你是发散型思维，本文仅限于讨论性能工具对 web 的仿真能力。你非要去讨论系统要怎么测试，要关注什么，哪些场景没有浏览器界面。
HTTP/2 情况下，不知道这个工具仿真能力怎样
有的工具支持 HTTP/2 协议，但不一定模拟多路复用。
另外，HTTP2 的压测工具需要解决几个问题：
1、端口复用问题，否则会造成端口使用完
2、客户端在 1 个连接中创建的 stream 上限（如 nginx 的 http2_max_concurrent_streams）
3、1 个连接的请求次数上限问题（如 nginx 的 http2_max_requests），达到上限，nginx 那边会切断连接，那压测端会不会自动做一些处理
@SagacitySea 你是在录制脚本的时候将所有请求的起始时间记录下来，然后在压测的时候按照时间戳间隔进行了模拟么？
这里有两个问题：
1、web 页面加载时，资源加载的顺序和策略是不完全固定的，按照录制那个时刻记录的时间戳，本身跟真实用户浏览器的加载也会存在偏差，并不能做到真实模拟浏览器；除非你的机制就是内置了浏览器的渲染引擎，但这对资源的消耗很高，很难做到较高的并发；
2、很多时候浏览器的并发资源加载都是静态资源，这些资源都是在 CDN 上的；大多数时候压测 CDN 资源的意义不大，会进行过滤处理，只压测 app 服务器的接口；而 app 服务器接口应该基本都是串行的。
debugtalk
回复
你的问题非常好。
1、使用真实浏览器多次访问同一个被测试对象的 web 网站，因为网络等资源问题，每一次都会不会过多全一样，存在一定的偏差。做为性能测试工具，都是尽可能的去模模拟浏览器的行为。任何一款性能测试工具都无法完全做到一模一样，都是尽可能的模拟。不好的性能测试工具模拟的结果偏差大，好的性能性能测试工具模拟的偏差小。
kylinPET 支持三种仿真能力：
1）根据录制到的请求以及 HTTP 协议的规则去模拟，尽可能的去仿真浏览器行。业界大部分是这种，但是模拟的偏差比较大。Jmeter 就是简单粗暴，全部是串行。最新版本的 LR 对动态请求模拟显得的力不从心，静态请求
2）另一种支持按照录制请求时间间隔下发请求。 3）串行，用户可以强制串行发下请求
2、APP 的请求不一定都是串行的，主要看开发人员的设计。
3、浏览器的加载资源加载顺序不固定，但是是有规律的，你可以仔细观察一下。HTTP1.1 协议最多 6 个并发等规则。
做为一款好的性能测试需要尽可能的模型这些规则。
SagacitySea
回复
我看过 kylinPET 的 HTTP2 的说明，说是 “在处理 HTTP/2 协议的 HTTP 的请求并发模型依据请求的父子关系，按照一定的算法进行并发”。
就是不知道这个工具内部是否利用多路复用特性，还是单纯的用并发来模拟
当前 loadrunner 有基于 HTML 和基于 URL 两种录制模式，如果你专注于资源请求的话，建议使用 URL 模式。
在 URL 模式下使用 loadrunner 录制时，会为单个请求生成如下函数：
web_concurrent_start、web_concurrent_end（并发组函数）
当脚本执行遇到 web_concurrent_start 时，会将到 end 之间的函数放在一起并发执行，使用这个函数应该可以解决你的性能仿真问题。
杨腾
回复
感谢你的回复，试了你的方法才，用 URL 模录制。URL 录制生成的脚本，把页面子了请求都放在脚本中了，相当于脚本中包含了所有请求。对于页面静态请可以生成 web_concurrent_start、web_concurrent_end（并发组函数），我的静态页面包含 8 个请求，录制结果把所有 8 个子请求都放在同一个并发请求组中（与实际不符），导致测试数据比浏览器加载时间小。又试页面动态请求 web_concurrent_start、web_concurrent_end 组，全部按串行处理，导致则试比实际的大。