使用JMETER进行REST API测试（分步指南）

标签：formatter   ice   tran   有关   conf   漂亮   proc   pap   actor   

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

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

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

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

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

准备好学习？我们走吧！

休息API登录

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

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

1. 登录使用HTTP POST请求通过提供username和password，
2. 接收临时身份验证令牌，以便以后请求标识自己，
3. 发送身份验证令牌的后续请求中，典型地经由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。从响应中提取变量的过程如下：

1. 服务器发回对我们的登录请求的响应，
2. 甲后处理器，像JsonPath提取是继执行
3. 提取器提取服务器响应的一部分并将其放入变量中${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我们是一个给定的用户。

重新注册Auth Token

我们的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端点服务器响应中提取了。现在，是时候重用它来检索访问受保护的资源了：

1. 首先，在getWorkspaces HTTP Request 下添加一个Http Header Manager，
2. 添加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的格式化可以使您的生活很多容易通过格式化输出。

使用JMETER进行REST API测试（分步指南）

标签：formatter   ice   tran   有关   conf   漂亮   proc   pap   actor   

原文地址：https://www.cnblogs.com/a00ium/p/10263495.html