《全栈性能测试-修炼宝典(JMeter实战)》

前言：什么是性能测试

　　早些年，把录制脚本、制造负载当成是性能测试。近几年，我们把定位、分析问题当成是性能测试的核心技术。现在，我们希望性能测试不仅能够定位、分析问题，还要把握系统性能变化趋势；性能测试工程师能够帮助解决性能问题，搞定测试过程中的各种不合理配置，给出专业的优化建议。

一、性能方向职业发展

1.1 软件测试痛处

　　地位高低在任何行业都是由所掌握的技能或资源的核心价值决定，易代替、无技术含量的职位自然地位低。

　　测试是开发后的附加工作，没有方法量化可见的产出，自然关注者少。测试不能左右一个项目或者产品的方向、技术、工期，在项目中并没有里程碑式的贡献，自然成绩很难突出，成就感也不强。

　　岗位处在工作流的末端。面临需求朝定夕改、且开发导致的缺陷过多，测试的时间越来越不够。在不增加测试资源的情况下加班赶工在所难免。

1.2 不仅仅是性能测试

　　全栈一般是技术方面的领导者，需要涉猎广。懂得如何解决问题以及对应所需的技术和工具。但具体的细节掌握比不上某个学科精专的。但是他们有强大的学习能力，会较多依赖搜索或即时学习，会根据需求，依托自己扎实的基础功底，把某一项或者二项技能达到或接近于专科人员的能力。

　　全栈是学习能力强，总结能力强、不断总结和融会贯通提高实战能力。善于分析因果并找到原因和解决方案的复合人才。

全栈除了测试之外还需要掌握哪些基本功：

　　需求

　　我们的行业存在的根本在于实现用户的业务需求。在实际的性能需求分析过程中，系统分析师必须清醒地认识到客户很难区分业务需求和用户需求的差别，搞清楚客户背后的真正的业务需求。

　　代码

　　想要在测试行业中脱颖而出的关键还是技术，流行的一句话：测试人员懂开发最好，开发人员懂测试最好，自然更受欢迎，价值更高；也就是技术不错，能够跨界。

　　运维

　　测试自动化是一个趋势，掌握运维手段也变成必要。

1.3 性能调优技能

　　面对一个性能不佳且复杂的系统，我们做的是建立性能数据分析模型、收集相关资源和指标信息、分析这些数据背后可能的原因。

　　所以性能测试最难的就是定位性能瓶颈。

　　另外性能优化是一个系统工程，内容涉及系统各方面，从上到下有软件产品（项目）、中间件、虚拟机、操作系统、硬件。软件产品有系统架构、业务涉及、代码实现、数据库物理设计和数据库各种配置等。所以想要做好性能调优，不仅仅是一个人的事，而是整个项目团队的事。

1.4 小结

　　科技是第一生产力，对选择技术方向的从业者来说技术是第一生产力。

二、性能测试初体验

　　性能测试是一项综合性的工作，致力于暴露性能问题，评估系统性能趋势。

　　性能测试工作实质上是利用工具去模拟大量用户操作来验证系统能够承受的负载情况，找出潜在的性能问题，分析并解决；找出系统性能变化趋势，为后续的扩展提供参考。

2.1 性能测试流程

　　待补充

2.2 性能测试成功与失败要素

　　待补充

2.3 性能测试相关术语

负载

　　模拟业务操作对服务器造成压力的过程，比如模拟100个用户进行发帖。

性能测试（performance Testing）

　　模拟用户负载（一定的负载）在测试系统在负载情况下，系统的响应时间、吞吐量等指标是否满足性能要求。

　　是指通过模拟生产运行的业务压力或用户使用场景来测试系统的性能是否满足生产性能的要求。
　　性能测试是一种“正常”测试，主要测试使用时系统是否满足要求，同时可能为了保留系统的扩展空间而进行的一些稍稍超过“正常”范围的测试（比如：当前系统使用用户100人，可能未来人数会增多到300人，所以要让系统能够在300人情况下正常运行）

负载测试（load testing）

　　在一定软硬件环境下，通过不断加大负载（不同虚拟用户数）来确定在满足性能指标情况下能够承受的最大用户数（超负荷）。简单说，可以帮我们对系统进行定容定量，找出系统性能的拐点，给与生产环境规划建议。这里的性能指标包括 TPS（每秒事务数）、RT（事务平均响应时间）、CPU Using（CPU利用率）、Mem Using（内存使用情况）等软硬件指标。从操作层面上来说，负载测试也是一种性能测试手段，比如下面的配置测试就需要变换不同的负载来进行测试。

　　是通过逐步增加系统负载，测试系统性能的变化，并在满足最终确定性能指标的情况下，系统所能承受的最大负载量的测试

　　性能指标：是系统应该满足的，比如请求响应时间等

　　负载测试是正常范围的测试　　

　　通过负载测试得到系统的负载模型，找到“性能拐点”和“有效峰值”

配置测试（Configuration Testing）

　　为了合理地调配资源，提高系统运行效率，通过测试手段来获取、验证、调整配置信息的过程。通过这个过程我们可以收集到不同配置反映出来的不同性能，从而为设备选择、设备配置提供参考。

压力/强度测试（Stress Tesing）

　　是在一定的负荷条件下，长时间连续运行系统给系统性能造成的影响。

　　压力测试的目标是测试在一定的负载下系统长时间运行的稳定性，尤其关注大业务量情况下长时间运行系统性能的变化（例如是否反应变慢、是否会内存泄漏导致系统逐渐崩溃、是否能恢复）；

　　压力测试是测试系统的限制和故障恢复能力，它包括两种情况：

　　稳定性压力测试：在选定的压力值下，长时间持续运行。通过这类压力测试，可以考察各项性能指标是否在指定范围内，有无内存泄漏、有无功能性故障等；

　　破坏性压力测试：在稳定性压力测试中可能会出现一些问题，如系统性能明显降低，但很难暴露出其真实的原因。通过破坏性不断加压的手段，往往能快速造成系统的崩溃或让问题明显的暴露出来；　　

最简单来说：
负载测试是测试软件本身最大所能承受的性能测试；
压力测试就是一种破坏性的性能测试；

稳定性测试（Endurance Testing）

　　在一定的软硬件下，长时间运行一定负载，确定系统在满足性能指标的前提下是否运行稳定。与上面的压力/强度测试区别在于负载并不强调是在极限状态下（很多测试人员会持保守观念，在测试时会验证极限状态下的稳定性），着重的是满足性能要求的情况下，系统的稳定性、比如响应时间是否稳定、TPS是否稳定。一般我们会在满足性能要求的负载情况下加大 1.5 到 2 倍的负载量进行测试。

TPS

　　每秒完成的事务数。通过指每秒成功的事务数，性能测试中重要的综合性性能指标。一个事务是一个业务度量单位，有时一个事务会包括多个子操作，但为了方便统计，我们会把这多个子操作计为一个事务。比如一笔电子支付操作，在后台系统中可能会经历会员系统、账务系统、支付系统、会计系统、银行网关等，但对于用户来说只想知道整笔支付花费了多长时间。

RT/ART（Respone Time/average Response Time）

　　响应时间/平均响应时间，指一个事务花费多长时间完成（多长时间响应可以请求），为了使这个响应时间更具代表性，会统计更多的响应时间然后取平均值，即得到了事务平均响应时间（ART），为了方便大家通常会直接用 RT 来代替 ART ，ART 与 RT 是代表同一个意思。

　　响应时间 = 客户端 + 服务器端 + 网络（性能工具拿到的是后两个数据）

PV（Page View）

　　每秒用户访问页面的次数，此参数用来分析平均每秒有多少用户访问页面

Vuser虚拟用户（Virtual user）

　　模拟真实业务逻辑步骤的虚拟用户，虚拟用户模拟的操作步骤都被记录在虚拟用户脚本里。Vuser 脚本用户描述 Vuser 在场景中执行的操作

　　并发用户数和在线用户数。并发，操作的，对系统造成压力的。在线的，有可能只是挂着系统，但是没有实际操作，对系统几乎没有压力。

Concurrncy并发

　　并发分为狭义和广义两类。狭义的并发，即所有的用户在同一时刻做同一件事情或操作，这种操作一般针对同一类型的业务，或者所有用户进行完全一样的操作，目的是测试数据库和程序对并发操作的处理。广义的并发，即多个用户对系统发出了请求或者进行了操作，但是这些请求或操作可以是不同的。对整个系统而言，仍然有很多用户同时进行操作。狭义并发强调对系统的请求操作是完全相同的，多适用于性能测试、负载测试、压力测试、稳定性测试场景；广义并发不限制对系统的请求操作，多适用于混合场景，稳定性场景

场景（Scenario）

　　性能测试过程中为了模拟真实用户的业务处理过程，在LoadRunner中构建的基于事务、脚本、虚拟用户、运行设置、运行计划、监控、分析等一系列动作的集合，称之为性能测试场景。场景中包含了待执行脚本、脚本组、并发用户数、负载生成器、测试目标、测试执行时的配置条件等。

思考时间（Think Time）

　　模拟正式用户在实际操作时的停顿间隔时间。从业务的角度来讲，思考时间指的是用户在进行操作时，每个请求之间的间隔时间。在测试脚本中，思考时间体现为脚本中两个请求语句之间的隔间时间。

标准差（Std. Deviation）

　　该标准差根据数理统计的概念得来，标准差越小，说明波动越小，系统越稳定，反之，标准差越大，说明波动越大，系统越不稳定。包括响应时间标准差、TPS标准差、Running Vuser标准差、Load标准差、CPU资源利用率标准差、Web Resources 标准差等。

点击数

　　点击数不是鼠标点击次数，是发送的请求数

吞吐量

　　单位时间内被测系统处理的业务或者请求的数量

PV和UV
　　PV：访问一个URL，产生一个PV（Page View，页面访问量），每日每个网站的总PV量是形容一个网站规模的重要指标。
　　UV：作为一个独立的用户，访问站点的所有页面均算作一个UV（Unique Visitor，用户访问）

压力测试与负载测试两者区别

相同点：都是性能测试
负载测试强调系统正常工作情况下的性能指标
压力测试的目的是发现在什么条件下系统的性能变得不可接受，发现应用程序性能下降的拐点。

举例：工人建桥，桥身上表明，该桥的最大负重量为60吨。—负载测试
该桥的内部建筑资料中，表明该桥的最大载重量为70吨。这个数据是给内部建桥工程师掌握的。—压力测试

无论使用测试工具还是模拟，本质上市通过一个程序去测试另一个程序。
负载测试一般包括5个阶段：规划、创建脚本、定义场景、执行场景和分析结果

2.4 性能测试通过标准

　　性能测试通过标准包括服务器性能、前端性能和用户体验性能。常规通过标准如下表

Web 项目性能测试通过标准
类别	判断维度	不通过	通过	备注
通过互联网服务端性能	超时概率	大于 0.5‰	小于0.5‰	性能测试团队根据通过标准，判断被测性能点不通过。没有绝对的标准，由专家组或项目负责人来评判
	错误概率	大于 0.5‰	小于0.5‰	网页响应时间一般根据（1s-优秀，3s-普通，5s-忍受极限）来判断。5s 为客户忍受上限，特殊功能另议
	TPS	小于期望高峰值	大于期望高峰值
	CPU 利用率	大于75％	小于75％
	响应时间	大于期望时间	小于期望时间
	Load	平均每核 CPU 的 Load 大于1	平均每核 CPU 的 Load 小于1
	JVM 内存使用率	大于 80%	小于 80%
	Full GC频率	平均小于半小时 1 次	平均大于半小时 1 次
前端页面性能	YSlow 评定	YSlow 评定为 C 级以下	YSlow 评定为 C 级，或 C 级以上

性能测试工具通过模拟协议模拟压力

测试计划的元素执行是有序的，通过以下方式执行：

1-配置结点

2-前置处理器

3-定时器

4-取样器

5-后置处理器（只在有结果可用情况下执行）

6-断言（只在有结果可用情况下执行）

7-监听器（只在有结果可用情况下执行）

一、简介

1.1 Jmeter是啥？

Apache JMeter是Apache组织的开放源代码项目，是一个纯Java桌面应用，用于压力测试和性能测试。它最初被设计用于Web应用测试但后来扩展到其他测试领域。

Jmeter不是浏览器，它只负责发出请求和接收请求，不运行JavaScript，不包括渲染。

1.2 Jmeter有啥用？

Apache JMeter可以用于对静态和动态的资源（文件，Servlet，Perl脚本，Java对象，数据库和查询，FTP服务器或是其他资源）的性能进行测试。JMeter可以用于分析不同压力条件下的总体性能情况。
也可以使用JMeter提供的图形化界面，分析性能指标或者在高负载情况下测试你的服务器，脚本，对象。

1.3 配置好JDK

　　建议安装JDK环境，虽然JRE也可以，但是压测https需要JDK里面的 keytool工具。压测需要HTTPS

　　JDK环境：http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

安装，这里使用的操作系统是Windows，选最后一个下载，下载完直接运行安装。安装完设置一下环境参数。

JAVA_HOME：D:\Program Files (x86)\Java\jdk1.8.0_131（jdk安装在哪个盘就写哪个路径）
Path：%JAVA_HOME%\bin;%JAVA_HOME%\jre\bin
Classpath：%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar

打开cmd，运行java –version，能得到下面的输出就表示配置正确了。

目前都是自动配置的。

1.4 安装JMeter

http://jmeter.apache.org/download_jmeter.cgi

下载解压就行。

1.4.1 Bin 目录文件

bin:核心可执行文件，包含配置
            jmeter.bat: windows启动文件：
            jmeter: mac或者linux启动文件：
            jmeter-server：mac或者Liunx分布式压测使用的启动文件
            jmeter-server.bat：mac或者Liunx分布式压测使用的启动文件
            jmeter.properties: 核心配置文件
            
            

extras：插件拓展的包
lib:核心的依赖包
　　ext:核心包
　　junit:单元测试包

1.5 中英文切换

1.5.1 控制台修改（暂时）

1.5.2 配置文件修改

　　D:\apache-jmeter-4.0\bin（此目录为安装目录）下的 jmeter.properties 文件。37行默认为 #language=en 改成language=zh_CN，现在默认中文，要改成英文的话，把#去掉即可

二、Jmeter功能概要

2.1 Jmeter 工具组成部分

2.1.1 资源生成器

　　用于生成测试过程中服务器、负载机的资源代码。（LR中的VuGen）

2.1.2 用户运行器

　　通常是一个脚本运行引擎，根据脚本要求模拟指定的用户行为。（LR中的Controller）

2.1.3 报表生成器

　　根据测试中实时地的数据生成报表，提供可视化的数据显示方式。（LR中的Analysis）

2.1.4 负载发生器

　　用于产生负载，通常以多线程或是多进程的方式模拟用户行为。（LR中的Load Generators）

2.1.5 Test Plan（测试计划）

　　用来描述一个性能测试，包含与本次性能测试所有相关的功能。也就是说本次性能测试的所有内容是基于一个计划的。

2.2 Threads（Users）线程用户

2.2.1 setUp thread group

　　一种特殊类型的 ThreadGroup，可用于执行预测试操作。这些线程的行为完全像一个征程的线程组元件。不同的是，这些类型的线程执行测试前进行定期线程组的执行。

2.2.2 teardown thread group

　　一种特殊类型的ThreadGroup，可用于执行测试后动作。这些线程的行为完全像一个正常的线程组元件。不同的是，这些类型的线程执行测试结束后执行定期的线程组。

2.2.3 thread group（线程组）

　　这个就是我们通常添加运行的线程。可以看做一个虚拟用户组，线程组中的每个线程都可以理解为一个虚拟用户。线程组中包含的线程数量在测试执行过程中是不会发生改变的。

2.3 测试片段（Test Fragment）

　　测试片段元素是控制器上的一种特殊的线程组。它在测试树上与线程组处于一个层级。它与线程组不有所不同，因为它不被执行，除非它是一个模块控制器或者是被控制器所引用时才会被执行。

　　以下是线程组的 8 类可执行元件

2.4 配置元件（Config Element）

　　配置元件（config element）用于提供对静态数据配置的支持。如 CSV Data Set config 可以将本地数据文件形成数据池（Data Pool）

2.5 定时器（Timer）

　　定时器（Timer）用于操作之间设置等待时间，等待时间是性能测试中常用的控制客户端QPS的手段。JMeter定义了 Bean Shell Timer、Constant Throughput Timer、固定定时器等不同类型的Timer。

2.6 前置处理器（Per Processors）

　　用于在实际的请求发出之前对即将发出的请求进行特殊处理。例如，HTTP URL 重写修复符则可以实现URl重写，当URL中有sessionID一类的session信息时，可以通过该处理器填充发出请求的实际的sessionID。

2.7 后置处理器（Post Processors）

　　用于对Sampler发出请求后得到的服务器响应进行处理。一般用来提取响应中的特定数据。

2.8 断言（Assertions）

　　断言用于检查测试中得到的相应数据等是否符合预期，断言一般用来设置检查点，用以保证性能测试过程中的数据交互是否与预期一致。

2.9 监听器（Listener）

　　是用来对测试结果数据进行处理和可视化展示的一系列元件。图形结果、查看结果树、聚合报告。都是我们经常用到的元件。注意：这个监听器可不是用来监听系统资源的元件。

　　JMeter有两种类型的控制器：取样器（sample）和逻辑控制器（Logic Controller），用这些原件来驱动处理一个测试。

2.10 取样器（sample）

　　取样器（Sample）是性能测试中向服务器发送请求，记录响应信息，记录响应时间的最小单元，JMeter原生支持多种不同的sampler，如HTTP Request Sampler、FTP Request Sample、TCP Request Sample、JDBCRequest Sampler等，每一种不同类型的 sampler 可以根据设置的参数向服务器发出不同类型的请求。

2.11 逻辑控制器

　　逻辑控制器，包括两类元件，一类是用于控制test plan 中 sampler 节点发送请求的逻辑顺序的控制器，常用的有如果（if）控制器、switch Controller 、Runtime Controller、循环控制器等。另一类是用来组织可控制 sampler 来节点的，如事务控制器、吞吐量控制器。

三、badboy

3.1 脚本录制

下载：http://www.badboy.com.au

　　badboy是一个强大的工具，旨在帮组测试和开发复杂的动态应用。Badboy包括一个简单而全面的捕获/回放界面，强大的负载测试的支持，详细的报告图表等等，从而使Web测试和开发变得更加容易。

弹窗问题

　　访问者所使用的浏览器不能完全支持页面里的脚本，形成“脚本错误”。遇到“脚本错误”时一般会弹出一个非常难看的脚本运行错误警告窗口，而事实上，脚本错误并不会影响网站浏览，因此这一警告可谓多此一举。要关闭警告则可以在浏览器的工具菜单选择Internet选项，然后单击高级属性页。进入到浏览标签，并选中“禁止脚本调试”复选框，以后你就不会再收到这些警告了。

3.2 badboy检查点与参数化

　　检查点设置：选择要检查的文字，然后在Tools>step1里添加断言，再回放。

四、Jmeter元件作用于和执行顺序

4.1 元件作用域

　　8类可被执行的元件（测试计划与线程组不属于可执行元件），这些元件中，取样器（samlper）是典型的不与其他元件发生交互作用的元件，逻辑控制器只对其子节点的取样器有效，而其他元件（配置元件、定时器、断言、监听器）需要与取样器（sampler）等元件交互。

　　在jmeter中，元件的作用域是靠测试计划的树型结构中元件的父子关系来确定的，作用域的原则是：

　　取样器（sampler）元件不和其他元件相互作用，因此不存在作用于的问题。

　　逻辑控制器（Logic Controller）元件只对其子节点中的取样器和逻辑控制器作用。

　　除取样器和逻辑控制器元件外，其他6类元件，如果是某个取样器的子节点，则该元件对其父子节点起作用。如果其父节点不是取样器，则其作用于是该元件父节点下的其他所有后代节点（包括子节点、子节点的子节点等）。

4.2 元件执行顺序

配置元件
前置处理程序
定时器
取样器
后置处理程序
断言
监听器

　　前置处理器、后置处理器和断言等元件功能对取样器作用，因此，如果在它们的作用域内没有任何取样器，则不会被执行。

　　如果在同一作用域范围内有多个同一类型的元件，则这些元件按照它们在测试计划中的上下顺序依次执行。

五、Jmeter 性能测试基础实战

　　测试需求：测试 20个用户访问 http：http://www.qiakr.com/t 在载达到30 QPS时的平均响应时间。

QPS：Query Per Second 每秒查询率。是一台查询服务器每秒能够处理的查询次数。在因特网上，作为域名系统服务器的性能经常用每秒查询率来衡量。

5.1 测试步骤

5.1.1 第一步：添加线程组

　　线程组主要包含三个参数：线程数、准备时长（Ramp-Up Period（in seconds））、循环次数。

　　线程数：虚拟用户数。一个虚拟用户占用一个进程或线程。设置多少虚拟用户数在这里也就是设置多少个线程数。

　　准备时长（单位为s）：设置的虚拟用户数需要多长时间全部启动。如果线程数为20，准备时长为10，那么需要10秒钟启动20个线程，也就是每秒钟启动2个线程。

　　循环次数：每个线程发送请求的次数。如果线程数为20，循环次数为5，那么每个线程发送5次请求。总请求数为20*5=100.如果勾选了“永远”，那么所有线程会一直发送请求，一到选择停止运行脚本。

5.1.2 增添HTTP请求

　　一个HTTP请求有着许多的配置参数，下面将详细介绍：

名称：本属性用于表示一个取样器，建议使用一个有意义的名称
注释：对于测试没有任何作用，仅用户记录用户可读的注释信息。
服务器名称或IP：HTTP请求发送的目标服务器名称或IP地址。
端口号：目标服务器的端口号，默认值为80.
Timeouts（milliseconds）：设置请求和响应的超时时间。
方法：发送HTTP请求的方法，可用方法包括GET、POST、HEAD、PUT、OPTIONS、TRACE、DELETE等。
Content encoding：内容的编码方式，默认值为iso8859.
路径：目标URL路径（不包括服务器地址和端口）
自动重定向：如果选中该选项，当发送HTTP请求后得到的响应是302/301时，JMeter自动重定向到新的页面。
Use keep Alive：当该选项被选中时，jmeter和目标服务器之间使用keep-Alive方式（又称持久连接、连接重用）进行HTTP通信，默认选中。
Use multipart/from-data for HTTP POST：当发送HTTP POSt请求时，使用Use multipart/from-data 方法发送，默认不选中
同请求一起发送参数：在请求中发送URL参数，对于带参数的URL，jmeter提供了一个简单的对参数化的方法。用户可以将URL中所有参数设置在本表中，表中的每一行是一个参数值对（对应URL中的名称1 = 值1）。
同请求一起发送文件：在请求中发送文件，通常HTTP文件上传行为可以通过这种方式模拟。

　　从HTML文件获取所有有内容的资源：当该选项被选中时，jmeter在发出HTTP请求并获得响应的HTML文件内容后，还对该HTML进行分析并获取HTML中包含的所有资源（图片、flash等），默认不选中，如果用户只希望获取页面中的特定资源，可以在下方的Embedded URLs must match文本框中填入需要下载的特定资源表达式，这样，只有能匹配指定正则表达式的URL指向资源会被下载。

　　用作监视器：此取样器被当成监视器，在Monitor Results Listener 中可以直接看到基于该取样器的图形化统计信息。默认不选中。

　　Save response as MD5 hash？：选中该项，在执行时仅记录服务端响应数据的MD5值，而不记录完整的响应数据。在需要进行数据量非常大的测试时，建议选中该项以减少取样器记录响应数据的开销。

5.1.3 第三步：设置QPS限制

　　Jmeter提供了一个非常有用的定时器，称为Constant Throughput Timer（常数吞吐量定时器），该定时器可以方便地控制给定的取样器发送请求的吞吐量。

Constant Throughput Timer 的主要属性介绍：

　　Target throughput（in samplers per minute）：目标吞吐量。注意这里是每分钟发送的请求数，实际填的数值为：60*QPS。

　　其次，Calculate Throughput based on 有5个选项，分别是：

This thread only：控制每个线程的吞吐量，选择这种模式时，总的吞吐量为设置的 target Throughput 乘以该线程的数量。
All active threads：设置的 target Throughput 将分配在每个活跃线程上，每个活跃线程在上一次运行结束后等待合理的时间后再次运行。活跃线程指同一时刻同时运行的线程。
All active threads（shared）：与All active threads的选项基本相同，唯一的区别是，每个活跃线程都会在所有活跃线程上一次运行结束后等待合理的时间后再次运行。
All active threads in current thread group：设置的target Throughput将分配在当前线程组的每一个活跃线程上，当测试计划中只有一个线程组时，该选项和All active threads选项的效果完全相同。
All active threads in current thread group（shared）：与All active threads in current thread group基本相同，唯一的区别是，每个活跃线程都会在所有活跃线程的上一次运行结束后等待合理的时间后再次运行。

5.1.4 添加监视器

　　脚本的主要部分设置完成后，需要通过某种方式获得性能测试中的测试结果，在本例中，我们关系的是请求的响应时间。

　　Jmeter中使用监听器元件收集取样器记录的数据并以可视化的方式来呈现。Jmeter有各种不同的监听器类型，因为上HTTP请求，我们可在添加聚合报告，更为直观的查看测试结果。

　　添加聚合报告，右键点击线程组，在弹的菜单（添加--->监听器-->聚合报告）中选择聚合报告。

5.1.5 运行脚本

　　如果出现403，网址有做一个保护，即对网站请求源做了保护，如果是来源不明的请求就会拒绝访问（防止爬虫什么的），所以需要在jmeter中添加模拟浏览器的信息。

　　模拟浏览器的信息是存在了User-Agent中，这个参数在百科中的解释：User Agent中文名为用户代理，简称 UA，它是一个特殊字符串头，使得服务器能够识别客户使用的操作系统及版本、CPU 类型、浏览器及版本、浏览器渲染引擎、浏览器语言、浏览器插件等。

　　一些网站常常通过判断 UA 来给不同的操作系统、不同的浏览器发送不同的页面，因此可能造成某些页面无法在某个浏览器中正常显示，但通过伪装 UA 可以绕过检测。

5.1.6 聚合报告分析

Term	Definition
Label	每个JMeter的element（例如 HTTP Request）都有一个Name属性，这里显示的就是Name属性的值
#Samples	表示你这次测试中一共发出了多少个请求，如果模拟10个用户，每个用户迭代10次，那么这里显示100
Average	平均响应时间--默认情况下是单个Request的平均响应时间，当使用了Transaction Controller时，也可以以Transaction为单位显示平均响应时间
Median	中位数，也就是50%用户的响应时间
90%Line	90%用户的响应时间
Min	最小响应时间
Max	最大响应时间
Error%	本次测试中出现错误的请求的数量/请求的总数
Throughput	吞吐量---默认情况下表示每秒完成的请求数（Request per Second）。
KB/sec	每秒从服务器端接收到的数据量。