有案例讲解吗？ 貌似人开发出 ant 执行，生成报告，也比较简单，它的客户端到时可以做比较多的数据和图表是。

这个 pk 不够大呀。。。

这点对比算不上 pk,顶多算是掰掰手腕吧😂😂

—— 来自 TesterHome 官方 安卓客户端

LR 太重量级，全部封装好的，接触不到底层逻辑；并且 还收费；
比较支持 jmeter，开源，并且可以二次开发；

至于生成的报告，可以自己优化

Jmeter 3.0 之后的图表改善了很多啊，基本 LR 有的它都有。时间轴都是从开始时间作为零点，这个所有的图表都一样，不会有什么困扰啊。

LR 可以动态调整并发用户数，这个 Jmeter 不好做。而且 Jmeter 分布式测试要配置的东西多，容易出错。没有 LR 那样有个 Controller 管理所有的压力端。

说 lr 落后的够了....这真的是用过 lr 的人能说出的话？

接触不到底层的是 jmtet， LR 都是基于传输层写代码的 这还不够底层？

性能测试工具只是辅助，方案和策略才是关键，我觉得很多人黑 LR 就是因为太开放太底层了 所以 基础的人无从下手罢了

LR 学习成本相对较高，但是结果分析方面 jmeter 是不能比的

Jmeter 扩展性较好，开发插件方便 (比如一些私有协议需要测试)，至于报告不好看，这个完全可以自己定制（InfluxDB+grafana+Jmeter 的 BackEndListenser）

个人见解：工具无分好坏，适合自己的场景能达到测试目的即是好工具

是的 我在阿里见证了 lr 从热门到被排除的整个过程 请问 bat 哪家还在用 lr 做自己的性能测试体系
目前这个工具只适合中小公司和一些技术落后的公司使用 以及一些偏门的不会自己封装协议的公司在用 现在的在云压测的 也没一家用 lr
lr 很强大 但是理念过时了很多工具都比他更实用 也支持很好的持续集成

那你说说哪些思想过时了

jmeter elk grafana influxdb 这些工具才是行业最主流的 主流的互联网公司基本都在使用这套架构

当然你还挺聪明 说 lr 的缺点或者不好 容易得罪一票人 毕竟市面上的以 lr 为生的人太多了

不妨反问下 为什么那些大公司都不用 lr 了

因为服务器都部署在大型机房 大型机房里都是 linux 的服务器 如果在办公网络加压机房 第一个压垮的是你的办公网络 不少公司就因为这个出过好几次内网故障

lr 的监控也一样 服务器在云端 监控数据需要发送到云端的监控系统做综合分析 里面的数据很大 需要常年的留存 不是 gui 的工具能分析处理的

lr 里面的数据也无法导出到正规的数据平台分析 自己太封闭了

另外加压能力也有限 虽然 lr 支持分布式 但是 windows 这种很 low 的平台上是发挥不出来的 同等的硬件 jmeter gatling ngrinder 等都比他能制造更大的并发请求

lr 的优点也很明显 协议全 功能丰富 操作傻瓜化又不失深度和强大 小公司做个压力测试 很容易就上手 所以市场目前仍然很大

最新的 lr 我记得是 4g 以上了吧 这种庞然大物那能那么容易集成到测试流程 只能专人负责 现在行业里面专职的性能测试越来越少了 性能测试工作会被测试开发工程师用更容易集成的工具替代 被研发工程师搞的全链路压测 以及监控平台和各类 profile 工具代替

这本身不是 lr 不好 而是架构决定了这个工具的前途 说不准以后 lr 也会搞 linux 服务器版本 支持跟 elk grafana 的集成 一切都在变化的

LR 支持 linux ，而且你完全可以手动集成和分析 LR 的结果集文件。说到傻瓜化 那 LR 是比不上 jmter 的 LR 还真不是傻瓜话操作，JMter 比 LR 傻瓜多了

无论什么工具，自己适用、顺手；都可以:

lr 现在支持了 linux 但是也没见那些用 linux 的公司用这个工具吧 整体打造为服务器版本没那么容易
目前的服务器都是没有 ui 的 到时候 gui 的部分会被废弃掉 用命令行调用 用监控平台分析 用配置文件设定压力 用录制器生成代码 这跟 jmeter 和 gatling 已经没区别了

对于公司来说 为什么不用轻快的小工具 而用这种收费巨贵不开放代码的庞然大物哪 所以就算 lr 支持 mac 和 linux 也挽救不了他的市场前途

傻瓜化方面 我妥协下 权且认为 jmeter 好用吧 这个赞同你 傻瓜化其实是优点 开源社区做的东西一向是架构清晰交互欠缺的 比界面我更喜欢 lr

加精理由: 对错不重要 思辨有意义

因为服务器都部署在大型机房 大型机房里都是 linux 的服务器 如果在办公网络加压机房 第一个压垮的是你的办公网络 不少公司就因为这个出过好几次内网故障

好吧，本人就干过这种蠢事情，05 年压力测试，服务器在美国，一夜下来直接导致公司中美网络 gg 了，我们那服务器还是 windows 2003 的。LR 不便宜，当时公司买了 2 个序列号，美国中国各一个，送了一次培训。现在小而美的公司估计都不会去买，估计很多人自学首先会想到 LR。

光我亲身经历的 阿里内网就被 lr 压垮过三次 朋友的公司也因为这个被压垮过好几次 还有更奇葩的 全公司都是 mac 他非要找 linux 服务器安装 windows 虚拟机用 lr 无力吐槽

因为市面上 lr 的图书和培训机构铺天盖地 导致很多新人以为这就是性能测试的大成工具 其实五六年前就被阿里和其他的互联网公司否定了

所以互联网公司面试有一条隐形的经验 精通 qtp lr 的人 尽量不要招 要不就是三流培训机构出来的人 要不就是很多年研究 lr 自以为是的井底之蛙 lr 里面也有很多高手 但是只会 lr 的人绝对不是高手

中国用 lr 的 90% 都是用的盗版 那费用贵的离谱 是针对人傻钱多的公司准备的 创业公司哪有钱买

所以后面 lr 的市场逐渐会被各种云压测服务和压测开源工具代替

自己把内网压垮了 怎么就怪在工具上了

没怪工具啊

评论比原文更具有 PK 价值~~我是来看评论的

额。
性能测试工具就是网络通讯协议层面的实现，只要传输协议和数据协议都能支持，本身不存在较大的性能问题（自己不成为瓶颈），有良好的参数化和关联支持等主要功能，都可以用来做性能测试。

不管是 lr，还是其他的 jmeter 等，只要能满足自身的需求，都可以用的。

阿里用了不合适，并不代表所有的都不合适。
lr 作为商业产品，已经过了鼎盛时期了，后续的迭代不明。
其他的开源类产品，如果一两年没新的版本出来，死掉的速度只会比 lr 快。
至于云压测，毕竟还是有局限性，不是刚需。

所以，还是要根据自身的业务特点和性能需求而定，没有绝对的好与不好。

评论比原文更具有 PK 价值~~我是来看评论的😄

挺 lr 的，请问用的是正版的吗？
就算我夸 lr 真棒，但是公司不让买怎么办？
不过我也不用 jmeter，实现一个通用压测工具并不是难事

怎么实现呀 ？求指教

我不怎么了解性能测试，也折腾过一段时间，感觉很无力：

• 1.现在性能测试的难题不是工具问题，不管工具也好，自己写脚本也好，只是一个压测端，难点一直都是监控和调优
• 2.我遇到几次都是项目要求你做项目测试，然后给个测试服务器，自己去折腾，然后就要测试报告

最后贴下谷歌的第一条测试工具排名的搜索结果：
Top 15 Performance Testing Tools of 2017: Comprehensive Load Testing Tools List

适合自己团队就行。 我曾经在接手性能时，我还丢去 Jmeter 选用了 nGrinder ，理由他是平台，便于查看历史，配置完场景，开发想调试给他个账号密码，他自己就能执行，分析。

刚毕业的时候去的一家第三方测评机构，因为要出测试报告，只能用市场占有率高的商业工具（正版），所以用了三四年的 LoadRunner，自我感觉算是精通了。
后来跳槽去互联网公司后，就再也没有使用 LoadRunner 了，原因嘛，基本上就是 @seveniruby 说的，太笨重，而且不支持 Linux。
后来就根据自己熟悉的编程语言 Python，挑了一款开源的性能测试工具，Locust，还是很不错的。到了现在的公司后，也把这款工具在公司内部推广了，现在公司内部基本都是采用这款工具了。
开源的最大魅力，就是除了使用工具，同时还可以清楚地了解工具本身的实现，从而对性能测试具有更深的理解；当遇到没有的特性的时候，也方便进行二次开发进行扩展，多好~

lr 不支持服务端压测 你注定就得在办公网压 lr 搞出故障也是顺理成章的 毕竟你也不知道办公网路由器的小心脏有多大

方案设计 监控和调优才是性能测试的核心 加压只是入门功能 工具选择很多
你搜索的那个列表是十年前的总结吧 没有 gatling ngrinder 不科学

@jinglebell
借此请教个问题，jemeter 压测页面时，页面中的 js 会被执行吗？

评论 pk 更精彩，个人放弃 lr 的原因是要收费，安装复杂，1.在创业公司用不起，2.在传统大公司没权限用。jmeter 相对来说更方便，如果要分布式，自己集成 jenkins 或自己写任务调度服务器也是可行的。最后，说一次真实经历，有一次把同程的短信误认为诈骗短信，直接对里面的跳转地址用 jmeter 压 5000 并发，然后自己网关被暂时封了

服务端压测是指什么？

就是可以在被测服务器同机房压测 不跨路由器和交换机

LR 为什么不可以？

理论上你在同机房装个虚拟机安装 windows 也可以 .后者在 linux 上安装个 agent, 再在自己的办公网络安装个 windows 去加压也可以.
也可以通过批处理结合 Jenkins 做个持续集成.
理论和实际落地是有偏差的, 最优的方案不是这样的. 所以只要公司技术跟得上, 都会走上了自己的基于开源的方案.

评论 pk 好精彩，说说自己的感觉。

• 最早入门性能测试用的是 lr 用了一段时间感觉还是很高大上的，对于做专门性能测试还是挺好用的；
• 后来转到互联网公司，要做持续集成的性能测试，发现 lr 真心有点复杂，太重，虽然搞定了 lr 的各种命令行执行，远程机房 agent 设置，失败后杀进程重测等各种坑，但是真心觉得太累了；
• 再后来又换到一家公司就改用 jmeter 做持续集成性能测试了，开源的可以自己做二次开发，还有很多插件，确实还是不错的；
• 其实个人感觉 lr 或者 jmeter 只是压力工具，性能测试最难的还是瓶颈分析。

事实就是 n 年前我就是 windows control ➕ linux agent 顺利的完成了很多项目测试，对于工具问题我不想在争了感觉回到了刚入行的阶段，吹一个东西为什么一定要黑另一个呢

果然 pk 了

—— 来自 TesterHome 官方 安卓客户端

你可以用这套体系糊口也是合理的 lr 是一直很有价值的 就跟 vb 一样大学有人教 也有人用他开发了很多项目 但是我不建议现在的新人去学它了

它的时代已经过去 他的理念已经不适合现在的架构了 我说出了他的缺点 也说出了他的优势 他死不了 但是会走向没落

说几句实话而已 你非要说我黑他我也承认啊 我跟 lr 没利益关系 直说而已
其他工具也有缺点 你也可以有证据随便黑 对我来说 这就是正常的对比而已 比如 jmeter 晦涩丑陋的 UI 体系, gatling 小白完全无法入手的.
说几个 LR 的缺点并不代表它一无是处, 也不否认它曾经是划时代的性能测试王者.
从他加压的方式 监控的方式 agent 的性能 都已经是落后了

理想的性能测试方案, 至少满足如下几个场景

• 可持续集成. 也就是固定的服务在部署到特定的环境后可以自动使用老的数据回归性能,
• 监控平台化. 可以随时调出待测服务器集群中的某台设备查看 tps/qps 和 cpu mem 句柄数 连接数 流量 jvm 的 profile 数据 数据库的状态数据 应用自身 log 统计数据的对应关系图. 可以随时调出上个季度的服务器性能和当前的服务器性能做对比.
• 问题定位方便. 可随时根据时间点和曲线图的拐点分析特定时间段的各类指标和应用 log

另外你服务过的项目 你能透露下嘛 服务器多少台 你得出的性能数据和监控数据是多少 超过 50 台的服务集群你用了多少 agent 压测 恕我直言超过 50 台你用 lr 是拿不出监控数据的 不信你可以试试

jmeter 最大的优点 beanshell，处理一些只能通过方法获取的参数容易得多。

lr 虽然笨重，但是能通过 c 语言实现很多复制的业务逻辑，有时需要模拟一些加解密的算法都可以很快写一套出来，关于 lr 的 Linux 版本，在之前的公司都是压力机用 Linux，办公机只是做数据收集和展示，对办公网压力基本上没影响。jmeter 也有很多优点，开源可以做持续集成，但是有时候要做复杂的业务逻辑和断言就有点麻烦，可能个人能力有限，关于对 jmeter 做二次开发的能力不够，所有在脚本开发上感觉 lr 还是很强大的，但是就是收费的

其实性能测试的难点不是脚本开发上，而是在于测试场景的设计上，如何更加真实的模拟线上的情况，问题定位和调优一直是性能测试最大的挑战，这块才是能够体现一个性能测试工程师能力的核心。而不是在工具的选择上和脚本的开发上

我早就说过了 你可以手动去合并 lr 的 result 数据 我最多上过 200 台 agent 测一个项目，而且还是 windows（vm 确实复制环境牛逼），算了反正你大概也无法想象吧 ，性能根本没所谓的什么持续集成，我们的脚本都是即抛型的，上一次的脚本根本无法服用（跨度太大）保留的只是测试数据和一些配置参数，性能测试很耗费资源包括人力和时间，不可能隔一小段时间又测一次，所以性能的所谓持续集成笑笑就可以了

工作习惯不同吧, 那你们公司适合 LR. 那就继续用吧. 反正有的是金钱人力和 windows 的机器.

楼者能把评论者的思辨整理一下就好了，不负精华贴之名

评论比正文精彩系列，留个抓。也希望楼主能把评论者的思辨整理一下

我来说一个 LR 的独到之处吧：打标！ to B 的企业去竞标需要性能测试报告的，很多招标企业硬性要求需要 LR 的报告。这一点，是其它市场上的主流工具所不具备的。
另外，真正的高性能领域都是订制硬件 + 订制系统，这块很多传统网安厂商有技术积累，只不过没应用在性能测试领域。

赞同。看正文觉得匹不上题目，倒是看评论收获不少

我也说说，我们公司最近也要求做服务器的性能测试，客户端是 app，有一部分能录制脚本的是用 LR 压测的，一部分是加密的，用 LR 录制不了脚本，就只能用 Jmeter 压测。测试出的数据对比，比如同样的场景配置，LR 测试出的数据比如响应时间要比 Jmerer 的要高出 0.5 到 1 倍。不知道为什么？第二 LR 有页面分解功能，知道哪个页面的 JS 文件比较大，在协议的哪个点耗时较长，比如 received 的时间较长 @seveniruby

哈哈哈，我也是从事互联网的，以我的工作环境来说，支持@seveniruby说的，我们工作确实遇到了，对于大型互联网来说，LR 确实使用太少了，至少我们公司就没听说，一般都是 Jmeter，ngrinder，还基于 ngrinder，进行二次开发，配置可扩容的压测集群，模拟生产流量等等，各种报告，也可以收集起来，进行定制展示。
但 LR 各种书籍很多，入门和上手相对容易，工具较丰富。

本人比较 low ，不知道压测 linux 本身的 ab 有什么问题，问什么没有人提及？

哈哈，这篇文章有点老，可是今天才看见，看你们的辩论还是很好玩的，可你们都忽略了一件事，LR 还是 Jmeter 都是一个发起工具，真正做性能测试的人更关注的是服务器和数据库的性能，后端监控有很多开源和收费或者自己写一些小工具，感觉这个才是重点

留个爪 见证下

喜欢看大佬们，斗法

多谢分享内幕哈 我们当初选择 loadrunner 也是因为手头有个书，而且在脚本方面 lr 编写起来比较直观，就一直用着，当然遇到的坑也很多，比如兼容问题，现在用 win10，lr 兼容不了，就用了 jmeter，单纯就工具方面来考虑，用两个工具做过一些项目的话，切换上手应该不难。目前还没涉及过云压测这种比较大型的项目，如果有的话 我觉得还是平台好，平时做性能的时候，也是希望有个平台能帮忙或者提供一些记录分析功能。用 nmon 之类的还是觉得比较麻烦。新手培训我觉得两者都可以，还是 lr 比较有亲和力一点。但进阶的话，推荐 jmeter，毕竟通用性和开源，lr 体积太大有时候客户现场压测网络受限就见鬼了，怎么传到压测机上都要努力半天，还有合规性的要求……除了这俩压测我还没有正式的用过其他的，看你们说的 gatling ngrinder ，回去研究下

博大精深的评论区，学习到了。

“被测服务器同机房压测 不跨路由器和交换机”

• LR：安装包超级大，三大组件。以前就啃了三个月，结果一年没摸啥都忘了
• Jmeter：相比之下真的安装包好小哇。上手什么的快多了，一年不摸还是能想起它的界面。 （ LR 界面那多得多的功能想都不想想）

不妨了解下最新的 loadrunner developer 这个新概念，是 LR 新出的，专门针对敏捷的解决方案，而且非常适合性能测试左移。

以前的环境真好啊