服务端性能测试
原文见：在路上的博客此文主要为科普文章，通过性能测试中常用的功能，来熟悉Jmeter和一些性能测试常识。想更多了解服务端性能知识的，可以阅读：服务端性能测试-入门指南(慎入:6000字长文)
俗话说的好：不依赖工具，但要重视工具。压测工具是压测理论的产物，学习好工具，可以帮助更加理解性能测试的基础知识。
性能测试，简而言之，就是模拟大量用户同时访问，测试服务是否满足性能要求。
1、选择合适的工具选择工具之前，首先了解一下，我们平常做性能测试，对性能工具的需求有哪些：
经常测试的对象：Http(s)协议、WebSocket(网络通信协议)、TCP/IP(测试Mysql、Redis)扩展性好：支持分布式部署使用成本低：文档多、支持UI界面操作、插件全下面，我们从工具功能和性能两个角度，来横向对比。
性能测试工具功能对比：
性能测试工具性能对比：
综上，考虑到免费、开源、支持多协议、分布式扩展、脚本开发方式、平台支持和性能表现，选择Jmeter作为我们主要的性能测试工具。
2、了解Jmeter（1）安装Jdk安装Jmeter.zip下载解压后，运行Jmeter.bat或Jmeter.sh即可启动后界面：
这里的线程组，可以理解为一个用户模型。
（2）线程组线程组可以理解为用户模型。
线程组控制面板包括：
线程组名称线程数（正在测试的用户数）加速(Ramp-up)时间：从0增加到线程数的时间循环计数：循环测试的次数调度器：持续时间：表示脚本持续运行的时间，以秒为单位，比如如果你要让用户持续不断登录1个小时，你可以在文本框中填写3600。这样就会在1小时内循环执行。启动延迟：表示脚本延迟启动的时间，在点击启动后，如果启动时间已经到达，但是还没有到启动延迟的时间，那么，启动延迟将会覆盖启动时间，等到启动延迟的时间到达后，再运行系统。（3）测试Http服务下面以开发一个Http脚本为例，来熟悉性能测试中常用的功能和插件。
A.http脚本开发如图中所示，界面中一目了然，协议、域名、Method、Url、参数分别填到对应位置即可。
如果请求需要header，可以添加Http信息头管理器，添加header信息。
B.参数化总所周知，性能测试接口必须进行参数化，如果是固定数据，可能导致所有请求全部访问了缓存，这样就无法评估服务真实性能。
Jmeter参数化有3种常用方法：用户自定义变量、csv数据文件设置、BeanShell预处理变量。
用户自定义变量可以设置一些常量变量。
csv数据文件设置可设置参数化数量较多常量。
BeanShell预处理变量当有些变量需要加解密处理时，就需要BeanShell预处理。
注意：Jmeter通过vars.put(“变量名”,“变量值”)来声明Jmeter变量。
importorg.apache.commons.net.util.Base64;//base64加密Stringsource="哈利波特";byte[]encodedBytes=Base64.encodeBase64(source.getBytes("UTF-8"));Stringencoded=newString(encodedBytes);vars.put("b64",encoded);C.断言断言是用于检查Http请求Response是否满足预期的手段。
Jmeter常用的断言方法有3种：响应断言、Json断言、Beanshell断言。
响应断言如图所示，可以直接判断Responsebody中是否包含期望字符串，方式有包含、匹配、相等…
JSON断言当ResponseBody为Json格式时，可以通过Json断言插件，精确断言响应内容。
BeanShell断言参考：JMeter中使用BeanShell断言详解
BeanShell是jmeter的解释型脚本语言，和java语法大同小异，并有自己的内置对象和方法可供使用。
vars:操作jmeter的变量：vars.get(StringparmStr)获取jmeter的变量值；vars.put(Stringkey,Stringvalue)把数据存到Jmeter变量中；
prev:获取sample返回的信息，prev.getResponseDataAsString()获取响应信息；prev.getResponseCode()获取响应状态码；
importorg.json.*;Stringresponse=prev.getResponseDataAsString();//获取响应数据JSONObjectresponseJson=newJSONObject(response);//转为JSON对象//从Json中提取值Integercode=responseJson.getInt("code");Stringresult=responseJson.getString("result");log.info("====================================");log.info("响应code字段："+code);log.info("响应result字段："+result);log.info("====================================");intexceptCode=200;//判断并断言if(code==exceptCode){Failure=false;}else{Failure=true;FailureMessage="响应code字段:期望值："+exceptCode+"，实际值:"+code;}##（4）测试Mysql
参考：JMeter进行MySQL接口性能测试实战：数据库服务器测试
配置mysql连接（JDBCConnectionConfiguration）需要设置一些重要的字段，这些字段将决定数据库和JMeter之间的正确连接。这些字段包括：
上半部分：
ariablesNameforcreatedpool：变量名，在JDBCRequest的时候会用同样的名字确定是连接的那个库和进行的配置MaxNumberofConnection：数据库最大链接数，通常该值设置为0Maxwait：最大的等待时间ms毫秒，超出后会抛一个错误TimeBetweenEvictionRuns(ms)：数据库空闲连接的回收时间间隔AutoCommit：自动提交。有三个选项，true、false、编辑，选择true后，每条sql语句就是一个事务，执行结束后会自动提交；false、编辑则不会提交，需要自己手动提交TransactionIsolation：数据库事务隔离的级别设置TRANSACTION_NONE：不支持的事务TRANSACTION_READ_UNCOMMITTED：事务读取未提交内容TRANSACTION_READ_COMMITTED：事务读取已提交读内容TRANSACTION_SERIALIZABLE：事务序列化（一个事务读时，其他事务只能读，不能写）DEFAULT：默认TRANSACTION_REPEATABLE_READ：事务重复读（一个事务修改数据对另一个事务不会造成影响）下半部分：
绑定到池的变量名称-它唯一地标识配置。JDBCSampler将进一步使用此名称来标识要使用的配置。这里将其命名为test。数据库URL：jdbc:mysql://127.0.0.1:3306/AutoTest?useSSL=trueJDBC驱动程序类-com.mysql.jdbc.Driver。用户名-root。密码-root用户的密码。其他字段保持不变。JDBCRequest可直接输入SQL：
检查Sql语言执行结果：
（5）事务定义将多个接口定义为事务，以便从业务的角度，来评估性能。
比如，完整的手机验证码登录流程，一般包含：（1）获取手机验证码；（2）用手机号和验证码进行登录；
当定义为登录事务时，性能测试的时候，我们就可以更宏观的关注服务端对登录事务的性能评估，而不是只关注到接口层。
（6）逻辑控制器当面对复杂业务时，比如涉及到逻辑判断的，就需要添加逻辑控制器。
比如，if控制器：
参考：Jmeter中if控制器的使用
利用接口1的返回信息，进行逻辑判断，决定是否执行接口2。比如根据用户状态信息，判断用户是否是VIP用户，如果不是，则不能购买某商品。
（7）调试插件查看结果树调试脚本时，可以利用查看结果树插件来查看request和response信息，保障脚本的正确。
Jmeter执行Log一般是编写BeanShell或引入jar包时，脚本调试需要看log，定位脚本开发的问题。
（8）关注的性能指标QPS(TPS)：每秒请求数成功率：请求成功率95%响应时间和99%响应时间：更真实表现大部分用户承受的响应时间。响应时间和QPS变化曲线：主要看性能测试期间，服务是否稳定。比如Java后端，在性能测试期间，不允许出现FullGC。3、Jmeter优化建议参考：Jmeter性能调优建议
（1）调整JMeter堆栈内存大小在默认情况下现在JMeter5版本开辟的内存空间为1G，这也是它的最大内存。在实际测试的过程中，默认JMeter内存配置情况下，开启3W个线程来处理http的静态访问求基本上就达到了极限。再往上加的可能会报OOM的错误。
有两个JAVA的参数直接影响着JMeter能够使用的系统内存为多少，一个是“Xms”（代表初始化堆栈内存的大小），一个是“Xmx（代表最大内存池可以分配的大小）”。如果你的测试机器只跑JMeter一个JAVA应用程序，那么建议Xmx和Xms保持一致。Xmx和Xms保持一致是为了减少JVM内存伸缩，减少维护伸缩带来的成本。
（2）64位操作系统内存配置大小JMeter内存分配尽量在32位的系统上避免分配4G以上空间，在64位的操作系统尽量避免分配32G以上的空间。
（3）垃圾回收机制参考：【JVM】hotSpotVM7种垃圾收集器：主要特点应用场景设置参数基本运行原理
在JAVA中有大概五类的垃圾回收机制。分为Serial收集器，ParNew收集器，Parallel收集器，Cms收集器，G1收集器。在垃圾回收机制上应该尽量减少垃圾回收器带来的内存和CPU的性能损耗。当然这些并不会对开启线程数有着决定性的影响，属于细节性的微调。这里比较推荐使用G1垃圾回收器。G1垃圾回收器的特点如下：
支持很大的堆，高吞吐量支持多CPU垃圾回收在主线程暂停时，使用并行回收在主线程运行时，使用并发回收。（4）使用非GUI模式GUI在一定程度上冻结并消耗资源，这样会更容易产生一些不准确的性能测试结果。对于JMeter来说GUI存在的意义主要在于可视化输出结果，编写你的测试计划和debug你的测试计划。
jmeter命令执行：
jmeter-n-t/usr/local/apache-jmeter-4.0/my_threads/sfwl.jmx参数说明：
-h帮助->打印出有用的信息并退出
-n非GUI模式->在非GUI模式下运行JMeter
-t测试文件->要运行的JMeter测试脚本文件
-l日志文件->记录结果的文件
-r远程执行->启动远程服务
-H代理主机->设置JMeter使用的代理主机
-P代理端口->设置JMeter使用的代理主机的端口号
**注意：**如果未设置Jmeter的环境变量则在执行脚本的时候需要检查当前目录是否是jmeter的bin目录下
（5）升级JMeter与JAVA版本尽可能使用最新版本的JMeter来进行性能测试，新版本的JMeter会使用新版的JRE和JDK，这样会一定程度上带来性能的提升。
（6）压测过程中禁用监听器实行压测的过程中尽可能少使用监听器，最好别用。启用监听器会导致额外的内存开销，这会消耗测试中为数不多的内存资源。比较明智的做法是使用非GUI模式，将测试结果全部保存到“.jtl”的文件中。测试完成之后将jtl格式的结果文件导入的JMeter中再进行结果分析。
（7）谨慎使用断言添加到测试计划的每个测试元素都将被处理。这样会占用较多的CPU和内存。这种资源的占用适用于所有的断言，尤其是比较断言。比较断言消耗大量资源和内存，所以在压力测试时慎重的使用断言和断言的数量。
（8）利用分布式参考：压测必经之路，解读JMeter分布式
分布式部署Jmeter，利用压力机集群进行压测，提升Jmeter的测试能力。
性能测试总结(三)
本篇文章主要简单总结下性能测试工具的原理以及如何选型。性能测试和功能测试不同，性能测试的执行是基本功能的重复和并发，需要模拟多用户，在性能测试执行时需要监控指标参数，同时性能测试的结果不是那么显而易见，需要对数据进行分析。这些特点决定了性能测试更适合通过工具来完成。
一、浅谈为什么需要工具
我们来看下工具的定义：它原指工作时所需用的器具，后引申为为达到、完成或促进某一事物的手段。（---来自百度的解释）
1、从人类进化的角度来看，会制造并使用工具是人和猿人最根本的区别，因为工具可以帮助我们提高生产力和效率。
2、想象下如果不使用工具进行性能测试会怎么样？
我们可以从性能测试的定义的角度来分析，性能测试是指通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。如果不使用工具，仅靠人工进行性能测试会存在以下的弊端：
a）测试需要投入大量的资源：
为了模拟多种负载、并发的场景需要多人协同工作，通常测试没有很多的资源，而且就算有资源人工的效果也会大打折扣，甚至于某些场景仅凭人工是无法完成的。
b）可重复性非常差：
性能测试经常需要反复调优和测试执行，如果没有工具的帮助，全靠人工实在不敢想象。
c）测试准确性较差：
由于需要模拟多种负载和并发场景，如果由人工来操作，难免会存在误差，而且相对工具或程序来说这种误差会更大，对测试结果影响也非常大。
d）结果的收集、整理和呈现形式差：
如果没有工具，全凭人工采集数据相对工具来说也会存在较大的误差。
二、性能测试与性能测试工具的关系
1、性能测试从测试阶段来划分属于系统测试，其和具体使用什么工具并没有直接的关系。使用工具只是为了提高性能测试效率和准确性的一种方法和手段。从本质上来看，同做其它事情时使用工具没有什么实质性的区别。
2、性能测试不等于Loadrunner，LR只是性能测试工具其中的一种，而且它也不是万能的，在某些情况下它也并不能派上用场。推荐看下《让LoadRunner走下神坛》和《让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为什么一直这流行就知道了。
四、常见性能测试工具：
性能测试工具，从理论上来讲在性能测试过程中使用到的所有工具都可以称其为性能测试工具，通常分为以下几类：
说明：
服务器端性能测试工具：需要支持产生压力和负载，录制和生成脚本，设置和部署场景，产生并发用户和向系统施加持续的压力。web前端性能测试工具：需要关于心浏览器等客户端工具对具体需要展现的页面的处理过程。移动端性能测试工具：同web端性能测试工具也需要关心页面的处理过程，另外还要具体数据采集的功能，比如：手机CPU、内存、电量，启动时间等数据的记录。资源监控工具：这个主要是能够收集性能测试过程中的数据以及良好的结果展现方式。
PS：本篇文章主要总结下服务器端性能测试工具LR和Jmeter，后面也会对这两个工具进行简单的对分。
五、常见性能测试工具特点
JMeter：采用的是多线程模型，扩展性很强，不过制造压力没有那么高。它很适合用来压一些Tomcat服务，或者一些后端接口。JMeter的缺点是压力值不能精确控制，难以适应高并发的情况，而且由于是JAVA编写的，本身比较消耗资源。LoadRunner：更像是一个模拟器，它比较适用于前端构造较复杂场景的情况，比如模拟100个用户登录的场景，LoadRunner对非技术人员提供了很好的支持。LoadRunner不适用后端接口。下表为JMeter和LoadRunner对比表：
描述JMeterLoadRunner架构原理通过中间代理，监控和收集并发客户端的指令，把他们生成脚本，再发送的应用服务器，再监控应用服务器反馈的过程同JMeter安装简单，解压即可，比较灵活LoadRunner安装包比较大，安装比较麻烦，工具本身相对比较笨重支持的协议支持多种协议：HTTP、HTTPS、SOAP、FTP、DatabaseviaJDBC、JMS等，但相对LR还是不够全面，由于此原因相对来说jemter比较灵活，轻便支持的协议非常多，比较全面，但正因此显得工具本身比较笨重，不够灵活脚本录制提供了一个利用本地ProxyServer（代理服务器）来录制生成测试脚本的功能，也支持badboy录制再生成JMeter脚本自带录制功能强大，可直接录制回放并发模型通过增加线程组的数目，或者是设置循环次数来增加并发用户支持多种并发模型，通过在场景中选择要设置什么样的场景，然后选择虚拟用户数分布式测试支持，可设置多台代理，通过远程控制实现多台机器并发压力同JMeter资源监控通过JMeterPlugins插件和ServerAgent实现自带资源监控功能报告分析通过与Ant集成，生成HTML报告自身支持生成HTML、Word报告虚拟IP不支持支持网速模拟不支持支持扩展性开源，可根据需求修改源码通过扩展函数库实现学习成本主要是自学官网上的资料网上资料和相关培训很多，购买正版的话，还有技术支持
六、性能测试工具学习教程：
1、Loadrunner：目前还未整理，后续会慢慢整理成文章，敬请期待...
2、Jmeter：可查看我的另一篇文章Jmeter教程索引贴
3、Gatling：未使用过，网上资料也比较少，入门推荐：新一代服务器性能测试工具Gatling
性能测试包括哪些类型性能测试种类介绍
系统的性能是一个很大的概念，覆盖面非常广泛，包括执行效率、资源占用、系统稳定性、安全性、兼容性、可靠性、可扩展性等，性能测试就是描述测试对象与性能相关的特征并对其进行评价而实施的一类测试。
性能测试是一个统称，它其实包含多种类型，主要有负载测试、压力测试、并发测试、配置测试等，每种测试类型都有其侧重点，下面对这几个主要的性能测试种类分别进行介绍。
1.负载测试
负载测试是指逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统性能指标的情况下，系统所能够承受的最大负载量。负载测试类似于举重运动，通过不断给运动员增加重量，确定运动员身体状况保持正常的情况下所能举起的最大重量。
对于负载测试来说，前提是满足性能指标要求。例如一个软件系统的响应时间要求不超过2s，则在这个前提下，不断增加用户访问量，当访问量超过1万人时，系统的响应时间就会变慢，超过2s，从而可以确定系统响应时间不超过2s的前提下最大负载量是1万人。
2.压力测试
压力测试也叫强度测试，它是指逐步给系统增加压力，测试系统的性能变化，使系统某些资源达到饱和或系统崩溃的边缘，从而确定系统所能承受的最大压力。
压力测试与负载测试是有区别的，负载测试是在保持性能指标要求的前提下测试系统能够承受的最大负载，而压力测试则是使系统性能达到极限的状态。例如软件系统正常的响应时间为2s，负载测试确定访问量超过1万时响应时间变慢。压力测试则继续增加用户访问量观察系统的性能变化，当用户增加到2万时系统响应时间为3s，当用户增加到3万时响应时间为4s，当用户增加到4万时，系统崩溃无法响应。由此确定系统能承受的最大访问量为4万。
压力测试可以揭露那些只有在高负载条件下才会出现的Bug(缺陷)，如同步问题、内存泄漏等。
3.并发测试
并发测试是指通过模拟用户并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或其他性能问题。并发测试一般没有标准，只是测试并发时会不会出现意外情况，几乎所有的性能测试都会涉及一些并发测试，例如多个用户同时访问某一条件数据，多个用户同时在更新数据，那么数据库可能就会出现访问错误、写人错误等异常情况。
4.配置测试
配置测试是指调整软件系统的软硬件环境，测试各种环境对系统性能的影响，从而找到系统各项资源的最优分配原则。配置测试不改变代码，只改变软硬件配置，例如安装版本更高的数据库、配置性能更好的CPU和内存等，通过更改外部配置来提高软件的性能。
5.可靠性测试
可靠性测试是指给系统加载一定的业务压力，使其持续运行一段时间(如7×24h)，测试系统在这种条件下是否能够稳定运行。由于加载有业务压力且运行时间较长，因此可靠性测试通常可以检测出系统是否有内存泄漏等问题。
6.容量测试
容量测试是指在一定的软硬件及网络环境下，测试系统所能支持的最大用户数、最大存储量等。容量测试通常与数据库、系统资源(如CPU、内存、磁盘等)有关，用于规划将来需求增长(如用户增长、业务量增加等)时，对数据库和系统资源的优化。猜你喜欢:
如何进行性能测试?完整的性能测试流程
功能测试、性能测试和自动化测试有什么区别?
如何做性能测试?
中级软件测试工程师培训课程