jmeter实现Http接口测试介绍

构建一个测试页面

页面功能测试说到底就是模拟用户浏览点击页面的全过程，很多的测试工具都可以对该过程进行录制后模拟用户操作，而压力测试就是将这个过程在单位时间内重复成千上万次，看检测应用的高可用，接下来就来一步步的构建我们的页面测试计划吧。比如说我们现在有10个用户，每人请求2个页面并且请求2次，总请求次数为10 * 2 * 2 = 40。

第一步，创建模拟用户，实际上就是线程。（ Test Plan（右键） –> 添加 -> Threads -> 线程组），在该页面中可以修改线程组名，在该场景下，将线程数设置为10、循环次数设置为2、ramp-up period设置为1秒（10个线程/1秒 = 10线程每秒，即每秒创建10个线程，设置为0则直接创建）。

（之后相类似截图省略）

第二步，添加默认的http请求属性，在之前创建的线程组User（右键） -> 添加 -> 配置元件 -> Http请求默认值，这个默认值会在所有的http请求中使用，最常见的设置是请求的目标服务器名称或IP，如本机localhost。

第三步，添加cookie的支持，线程组User（右键） -> 添加 -> 配置元件 -> cookie管理器，我们知道Cookie中主要用于存放用户的相关信息，尤其是登录信息，如果不能正确的设置这部分内容，我们请求页面可能会一直把请求跳转到登录页面。

第四步，添加Http请求，这是整个操作的核心，线程组User（右键） -> 添加 -> Sampler –> HTTP请求。比如请求的页面为Home页，路径Path设置为"/"表示根路径，接着再另外添加一个页面及其路径，比如"/Product"。比如针对.NET的Form认证模式，可以通过POST用户名密码到login页面来完成相应的操作。

第五步，最后为请求对应添加监听器用于获取测试结果，线程组User（右键） -> 添加 -> 监听器 –> 图形化结果，只需要指定好文件路径和文件名即可。

补充:

处理通过URL重写的用户会话：如果web应用使用URL重写来代替Cookie保存Session信息的场景下，需要一些额外的操作，使用适当的HTTP URL重写器去完成这部分工作。简单的输入sessionID参数到重写器，它会将该内容添加到每一个请求，如果请求已经有该值，则替换，如果检测是否缓存了Session ID，那么最近的sessionID将被保存并被之前不包含sessionID的请求使用。这而为了控制这个重写器的工作范围，将在该用户（线程）组下建立一个简单控制器，线程组User（右键） -> 添加 -> 逻辑控制器 -> 简单控制器，之后在其中添加一个URL重写器，这个想想也能知道，这应该属于一个前置的拦截器，因而菜单项为, 简单控制器（右键）-> 前置处理器 -> HTTP URL重写操作符，之后设置会话参数名称即可。

Http头管理器(Header Manager): 这部分内容在Web服务时会使用的比较多，应用服务的验签一般是通过请求头中存放token来处理的。

这部分的重点就是：线程数、信息头、信息体、断言（简单的就是对response体属性的判断，复杂的可以使用正则表达式），以及整体的结果树，需要注意在测试模拟时，只用记录错误级别的日志即可，减少对测试环境资源的消耗。还可以安装一个Google开发的插件，会更加的方便,此外，jmeter的Help文档也非常的丰富，需要时查阅即可。

构建一个webservice测试

虽然SOAP协议现在已经不再是搭建公共服务的主流，但毕竟大部分的SOA项目还是使用该协议，因此还是对它进行简要的介绍，这儿的例子用到之前提到的及其方便的模板，文件-> Template模板，选择"Building a SOAP Webservice Test Plan"，创建后的步骤如下所示。

Step1: 在HTTP请求默认参数页或用户定义变量页（不同版本有细微差异）设置指定服务器名或IP。

Step2: 在用户组的Soap请求页，修改Path

Step3: 在该请求下的HTTP请求头管理器中指定SOAPAction（仅用于.NET WebService，其他情况下删除，而JAVA的相关服务包括Weblogic、Axis、JWSDP等）

Step4: 修改之前请求中的Body data即可，一个简单的服务压测就完成了，是不是很棒，哈哈。

Restful Service

这是现在最常见的服务形式，整个操作和以前基本一致，只需要做部分细微修改即可。在HTTP请求页面中，将httpMethod修改为所需方法，Body data设置为指定的数据格式，如Json。最后在Http头管理中将Content-Type选择为指定的数据格式即可，比如application/json。

实践

之前介绍Jmeter的demo应用，现在来介绍其在实际应用中的一些重要知识，首先通过几个问题引入当前的话题。单位时间内平均的用户数量(并发数)是多少?用户的峰值数量是多少？什么时候是比较合适的压力测试的时机（在没有相应替补生产环境的情况下，考虑如何达到接近真实测试的目的）？我们的web应用程序是有状态么，如果有，应用程序是如何管理诸如cookies、session-rewriting等状态对象的？我们的测试目标是什么？

为了达到我们的测试目标，首先需要考虑的搭建测试环境时，申请到相关的资源，比如防火墙、代理服务器等网络问题，CPU的核数、内存的大小等硬件资源问题。此外，考虑使用什么样的操作系统，比如像windows系统其自身就会暂用很多的资源，可能无法模拟出你所需的并发数。这些东西在实际的项目中显得非常重要，因为这些可能不是一个人技术好就可以决定的，需要充分的沟通和合作。如果你需要很多的机器来测试网络延迟，也可以考虑使用云的方式，Jmeter支持商业云PAAS来运行基准测试和压力测试，需要注意的是，在压力测试时，需要运行Jmeter的非GUI版本，GUI版本只是用于创建测试计划和Debug。

本篇内容主要侧重实战，以我们公司主要应用的Http接口为核心讲解。

1、打开Jmeter

主界面介绍：

JMeter的主界面主要分为状态栏、菜单栏、工具栏、树形标签栏和内容栏

状态栏：主要显示JMeter的主版本和release版本。

菜单栏：全部的功能的都包含在菜单栏中。

工具栏：工具栏中的按钮在菜单栏都可以找到，工具栏就相当于菜单栏常用功能的快捷按钮。

树形标签栏：树形标签栏通常用来显示测试用例相关的标签。

内容栏：配合树形标签栏显示，树形标签中点击哪个标签，内容栏中就显示相应的内容和操作。

2、并发请求模拟 ----- 线程组

性能测试主要为了模拟大量并发请求。JMeter使用线程组模拟同时有多个用户并发访问的场景。

在“测试计划”上点击鼠标右键-->添加-->threads(Users)–>线程组，添加测试场景设置组件，接口测试中一般设置为1个“线程数”，根据测试数据的个数设定“循环次数”。

线程组界面介绍：

名称：可以给线程组设置一个个性化的命名
注释：可以对线程组添加备注以标记
在取样器错误后要执行的动作：就是在错误之后要如何执行，可选继续执行后续的、停止执行等。
线程数：就是需要设置多少线程执行测试。
Ramp-up Period （in Seconds）：用于告知JMeter 要在多长时间内建立全部的线程。默认值是0。如果未指定ramp-up period ，也就是说ramp-up period 为零， JMeter 将立即建立所有线程。假设ramp-up period 设置成T 秒，全部线程数设置成N个， JMeter 将每隔T/N秒建立一个线程。
循环次数：就是决定一个线程要跑多少次测试。
Delay Thread creation until needed：直到需要时延迟线程的创建
调度器：选中之后可以配置启动时间，立即或者预定的时间

3、测试场景环境参数设置 ——— “Http请求默认值”组件

当被测系统有唯一的访问域名和端口时，这个组件很好用。

同时更改访问域名和端口时，统一配置数据

“HTTP 请求默认值”组件配置页面

4、添加“HTTP信息头管理器”组件

请求头信息常常需要包含token、session、type等信息。

5、设置“HTTP信息头管理器”

设置默认请求头，可以添加Authorization绕过登录验证；

设置Content-Type指定请求内容类型；

设置charset指定请求字符集等；

6、在“线程组”里添加“HTTP 请求”的Sampler

7、设置“HTTP请求”

在HTTP请求设置页面，录入被测接口的详细信息，包括请求路径，对应的请求方法，以及随请求一起发送的参数列表

8、添加检查点：在被测接口对应的“HTTP 请求”上，添加“响应断言”

9、设置检查点

在设置页面上添加对相应结果的正则表达式存在性判断即可。

10、添加监听器

方便查看运行后的结果

11、查看“聚合报告”

Label：定义的HTTP请求名称
Samples：表示这次测试中一共发出了多少个请求
Average：访问页面的平均响应时间
Median：访问页面的中位数响应时间
90% Line：访问页面的90%响应时间
95% Line：访问页面的95%响应时间
99% Line：访问页面的99%响应时间
Min: 访问页面的最小响应时间
Max: 访问页面的最大响应时间
Error%：错误的请求的数量/请求的总数
Throughput：每秒完成的请求数
KB/Sec：每秒从服务器端接收到的数据量

关于90% Line：

一组数由小到大进行排列，找到他的第90%个数（假如是12），那么这个数组中有90%的数将小于等于12 。

用在性能测试的响应时间也将非常有意义，也就是90%请求响应时间不会超过12 秒。

上述步骤完成了一个简单测试案例的创建，复杂测试案例均在此基础上扩展完成。

使用Jmeter工具开发的接口测试案例，一个子系统建议放在同一个 “测试计划”中，流程测试可以通过“线程组”来区分，这样也便于设定不同的测试数据个数。

比较独立的接口，可以统一放在一个线程组内，顺序完成测试。　　

流程性接口的测试：如果要测试的接口可以组成一个流程，只需要顺序添加多个“HTTP 请求”的Sampler，各请求之间可以提取需要在上下文传递的数据作为参数，以保证流程中数据的一致性。