性能测试框架对比初探

最近收到一项任务，就是对比主流开源性能测试框架，我搜了一些，列出来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是不二的选择。