最近收到一项任务，就是对比主流开源性能测试框架，我搜了一些，列出来JMeter、k6、Gatling、siege、ngrinder、locust以及FunTester。
下面是一些定性的指标收集结果：
| 工具 | 语言 | 使用方式 | 用例形式 | 分布式 | 易用性 | 拓展性 | 流量编排 | 链路 | 社区 | 可读性 |
|---|---|---|---|---|---|---|---|---|---|---|
| JMeter | Java | Client/命令行 | jmx 文件 | 中 | 优 | 低 | 差 | 差 | 11,800,000 | 差 |
| k6 | JavaScript | 命令行 | JS 脚本 | 否 | 中 | 优 | 中 | 优 | 1,840,000 | 优 |
| Gatling | Scala | 命令行 | Scala 脚本 | 否 | 差 | 优 | 差 | 中 | 333,000 | 优 |
| siege | C | 命令行 | 命令行 | 否 | 优 | 差 | 否 | 否 | 882,000 | 中 |
| ngrinder | Groovy | Web 页面 | Groovy 脚本 | 优 | 优 | 优 | 差 | 差 | 219,000 | 优 |
| locust | Python | 命令行/web | Python 脚本 | 中 | 中 | 优 | 差 | 优 | 930,000 | 优 |
| FunTester | Java&Groovy | 命令行/服务接口 | 参数/脚本 | 是 | 中 | 优 | 优 | 优 | 342,000 | 优 |
由于要做一些性能测试对比，相对比较来说，其中几个性能测试框架并不适合我现在的需求，所以先放弃了几个。下面就是放弃的框架以及放弃的原因。
加特林是一种开源性能测试工具。该工具允许开发人员构建和执行测试，并轻松地在本地或云中管理他们的测试。 要使用 Gatling 编写测试，我们需要使用Scala，Gatling允许用户定义提供类似功能的Scala类，但它们的可读性要高得多。
Gatling执行步骤如下：
- 编写或者录制脚本（
Scala语言脚本）- 编译脚本（运行
sh命令）- 交互模式下选择脚本
- 等待运行结果
shell命令，然后在交互界面肉眼选择所要执行脚本的ID。Scala非主流性质，使用方式上来说不太符合现在的习惯其优秀的录制功能，可以快速生成测试脚本，通过简单配置（修改脚本调用 API）即可完成用例编写。
Siege 是一个压力测试和评测工具，设计用于 WEB 开发这评估应用在压力下的承受能力：可以根据配置对一个 WEB 站点进行多用户的并发访问，记录每个用户所有请求过程的相应时间，并在一定数量的并发访问下重复进行。
这个搜资料时候发现的，用 C 语言编写，使用方式上有点类似 curl 和 ab 测试框架，纯命令行使用方式。
使用简单，对于临时起意做个接口性能测试还是不错的。
Locust 是一个简单易用的分布式用户负载测试工具。它用于 web 站点 (或其他系统) 的负载测试，并计算一个系统可以处理多少并发用户。
shell命令启动不能任意切换用例当然由于对locust的粗线理解，很多地方不太熟悉，特别是量化性能指标这块，在下一期的性能测试框架实测对比当中，我也会测试locust的性能。
nGrinder 是一款在一系列机器上执行 Groovy 或 Jython 测试脚本的应用，内部引擎是基于 Grinder。 nGrinder 使用 controller 和 agent 分别包装了 Grinder 的 console 和 agent ，而且扩展了多种功能使其能够支持并发测试。
不得不说我一开始还是很喜欢这个框架的，无他，就是简单。从一开始部署和构建，以及编写第一个脚本都非常简单。但是：
还是放弃了。当然你可以选择重写项目里的这部分功能，以解决这些缺点，我就是这么做的。
如果你是一个 Java 技术栈的测试工程师，那么除了 JMeter 客户端形式的测试框架意外，nGrinder 是一个非常不错 Web 性能测试框架。如果想脚本、监控、执行一步到位，nGrinder 是不二的选择。