使用JMETER进行REST API测试

我确定你在这里是因为你需要加载测试Json Rest API。这并不奇怪，因为Rest API现在越来越受欢迎。

这本指南的目的：帮助您进行负载测试一个Json的 REST API 通过一个具体的例子，OctoPerf的Json的REST API。

本指南将完全为您提供以下知识：

使用Http POST请求处理Rest API API登录，
从Json Response中提取变量，稍后在脚本中重用它，
并使用JMeter Json Assertion（在JMeter 4中引入）验证Json响应。

这里没有理论，只有实践：一切都基于一个现实的Rest API（不是一个虚拟的例子）。您可以在学习本教程的同时下载示例JMX。

准备好学习？我们走吧！

休息API登录

OctoPerf平台基于Json Rest API。我们将看看如何使用JMeter模拟我们的API登录。

但是身份验证如何运作？我们如何使用JMeter模拟登录？大多数Rest API使用以下登录工作流程：

登录使用HTTP POST请求通过提供username和password，
接收临时身份验证令牌，以便以后请求标识自己，
发送身份验证令牌的后续请求中，典型地经由HTTP标头一样Authorization: Bearer AUTH_TOKEN。

OctoPerf API也是如此。这与Oauth身份验证非常接近。

登录API规范

首先，让我们看看如何登录OctoPerf Application。值得庆幸的是，我们的API有一个Swagger规范：Swagger是一个提供Rest API文档的工具。

Doc指定如何通过OctoPerf的API登录

好！现在让我们来看看使用JMeter进行伪造所需的请求：

Http方法：必须是POST请求，带有一些post参数，（参见GET vs POST）
Http Scheme：https由于我们的Rest API 受SSL保护，
主机名：api.octoperf.com，
路径 :( /public/users/login登录端点路径），
发布参数：
- 用户名：帐户用户名，如果你没有，你可以在这里轻松注册，
- 密码：关联的密码。

然后我们应该从服务器接收一个Json Response，它看起来像：

{

  "token": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

}

在这里看到令牌？这是我们稍后将用于在Rest API上识别自己的东西。但是，首先让我们来看看JMeter HTTP请求。

执行登录

通过Rest API登录OctoPerf

在这里，我们已准备好将Login Http Request发送到我们的服务器。我刚刚隐藏了敏感信息，但这基本上就是您的帐户信息。为了调试登录，我们将使用View Results Tree Listener。

登录请求发送到服务器

我们可以看到，发送的请求是一个POST表单-urlencoded，其中包含我们的登录名和密码。这里没什么难的！现在，我们对服务器发送的Json响应感兴趣。

从服务器收到响应

精细！现在我们已经收到了身份验证令牌，我们可以提取它以在后续请求中重用它。

提取身份验证令牌

基于令牌的身份验证是一种简单的机制，其中令牌唯一地标识用户会话。我们需要处理这个问题dynamic parameter以正确模拟与Json API交互的用户。

使用Json Extractor

要从服务器响应中提取身份验证令牌，我们将使用JMeter JsonPath Extractor。从响应中提取变量的过程如下：

服务器发回对我们的登录请求的响应，
甲后处理器，像JsonPath提取是继执行
提取器提取服务器响应的一部分并将其放入变量中${token}。

从服务器响应中提取身份验证令牌

我们已经使用这些设置配置了JMeter Json Extractor：

创建变量的名称：token，这将导致带有语法的可重用变量${token}，
Json Path表达式：$.token，有关详细信息，请参阅示例JsonPath表达式，
并且匹配Nr：简单地说1，第一次出现。但我们可以把它留空。

看看我放置提取器的位置？在loginHTTP请求下。我们还添加一个Debug Sampler来查看是否正确提取了变量。

启用调试

在Debug Sampler中启用JMeter变量

通过设置JMeter的变量来true，我们启用了采样器输出变量的试运行期间。

测试提取

使用Json Extractor从服务器响应中成功提取令牌

大！Json提取器完美无缺。它token从Json响应中提取字段的值。我们现在可以${token}在后续请求中使用表达式来执行经过身份验证的请求。

让我们看看我们如何重用此令牌来告诉我们的Rest API我们是一个给定的用户。

重新注册验证令牌

我们的Rest API有许多需要身份验证的端点。这些端点提供用户工作区，项目，虚拟用户等数据。要访问受用户保护的端点，必须：

登录以获取身份验证令牌（就像我们之前所做的那样），
Authorization: Bearer TOKEN对于每个后续请求，在http请求标头内发送身份验证令牌。

这正是我们要在这里做的。

检索用户工作区

我们现在特别感兴趣的是查询用户的工作空间。这是Workspaces API端点的一部分。

工作区从Swagger API文档中休息API端点

我们将GET使用路径向端点执行请求/workspaces/member-of。它应该返回包含用户工作空间的Json响应。这是一个示例响应：

[

  {

    "created": "2018-04-23T12:40:00.133Z",

    "description": "This is my personal workspace.",

    "id": "workspaceId",

    "lastModified": "2018-04-23T12:40:00.133Z",

    "name": "Personal",

    "userId": "myUserId"

  }

]

让我们在JMeter中创建一个HTTP请求来查询它们。这很简单，如下面的截图所示。

从JMeter调用端点成员

在这里，我们设置了一个HTTP请求来查询用户的工作区：

Http方法：必须是GET请求，不涉及参数，
Http Scheme：https由于我们的Rest API 受SSL保护，
主机名：api.octoperf.com，
路径：/workspaces/member-of。

完了吗？还没。目前，如果我们不提供身份验证令牌，服务器将拒绝我们的请求。

服务器返回错误

服务器以Http 4xx错误拒绝请求：401 Unauthorized。

与403 Forbidden类似，但专门用于需要身份验证且已失败或尚未提供的情况。

我们需要通过Authorization在请求中包含标头来提供身份验证令牌。怎么样？通过向请求添加HTTP标头管理器。

添加授权标头

在Authorization标头中设置提取的令牌

请记住：我们之前已经token从/public/users/login端点服务器响应中提取了。现在，是时候重用它来检索访问受保护的资源了：

首先，在getWorkspaces HTTP Request 下添加一个Http Header Manager，
添加Authorization带有值的标头Bearer ${token}。

从服务器获得工作区

太好了！它现在正在工作！我们拥有属于已登录用户的所有工作空间。

授权标头已在请求中发送

授权标头已成功包含在请求标头中。但是，有一点令人讨厌的是：Json格式不正确。为什么？

大多数服务器以紧凑格式发送json，跳过缩进。这是出于性能原因（减少带宽使用和服务器CPU使用）

格式化Json响应

为了解决这个问题，JSON Formatter PostProcessor能够很好地完成这项工作。

JMeter Json Formatter后处理器

请参阅我们的JMeter插件安装指南，了解如何安装Json插件。另一个选择是使用JSR223脚本自己格式化Json 。

Json现在打印得很漂亮！

现在，我们可以利用Json Assertion（在JMeter 4.0中引入）的强大功能来检查服务器响应。

使用Json Assertion

我们将确保服务器响应包含Personal工作区。这是Json断言的工作。要添加Json断言，请右键单击HTTP Request采样器，然后选择Add > Post Processor > Json Assertion。

组态

断言响应包含个人工作空间

Json断言配置如下：

断言的Json路径存在：$.[1]['name']指第二工作区返回，并采取了name，
另外Assert Value：选中以检查name字段的值，
预期价值：应该是Personal。

执行

假设我们断言期望值是Other不是Personal。

查找名为Other的 workspaced时，Json Assertion失败

正如预期的那样，断言失败并显示以下消息：

Assertion error: false

Assertion failure: true

Assertion failure message: Value expected to be 'Other', but found 'Personal'

性能

当然，您不仅限于使用Json Assertion。如果您愿意，也可以使用JMeter Response Assertion。它在性能方面甚至是有益的，因为根据我们的断言性能比较表，响应断言比Json断言消耗更少的CPU /内存资源。

模拟动态行为

现在我们知道如何登录Json Rest API并发送访问受保护端点的请求，让我们看看如何dynamically behaving使用JMeter 模拟用户。

这是本教程的最后一部分：

首先，我们将提取随机工作区ID，（将${workspaceId}）
其次，我们将使用端点查询该工作空间的项目/projects/by-workspace/${workspaceId}/DESIGN。

OctoPerf的Projects Rest API端点

最后一个Rest API端点让我们感兴趣。我们将从JMeter调用它，但首先我们需要提取一个随机workspaceId。

提取WorkspaceId

提取随机workspaceId

提取器配置为getWorkspaces请求的后处理器，具有以下设置：

创建变量的名称：workspaceId，
Json Path表达式：$..id，
匹配号：0，这是随机的。

这将提取随机workspaceId，并将其放入${workspaceId}变量中。

查询项目

最后，我们需要根据之前提取的内容查询项目workspaceId。为此，我复制并修改了之前的请求以获得一些时间。

使用workspaceId变量查询项目

在这里，我们设置了一个HTTP请求来查询工作区的项目：

Http方法：必须是GET请求，不涉及参数，
Http Scheme：https由于我们的Rest API 受SSL保护，
主机名：api.octoperf.com，
路径：/design/projects/by-workspace/${workspaceId}/DESIGN。DESIGN工作空间中包含的项目的状态。（而不是结果，这将是RESULT）

我想我们已经准备好进行快速迭代来试试这个了！

查看结果

执行导致查询项目

如果我们多次执行用户，我们会看到响应因提取的随机workspaceId 而异。

最后的话

JMeter非常适合Rest API测试，特别是那些基于Json格式的测试。使用JMeter测试Json API非常简单。

基本上，如果你掌握了上面提到的JMeter组件，那么你很高兴！

如果你想进一步挖掘，我强烈建议你阅读我们的文章：

JMeter JsonPath Extractor：从Json响应中提取任何内容，了解有关JsonPath语法的更多信息，
JMeter Json Assertion：专门断言json响应，
和JMeter的插件，如Json的格式化可以使您的生活很多容易通过格式化输出。

如果您发现它有用，请随时分享本指南！