1、概述
在做性能测试时，网络上关于性能测试工具推荐有很多，到底如何选择一款性能测试工具比较好呢？网络上关于性能测试工具对比他们优缺点有很多描述，但主要是从：并发能力、资源监控、是否开源、是否支持录制、是否支持分布、实现语言、社区活跃度、脚本的维护、易用性、可扩展性、压测平台编码量等方面对比。但几乎没有人提到性能测试工具的仿真度能力。仿真度就是性能测试工具模拟客户端向服务端下发请求与客户端的相似能力。仿真度越高，测试获得的结果越可信。
本文宗旨是选择几款常用的性能测试工具进行仿真度对比测试，以此来帮助软件测试人员在工作中如何选择一款适合自己工作需要的性能测试工具。
性能测试工具比较多，限于作者时间有限，不能对每一款性能测试工具一一测试，计划挑三款性能测试工具相互对比测试。选择策略是：挑选国产一款，国外二款（商用和开源免费各选择一款）
国外的性能测试工具我们挑选国内最常用两款：
LoadRunner、Jemeter作为测试对象；国产的性能测试工具我们选择KylinTOP(B/S)作为测试对象。
性能测试工具一般支持的协议都非常多，不可能对每一种协议都做仿真度测评。国内常用的协议主要是HTTP协议，因此文本主要针对HTTP协议的仿真度进行测评。
文本所有通过wireShark抓包文件分析获得的瀑布图，在附录中均附有抓包文件及过程分析数据。
2、浏览器并发能力分析
在向浏览器地址栏输入一个URL地址回车时，浏览器呈现在我们眼前的是一个完整的页面。页面中有很多的元素（如：文字链接、按钮、输入框、图片等），这些元素都是浏览器从服务端获取的数据。浏览器获得这些元素按并行方式获取的（通过并行的HTTP请求获得），每个浏览器并行获取的能力也是不同的，详见下表：
| 浏览器 | 并发数 | |
|---|---|---|
| HTTP / 1.1 | HTTP / 1.0 | |
| IE 11 | 6 | 6 |
| IE 10 | 6 | 6 |
| IE 9 | 10 | 10 |
| IE 8 | 6 | 6 |
| IE 6,7 | 2 | 4 |
| 火狐 | 6 | 6 |
| Safari 3,4 | 4 | 4 |
| Chrome 4+ | 6 | 6 |
注：浏览器的并发能力引用：HTTPs://www.cnblogs.com/sunsky303/p/8862128.html
文章中提到的注册表中的：MaxConnectionsPerServer（**HTTP
1.1）和MaxConnectionsPer1_0Server（HTTP
1.0）**配置项，作者使用的是wind10，自带ie11浏览器,其中MaxConnectionsPerServer=10，但是浏览的并发量并没有增加到10，仍为6。
3、仿真度的重要性
性能测试工具的工作流程：录制脚本-新建测试计划（新建测试场景）-执行测试计划-分析测试结果。工作原理是：启动一个线程循环执行录制脚本，相当于仿真一个真实在线用户不停的循环操作。那么这个用户的仿真度就与执行脚本的方式具有强相关性。执行方式与浏览行为越接近，那么它的仿真度越高。
性能测试工具的新建测试计划（场景）步骤可以选择的属性有：
运行时间或迭代次数、并发用户数以及用户新增或下降方式等。其中“运行时间或迭代次数”和并发用户数是性能测试过程中的两个重要的属性特征。用于测试服务器在指定的时间段内可承受的最大并发用户数。直接反应服务器性能指标的参数是：HTTP请求数/秒、吞吐量（Mb/秒），但是这两个属性不能按业务层面反应服务器的性能，如：最大并发用户数是一个业务层面的性能指标。因为业务不同，浏览器的并发请求数和请求时序不同，且对应的HTTP类型也不同。有些HTTP的请求是比较消耗资源的，尤其是对业务复杂处理的HTTP请求。
性能测试工具的仿真度的高低，直接体现了性能测试工具对真实业务的仿真，包括HTTP请求并发量、并发时序，业务类型等。仿真度越高测试结果获得的数据越可信。
如下图所示，每一个用户就代表一个线程，每一个线程就是对录制脚本的循环执行。下图中的每一个方格就代表对录制脚本的一次完整执行。红框标志出某一刻服务器承受的所有并发用户数，它所承受的HTTP并发请求总数等于每一个方格此时此刻的HTTP并发数总和，用公式表达就是：
服务器承受的HTTP并发总数＝（1-2用户HTTP请求并发数）+（2-2用户HTTP请求并发数）+……+(m-2用户HTTP请求并发数)。
从这个表达式可以看出，服务器承受的HTTP并发总数与每一个方式格的并发数相关，即录制脚本在此时运行的并发数。如果性能测试工具按照脚本HTTP请求，顺序执行HTTP请求（最不理想的情况），那么它的并发总数就是：ｍ，如果按浏览器的最大并发数运行,它的并发总数就是：6m（浏览器一般可以最大并发６个），相差５倍。在服务器承受的HTTP并发能力一定的情况下，脚本运行的并发数，决定了并发用户数。那么如何才能体现真实的并发用户数呢，只有在性能测试工具执行脚本的HTTP请求时，HTTP并发数、时序完全与浏览器完全相同时，才能最能真实的反映出服务器承受的最大并发用户数。
4、测试设计分析
性能测试工具的工作原理是仿真浏览器该问服务端。每一个浏览器相当于一个使用者（用户）。性能测试工具通过多线程实现模拟多用户的访问（相对比较容易实现），每个用户通过模拟浏览器的行为仿真实用户行为(实现难度较大)。浏览器的行为包括：HTTP请求、以及HTTP请求之间的关系，这些关系通过浏览器的瀑布图可以观查到也可以通过wireShark抓包工具来分析获得。本文的重点旨在通过测试对比找出最佳的用户仿真能力的性能测试工具。
用户行为即浏览器的HTTP请求行为，HTTP请求行为主要包括：
- HTTP请求顺序，包括：并行和串行两种行为，如下所示：waterfall中的横向图代表一个HTTP请求的开始与结束时间。串行的HTTP请求，表示只有前面的HTTP请求返回响应值后，再请求下一个HTTP请求。并行HTTP请求，可以同时下发请求。
- HTTP请求的数量，如下图所示每一个页面都由多个HTTP请求组成。
- HTTP的请求类型，其中包括：静态请求(如；css,js,html,jsp,png)和动态请求(后台接口)
如果性测试工具如果能对上述三种HTTP行为模拟的越接近，则性能测试工具的仿真度越高，测试结果与真实能力越接近。因此本文就围绕这三种能力进行对比测试。
图2-01
5、测试环境
5.1、试环境配置
| 操作系统 | CPU | 内存 | ||
|---|---|---|---|---|
| kylinTOP | Window 10 专业工作站版 64bit | Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz | 8GB | |
| LoadRunner 12.55 | Window 10 专业工作站版 64bit | Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz | 8GB | |
| LoadRunner 11 | Windows 7 专业版，32位 | Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz (2 CPUs), ~2.7GHz | 2524MB RAM | 虚拟机 |
| Jemeter | Window 10 专业工作站版 64bit | Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz | 8GB |
5.2、测试工具
| 工具名称 | 版本 | 工具作用 | 工具介绍 |
|---|---|---|---|
| kylinTOP | 1.8 | 性能测试工具 | 深圳市奇林软件有限公司成立于2016年，是一家从事测试工具开发与测试服务的公司。kylinTOP是一款国产的性能测试工具。 |
| Jmeter | 5.1 | 性能测试工具 | Apache软件基金会（ASF）是一家总部位于美国的非营利性慈善组织。ASF的所有产品都通过公共论坛的在线协作开发，并从美国境内的*服务器分发。Jmeter是ASF的一款开源免费软件 ，在国内被很多中小公司当作性能测试工具广泛使用。 |
| LoadRunner | 11.04.0.0，12.55 | 性能测试工具 | 惠普（HP）是世界最大的信息科技（IT）公司之一，成立于1939年，总部位于美国加利福尼亚州帕洛阿尔托市。LoadRunner是目前国内使用最广泛的性能测试工具。 |
| Wireshark | 3.0.5 | 网络抓包工具 | 美国*软件基金下的一款优秀的开源免费协议分析软件,，Wireshark（前称Ethereal），是目前全世界使用最广泛的网络封包分析软件之一。 |
| Internet Explorer 11 | 11.805.17763.0 | 浏览器 | Windows系统自带的一款web浏览器 |
| Internet Explorer 9 | 9.0.8112.16421 | 浏览器 | Windows系统自带的一款web浏览器 |
| Google Chrome | 76.0.3809.87（正式版本）（32 位） | 浏览器 | Google公司的一款世界著名的浏览器 |
5.3、测试环境组网
图5-3-01
5.4、被测试对象
HTTP://cloud.10oa.com/trial/view/catalogue.aspx?sid=132000&name=%u6211%u7684%u5DE5%u4F5C%u8BA1%u5212
或
HTTP://cloud.10oa.com/trial/view/catalogue.aspx
注：这两个地址内容是一样的，kylinTOP使用的是第1个地址，Jmeter使用的是第2个，因为Jmeter录制时无法解析第1个地址，弄了很久才发现把后的参数去除才可以录制。后续loadRunner均使用第2个地址，以免出现相同的问题。
图5-4-01
打开该主页共：16个请求,用时：815ms
6、HTTP请求仿真度对比
6.1、测试思路
步骤1：Loadrunner、kylinTOP、JMeter具录制同一个网页
步骤2：调试脚本回放，使之请求内容相同（录制能力不同录制结果也不同，这里只对比双方都能录制的请求）
步骤3:建立测试计划，各自运行脚本一次，运行的过程通过（wireShark抓包）
步骤4：通过对wireShark网络抓包结果分析HTTP请求的顺序，然后进行相互对比。
注：kylinTOP工具能够记录录制和执行过程中的HTTP请求顺序，但loadrunner无此功能需要通过抓包分析。
6.2、对比基线
6.2.1、请求列表
| 序列 | Info |
|---|---|
| 1 | GET /trial/view/catalogue.aspx?sid=100000&name=%u6211%u7684%u684C%u9762 HTTP/1.1 |
| 2 | GET /trial/awesome/css/font-awesome.min.css HTTP/1.1 |
| 3 | GET /trial/skin/view.css HTTP/1.1 |
| 4 | GET /trial/common/viewCn.js HTTP/1.1 |
| 5 | GET /trial/common/view.js HTTP/1.1 |
| 6 | GET /trial/common/10oa.png HTTP/1.1 |
| 7 | GET /trial/images/dotBlue.gif HTTP/1.1 |
| 8 | GET /trial/images/dotGreen.gif HTTP/1.1 |
| 9 | GET /trial/images/dotYellow.gif HTTP/1.1 |
| 10 | GET /trial/images/dotRed.gif HTTP/1.1 |
| 11 | GET /trial/images/dotGray.gif HTTP/1.1 |
| 12 | GET /trial/images/person.png HTTP/1.1 |
| 13 | GET /trial/images/lock.png HTTP/1.1 |
| 14 | GET /trial/skin/bg.jpg HTTP/1.1 |
| 15 | GET /trial/skin/bg40.png HTTP/1.1 |
| 16 | GET /trial/skin/bg20.png HTTP/1.1 |
表1
6.2.2、 IE11浏览器HTTP请求瀑布图
图6-2-2-01
图6-2-2-02
图6-2-2-03
TTFB 全称 Time To First
Byte，是指网络请求被发起到从服务器接收到第一个字节的这段时间,此时HTTP请求已发出。从IE11提供瀑布图看并发请求最高达到7个。但对应wireShark抓包只有6个。后续对比我们以wireShark抓包图为准。
6.2.3、IE9浏览器HTTP请求瀑布图
ie9单独访问URL，最大并发数是6个。
图6-2-3-01
HTTP的实际请求开始时间从黄色背景开始
6.2.4、Chrome浏览器HTTP瀑布图
Chrome自带的瀑布图与wireShark工具抓包分析瀑布图显示一致
图6-2-4-01
图6-2-4-02
图6-2-4-03
图6-2-4-04
6.3、KylinTOP仿真度分析
6.3.1、kylinTOP脚本录制：chrome浏览器代理录制
图6-3-5-01
注：kylinTOP录制的HTTP请求要比loadrunner多，在调试过程中已删除多余部分，方便两者对比。
图6-3-5-02
图6-3-5-03
注：kylinTOP自带的绘制HTTP请求瀑布图与wireShark抓包数据分析绘制的HTTP请求瀑布图完全一致（注意两图的有三个HTTP请求位置不同导致看起来不一样，但开始与结束时间是相同的）
6.3.2、执行性能测试任务
6.3.2.1、模拟浏览器行为，根据录制并发请求
图6-3-2-1-01
从上图分析kylinTOP性能监控执行HTTP请求瀑布图与录制时的请求瀑布存在一些差异，差异部分是HTTP请求之间空白时间段被压缩。
图6-3-2-1-02
注：kylintTOP自带的绘制HTTP请求瀑布图（录制快照图和性能测试计划中运行时间图）与wireShark抓包数据分析绘制的HTTP请求瀑布图完全一致，后续将以kylinTOP画图结果为准，不再另行wireShark抓包。
6.3.2.2、模拟浏览器行为，按照录制时间间隔时间并发请求
图6-3-2-2-01
注：wireshark的抓包瀑布图只包括绿色和蓝色两部分。
6.3.3、测试结果分析
模拟浏览器行为，按按照录制时间间隔并发请求模式：
kylinTOP的性能测试计划执行获得HTTP请求瀑布图与kylinTOP录制快照图（图6-3-5-02）及录制时的wireShark抓包图（图6-3-5-03）（包括：HTTP请求之间的时间间隔）。录制的HTTP请求瀑布图与chrome单独打开URL的瀑布图（图6-2-4-01至图6-2-4-04）存在一点差异，但相似度非常高（并发数、请求时序），目测相似度在95%左右。chrome每一次单独打开URL的瀑布图也是不一样的，也就是说HTTP请求时序存在一定的随时性，但并发总是不变的。因此kylinTOP的仿真的相似度在并发数和请求时序上几乎与浏览器完全一样。
模拟浏览器行为，根据录制并发请求
该种模式下kylinTOP给使用者多了一种选择，把HTTP请求之间的空闲期进行压缩，并尽可能的并发请求。作者猜想可能为了解决以下场景：、
场景1：录制的脚本的HTTP请求有空闲期，这种情况页一般来说是需要优化的，但开发人员还没有优化，kylinTOP提供一种提前解决脚本的办法。
6.4、Jmeter仿真度分析
6.4.1、Jmeter脚本录制
图6-4-1-01
图6-4-1-02
6.4.2、执行性能测试计划
图6-4-2-01
图6-4-2-02
6.4.3、测试结果分析
从Jmeter的测试计划执行结果的wireShark抓包分析的瀑布图看，Jmeter对HTTP请求是按顺序执行，并发数为1个HTTP,从开始执行到最后执行结束，用时超过3秒钟，真实浏览器单独访问URL时长在1秒左右，参见附件7.1：《Chrome单独访问URL抓包数据分析_wireShark_001.xlsx》。主要是因为Jmeter的用户HTTP请求采用串行请求，不具有真实浏览器的仿真能力。
6.5、LoadRunner 11仿真度分析
6.5.1、脚本录制
图6-5-1-01
图6-5-1-02
从并发图看，有5个并发，但6个并发不是很明显示，与IE9单独访问时的瀑布图（详见：6.2.3章节）相差很大。图形有并发请求，但请求之间交错比较明显，不存在明显的同时并发。
6.5.2、执行性能测试测试计划
图6-5-2-01
图6-5-2-02
6.5.3、测试结果分析
通过LoadRunner11的测试计划的执行结果的瀑布图看，HTTP请求基本上是按2个HTTP请进行并发的。HTTP的请求时序与录制时IE的请求瀑布图不同，且与IE9单独访问URL时的HTTP请求瀑布图也不相同。请求瀑布图是按照loadRunner自己的内部规则并发，与Jmeter相比，在单用户内有2个并发，是有一点进步的，但与IE浏览器的真实行为仍然差距很大。
6.6、LoadRuner12仿真度分析
6.6.1、脚本录制：基于HTML的脚本
6.6.2、执行测试计划
| 配置测试计划：启动1个虚拟用户且只运行一次 | |
|---|---|
| LoadRunner12在运行1虚拟用户的场景，在左图中看起来多启了2个用户。 | |
| 测试计划执行完毕后，通过的数是1个。通过wireShark抓包分析，脚本执行了3次。抓包文件详见附件。 |
6.6.3、测试结果分析
- 从并发数个看，已达到6个，与浏览器能力一致。
- 与录制时的HTTP请求瀑布图对比。相者相差很大，也就是说LoadRunner12在录制时没有记录HTTP的时序。是按照自己内部规则下发请求。
- 与浏览器单独访问题的瀑布图相比，存在一定差异，如：catalogue.aspx和font-awesome.min.css这两个HTTP请求，LoadRunner是顺序执行，存在并行的时间窗口。
- 对于/trial/skin/bg.jpg这个HTTP请求，浏览器始终是放在倒数第3个请求执行，LoadRunner12提前了很多。
总结：LoadRunner12对录制的请脚本执行，可以仿真IE11浏览器的6个线程并发，但不能仿真器的HTTP请求之间的顺序，相比LoadRunner11已经有了很大的提升。
6.7、HTTP请求仿真度对比总结
通过kylinTOP、Jmeter、LoadRunner11、LoadRuner12的测试计划执行结果的HTTP瀑布图对比结果看。他们的仿真能力排序：kylinTOP>LoadRuner12>LoadRunner11>Jmeter。
根据他们的能力行为，给出如下测试建议：
Jmeter：
可用于开发人员在产品开发中的功能调试使用并做一些非定量的性能测试，不适用于测试人员做定量的性能测试，更不能以此测试结果输出测试结论误导他人。
LoadRunner11：用于开发人员在产品开发中的功能调试使用显示得比较厚重，用起来不是很方便，因为LoadRunner11的HTTP请求被LoadRunner做了二次封闭，不便于开发人员调试。用于测试人员做定量的性能测试，准确度又不够（误差还是比较大），因此处于一个比较尴尬的地位。
LoadRuner12
：仿真的测能力与浏览器相近，可以用于性能测度，但定量的准确度还不够。
KylinTOP:可以用于开发人员在产品开发过程中的功能调试并一些非定量的性能测试（kylinTOP的HTTP未做二次封装）。同时也适用于测试人员做定量的性能测试，仿真度比较高，测试结果相对其它性能测试工具准确可信。
上述性能测试工具仿真度的测评都是以静态HTTP请求为基准的测试结果，后续我们将进一步以动态HTTP请求为作为测试对象，对性能测试工具做一次更高能力的测评，敬请关注。