测试在牛逼你也是测试。

有啥好争论的啊，闲的蛋疼。

这个下掉了，没啥人关注，感觉其实也没做好，回头打磨打磨再拿出来吧。

感觉远远超出了测试的范畴。
有些东西可能连开发运维都不是那么懂。

技术含量过高！！！

还让开发活吗？

支持支持。

你有老婆，至少证明你比中国另外的 3000W 过的好！！！

开源工具来刚有个新的 mock 工具 DOO ，你可以看下。

代码写习惯了觉得代码才是最灵活的，如果这种框架不是自己开发的，往往遇到问题不知道如何解决很费时间。
当然，如果自己有能力，我觉得可以参考这种思想，自己弄一个出来自己用。

顶一下，可能以后会用到

支持下，我也是做了 4 年的性能测试。

不过我写不来这么多东西。

楼主写的还是不错，代码也比较容易看懂，可以拿过去自己再进行二次开发。
另外，我觉得既然压测的核心已经交给了 jmeter，二次开发还是聚焦在数据展示上面比较好，如果能够实现 loadrunner 那种实时数据、监控资源展示，还有报表分析的能力那就牛逼了。

规避是不可能规避的。
总结原因 无非是找背锅的，测试、开发、运维、DBA？

建议使用 jmeter，脚本可以手工开发，在 IDE 上调试通过了在转到 jmeter 上。

游戏设置里有 bug 提交反馈，这里人家收不到的

牛逼牛逼！！

不会一个小知识点就发一贴吧

感谢，公司内部交流的公众号。
会注明出处的。

可以转载吗，大佬？

国内的禅道用的比较多，又是开源的，比较好改造。
QC 之前用过，觉得太笨重了。
你也可以尝试下 TestCenter

其他的软件只听说过，没深入使用过，不好评价。

先看下各个机器的资源又没到到瓶颈，一般的 CPU、内存、磁盘 IO、带宽。
这些没问题，再看压测机和被测机上的 TCP 端口是否已经满了，最后看代码层面，比如 java 的看下 jvm,还有就是数据库的连接数限制。