互联网压力性能Badboy.Jmeter
http://itopic.org/jmeter-http-tcp.html
使用JMeter录制手机App脚本
](https://testerhome.com/uploads/photo/2017/2a131cd8-a9ac-4103-aa0b-932f26d71e19.png!large)
备注：本人不太喜欢用Jmeter的录制功能，因为会录制很多无效的网络请求，但若不知道接口参数的情况下，可以采用录制方式，然后删除修改。
线程组的设置
普通线程组1、 线程数：设置并发用户线程数量，即通常意义的并发用户数2、 Ramp-Up Period （in seconds）：设置并发用户加载时间，假设并发用户数设置为100，此处设置为10，则认为jmeter会在10s内加载完成100并发用户数，也就是说每隔10秒加载一个3、 循环次数：输入框与复选框只能选择一种，不能同时被选择为场景循环方式；输入框输入数字则被认为是当前线程组所控制的脚本区域的执行次数；【永远】复选框选择后，输入框内的数字将失效，启动后脚本将一直执行下去。4、 调度器：对于调度而言，顾名思义就是我们想在什么时间开始运行，运行多长时间自动停止诸如此类的场景需求均可以在此设置。 • 启动时间：在设置时间点开始运行场景，比如你想在下班后开始运行，如果时间小于当前时间，启动后立即执行，大于当前时间，启动后等待本地时间到了自动运行 • 结束时间：在设置时间点结束运行场景，比如上班前结束运行，结束时间如果小于开始时间或者当前时间，自动运行后立即终止 • 持续时间：设置当前场景持续运行的时间 • 启动延迟：设置场景启动后多长时间再开始真正运行，比如你想在下班后5分钟开始运行场景其中持续时间和启动延迟的优先级高于启动时间和结束时间，也就是说当你设置了持续时间或者启动延迟，那么你的启动时间或者结束时间将失效，5、 几种设置场景组合： • 不勾选【永远】，选择【调度器】，设置完成后，启动运行也只会运行当前并发用户数循环次数，运行完成即会结束。所以此中选择可用于希望未来某时间点开始运行完成并发用户数循环次数的场景 • 勾选【永远】，设置启动时间及结束时间，持续时间和启动延迟均为空，可用于希望未来某时间点自动运行并且到未来某时间点自动结束的场景 • 勾选【永远】， 设置 持续时间和启动延迟， 可用于希望在启动多久后自动运行并持续多长时间的场景
另外介绍一个调试工具Debug Sampler，会把我们自定义的变量输出在response data中，方便我们调试的时候使用，但在正式执行脚本时需要删除Debug Sample[
](https://testerhome.com/uploads/photo/2017/e1e8d832-6d0e-466b-9c3d-1eead591b061.png!large)
jp@gc - Stepping Thread Group
[
](https://testerhome.com/uploads/photo/2017/a59940a0-c7da-4bfd-8c76-8a4b72b9cb35.png!large)类似loadrunner的场景设置，解释: This Group will start 100 threads：这次的测试总共会起100个线程。 First , wait for 0 seconds：等待0s后开始起线程，也就是不等待直接起线程。 Then start 10 threads every 30 seconds：每起10个线程后会运行30s，再起余下的10个线程，再运行30s，以此类推。 Using ramp-up 5 seconds：前面每起多少个线程的时候花5s，与上面结合起来即5s内起10个线程，运行30s，然后再再5s内再起10个线程，再运行30s，以此类推。 Then hold load for 60 seconds. ：全部的线程起来后，运行60s 后开始停止（跟loadrunner类似，从jmeter聚合报告里面可以看出来，这里的hold load 的意思，其实是这些线程，一直在请求，相当于jmeter普通线程组里面的循环运行）。 Finally , stop 5 threads every 1 seconds：最后停止线程，5个线程停一次，等1s再停5个线程（当然，第一次是hold时间一过就先停5个线程，然后等1s再停余下的5个线程）。
介绍几个常用的逻辑控制器
JMeter中的Logic Controller分为两类：a) 控制测试计划执行过程中节点的逻辑执行顺序，如：循环控制器（Loop Controller）、if控制器（If Controller）等；b) 对测试计划中的脚本进行分组、方便JMeter统计执行结果以及进行脚本的运行时控制等，如：吞吐量控制器（Throughput Controller）、事务控制器（Transaction Controller）。一、ForEach控制器（ForEach Controller） 作用：ForEach控制器一般和用户自定义变量一起使用，其在用户自定义变量中读取一系列相关的变量。该控制器下的采样器或控制器都会被执行一次或多次，每次读取不同的变量值。二、包含控制器（Include Controller） 作用：用于引用外部的Jmx文件；从而控制多个测试计划组合三、事务控制器（Transaction Controller） 作用： 事务控制器会生产一个额外的采样器，用来统计该控制器子结点的所有时间。四、仅一次控制器（Once Only Controller） 作用：在测试计划执行期间，该控制器下的子结点对每个线程只执行一次，登录场景经常会使用到这个控制器。五、吞吐量控制器（Throughput Controller） 作用：控制其下的子节点的执行次数与负载比例分配，也有两种方式： Total Executions：设置运行次数 Percent Executions：设置运行比例(1~100之间，不用写%) 如：设置线程组循环5次，吞吐量控制器1：百分比40，吞吐量控制器2：百分比60[
](https://testerhome.com/uploads/photo/2017/2345227d-9435-47c0-9680-efe544dae85b.png!large)
六、If 控制器（If Controller） 作用：根据给定表达式的值决定是否执行该节点下的子节点，默认使用javascript的语法进行判断[
](https://testerhome.com/uploads/photo/2017/88ecd8db-f685-4e9a-a7af-3c4d7b6fb711.png!large)
脚本参数化的几种方式
一、使用Jmeter自带函数获取参数值 Jmeter中可以产生值的函数有：Random( , , )，threadNum，CSVRead( , )，StringFromFile( , , , ) 。函数调用方法就不细说了，因为Jmeter中有函数助手[
](https://testerhome.com/uploads/photo/2017/74059e48-7c1e-4bf0-8920-3246b46bb669.png!large) 然后将函数复制到需要用到随机数的地方，当我们设置的线程数超过随机数范围时，随机数将会重复生成。
不过需要重点介绍下正则表达式的使用，后续有需要用到关联测试，因为在测试过程过有些数据是经常发生变化的，要获取并使用这些数据，就要使用关联。[
](https://testerhome.com/uploads/photo/2017/92824be3-63ec-488c-859a-7be8aabb4c7e.png!large)
1、 第一个参数：用于解析服务器响应数据的正则表达式。它会找到所有的匹配项。如果测试人员希望将表达式中的某部分应用在模板字符串中，记得加上圆括号。2、 第二个参数：这是一个模板字符串，函数会动态填写字符串的部分内容。要在字符串中引用正则表达式捕获的匹配组合，请使用语法：$[group_number]$。例如$1$或者 $2$。测试人员的模板可以是任何字符串3、 第三个参数：第3个参数告诉JMeter使用第几次匹配。测试人员的正则表达式可能会找到多个匹配项。对此，测试人员有4种选择： 整数，直接告诉JMeter使用第几个匹配项。 “1”对应第一个匹配，“2”对应第二个匹配，以此类推 RAND，告诉JMeter随机选择一个匹配项 ALL，告诉JMeter使用所有匹配项，为每一个匹配项创建一个模板字符串，并将它们连接在一起 浮点值0到1之间，根据公式（找到的总匹配数目*指定浮点值）计算使用第几个匹配项，计算值向最近的整数取整4、 第四个参数：如果在上一个参数中选择了“ALL”，那么这第4个参数会被插入到重复的模板值之间5、 第五个参数：如果没有找到匹配项返回的默认值6、 第六个参数：重用函数解析值的引用名，参见上面内容7、 第七个参数：输入变量名称。如果指定了这一参数，那么该变量的值就会作为函数的输入，而不再使用前面的采样结果作为搜索对象
二、使用CSV Data Set Config获取参数值[
](https://testerhome.com/uploads/photo/2017/07956f7f-1acf-4e80-a6d7-aa20b674f7ea.png!large)
三、使用用户定义的变量获取参数值[
](https://testerhome.com/uploads/photo/2017/d3747148-55e5-4ac2-8928-98fab49cef51.png!large) 一般配合ForEach控制器一起使用
参数值的传递
一、利用Cookie进行值的传递 用JMeter进行接口调试时，有时候会遇到需要登录的情况，如请求wetest的DataSearchAjax接口：[
](https://testerhome.com/uploads/photo/2017/040fc1fd-a17e-411f-b566-493ac6d14e19.png!large) 出现这种情况的原因很明显是未登录引起的。一个较好的解决方法就是将登录后的cookies保存下来，在访问DataSearchAjax接口的时候，带上用户登录后的cookies信息进行查看。 在JMeter中，我们可以通过如下途径进行cookies的传递，如下图添加HTPP Cookie管理器：[
](https://testerhome.com/uploads/photo/2017/9133cdb9-ea5b-4d9a-b6cf-d14f14060e84.png!large) 再给登录的接口添加前置处理器Bean Shell PreProcessor，用来保存登录的cookies：[
](https://testerhome.com/uploads/photo/2017/29b96836-e878-4d5f-aed1-0741b168fdc3.png!large) 我们要在Bean Shell PreProcessor里面添加我们的cookies值了。二、利用正则匹配提取上一个接口的返回数据作为下个请求的输入 用JMeter进行接口调试时，经常会遇到上一接口的返回值中的某个字段，要作为下一接口的输入，这种情况下，我们需要利用正则匹配来提取我们需要的值。 例如，若要提取相应数据中的userid字段作为下个接口的输入的话，可以在该接口请求后面添加正则表达式提取器：[
](https://testerhome.com/uploads/photo/2017/8af43d26-d2bb-418d-977a-cc7b1a819b98.png!large) 我们给正则表达式提取器命名为get_userid，并填写引用名称、正则表达式、模板、匹配数值、缺省值，填写后的如如下：[
](https://testerhome.com/uploads/photo/2017/c2055827-ae22-4656-a658-dbc979696876.png!large)
填写完成后，在添加新的HTTP请求，来测试提取到的user_id字段：[
](https://testerhome.com/uploads/photo/2017/3be56d03-2e7e-4401-ba62-8bbf4339b314.png!large)
介绍几个定时器的用法，类于loadrunner中的thinktime，集合点的设置
一、固定定时器（Constant Timer）[
](https://testerhome.com/uploads/photo/2017/2c8b307a-1aef-4566-8eec-a9cb009606c4.png!large) 这是一个很重要的定时器，如果你需要让每个线程在请求之前按相同的指定时间停顿，那么可以使用这个定时器；需要注意的是，固定定时器的延时不会计入单个sampler的响应时间，但会计入事务控制器的时间。 对于“java请求”这个sampler来说，定时器相当于loadrunner中的pacing（两次迭代之间的间隔时间）； 对于“事务控制器”来说，定时器相当于loadrunner中的think time（思考时间：实际操作中，模拟真实用户在操作过程中的等待时间）。二、高斯随机定时器（Gaussian Random Timer）[
](https://testerhome.com/uploads/photo/2017/0752d6c0-0ba5-4bed-a6c1-d98db575508e.png!large) 如果需要让每个线程在请求之前按随机的时间停顿，那么可以使用这个定时器，上图表示暂停时间会分布在100到400之间三、同步定时器（Synchronizing Timer）[
](https://testerhome.com/uploads/photo/2017/94dcf155-b39f-4ca8-8639-f5ab2673d5c3.png!large) 这个定时器和loadrunner当中的集合点（rendezvous point）作用相似，其作用是：阻塞线程，直到指定的线程数量到达后，再一起释放，可以瞬间产生很大的压力（1）Number of Simulated Users to Group by:模拟用户的数量，即指定同时释放的线程数数量（2）Timeout in milliseconds:超时时间，即超时多少毫秒后同时释放指定的线程数
监听器配置
将下载的JMeterPlugins.jar包复制到Jmeter的lib目录下面的ext目录下面,重新启动Jmeter，我们点击添加就可以看到出现了很多的jp@gc-开头的文件。这里监控内存我们使用的是：jp@gc - PerfMon Metrics Collectot 在使用之前，我们需要下载ServerAgent-2.2.1，然后运行/serverAgent/startAgent.bat这个文件，我们需要将serverAgent目录及下面的文件复制到我们测试的服务器上，然后点击打开，它的默认端口为4444。 常用的监听器还有如下jp@gc - Active Threads Over Time，jp@gc - Transactions per Second，jp@gc - Response Times Over Time，jp@gc - Composite Graph，保存响应到文件，聚合报告，察看结果树[
](https://testerhome.com/uploads/photo/2017/fcb834f1-6257-4c54-9992-95ac55cfd73a.png!large)其中jp@gc - Composite Graph可以将多个监听视图进行合并分析
最后测试报告的生成
使用jmeter进行性能测试，运行完毕后生成html格式的测试报告，需要进行如下操作（3.0含及以上的版本）：一、在jmeter.properties或者user.properties确认如下配置项
• jmeter.save.saveservice.bytes = true• jmeter.save.saveservice.label = true• jmeter.save.saveservice.latency = true• jmeter.save.saveservice.response_code = true• jmeter.save.saveservice.response_message = true• jmeter.save.saveservice.successful = true• jmeter.save.saveservice.thread_counts = true• jmeter.save.saveservice.thread_name = true• jmeter.save.saveservice.time = true• jmeter.save.saveservice.timestamp_format = ms• jmeter.save.saveservice.timestamp_format = yyyy/MM/dd HH:mm:ss
o 如果希望在Errors报告中展示更详细数据，需要确保如下配置: jmeter.save.saveservice.assertion_results_failure_message = trueo 如果使用了事务控制器(Transaction Controller)，确认Generate parent sample为未勾选状态
运行jmeter程序，在命令行输入如下信息1）Windows系统输入格式如下：jmeter.bat -n -t -l -e -o 实际输入：C:\apache-jmeter-3.0\bin\jmeter.bat -n -t Movie.jmx -l movie.jtl -e -o test
2）Linux系统输入格式如下：jmeter -n -t -l -e -o 实际输入：/opt/apache-jmeter-3.0/bin/jmeter -n -t final-result.jmx -l final-result.jtl -e -o /opt/apache-jmeter-3.0/test
[
安装必要插件jmeter-plugins（windows下）
下载插件管理器
http://www.jmeter-plugins.org/get/ 将下载所得的jar包放在{jmeter}/bin/lib/ext目录下
打开GUI模式下的jmeter下载所需插件
选择菜单栏中的“选项”，选择“Plugings Manager”，如图
选择所需插件安装
打开插件管理器后选择Available Plugings，勾选3 Basic Graph 以及Custom Thread Groups，点击Apply Changes and Restart JMeter，等待下载完成重启JMeter即可。
安装必要插件jmeter-plugins（Linux下）
查找并复制jar包
在windows的界面下，安装好插件后，根据上图的Review Changes中的信息，在{jmeter}/bin/lib/ext中找到新增jar包，复制到linux上。
使用JMeter测试
GUI模式下测试接口
添加线程组
在GUI模式，打开JMeter。右键点击“测试计划”，选择“添加”→“Threads（Users）”→“线程组”，如图所示：
添加HTTP请求
线程组属性不做修改，右键点击新添加的“线程组”，选择“添加”→“Sampler”→“HTTP请求”，如图所示：
完成HTTP请求
根据请求信息，完成“HTTP请求”：修改名称；注意IP和端口号，在路径栏补齐除ip端口号的剩余路径；Implementation使用httpClient4；使用https的协议需要在协议栏填写https；选择请求的方法，多数为POST或这GET；若请求体中含有中文，最好在content encoding中填写utf-8；请求参数可以选择Parameters或者Body Data，Parameters的参数更加直观，Body Data的更加方便参数修改且参数以parameter1=value1&mmeter2=value2形式。
添加查看结果数
右键点击“HTTP请求”，选择“添加”→“监听器”→“查看结果树”，如图所示：
添加证书文件
协议为Https的请求还需要加载证书，如果为https协议，在没有加载证书的情况下，进行了测试，最好保存测试计划，然后重启JMeter，重启后先加载证书，再进行测试，否则，报错。选择“选项”→“SSL管理器”，如图所示：
选择pkcs12的证书文件
使用pkcs12的证书文件，jks直接用是不行的，需要java打包下
启动测试
点击“启动”按钮，启动测试，如图所示
输入pcks12的密码
启动测试后，弹出“KeyStore Password”，输入pcks12生成时用的密码。
测试后查看结果树
测试结束后，点击“查看结果树”，可以看到当前测试运行了一个实例，选中该结果，点击“响应数据”查看响应的文本，检查文本是否为正确的响应数据，JMeter会把所有响应码200的回复都当成成功，一些服务例如查询等，可能会设置查询失败下返回提示语句但响应码依旧是200。此时需要查看响应文本中正确响应的关键词，方便压测时设置响应断言。
GUI模式下创建压力测试计划
添加Concurrency Thread Group
可以新建一个测试计划，也可以在原先接口测试的测试计划上修改。本例直接修改原先的接口测试，右键“测试计划”，选择择“添加”→“Threads（Users）”→“Concurrency Thread Group”，如图所示：
设置Concurrency Thread Group
根据需求完成线程组的设置，需要填写“Target Concurrency”，为压力测试预期的并发压力（注意Jmeter采用线程模拟并发的策略，大并发意味着大量线程，测试机性能会大量消耗，甚至影响测试结果，所以需要大并发的情况下，建议采用分布式部署Jmeter进行测试）；“Ramp Up Time”，为测试并发数启动所需时间（注意测试并不是所有并发启动后才运行，在启动过程中，先启动的线程会先运行请求）；“Ramp Up Steps Counts”，为是否将启动线程分阶段的启动，例如10即为分10次阶段性的启动一部分线程，可以为空；“Hold Target Rate Time”，为并发达到要求后再运行多久时间；“Time Unit”，时间单位，非常重要，有分和秒，不要选择错误。
添加Http请求
直接复制之前接口测试时的http请求，删去查看结果树即可。
添加聚合报告
右键http请求，选择“添加”→“监听器”→“聚合报告”。如图所示
聚合报告中保存测试数据
在聚合报告的“文件名”栏，填入./*****-${__time(yyyyMMdd-HHmmss,)}.jtl，表示在当前目录生成jtl（jmeter的数据文件格式），${__time(yyyyMMdd-HHmmss,)}为jmeter的时间函数，生成测试的年月日分钟秒，方便后期管理测试数据。
添加响应断言
右键http请求，选择“添加”→“断言”→“响应断言”，如图所示：
配置响应断言
不同请求配置不同的断言。根据之前的接口测试，点击添加，输入判断文本，不同模式匹配规则，自行百度
保存测试计划
删除接口测试的线程组，点击“文件”，选择“保存测试计划为”，保存测试计划。压测计划创建完成。注意3.1版本“保存测试计划为”下面是“选中部分保存为”，旧版就是“保存为”，会保存选中的部分，然后实际测试的时候因为测试计划不完整是没法跑测试的，会报Error in NonGUIDriver java.lang.RuntimeException: Could not find the TestPlan class!，这雷旧版很容易踩上。
NO-GUI模式下启动压力测试
Windows下
打开cmd，目录切换到测试计划（jmx）所在的目录，证书放在同一目录下，输入{jmeter}/bin/jmeter -Djavax.net.ssl.keyStore=****.pkcs12 -Djavax.net.ssl.keyStorePassword=**** -n -t *.jmx {jmeter}为jmeter的安装目录 -Djavax.net.ssl.keyStore=****.pkcs12 是证书文件 -Djavax.net.ssl.keyStorePassword=**** 是证书文件生成时的密码 -n 为nogui模式 -t 后面为测试计划文件（jmx）
linux下（推荐）
目录切换到测试计划（jmx）所在的目录，证书放在同一目录下，输入{jmeter}/bin/jmeter -Djavax.net.ssl.keyStore=****.pkcs12 -Djavax.net.ssl.keyStorePassword=**** -n -t *.jmx |tee -a *.out {jmeter}为jmeter的安装目录 -Djavax.net.ssl.keyStore=****.pkcs12 是证书文件 -Djavax.net.ssl.keyStorePassword=**** 是证书文件生成时的密码 -n 为nogui模式 -t 后面为测试计划文件（jmx） tee -a 参数后为文本文件，用于保存测试时输出summarize数据 若是为http的，Djavax.net.ssl.keyStore=****.pkcs12 -Djavax.net.ssl.keyStorePassword=**** 直接省去
使用JMeter查看数据
在GUI模式下
选择报表
打开Jmeter，右击测试计划，选择“添加”→“监听器”→“聚合报告”；“添加”→“监听器”→“Response Times Over Time”；“添加”→“监听器”→“Transactions per Second”（有其他图表需要可以自行下载插件安装），如图所示：
加载数据
选择聚合报告，点击文件名栏后的浏览，选择jtl文件，加载数据（其余监听器类似），如图所示:
其他：
http会产生cookie的，需要删除或者其他操作的，需要添加cookie管理器。 默认jtl数据不保存响应文本，需要保存错误文件的信息，可以添加监听器中的保存响应到文件，勾选Save Failed Responses only(不推荐有较多错误的情况去保存文本，容易卡住）。 Bin目录下有个templates文件夹，里面有些JMeter用法的例子，可以看看。 NOGUI模式下可以使用jmeter -g result.jtl -o ./ResultReport生成一个html的报表（3.0版本以上）
[jmeter进行分布式测试]
一、背景：
之前在Jmeter插件监控服务器性能一篇中说到，在非GUI环境中监控时为了保存监控数据需要修改jmeter脚本，并且每次通过施压机（远程服务器，非GUI环境）来压测时都要将jmeter脚本上传然后在服务器上通过命令行启动，测试完成后再把结果数据下载到本地GUI环境中查看，总是有很多不方便。
本次压测需求需要很大的并发量，例如3000，但是单台施压机难以实现，因此希望多台施压机并行，并且我能同步控制它们。
在这样的需求下经过了解，jmeter工具本身有一个很强大的远程启动功能，于是尝试了一下。
二、jmeter分布式原理
客户端机器作为一个控制器controller，控制多台slave机器的操作。
controller通过GUI界面启动slave机器，将jmeter压测发送给每台启动的slave，slave获得脚本后开始执行。slave本地不需预先存储脚本；
各台slave执行完成后，将结果传回给controller，controller收集整合显示。
三、jmeter远程启动配置
服务器（slave）配置
服务器（slave）需安装jmeter，最好与客户端（controller）保持同版本，jdk最好也保持同版本，无法满足时至少保证服务器上的jmeter能正常运行（如jmeter3.0以后需要jdk1.7及以上版本）。
注意：上图红框中的ip为服务器的ip地址，当服务器有多网卡时它会随机挑选一个网卡使用，红框中的端口号port为启动jmeter服务监听的port，一般会有个默认端口号1099，但最好自定义，确保端口号不冲突。修改方法在下文介绍。
客户端（controller）配置
在客户端上要保证执行命令能发送到服务器，因此需配置客户端远程的ip地址和port。在客户端安装目录的bin文件夹下，找到jmeter.properties，修改配置如下图,其中ip和port即为上一步slave的ip和port，如上图中jmeter-server启动时红框中显示的内容。多个slave机器的配置可通过逗号分隔。
remote_hosts=10.165.124.6:1029
四、问题
slave机器的自定义端口号配置
在slave机器的%JMETER_HOME%bin目录下找到jmeter.properties，修改如下两项配置，即可自定义端口号：
server_port=1029server.rmi.localport=1029
修改后执行服务端的jmeter-server即可看到控制台消息中修改是否生效；修改生效后需在客户端修改相应的jmeter.properties下的remote_hosts。
slave机器和客服端多网卡的问题
我在执行过程中slave机器的jmeter-server.log和客户端的jmeter.log中均报错提示connect refused。经过检查后发现服务器上有2个网卡，客户端有两个网卡，两台机器通过vpn在内网环境通信。而jmeter在远程通信的时候是随机选择一个网卡的ip，这样很容易导致连接不成功。
可通过如下配置指定服务器和客户端的网卡，在服务器端的jmeter-server文件中，修改配置指定服务器端的网卡ip
RMI_HOST_DEF=-Djava.rmi.server.hostname=10.165.124.6
在客户端的jmeter.bat中修改配置指定客户端的网卡ip
增加配置项：set rmi_host=-Djava.rmi.server.hostname=10.165.120.4修改配置项：set ARGS=%DUMP% %HEAP% %NEW% %SURVIVOR% %TENURING% %PERM% %CLASS_UNLOAD% %DDRAW% %rmi_host%
在修改配置后尝试远程启动，发现还是不成功，打开客户端jmeter.log，发现客户端发送成功；打开服务器端的jmeter-server.log显示服务器连接客户端不成功，尝试ping了一下也确实ping不通，然后网上搜了一下说是因为客户端的防火墙阻止了，关闭客户端所有防火墙，再次执行，测试成功。
依赖文件报错的问题
当jmeter脚本中需要依赖csv等数据文件时，该文件需上传至服务器，并需要设置正确的路径。
处理利用jmeter实施监控压测时受压机的各项性能
操作步骤：
施压机上的jmeter/lib/ext中放入下载的插件包 jmeter-plugins-perfmon-2.1.jar
受压机上放入ServerAgent-2.2.1
运行受压机上的ServerAgent
施压机上：添加监控：
运行case，可查看曲线结果
非GUI图像操作：
由于非GUI图像需要先存储数据，然后放到GUI图形界面中查看或处理，而在非GUI中运行jmeter的命令时未提供如何保存性能数据的方法，在此可通过shell脚本修改保存性能数据的路径。脚本如下：其中filename为保存jemter压测结果数据的文件名，serverFilename为保存jmeter压测时相应服务器性能数据的文件名。
!/bin/basharg1=$1arg2=$2arg3="Click"filename="result_"$arg3"$1$2.jtl"serverFilename="serverInfo_"$arg3"$1$2.jtl"echo $arg1 echo $arg2echo $serverFilenamesed -i -e 's|<stringProp name="ThreadGroup.num_threads">.|<stringProp name="ThreadGroup.num_threads">'"$arg1"'</stringProp>|' captchaClick.jmxsed -i -e 's|<stringProp name="filename">.|<stringProp name="filename">'"$serverFilename"'</stringProp>|' captchaClick.jmx../../bin/jmeter -n -t ./captchaClick.jmx -l ./$filename
问题：
受压机上的ServerAgent的执行脚本直接关闭时无法正常关闭，需通过kill -9命令杀掉进程。
##################################################################
http://www.s-uu.com/index.php/2017/05/23/230/
https://www.iyunv.com/thread-385799-1-1.html
##########################################################
1、求和
cat data|awk '{sum+=$1} END {print "Sum = ", sum}'
2、求平均
cat data|awk '{sum+=$1} END {print "Average = ", sum/NR}'
3、求最大值
cat data|awk 'BEGIN {max = 0} {if ($1>max) max=$1 fi} END {print "Max=", max}'
4、求最小值（min的初始值设置一个超大数即可）
awk 'BEGIN {min = 1999999} {if ($1<min) min=$1 fi} END {print "Min=", min}'
5、求访问次数的Top 10 Resource，可以根据此进行优化
cat output/logs/cookie_logs/date +%u/cookie_log|grep -v '172.16'|grep -v '127.0.0.1' |awk -F' ' '{ if(index($1,"219.141.246")!=0) print $2; else print $1 } '|sort|uniq -c|sort -n |tail -n 10
QPS:每秒查询率(Query Per Second) ,每秒的响应请求数，也即是最大吞吐能力。QPS = req/sec = 请求数/秒QPS统计方式 [一般使用 http_load 进行统计]QPS = 总请求数 / ( 进程总数 * 请求时间 )QPS: 单个进程每秒请求服务器的成功次数
峰值QPS:原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)
PV:访问量即Page View, 即页面浏览量或点击量，用户每次刷新即被计算一次单台服务器每天PV计算公式1：每天总PV = QPS * 3600 * 6公式2：每天总PV = QPS * 3600 * 8
UV:独立访客即Unique Visitor,访问您网站的一台电脑客户端为一个访客。00:00-24:00内相同的客户端只被计算一次服务器数量：机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器机器：ceil( 每天总PV / 单台服务器每天总PV )
并发数：并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量
吐吞量：吞吐量是指系统在单位时间内处理请求的数量
响应时间（RT):响应时间是指系统对请求作出响应的时间
例子：每天300w PV 的在单台机器上，这台机器需要多少QPS？答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)如果一台机器的QPS是58，需要几台机器来支持？答：139 / 58 = 3
这篇文章将关注测试金字塔里的单元测试层，并探讨如何高效地为分布式系统（如微服务）构建单元测试。
定义测试边界
定义测试边界是实现高效测试的第一步。测试的目的是为了验证边界里“黑盒”的行为是否符合预期，我们向黑盒输入数据，然后验证输出的正确性。
在单元测试里，黑盒指的是函数或者类的方法，目的是单独测试特定代码块的行为。为了更好地理解这个概念，我们以简单的注册功能为例：
我们可以看到这个函数包含了一些输入和输出。这个函数接受基本的用户注册信息作为输入参数，并返回新创建的用户ID。
不过这里也有一些不是很明显的输入数据。这个函数调用了另个外部函数：一个向数据库插入数据，一个对密码进行散列和持久化。在某些情况下，数据库可能会返回错误。比如，因为用户名唯一性问题导致数据库插入失败，又或者需要通过调用外部的微服务进行密码散列，如果网络连接出现问题或密码散列服务因发生过载导致服务超时，那么密码散列函数就会返回错误。
为了全面测试用户注册功能，单元测试所要做的不仅仅是简单地传进去不同的输入参数，它还要能够让外部依赖项能够使用这些输入来验证函数的行为是否符合预期。在测试函数的错误处理逻辑时，这点很重要的。
Stub和Mock
为了制造各种输入数据，需要使用stub，也叫作mock。这个可以使用依赖注入或方法搅拌（swizzle）来实现。测试框架在运行被测试的函数时可以确保对底层依赖项的调用会被重定向到stub上：
我们可以使用stub来达到各种目的：
stub可以什么事也不做。这样可以加快个别单元测试的速度，如果后续有其他单元测试可用于测试边界情况的话就可以这样做。
stub可返回任意的值，用于模拟外部函数的输出。这在测试罕见的边界情况时会非常有用，比如有些错误场景很少会发生或者难以重现。
stub也可以用于捕捉被测试函数欲传给外部函数的参数，或者把这些参数记录下来。这样就可以验证被测试函数需要调用哪些外部函数以及需要传给外部函数哪些参数。
测试分布式系统需要有一套很好的stub，有了这些stub，单元测试才能够在没有外部服务的情况下运行。下面列出了一些工具，用于创建各种stub。
Node.js/JavaScript
sinon.js (提供了stub和间谍功能)
testdouble.js (主要用于面向对象API的stub生成器)
nock (主要用于模拟HTTP请求行为)
Python****
mock
Go
gomock
Java
mockito
easymock
单元测试流程
单元测试的目的是为了给开发人员提供快速验证他们所写代码的行为。因为对外部依赖的调用使用了stub，所以通常可以在几秒钟内就可以执行数千个单元测试。所以，开发人员可以把单元测试加入到他们的开发工作流当中，要么直接集成到他们的IDE里，要么通过终端命令行来运行。开发人员在编写代码的同时频繁地运行单元测试可以帮助他们及早地发现代码中的问题。
一旦开发人员养成了这样的习惯，那么就可以进行测试驱动开发了。开发人员在开发新特性之前会先准备好单元测试，在新特性被加进来之前，测试总是失败。在经过不断的测试和代码修改之后，一个完整的功能被开发出来了，最后再运行测试就能通过。
单元测试的作用不应局限于代码开发，它们也应该被集成到代码合并流程里。GitHub支持一些主流持续集成服务器的状态检查。一般的流程是这样的：保护好“master”分支，不允许开发人员向该分支提交代码，而是让他们把代码提交到其他分支上。在将代码合并到master分支的时候，GitHub要求先通过状态检查。
Jenkins、CircleCI和TravisCI都提供了状态检查钩子（hook），它们会从分支上获取代码并运行单元测试。如果通过了，就允许合并代码，否则就不允许。
总结
单元测试是测试工具箱里的一个非常重要的工具。为了对分布式系统代码进行全面的单元测试，有必要利用一些支持stub的测试框架，用于模拟各种错误场景或外部依赖的各种响应。
