最近收到一项任务，就是对比主流开源性能测试框架，我搜了一些，列出来JMeter、k6、Gatling、siege、ngrinder、locust以及FunTester。

下面是一些定性的指标收集结果：

由于要做一些性能测试对比，相对比较来说，其中几个性能测试框架并不适合我现在的需求，所以先放弃了几个。下面就是放弃的框架以及放弃的原因。

Gatling（加特林）

简介

加特林是一种开源性能测试工具。该工具允许开发人员构建和执行测试，并轻松地在本地或云中管理他们的测试。 要使用 Gatling 编写测试，我们需要使用Scala，Gatling允许用户定义提供类似功能的Scala类，但它们的可读性要高得多。

放弃原因

Gatling执行步骤如下：

• 编写或者录制脚本（Scala语言脚本）
• 编译脚本（运行sh命令）
• 交互模式下选择脚本
• 等待运行结果

1. 首先这个过程非常不容易自动化，特别是在手动执行shell命令，然后在交互界面肉眼选择所要执行脚本的ID。
2. 语言Scala非主流性质，使用方式上来说不太符合现在的习惯
3. 定制化测试用例比较困难，包括结果验证和串联测试

夸两句

其优秀的录制功能，可以快速生成测试脚本，通过简单配置（修改脚本调用 API）即可完成用例编写。

siege

简介

Siege 是一个压力测试和评测工具，设计用于 WEB 开发这评估应用在压力下的承受能力：可以根据配置对一个 WEB 站点进行多用户的并发访问，记录每个用户所有请求过程的相应时间，并在一定数量的并发访问下重复进行。

这个搜资料时候发现的，用 C 语言编写，使用方式上有点类似 curl 和 ab 测试框架，纯命令行使用方式。

放弃原因

1. 纯命令行使用方式实在让人无法喜欢起来
2. 测试报告也是命令行输出，缺少记录和汇总功能
3. 貌似不更新了

夸两句

使用简单，对于临时起意做个接口性能测试还是不错的。

locust

简介

Locust 是一个简单易用的分布式用户负载测试工具。它用于 web 站点 (或其他系统) 的负载测试，并计算一个系统可以处理多少并发用户。

放弃原因

1. 技术栈是 Java，Python 相对不熟
2. 每次需要shell命令启动不能任意切换用例
3. 分布式方案不给力，缺少同步和协调功能

夸两句

1. 用例简单，可读性高
2. 脚本形式用例，拓展性强
3. 功能强大，且使用上明显优于 JMeter

当然由于对locust的粗线理解，很多地方不太熟悉，特别是量化性能指标这块，在下一期的性能测试框架实测对比当中，我也会测试locust的性能。

nGrinder

简介

nGrinder 是一款在一系列机器上执行 Groovy 或 Jython 测试脚本的应用，内部引擎是基于 Grinder。 nGrinder 使用 controller 和 agent 分别包装了 Grinder 的 console 和 agent ，而且扩展了多种功能使其能够支持并发测试。

放弃原因

不得不说我一开始还是很喜欢这个框架的，无他，就是简单。从一开始部署和构建，以及编写第一个脚本都非常简单。但是：

1. 纯 Web 操作界面
2. 执行和结果难以拓展

还是放弃了。当然你可以选择重写项目里的这部分功能，以解决这些缺点，我就是这么做的。

夸两句

如果你是一个 Java 技术栈的测试工程师，那么除了 JMeter 客户端形式的测试框架意外，nGrinder 是一个非常不错 Web 性能测试框架。如果想脚本、监控、执行一步到位，nGrinder 是不二的选择。

FunTester，腾讯云年度作者、Boss 直聘签约作者，GDevOps 官方合作媒体，非著名测试开发，欢迎关注。

• FunTester 测试框架架构图初探
• 性能测试软启动初探
• 如何成为全栈自动化工程师
• FunTester moco server 框架架构图
• 分布式性能测试框架用例方案设想（一）
• 分布式性能测试框架用例方案设想（二）
• Appium 2.0 速览
• 链路压测中的支路问题初探
• 敏捷测试二三事
• 自动化测试框架的完整指南【译】
• moco 框架接口命中率统计实践
• 分布式性能测试框架单节点内测