6.3. 性能测试工具选型
6.3.1. 浅谈为什么需要工具
我们来看下工具的定义：它原指工作时所需用的器具，后引申为为达到、完成或促进某一事物的手段。
1、从人类进化的角度来看，会制造并使用工具是人和猿人最根本的区别，因为工具可以帮助我们提高生产力和效率。
2、想象下如果不使用工具进行性能测试会怎么样？
我们可以从性能测试的定义的角度来分析，性能测试是指通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。如果不使用工具，仅靠人工进行性能测试会存在以下的弊端：
a）测试需要投入大量的资源：
为了模拟多种负载、并发的场景需要多人协同工作，通常测试没有很多的资源，而且就算有资源人工的效果也会大打折扣，甚至于某些场景仅凭人工是无法完成的。
b）可重复性非常差：
性能测试经常需要反复调优和测试执行，如果没有工具的帮助，全靠人工实在不敢想象。
c）测试准确性较差：
由于需要模拟多种负载和并发场景，如果由人工来操作，难免会存在误差，而且相对工具或程序来说这种误差会更大，对测试结果影响也非常大。
d）结果的收集、整理和呈现形式差：
如果没有工具，全凭人工采集数据相对工具来说也会存在较大的误差。
6.3.2. 性能测试与性能测试工具的关系
1、性能测试从测试阶段来划分属于系统测试，其和具体使用什么工具并没有直接的关系。使用工具只是为了提高性能测试效率和准确性的一种方法和手段。从本质上来看，同做其它事情时使用工具没有什么实质性的区别。
2、性能测试不等于Loadrunner，LR只是性能测试工具其中的一种，而且它也不是万能的，在某些情况下它也并不能派上用场。推荐看下《让LoadRunner走下神坛》和《让LoadRunner再次走下神坛》这两篇文章于对性能测试和LR的关系讲的比较深刻。
3、自动化测试工具与性能测试工具的区别：性能测试工具一般是基于通信协议的（客户器与服务器交换信息所遵守的约定），它可以不关心系统的UI，而自动化使用的是对象识别技术，关注UI界面。自动化无法或很难造成负载，但是通过协议很容易。
6.3.3. 性能测试工具选型参考：
通常在公司或项目中，我们选择任何工具时都会做一些调研，目的就是为了选择适合公司或项目的工具。那么性能测试工具也不例外，通常可以从以下几个方面进行考虑：
1、成本方面：
a）工具成本：工具通常分为商业闭(shou)源(fei)和非商业开(mian)源(fei)两种，商业工具通常功能比较强大，收费，由于收费所以可提供售后服务，如果出了问题有专业人士帮忙处理。而开源工具通常是免费的，功能有限，维护工具的组织也是自发的，所以如果碰到问题需要自行解决，没有专人提供服务。具体选择商业还是开源的工具，需要根据公司的情况，比如公司规模、愿意承担的成本、项目综合情况等方面考虑。一般来看大公司通常可以承担的起工具的费用，会考虑购买商业工具。而小公司由于资金压力，可能会选择开源的工具。
b）学习成本：使用任何工具都需要进行学习，这样一来就会产生学习成本（比如：时间），因此我们在选择工具时也需要考虑到项目组成员的学习成本。如果有两种工具A和B都能满足项目组测试的需求，如果A工具大部分人都会使用，而B工具只有极少部分人会使用，那么建议优先考虑A工具。通常，对于测试人员最好熟悉一款流程的商业（性能）工具，一款开源免费（性能）工具，还需要熟悉常见的（性能）脚本开发语言等，这是基本要求。
2、支持的协议：
性能测试通常跟协议联系非常紧密，比如B/S的系统通常使用http协议进行客户端和服务器商的信息交换，C/S的系统通常使用socket协议进行信息交换。在选择工具时，需要考虑项目使用的协议。一个测试工具能否满足测试需求，能否达到令人满意的测试结果，是选择测试工具要考虑的最基本的问题。
3、生命力：
现在的性能测试工具非常多，比如LR，jmeter这类较大众的工具网上相关的资料非常多，但一些小众工具可能网上资料比较少。如果在工具使用过程中碰到了比较极手的问题，在录求解决方案或帮助时，大众的的工具相对来说会比较有优势一点，毕竟使用的人越多，资料越多，那么自己碰到的问题也许别人早就碰到并解决了，即时之前没有人碰到过，由于使用研究的人多，通过社区或论坛的帮助相信总会有高手能协助解决的。
4、跨平台：
这一点自不必多说，看看JAVA为什么一直这流行就知道了。
6.3.4. 常见性能测试工具
性能测试工具，从理论上来讲在性能测试过程中使用到的所有工具都可以称其为性能测试工具，通常分为以下几类：
说明：
服务器端性能测试工具：需要支持产生压力和负载，录制和生成脚本，设置和部署场景，产生并发用户和向系统施加持续的压力。
web前端性能测试工具：需要关于心浏览器等客户端工具对具体需要展现的页面的处理过程。
移动端性能测试工具：同web端性能测试工具也需要关心页面的处理过程，另外还要具体数据采集的功能，比如：手机CPU、内存、电量，启动时间等数据的记录。
资源监控工具：这个主要是能够收集性能测试过程中的数据以及良好的结果展现方式。
PS：本篇文章主要总结下服务器端性能测试工具LR和Jmeter，后面也会对这两个工具进行简单的对分。
6.3.5. 常见性能测试工具特点
常见性能测试工具特点
JMeter：采用的是多线程模型，扩展性很强，不过制造压力没有那么高。它很适合用来压一些Tomcat服务，或者一些后端接口。JMeter的缺点是压力值不能精确控制，难以适应高并发的情况，而且由于是JAVA编写的，本身比较消耗资源。
LoadRunner：更像是一个模拟器，它比较适用于前端构造较复杂场景的情况，比如模拟100个用户登录的场景，LoadRunner对非技术人员提供了很好的支持。LoadRunner不适用后端接口。
下表为JMeter和LoadRunner对比表：
描述 |
JMeter |
|---|---|
架构原理 |
通过中间代理，监控和收集并发客户端的指令，把他们生成脚本，再发送的应用服务器，再监控应用服务器反馈的过程 |
安装 |
简单，解压即可，比较灵活 |
支持的协议 |
支持多种协议：HTTP、HTTPS、SOAP、FTP、Database via JDBC、JMS等，但相对LR还是不够全面，由于此原因相对来说jemter比较灵活，轻便 |
脚本录制 |
提供了一个利用本地ProxyServer（代理服务器）来录制生成测试脚本的功能，也支持badboy录制再生成JMeter脚本 |
并发模型 |
通过增加线程组的数目，或者是设置循环次数来增加并发用户 |
分布式测试 |
支持，可设置多台代理，通过远程控制实现多台机器并发压力 |
资源监控 |
通过JMeterPlugins插件和ServerAgent实现 |
报告分析 |
通过与Ant集成，生成HTML报告 |
虚拟IP |
不支持 |
网速模拟 |
不支持 |
扩展性 |
开源，可根据需求修改源码 |
学习成本 |
主要是自学官网上的资料,git上有源码 |
描述 |
LoadRunner |
|---|---|
架构原理 |
同JMeter |
安装 |
LoadRunner安装包比较大，安装比较麻烦，工具本身相对比较笨重 |
支持的协议 |
支持的协议非常多，比较全面，但正因此显得工具本身比较笨重，不够灵活 |
脚本录制 |
自带录制功能强大，可直接录制回放 |
并发模型 |
支持多种并发模型，通过在场景中选择要设置什么样的场景，然后选择虚拟用户数 |
分布式测试 |
同JMeter |
资源监控 |
自带资源监控功能 |
报告分析 |
自身支持生成HTML、Word报告 |
虚拟IP |
支持 |
网速模拟 |
支持 |
扩展性 |
通过扩展函数库实现 |
学习成本 |
网上资料和相关培训很多，购买正版的话，还有技术支持 |