更新时间:2021-08-29 11:24:58
如何使用 JMeter 调用你的 Restful Web Service?进行简单的压力测试和自动化测试
表述性状态传输(REST)作为对基于 SOAP 和 Web 服务描述语言(WSDL)的 Web 服务的简单替代,在 Web 开发上得到了广泛的接受。
能够充分证明这点的是主流 Web 2.0 服务提供商在接口设计中对 REST 的普遍采用 - 包括雅虎、谷歌以及脸谱 - 出于简单易用、以面向资源的模型发布自己的服务的偏好他们都已经抛弃了 SOAP 和基于 WSDL 的接口。在你必须要对你的 RESTFul web service 进行测试的时候,你可能会有这两个选择:
本文示例中将会演示如何创建简单 Hello World WebService,并使用 JMeter 访问测试该 WebService。
如果你碰到了以下问题之一,那么恭喜你,你来对地方了:
1. 先决条件:RESTFul web service 的完整实现。
2. 创建简单 Java 类:CrunchifyJMeterTest.java(我们将使用 JMeter 访问的服务)。
3. 在 Tomcat 上对该应用进行重新部署。
4. 运行 JMeter 并打开下文提供的 .jmx 文件。
5. 执行并对你的测试结果进行分析。
先决条件:RESTFul web service 的完整实现。部署并运行应用程序。
创建 CrunchifyJMeterTest.java 文件
之后应该看到下面这种 Eclipse 目录结构:
将 CrunchifyRESTJerseyExample 在 Tomcat 上重新部署,使用这个 URL 测试你的 REST 服务:
URL:http://localhost:8080/CrunchifyRESTJerseyExample/crunchify/index/
将以下脚本拷贝到文本文件并另存为 Crunchify-JMeter-Test.jmx:
分析你的测试结果:
原文链接:How to Call Your Restful Web Service Using JMeter? Perform a Simple Load Testing and Automation。
一个基于 Jersey 框架实现的 RESTful web service 项目如下:
将其部署后,访问 wadl 地址 http://192.168.23.204/uas/resource/application.wadl:
我们要对其这个方法进行压测:
该方法单元测试相关代码:
RESTfulJsonClientFactory 是一个 WebService 的远程客户端创建类。执行该单元测试,输出:
请求报文:{}{"msgType":null,"tranCode":null,"sysCode":"1001","brcCode":"1000","srcCode":"01","frontNo":"dfs-02040668","frontTime":"2017-01-20 15:27:19","repCode":null,"repMsg":null,"remark":null,"version":"1.0","signature":null,"cerVersion":null,"channelNo":"01","token":"mytest004","value":"{\"csrfToken\":null,\"userInfo\":{\"loginName\":null,\"merCode\":\"102239\",\"merName\":null,\"accountList\":[{\"acccountCode\":\"1022380016\",\"accountName\":\"redis测试账户名称\"}],\"operator\":null,\"role\":null},\"menuTree\":null}","timeOut":"10000","reqDate":null}
响应报文:{}{"msgType":null,"tranCode":null,"sysCode":"1001","brcCode":"1000","srcCode":"01","frontNo":"channel.web.dfs.local","frontTime":"2017-01-20 15:26:24","repCode":"000000","repMsg":"成功","remark":null,"version":"1.0","signature":null,"cerVersion":null,"channelNo":"01","token":"mytest004","result":"1","reqDate":null}
SmartSniff 为我们截取到了这次 Web Service 调用,包括一个完整的 http 请求报文(蓝字部分)和返回报文(红字部分):
根据 SmartSniff 的结果我们拿到了这次 Web Service 调用的完整 URL:http:192.168.23.204/uas/resource/com.dfs.uas.biz.resource.UserResource/push,以及完整报文:
POST /uas/resource/com.dfs.uas.biz.resource.UserResource/push HTTP/1.1
Content-Type: application/json
User-Agent: Java/1.6.0_29
Host: 192.168.23.204
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 429
{"sysCode":"1001","brcCode":"1000","srcCode":"01","frontNo":"dfs-02040668","frontTime":"2017-01-20 17:12:29","version":"1.0","channelNo":"01","token":"mytest004","value":"{\"csrfToken\":null,\"userInfo\":{\"loginName\":null,\"merCode\":\"102239\",\"merName\":null,\"accountList\":[{\"acccountCode\":\"1022380016\",\"accountName\":\"redis..................\"}],\"operator\":null,\"role\":null},\"menuTree\":null}","timeOut":10000}
HTTP/1.1 200 OK
Server: nginx/1.10.2
Date: Fri, 20 Jan 2017 09:11:28 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
db
{"sysCode":"1001","brcCode":"1000","srcCode":"01","frontNo":"channel.web.dfs.local","frontTime":"2017-01-20 17:11:28","repCode":"000000","repMsg":"......","version":"1.0","channelNo":"01","token":"mytest004","result":1}
0
这些都是很有用的信息,URL 在我们写 HTTP 采样器配置路径的时候用,请求报文在我们组织请求报文体时用,返回报文可以用来参考写断言。
JMeter 新建测试线程组、新建 HTTP 信息头,信息头加入名称为 Content-Type 值为 application/json 项:
根据截取信息编辑 HTTP 请求采样器,注意标框部分:
根据截取信息编辑 HTTP 响应断言:
使用察看结果树对脚本调试成功之后,再配置线程组并发数、循环次数等,开始压测,一个小时后的 TRT 结果:
TPS 数据:
Web Service 的压力测试脚本其实很好写,但是如果从建立 Web Service 的客户端比如写 BeanShell 实现本地执行远程服务调用的角度出发往往会落入复杂繁琐而且遥遥无期的脚本开发调试之中(用《神探狄仁杰》里狄仁杰经常说的一句经典台词说:落入彀中)。换个思路,比如从协议的角度出发,Web Service 再复杂也脱离不了 HTTP 吧?然后在借助合理的协议工具的帮助下,看似复杂的脚本编写就会变得非常简单了。