首先你不用怀疑 jmeter 的正确性，loadrunner 跟 jmeter 都是一类工具，原理都类似。所以 loadrunner 的结果你认可，那么 jmeter 的工具你也应该认可.只不过 loadrunner 是商业工具，可能界面上好看一点，报告看上去更好看一点。报告该有的 jmeter 也有，只是可能相对不那么好看而已

1、使用压测工具 jmeter 进行脚本的录制与调试；
jmeter 的录制功能建议还是少用，尽量通过接口或者其它方式获取到请求 url，参数；然后再此基础上在在 jmeter ui 上进行调试

谈谈我对性能测试的认识：
目的：
性能测试的最终目标是找到性能瓶颈，并联合研发同学一起去优化这个问题，所以报告只是你对测试过程的总结，漂亮的报告 !=（不等于）完美的性能测试。

方案：
前面提到了性能测试的目的，那么一个好的性能测试方案可以让我们开展性能测试工作变得游刃有余，方案包括：

1、压测目标考虑，你压测的业务是什么，是基于什么协议实现的，模块与模块之前是如何调用的，只有清楚了这些，才能确定后面压测工具、压测协议、压测场景。
2、性能指标考虑，需要你基于现有日志系统去估算用户合理并发数 QPS，而不是怕脑袋想一个 QPS，也不是无限制的压下去
3、环境考虑，贴合真实线上环境搭建一套测试环境，包含服务器硬件（资源尽可能劣于线上环境）+ 网络传输（是否存在弱网传输情况）
4、压测策略考虑，基于压测目标设置压测场景，
比如
第一轮基准压测，俗称摸底，看看不进行调优的情况下，每种单业务能达到的 QPS 是多少——这个环节用于单指标调优
第二轮混合压测，比如业务有：登录后 + 访问页面 + 点击 A 页面/点击 B 页面，那么在混合压测里面就需要考虑：每种场景的比例时多少，即：登录、点 A 页面、点 B 页面的比例各是多少——这个环节用于混合指标调优
第三轮疲劳测试，经过前 2 轮测试与调优后，进入第三轮长时间压测，主要看系统是否稳定的测试，这里面就需长时间监控：压力机以及被压服务的各项资源，及时报警找性能的拐点，这个环节出现拐点（QPS 下降）大部分是内存泄露导致
5、技术框架考虑，需要你确定使用的压测工具 + 准备压测的数据 + 研发需要协助打的桩（可能每次需要验证码，但我们需要测试登录后的性能，所以需要研发屏蔽验证码）
6、监控工具考虑，可以是用压测工具自带监控工具，也可以使用一些第三方监控工具——nmon 工具等
7、性能测试用例，就是细化第 4 端——压测策略，把它们用例化
8、报告输出：一般第三方工具具有报告输出功能，例：jmeter、loadrunner 本身具有专业的报告，如果你是公司内部的压测工具，需要你自己写报告，那么报告里面需要包含：测试人员、测试执行时长、测试结果、期间被测服务的各项指标监控（响应时长、IO、内存、CPU 占用情况）等指标。

测试工具：
1、Jmeter ——该工具优点是开源免费、缺点是有的压测需要写 java 语法去驱动，例如对 dubbo 接口的压测。
2、ab 压测工具——开源的 linux 下的压测工具，支持对常见 http、tcp、udp 协议的压测，
3、loadrunner —— 企业级的性能压测工具，支持各种协议的录制与压测，优点是：有好的 UI 操作界面，通过简单录制后生成 C 语言的脚本，然后同关联、参数化脚本进行压测，并且可以对服务器的各项资源（CPU、内存、IO）进行监控，方便定位性能瓶颈，缺点是：不是免费的，如果是小公司可以找一些 license 去破解。

本人之前从事过性能测试、大数据测试、自动化测试，

我的公众号：数据猿温大大，更多干货在这里。

你的字多，你有理

您的意思是不需要这么多接口，而是找关键接口去校验，可是我不明白的是，这样并不能算是一个完整的业务流程呀，压测的时候能有说服力吗？

1. 梳理出业务需求 2. 转化成可执行的性能测试场景 3. 然后才是开发调试脚本，执行，监控，慢查询，问题定位

而且这种测试方案感觉比较低级，结果也不可控，没有说服力

• 方案不建议以低级高级论高低，关键还是是否符合需要。如果你觉得用脚本是低级，搞平台是高级，也可以搞，开源的也有 meterphere 可以直接用，底层同样基于 Jmeter。

• 至于结果不可控，不知道能否详细说下，正文中没看出哪里结果不可控

• 没有说服力。这个嘛，具体是哪个部分没有说服力，是 Jmeter 这个工具本身没有说服力，还是性能测试方案里设计的场景不真实没有说服力？一般性能测试结果没有说服力，大多是后者，前者见得比较少，Jmeter 本身大家还是比较认可的。

我们是根据这个流程来的，但是当并发或者重复达到比较高的值时，主机的性能会下降，遇到的问题就是执行的时候观察的数据可靠吗？而且数据过万时运行时间也是个大问题呀！

感觉你的出发点有些问题，好不好看不代表低不低级
可视化报告本身就不是给测试人员分析结果用的，毕竟好看的东西通常都是给外行人看的
至于测试结果可靠性的问题，Jmeter 作为目前最流行的开源性能测试工具，足以说明问题了
工具是死的，最终能不能满足要求还是看人怎么做

哥 你误会我了 我的意思是数据不容易观察，还不如 GUI 上面直接运行查看聚合报告，我说的低级是测试方案，因为之前也没接触过，都是根据情况来写的

那问题就简单了
觉得 GUI 更利于分析，就把结果文件在 GUI 中打开分析
觉得方案低级，就基于你的实际业务优化方案
至于生成的测试报告的价值，老实说，无非就是风格上好看点 (大概？)，忽悠外行的，无视就好了

meterphere 这个开源的工具地址可以麻烦贴一下吗？没搜索到

如果业务比较大的话呢？我这次生成的就是业务基准测试，1 个线程 100 次循环，到时候模拟多个并发几万条数据的时候，在 GUI 模式是不是太占内存了，我们是远程连接的压力机，生成的数据受到主机性能的影响吗？

我们现在只是简单模拟基准测试，1 线程 100 重复，因为录制的请求（过滤后）比较多，光跑就得 1 个多小时，生成的测试报告中所有的数据都重叠在一起（上图红框处），根本无法观察数据的情况，所以我就认为可视化报告是不是不太适合多个请求的数据展示。而且以后涉及到更大的压测，高并发多业务的时候，测试数据在 GUI 中是不是会受到主机性能的影响？如果是的话那测试报告中的数据也不太真实

用命令行执行测试 将测试结果保存到文件
测试结束之后，再用 GUI 分析结果文件

https://github.com/metersphere/metersphere
我的锅，打漏了一个 s。。。

想先问一个问题，你们要分析的指标是啥，每个接口的请求响应时间，还是别的啥？看你的截图是响应时间百分比分布，图里内容已经反映出 95% 以上的请求响应时间在 2s 内了，但灰色线的那个请求明显比大部队慢很多，需要结合场景看是否需要优化了。不知道你想知道的是什么信息。

如果是想看每个 url 的 90% 或者 95% 响应时间以及 tps ，应该要用另一个响应时间的报表，具体名字不大记得了，横轴是各种指标（最大响应时间、95% 响应时间、每分钟请求数等），纵轴是每个请求 sample。

另外，Jmeter 有很多报表插件的，建议你在确定了自己想要的指标后，先看看有什么相关插件，找到最合适自己的。你现在用的这个插件感觉不是太适合，那条灰色线和其他数据差异太大，所以其他数据基本都看不准确了。

你应该问一句：甲方你会不会，不会不要插脚。

这个甲方的地位应该高于华为了吧

主要还是响应时间，我们现在调整方案了，不这样测了，谢谢你的回答

最近做性能测试，也遇到过和楼主一样迷茫的境遇，不过我更差一些，我没什么选择权，只能自己摸石子过河，先尝试以后再做比对。

而且现在我遇到一个问题想问下，因为想做登录这一块的压力测试，本地 JMETER 线程数设置的就算很高也没意义，请求还没发到服务器就触发了超时，就算调高了超时的时间也没意义（因为摸不到服务器瓶颈）。现在使用分布式的测试，但是发现单个运行时不会报错（线程数为 800，Ramp-up 时间为 5S），远程执行全部（一共三台）的时候就会有出现大概百分之 10 的报错，均为超时。。想不通是因为啥。。

我们的测试环境只有一台服务机器，而线上是阿里云的部署，我怀疑我们在测试环境做的性能测试是否有说服力证明线上不会存在性能问题。开发对我们的测试结果也不认可。说测试环境只有 2MB 带宽，而线上是 20MB，所以你现在报的这样的问题不会在线上出现，想问问大佬这种情况下如何履行测试的职责？

带宽很重要，20mb 带宽比 2 带宽容纳的请求数量更多，尽量保持压测环境跟线上环境一致

这就难了啊……公司不给这个条件

大佬，公众号可以多讲讲性能这块的。