比较k6和JMeter的负载测试（转）
| 特征 | JMETER | K6 |
|---|---|---|
| 基于 | Java | Go |
| 脚本语言 | 非常有限: Java (Groovy, Beanshell, etc) | Javascript |
| 协议 | 通过插件支持大多数协议（本地支持HTTP/1.1、SOAP、FTP、JDBC、LDAP、MOM与JMS、SMTP、POP3、IMAP、外壳脚本、TCP、Java对象） | 支持较少的现代协议（HTTP/1.1, HTTP/2, WebSockets, gRPC） |
| 外部依赖项 | Java | 无 |
| 资源利用率 | 差劲; 一个负载生成器可以模拟数千个虚拟用户 | 非常好 ; 一个负载生成器可以模拟成千上万的虚拟用户 |
| 内存管理 | 必须设置JVM堆内存 | 本机使用负载生成器内存 |
| 线程模型 | 1个线程1个虚拟用户：性能较慢，资源成本较高 | 一个Goroutine1个虚拟用户：性能较快，资源成本更低 |
| 易于编写脚本 | 基于图形用户界面，带代码块 | 基于代码，VS Code插件 |
| 测试级阈值 | 不支持，仅个人请求 | 支持 |
| 脚本格式 | XML | javascript |
| 易于协作 | 难以同时工作，易于测试员使用，需要GUI应用程序进行编辑 | 易于开发者使用，易于版本； Javascript格式促进协作 |
| 维护 | 详细的脚本，XML格式难以阅读 | 更简洁的脚本； JavaScript易于阅读 |
| 社区 | 自1998年以来，许多第三方教程，广泛的文档，没有中央社区 | 自2017年以来，广泛的文档，更少的第三方教程，有官方社区 |
| 插件支持 | 需要许多功能的插件，有很多可用的插件 | 本机支持大多数功能，可提供插件支持，并且稀疏性 |
| 本机分布式负载生成 | 是 | 否（仅限高级会员） |
| 预先生成的报告 | 默认和自定义HTML报告，通过监听器记录 | 没有内置的预生成报告，通过第三方仪表板与分析工具集成 |
| 网站 | jmeter.apache.org | k6.io |
| 源代码 | JMeter | k6 |
结论
尝试选择负载测试工具时，最好的建议是与最有前途的候选人进行概念验证，在实际测试周期中使用时，某些功能或错误可能或多或少重要，不要把两个不同工具的负载测试结果看得太重，每个工具记录的指标都不同，并且使用同一工具将结果与以前的结果进行比较更有意义，切换工具时，每次都要在新工具中重新建立基线。
以下摘要可以帮助您在JMeter和k6之间进行选择。
两个工具都擅长：
- 通过编写复杂的用户流脚本来在应用程序服务器上生成协议级负载、
- 使用动态思考时间，测试数据生成和可重用或可自定义工作负载模型的逼真的脚本、
- 功能文档和发布的一致性。
两个工具都不支持：
- 生成浏览器级别的负载并与DOM元素进行交互，尤其是对于单页应用程序、
- 详细结果分析（JMeter有预先生成HTML报告和侦听器，但还差得远），用户应该能够将结果与数据库和数据可视化软件集成在一起。
JMeter最适合：
- 传统模式的测试团队、
- 偏爱基于GUI的测试工具的开发者，这些工具具有大量的第三方教程和广泛的协议支持、
- 以前是LoadRunner和NeoLoad等商业工具的用户。
k6最适合：
- 协作和跨职能的工程团队，其中测试涉及多个角色、
- 偏爱简单，轻量但功能齐全的负载测试工具的开发者、
- 希望将测试集成到现有开发工作流和CI/CD管道中的团队。
负载测试脚本工具不是负载测试成功的最重要考虑因素，了解测试的原因，测试要求，理解和传达结果更为重要，使用正确的工具有助于顺利解决这些问题，没有“最佳”工具，只有适合您项目和需求的工具。
原文：https://blog.csdn.net/keny88888/article/details/118727931
