「性能测试技术笔记系列」之性能测试工具选型

Posted 2023-04-08 程序员威子

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了「性能测试技术笔记系列」之性能测试工具选型相关的知识，希望对你有一定的参考价值。

一、浅谈为什么需要工具

我们来看下工具的定义：它原指工作时所需用的器具，后引申为为达到、完成或促进某一事物的手段。（---来自百度的解释）

1、从人类进化的角度来看，会制造并使用工具是人和猿人最根本的区别，因为工具可以帮助我们提高生产力和效率。

2、想象下如果不使用工具进行性能测试会怎么样？

我们可以从性能测试的定义的角度来分析，性能测试是指通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。如果不使用工具，仅靠人工进行性能测试会存在以下的弊端：

a）测试需要投入大量的资源：

为了模拟多种负载、并发的场景需要多人协同工作，通常测试没有很多的资源，而且就算有资源人工的效果也会大打折扣，甚至于某些场景仅凭人工是无法完成的。

b）可重复性非常差：

性能测试经常需要反复调优和测试执行，如果没有工具的帮助，全靠人工实在不敢想象。

c）测试准确性较差：

由于需要模拟多种负载和并发场景，如果由人工来操作，难免会存在误差，而且相对工具或程序来说这种误差会更大，对测试结果影响也非常大。

d）结果的收集、整理和呈现形式差：

如果没有工具，全凭人工采集数据相对工具来说也会存在较大的误差。

二、性能测试与性能测试工具的关系

1、性能测试从测试阶段来划分属于系统测试，其和具体使用什么工具并没有直接的关系。使用工具只是为了提高性能测试效率和准确性的一种方法和手段。从本质上来看，同做其它事情时使用工具没有什么实质性的区别。

2、性能测试不等于Loadrunner，LR只是性能测试工具其中的一种，而且它也不是万能的，在某些情况下它也并不能派上用场。

3、自动化测试工具与性能测试工具的区别：性能测试工具一般是基于通信协议的（客户器与服务器交换信息所遵守的约定），它可以不关心系统的UI，而自动化使用的是对象识别技术，关注UI界面。自动化无法或很难造成负载，但是通过协议很容易。

三、性能测试工具选型参考：

通常在公司或项目中，我们选择任何工具时都会做一些调研，目的就是为了选择适合公司或项目的工具。那么性能测试工具也不例外，通常可以从以下几个方面进行考虑：

1、成本方面：

a）工具成本：工具通常分为商业闭(shou)源(fei)和非商业开(mian)源(fei)两种，商业工具通常功能比较强大，收费，由于收费所以可提供售后服务，如果出了问题有专业人士帮忙处理。而开源工具通常是免费的，功能有限，维护工具的组织也是自发的，所以如果碰到问题需要自行解决，没有专人提供服务。具体选择商业还是开源的工具，需要根据公司的情况，比如公司规模、愿意承担的成本、项目综合情况等方面考虑。一般来看大公司通常可以承担的起工具的费用，会考虑购买商业工具。而小公司由于资金压力，可能会选择开源的工具。

b）学习成本：使用任何工具都需要进行学习，这样一来就会产生学习成本（比如：时间），因此我们在选择工具时也需要考虑到项目组成员的学习成本。如果有两种工具A和B都能满足项目组测试的需求，如果A工具大部分人都会使用，而B工具只有极少部分人会使用，那么建议优先考虑A工具。通常，对于测试人员最好熟悉一款流程的商业（性能）工具，一款开源免费（性能）工具，还需要熟悉常见的（性能）脚本开发语言等，这是基本要求。

2、支持的协议：

性能测试通常跟协议联系非常紧密，比如B/S的系统通常使用http协议进行客户端和服务器商的信息交换，C/S的系统通常使用socket协议进行信息交换。在选择工具时，需要考虑项目使用的协议。一个测试工具能否满足测试需求，能否达到令人满意的测试结果，是选择测试工具要考虑的最基本的问题。

3、生命力：

现在的性能测试工具非常多，比如LR，jmeter这类较大众的工具网上相关的资料非常多，但一些小众工具可能网上资料比较少。如果在工具使用过程中碰到了比较极手的问题，在录求解决方案或帮助时，大众的的工具相对来说会比较有优势一点，毕竟使用的人越多，资料越多，那么自己碰到的问题也许别人早就碰到并解决了，即时之前没有人碰到过，由于使用研究的人多，通过社区或论坛的帮助相信总会有高手能协助解决的。

4、跨平台：

这一点自不必多说，看看JAVA为什么一直在流行就知道了。

5、二次开发的能力

工具支持二次开发，能够更好地契合测试需求，更方面地统计结果数据，并能很好地与公司现有系统做集成。

四、常见性能测试工具：

性能测试工具，从理论上来讲在性能测试过程中使用到的所有工具都可以称其为性能测试工具，通常分为以下几类：

说明：

服务器端性能测试工具：需要支持产生压力和负载，录制和生成脚本，设置和部署场景，产生并发用户和向系统施加持续的压力。
web前端性能测试工具：需要关于心浏览器等客户端工具对具体需要展现的页面的处理过程。
移动端性能测试工具：同web端性能测试工具也需要关心页面的处理过程，另外还要具体数据采集的功能，比如：手机CPU、内存、电量，启动时间等数据的记录。
资源监控工具：这个主要是能够收集性能测试过程中的数据以及良好的结果展现方式。

PS：本篇文章主要总结下服务器端性能测试工具LR和Jmeter、kylinTOP，后面也会对这三个工具进行简单的对分。

五、常见性能测试工具特点

JMeter：采用的是多线程模型，扩展性很强，不过制造压力没有那么高。它很适合用来压一些Tomcat服务，或者一些后端接口。JMeter的缺点是压力值不能精确控制，难以适应高并发的情况，而且由于是JAVA编写的，本身比较消耗资源。
LoadRunner：更像是一个模拟器，它比较适用于前端构造较复杂场景的情况，比如模拟100个用户登录的场景，LoadRunner对非技术人员提供了很好的支持。LoadRunner不适用后端接口。
kylinTOP：是一款国产的集性能测试、自动化测试（UI、接口、APP）、业务&接口监控于一体的测试平台，支持跨平台（WINDOWS/LINUX/SOLARIS/麒麟/MAC等）运行。

下面为JMeter和LoadRunner、kylinTOP对比表：

描述	JMeter	LoadRunner	kylinTOP
架构原理	通过中间代理，监控和收集并发客户端的指令，把他们生成脚本，再发送的应用服务器，再监控应用服务器反馈的过程	同JMeter	BS架构，企业级平台，支持多人同时操作；支持项目管理、模块管理、用户管理、脚本用例管理、参数文件管理；支持多次运行报告历史对比、单个接口多次运行历史对比
安装	简单，解压即可，比较灵活	LoadRunner安装包比较大，安装比较麻烦，工具本身相对比较笨重	一路傻瓜式安装，记住安装目录位置
支持的协议	支持多种协议：HTTP、HTTPS、SOAP、FTP、Database via JDBC、JMS等，但相对LR还是不够全面，由于此原因相对来说jemter比较灵活，轻便	支持的协议非常多，比较全面，但正因此显得工具本身比较笨重，不够灵活	支持多种协议，支持HTTP/HTTP2、RTSP、RTMP、Socket、JAVA自定义等
脚本录制	提供了一个利用本地ProxyServer（代理服务器）来录制生成测试脚本的功能，也支持badboy录制再生成JMeter脚本	自带录制功能强大，可直接录制回放	支持浏览器代理录制、抓包文件录制
并发模型	通过增加线程组的数目，或者是设置循环次数来增加并发用户	支持多种并发模型，通过在场景中选择要设置什么样的场景，然后选择虚拟用户数	强大且灵活的并发模型，包括用户数/秒、CAPS/秒、目标模型，详细请点击链接
分布式测试	支持，可设置多台代理，通过远程控制实现多台机器并发压力	同JMeter	支持控制多个压测机实现分布式并发测试
资源监控	通过JMeterPlugins插件和ServerAgent实现	自带资源监控功能	提供Monitor代理器，支持CPU、内存、I/O、交换区、磁盘读写数、吞吐量等资源指标
报告分析	通过与Ant集成，生成html报告	自身支持生成HTML、Word报告	支持合并指标曲线、曲线过滤、曲线放大缩小、比较不同测试结果、日志分析，生成HTML报告
虚拟IP	不支持	支持	支持系统虚拟IP与工具虚拟IP（支持更多IP占用资源更低）
网速模拟	不支持	支持	支持限制每个用户上传/下载带宽
扩展性	开源，可根据需求修改源码	通过扩展函数库实现	支持JAVA语言扩展，解决私有算法或业务处理，如加解密，javascript计算
学习成本	主要是自学官网上的资料	网上资料和相关培训很多，购买正版的话，还有技术支持	部分功能付费的，大家判断是否可用，可以去看看价格

六、总结：

商用性能工具在易用性（脚本生成）、并发模型、统计指标上要比开源免费软件要好很多，可以大大提高工作效率，降低使用难度，在统计指标上要丰富的多。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取

性能测试总结--工具选型篇

　　本篇文章主要简单总结下性能测试工具的原理以及如何选型。性能测试和功能测试不同，性能测试的执行是基本功能的重复和并发，需要模拟多用户，在性能测试执行时需要监控指标参数，同时性能测试的结果不是那么显而易见，需要对数据进行分析。这些特点决定了性能测试更适合通过工具来完成。

一、浅谈为什么需要工具

我们来看下工具的定义：它原指工作时所需用的器具，后引申为为达到、完成或促进某一事物的手段。（---来自百度的解释）

1、从人类进化的角度来看，会制造并使用工具是人和猿人最根本的区别，因为工具可以帮助我们提高生产力和效率。

2、想象下如果不使用工具进行性能测试会怎么样？

a）测试需要投入大量的资源：

b）可重复性非常差：

　　性能测试经常需要反复调优和测试执行，如果没有工具的帮助，全靠人工实在不敢想象。

c）测试准确性较差：

　　由于需要模拟多种负载和并发场景，如果由人工来操作，难免会存在误差，而且相对工具或程序来说这种误差会更大，对测试结果影响也非常大。

d）结果的收集、整理和呈现形式差：

　　如果没有工具，全凭人工采集数据相对工具来说也会存在较大的误差。

二、性能测试与性能测试工具的关系

2、性能测试不等于Loadrunner，LR只是性能测试工具其中的一种，而且它也不是万能的，在某些情况下它也并不能派上用场。推荐看下《让LoadRunner走下神坛》和《让LoadRunner再次走下神坛》这两篇文章于对性能测试和LR的关系讲的比较深刻。

三、性能测试工具选型参考：

1、成本方面：

2、支持的协议：

3、生命力：

4、跨平台：

　　这一点自不必多说，看看JAVA为什么一直这流行就知道了。

四、常见性能测试工具：

性能测试工具，从理论上来讲在性能测试过程中使用到的所有工具都可以称其为性能测试工具，通常分为以下几类：

说明：

服务器端性能测试工具：需要支持产生压力和负载，录制和生成脚本，设置和部署场景，产生并发用户和向系统施加持续的压力。
web前端性能测试工具：需要关于心浏览器等客户端工具对具体需要展现的页面的处理过程。
移动端性能测试工具：同web端性能测试工具也需要关心页面的处理过程，另外还要具体数据采集的功能，比如：手机CPU、内存、电量，启动时间等数据的记录。
资源监控工具：这个主要是能够收集性能测试过程中的数据以及良好的结果展现方式。

PS：本篇文章主要总结下服务器端性能测试工具LR和Jmeter，后面也会对这两个工具进行简单的对分。

五、常见性能测试工具特点

JMeter：采用的是多线程模型，扩展性很强，不过制造压力没有那么高。它很适合用来压一些Tomcat服务，或者一些后端接口。JMeter的缺点是压力值不能精确控制，难以适应高并发的情况，而且由于是JAVA编写的，本身比较消耗资源。
LoadRunner：更像是一个模拟器，它比较适用于前端构造较复杂场景的情况，比如模拟100个用户登录的场景，LoadRunner对非技术人员提供了很好的支持。LoadRunner不适用后端接口。

下表为JMeter和LoadRunner对比表：

描述	JMeter	LoadRunner
架构原理	通过中间代理，监控和收集并发客户端的指令，把他们生成脚本，再发送的应用服务器，再监控应用服务器反馈的过程	同JMeter
安装	简单，解压即可，比较灵活	LoadRunner安装包比较大，安装比较麻烦，工具本身相对比较笨重
支持的协议	支持多种协议：HTTP、HTTPS、SOAP、FTP、Database via JDBC、JMS等，但相对LR还是不够全面，由于此原因相对来说jemter比较灵活，轻便	支持的协议非常多，比较全面，但正因此显得工具本身比较笨重，不够灵活
脚本录制	提供了一个利用本地ProxyServer（代理服务器）来录制生成测试脚本的功能，也支持badboy录制再生成JMeter脚本	自带录制功能强大，可直接录制回放
并发模型	通过增加线程组的数目，或者是设置循环次数来增加并发用户	支持多种并发模型，通过在场景中选择要设置什么样的场景，然后选择虚拟用户数
分布式测试	支持，可设置多台代理，通过远程控制实现多台机器并发压力	同JMeter
资源监控	通过JMeterPlugins插件和ServerAgent实现	自带资源监控功能
报告分析	通过与Ant集成，生成HTML报告	自身支持生成HTML、Word报告
虚拟IP	不支持	支持
网速模拟	不支持	支持
扩展性	开源，可根据需求修改源码	通过扩展函数库实现
学习成本	主要是自学官网上的资料	网上资料和相关培训很多，购买正版的话，还有技术支持