Jmeter实现接口测试

利用Jmeter做接口测试怎么做呢？过程真的是超级简单。

明白了原理以后，把零碎的知识点填充进去就可以了。所以在学习的过程中，不管学什么，我一直都强调的是要循序渐进，和明白原理和逻辑。这篇文章就来介绍一下如何利用Jmeter做接口测试的流程，主要针对的是功能测试。暂不涉及到自动化测试和性能测试的内容。

一把来说，主要的步骤都大差不差。

第一步：通过分析API文档和需求文档提取接口清单 。

也就是说，接口测试工作人员工作的开始就是从API文档和需求文档开始的。所以进入公司的第一件事情就是要拿到API文档和需求文档来了解，来看，来分析。从其中提取接口清单的话，主要是因为API文档中有很多冗余，不必要的信息。这些信息可能对于开发人员是有用的，但是对于我们测试人员是没有用的，所以要去除冗余，提取关键信息。

那么怎么提取呢？方法也很简单，从功能模块和方法模块对API文档中的内容进行提炼，提炼的关键是接口三要素：url+方法+参数+返回值。我的建议是可以先将所有的url提取出来，基本上一个url就是对应一个接口的，这样一条线把整体拎起来，就感觉混乱的局面清晰多了。

当然工作中，有的时候我们是可以直接拿到接口清单的，因为清单这个事情一个团队做一份就好了，并不是说要每个人都做一份。但是我们自己得会，得有这个能力。之前看到过一个面试题，问的是，如果没有API文档，怎么做接口测试？

其实问的就是如果没有API文档，应该怎么提取接口清单的问题。很简单，根据需求文档和原型图来提取。有的公司不正规，确实是没有API文档的。或者有的公司API文档写的不规范，那提取的时候，就很考验测试人员的经验和能力了。所以如果能找到遵循restful风格写的优秀API文档，那就好了，提取的时候很方便。

第二步：针对接口清单，做单接口测试和关联接口测试。

在实际测试过程中，单接口测试和关联接口测试的时间是不一样的，这涉及到业务逻辑测试和功能点测试等。但是在测试的时候，他们的逻辑和方法是类似的。

当然这里主要介绍的是单接口测试，因为单接口测试时会考虑各种可能的情况，而关联接口测试一般是建立在单接口没有问题的前提下的。换个角度来说，就相当于是两个层次，单接口测试是基础，而关联接口测试是拔高。

那么具体应该怎么做呢？比如我们这里已经选定而来某一个接口来测试。

首先，根据选定的接口来搭建测试框架 。

接口不是什么大不了的事情，无非就是url、方法、参数、返回数据这四块。这样就意味着，一个接口的框架是固定的，只不过每次传输的数据和返回的数据可能会不一样而已。所以我们要做的第一步就是搭建测试框架。

那么怎么搭建呢？这里就要用到从API文档中整理出来的接口清单和Jmeter了。从接口清单里，可以拿到当下接口的url+方法+参数+预期返回数据。这就是我们搭建测试框架的依据。接下来用Jmeter搭建。

首先需要打开Jmeter，然后基于测试计划，创建线程组，基于线程组创建HTTP请求。考虑到单接口测试，一个框架，要测试N多个数据，而且后面的接口可能也要用到同样的ip地址、同样的content-type，所以一般会先创建一个HTTP请求默认值，将一些可能会重复用到的信息填进去，比如说端口号、协议之类的。如有必要还需要添加HTTP信息头管理器，放一些user-agent、content-type等内容。

好的，有了这两个基础就可以来创建HTTP请求。在新的请求里，已经填写的端口号呀、ip地址呀之类的就无需填写了，只需要填写方法之类的即可。那么搭建框架在哪里搭建呢？一般会考虑para或者body里。比如说，要提交一段json格式的数据，那么就要用body（消息体）来提交，如下图所示。

将从接口清单里拿到的json数据填写到消息体数据里，然后将需要不断传入的数据进行参数化设置，那搭建测试框架就算是完成了。接下来只需要把数据一条一条传入进行测试即可。

那么如何把数据进行传入呢？

其实我们在下面的这篇文章里已经介绍了，传入数据的方法有四种，但主要使用的还是csv data set config 和函数。做功能接口测试，用csv就足够了。那么具体怎么用呢？

星空下：软件接口测试工具Jmeter使用核心详解12 赞同 · 0 评论文章

基于当前的线程组或者请求创建CSV数据文件配置组件。如果这份数据只有这一个请求会用，那么就基于请求创建即可。如果这份数据会被这个线程组里的多个请求使用，那么就基于线程组创建。

创建了以后就需要填入文件了呢？可是文件在哪里呢？这个时候就要稍微停一下jmeter的 *** 作，先去针对当前接口设计测试用例并形成有关文档了。有关于功能接口测试的用例设计，我们之后会专门用一篇文章来介绍，这里先带过。这是因为设计测试用例是做测试过程中最核心的一步。

在测试用例设计完之后，可以将其保存在一个txt文档里，采用utf-8编码，保存到Jmeter脚本的同一父目录下。然后按照上面那篇文章里的设置方法进行设置即可，注意路径可以采用相对路径，便于数据文件的拷贝和使用。

csv组件设置好以后，数据源有了，变量名有了，变量名的赋值也有了，接下来就只剩引用参数就可以了。在测试框架里需要引用参数的地方引用，引用的格式是${参数名}。到这里，针对于某一个接口的测试工作就准备完成了。

然后在Jmeter里面添加查看结果树组件，执行请求，依次查看结果 。看一看返回的数据和我们的预期结果是否一致，不一致，那可能就是一个bug。

做一个小小的总结吧，用jmeter做功能接口测试，其实很简单的。逻辑和原理都是类似的，如果遇到新的项目，可能说会用一些新的组件而已，那百度一下几分钟的事情。在学习软件测试的时候，最重要的就是不要怂，不要看起来说怎么要学的东子这么杂这么多，只要能够拎出其中的线索和主干，然后把一些零碎的点给组装上去，就会感觉，哇，忽然之间，好有条理。

在进行网页或应用程序后台接口开发时，一般要及时测试开发的接口能否正确接收和返回数据，对于单次测试，Postman插件是个不错的Http请求模拟工具。

但是Postman只能模拟单客户端的单次请求，而对于模拟多用户并发等性能测试，就必须借助其他的工具了，这里推荐功能强大的JMeter自动化测试工具

Apache JMeter - Apache JMeter™

Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试，它最初被设计用于Web应用测试但后来扩展到其他测试领域。 它可以用于测试静态和动态资源例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库， FTP 服务器， 等等。JMeter 可以用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下测试它们的强度和分析整体性能。

下面就以上图的Restful类型的接口为例简单介绍使用Jmeter进行接口测试的方法。

获取某个具体网关设备的基本信息。

请求

方法：GET

URI：/api/gateway/<gateway_id>

参数：

在HTTP请求（http request）的头部（header）添加Userid和Token字段作为用户验证字段

响应

返回值：JSON格式的网关信息

参数：

.启动jmeter：在bin下以管理员身份运行jmeter.bat，启动jmeter

2. 创建测试计划：

默认启动jmeter时会加载一个测试技术模板，保存测试计划：修改名称为Apitest,点击保存，选择保存路径,后面的步骤，每次添加或修改了了一些选项，软件并不会自动保存到jmx文件中，所以进行测试后，如果需要保存本次测试选项，要手动到“文件”菜单中保存一下。

3. 添加线程组

右键左边树中的测试计划“Apitest”节点，“添 加”→”Threads”→”线程组”

添加成功后，“Apitest”节点下多了“线程组” 节点,当然这个线程组的名称是可以自己设定的。

4. 添加http默认请求：（用来配置公共参数,不是http请求）

右键线程组，选择“添加”→ “配置元件”→“HTTP请求默认值”，点击“HTTP请求默认值”后

添加成功后，线程组”节点下多了“HTTP请求默认值”节点

这里可以设置主机地址等一下公共参数，比如我们的例子中请求路径前面都是主机地址+index.php,就可以统一在"http请求默认值"里设置

填写默认请求名、服务器、默认请求路径，保存测试计划。

5.添加http请求信息头

这一项并不是必须的，只不过我们的例子中使用了Userid和Token放在HTTP请求头中用作用户验证

右键“Apitest”，选择“添加”→ “配置元件”→“HTTP信息头管理器”

6. 添加http请求

右键“Apitest”，选择“添加”→ “Sampler”→“HTTP请求”

添加成功后，出现新的节点“HTTP请求”，就可以填写具体的请求参数了。

填写完成，保存测试计划

7. 添加监听器：

右键线程组，选择“添加”→“监听器”→“XXXXXXXXX”

可以添加的监听器有很多种，可以添加多个监听器，这里我们添加几个常用的“图形结果”、“察看结果树”、“聚合报告”

添加成功后，“线程组”下增加了几个节点

8. 试运行

点击执行

可以查看各个“监听器”的结果

Label：每个 JMeter 的 element（例如 HTTP Request）都有一个 Name 属性，这里显示的就是 Name 属性的值

#Samples：表示你这次测试中一共发出了多少个请求，如果模拟10个用户，每个用户迭代10次，那么这里显示100

Average：平均响应时间——默认情况下是单个 Request 的平均响应时间，当使用了 Transaction Controller 时，也可以以Transaction 为单位显示平均响应时间

Median：中位数，也就是 50％ 用户的响应时间

90% Line：90％ 用户的响应时间

Note：关于 50％ 和 90％ 并发用户数的含义，请参考下文

http://www.cnblogs.com/jackei/archive/2006/11/11/557972.html

Min：最小响应时间

Max：最大响应时间

Error%：本次测试中出现错误的请求的数量/请求的总数

Throughput：吞吐量——默认情况下表示每秒完成的请求数（Request per Second），当使用了 Transaction Controller 时，也可以表示类似 LoadRunner 的 Transaction per Second 数

KB/Sec：每秒从服务器端接收到的数据量，相当于LoadRunner中的Throughput/Sec

9. 修改线程组的线程数等参数，用于压力测试

点击左侧树形导航中的“线程组”

设置上面几个参数，模拟的总的请求数是：线程数*循环次数。执行一下，用“图形结果”监听器查看一下

样本数目：总共发送到服务器的请求数.

最新样本：代表时间的数字,是服务器响应最后一个请求的时间.

吞吐量：服务器每分钟处理的请求数.

平均值：总运行时间除以发送到服务器的请求数.

中间值：时间的数字,有一半的服务器响应时间低于该值而另一半高于该值.

偏离：服务器响应时间变化、离散程度测量值的大小,或者,换句话说,就是数据的分布.

说明：最近在做老系统的接口自动化，老系统的接口欠缺维护；我一步步梳理清楚业务主流程，然后对主流程接口在jmeter上进行验证（顺便做下单接口的并发，下期讲），接口流程跑通后，就可以直接快速编写接口自动化测试用例啦

涉及知识点：登录、获取token、设置token为全局变量

步骤适合有点基础的同学

首先登录、然后提取登录接口返回参数 [多个参数使用json提取器，使用规则见下图]；

将接口默认设置配置元件中，最后将token设置为全局变量 [ 脚本见下图]

一、Response Assertion（响应断言）

二、Size Assertion（数据包字节大小断言）

判断响应结果是否包含正确数量的byte。可定义（=, !=, >, <, >=, <=）

三、Duration Assertion（持续时间断言）

判断是否在给定的时间内返回响应结果（ms）

四、beanshell 断言（自由断言）

---