目前在性能测试领域市场jmeter占有率是非常高的，主要原因是相对比其他性能测试工具使用更简单（开源、易扩展），功能更强大（满足多种协议的接口），但是随着研发协同的升级，平台化的性能测试工具更能高效的基于团队开展协作，比如我们今天要说的开源测试平台RunnerGo。
性能测试工具平台化优势
RunnerGo作为web平台能在线做到接口管理，脚本编辑，场景编辑，报告管理这是jmeter这种工具不具备的。
RunnerGo支持实时查看服务器状态、测试报告、debug日志并且支持发送测试报告到指定邮箱，而jmeter默认不支持性能监控，只能是在GUI模式下，通过扩展监听器插件来实现，并且No-GUI模式下只能生成结果报告。
在使用jmeter时接口管理和性能测试一般是分开去做的，或者用其他Api调试工具去做接口管理（比如Apipost）然后再去jmeter中配置脚本，但其实性能测试应该是基于接口管理的基础上做的，RunnerGo可以直接从接口管理中引用调试好的接口，配置好一条场景，然后在此基础上进行持续性测试，自动化测试，这样在接口测试阶段就可以直接执行性能测试。
RunnerGo与jmeter结构分析
jmeter的单机模式在一般的压力机配置下，会受限于jmeter自身的机制和硬件配置，最多可以支持几百至一千左右的模拟请求线程。想部署分布式集群测试会带来非常多的运维管理问题。同时，Master-Slave模式，还会给主节点带来很大的交互压力，部署大规模的分布式集群压测非常难做到。
RunnerGo自带分布式结构轻松支持大规模并发。
对于RunnerGo的真实性能我做了一个小的实验进行对比，结果如下：
一条使用查看新闻的场景：六个接口，使用并发模式，20的并发，执行10分钟。
相同的配置下进行压测
jmeter聚合报告：
RunnerGo直接发送到邮箱的测试报告
由于计算方式不同这里只对比总请求数，汇总下来：
RunnerGo总请求数：98640个，错误率：0
jmeter总请求数：91219个，错误率：0