可以敲代码的话，用https://testerhome.com/opensource_projects/avatar吧
jmeter 的不够灵活

分两方面去验证这个问题吧：
1、验证你的业务性能，可以用多台 jmeter 或者其他测试工具去做；
2、验证 jmeter 的压力性能，可以在验证了你的服务能力后，用不同的压力工具去做同类对比，然后再得出结论

你是外网压测的，还是内网压测的？

嗯嗯

不是说服别人，我的意思是，既然您已经 5、6 年没有接触过一线的技术了，其实没必要在具体的问题这里浪费时间。
您这个级别的，可以给更多的方向性指导，相信您对于质量体系和质量管理这块很有建树

从题主的答案和推理逻辑，以及你的 “这个服气” 里面看出来的，并没有了解到问题的本质，不了了之的 “服气”

让我想起来最近面试，碰到的一个研发部门总监，问我 loadrunner 的参数化怎么做的，我还心想问这个干什么，这不是很基本的问题嘛
后来才知道，他的使用经验在 2000 年的时候。

公司面试流程还是很重要的，如果脱离太久，就不要问那种问题了

你碰到的这个问题，具体分析，如果是你服务器端的连接数有限，导致的 QPS 上不去，你就是再多的并发用户，也进不去真正的队列
当你的连接数够大的时候，你的并发用户才能真正的进行排队，然后对你的服务器才有真实的压力

哥，从你回答的 jmeter 和 loadrunner 这两个问题来看，你是不是离开一线时间太长了？？？

从这里来看，你是想测试业务的性能拐点吗？
如果你想测试性能拐点，首先要保证你的压测服务器本身不是瓶颈，确保真的发出了你所设置的线程或者并发

jmeter 这个锅不背

试试这里

做查询业务的，为什么要设置 init、end 和 action 一起循环呢？而且 loadrunner 默认迭代不包括 init 和 end，他只有一个查询业务，也是写在了 action 中

哥，他做的是查询，跟 Vuser 和参数行数有什么关系啊

是场景问题，你的场景设置完持续运行时间后，结束的时候设置为执行完事务结束，而不是直接结束
备注：loadrunner 参数化文件最后一行就是空行，这是 loadrunner 参数化文件结束的标志

这里的请求数误差，指的是测试工具统计的请求数，和实际的请求数之间的误差吗？

哦哦，这个是我们公司内部开发版本，你用你们公司版本，或者用公开版本
Maven 资源地址：http://mvnrepository.com/

文章棒棒哒

嗯嗯，原生的框架其实就那几个，我是想问二次开发或者优秀的开源框架

嗯嗯，理解了，

飞哥，求解，应该用什么驱动啊？

细思极恐

我完全是被东哥的故事吸引了。
不过作为测试，你的文采这么好，你家开发和产品估计压力有点大