我确定你在这里是因为你需要加载测试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使用以下登录工作流程:
- 登录使用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
,第一次出现。但我们可以把它留空。
看看我放置提取器的位置?在login
HTTP请求下。我们还添加一个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
端点服务器响应中提取了。现在,是时候重用它来检索访问受保护的资源了:
- 首先,在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的格式化可以使您的生活很多容易通过格式化输出。
原文地址:https://www.cnblogs.com/a00ium/p/10263495.html