目录
普遍存在的问题
工具选型和推荐
软件测试而非测试工具
总结:
普遍存在的问题
聊压测工具之前,先聊一下我面试候选人时问的问题以及在技术交流群经常遇到的一个情况。
面试候选人特别是性能测试岗位,我一般很少问测试工具的问题,大多问的是测试策略,针对特定场景如何设计压测方案以及如何定位排查性能瓶颈如何优化方面的问题。
但大多数候选人的第一反应是用什么工具,第一步怎么操作第二步怎么操作,如果你问这个工具的原理和特性,又回答的支支吾吾。
还有在一些技术交流群,很多同学会说自己遇到的问题,如不知道怎么用jmeter参数化,locust的压测结果图表怎么看,怎么写gatling的压测脚本等等。
并不是说觉得用工具low,而是遇到问题,我个人觉得首先应该分析问题,找到解决方法和策略,然后寻找合适的工具来辅助自己快速解决问题。
工具选型和推荐
聊完了对工具的认知后,接着聊聊如何选择合适的压测工具吧,这一段更适合性能测试新手或者小白,大佬请无视。
当然,我理解让新手掌握学习枯燥无味的概念和方法论有点强人所难,并不是所有人都有时间和耐心去学习这些知识的。
废话不多说,挑选了几个适合不同场景和不同阶段测试同学可以直接上手的工具,下面内容供参考:
工具名称 | 特性和脚本开发 | 适用场景 | 不足(对于新手) |
Wrk | 特性:体积小、安装便捷、纯命令行 脚本开发:脚本参考官方文档的demo | 适用于新服务研发自测或粗略的性能评估 | 不适合日常压测 |
Locust | 特性:体积小、安装便捷、可视化界面配置 脚本开发:简单脚本参考官方文档的demo或其他教程即可开始压测(需要写代码) | 满足日常压测和小团队使用 | 二次开发成本高 |
Jmeter | 特性:体积小、安装便捷、支持拖拽、扩展组件多、可视化界面配置 脚本开发:简单脚本参考官方文档的demo或其他教程即可开始压测(大部分场景无需写代码) | 满足团队和企业级日常压测所需 | 企业级使用需要二次开发和包装 |
Gatling | 特性:体积小、安装便捷、多协议支持、扩展性较好 脚本开发:简单脚本参考官方文档的demo或其他教程即可开始压测(需要写代码) | 满足团队和企业级日常压测所需 | 企业级使用需要二次开发和包装 |
Loadrunner | 特性:体积巨大、安装繁琐、功能齐全、可视化界面配置 脚本开发:简单脚本参考官方文档的demo或其他教程即可开始压测(大部分场景无需写代码) | 满足团队和企业级日常压测所需 | 企业级使用要钱 |
软件测试而非测试工具
很多同学把压测工具当作了性能测试核心,忽略了需求分析、测试策略、定位问题和优化方面,这样其实有点舍本逐末。
软件测试只是整个交付环节里面的一部分,而软件研发交付本身是依赖于软件工程的方法论指导而实践出来的。
因此,我还是建议一些学性能测试或者做性能测试的同学,需求分析很重要,测试策略很重要,定位问题并找到合适的优化方案很重要,工具并没有那么重要。
工具只是在有解决方案的前提下,帮助你提高解决问题效率的辅助而已。
毕竟,做软件测试工作的是人,而非工具。人具有主观能动性和创造力,工具仅仅是辅助工具。
质量保障需要人去保障,工具只是辅助的提效工具。
总结:
感谢每一个认真阅读我文章的人!!!
我个人整理了我这几年软件测试生涯整理的一些技术资料,包含:电子书,简历模块,各种工作模板,面试宝典,自学项目等。欢迎大家评论区留言333或私信我