jmeterapi文档_使用jMeter对基于SAPIDservice进行认证的RestfulAPI进行并发测试

这篇文章本来Jerry只在SAP社区上写了英文版的&＃xff0c;可以通过点击文末的“阅读原文”获得。后来有两位做Marketing Cloud开发的德国同事&＃xff0c;写邮件询问关于文章的更多细节&＃xff0c;声称这种方式对他们自己的API性能测试很有用&＃xff0c;所以我觉得还是值得用中文再写一遍。

在SAP官网http://api.sap.com里有大量发布的API&＃xff0c;方便合作伙伴和客户自开发应用同SAP解决方案进行集成。

比如Jerry上个月做的一个项目&＃xff0c;就是和国内一家专注于提供人脸识别技术解决方案的企业合作, 用户通过微信扫码从而完成人脸识别后&＃xff0c;在用户授权的情况下&＃xff0c;会调用SAP Marketing Cloud的contact API&＃xff0c;生成对应的contact数据&＃xff0c;并且将人脸识别得出的面部特征码通过Marketing Cloud扩展字段的方式一并存入contact数据中。

因为这个项目最后会在2019年6月5日于上海举行的SAP云大会上展示&＃xff0c;所以当时Jerry完成集成工作后心想&＃xff0c;还是得提前测试一下咱们的Marketing Cloud在响应并发请求时的性能, 做到心里有数。

我们在SAP上海云大会上演示的场景是&＃xff0c;将SAP Marketing Cloud的Launchpad通过大屏幕投影出来&＃xff0c;参会嘉宾完成人脸识别后&＃xff0c;Marketing Cloud contact创建API自动被调用&＃xff0c;在系统生成contact数据&＃xff0c;并且Launchpad contact tile的计数器加一。

所以下一步就是如何模拟大量对Marketing Cloud API的并发请求。

对于程序员来说&＃xff0c;最容易想到的方式就是自己动手写一个程序来发送大量请求。Jerry选择的最简单的编程方式&＃xff0c;在Java程序里新建大量线程&＃xff0c;每个线程发送一个请求&＃xff0c;当然也可以直接用JDK里提供的线程池库。我的Java程序源代码在github上&＃xff1a;

https://github.com/i042416/JavaTwoPlusTwoEquals5/tree/master/src/odata

除了自己动手编写代码外&＃xff0c;还可以重用一些API测试工具来达到同样的目的。Postman是一个API开发人员常用的接口调试利器&＃xff0c;它也有定义变量和简易的编程功能&＃xff1a;

可以通过称之为Collection Runner的功能&＃xff0c;一键运行Collection里的多个请求。

Jerry在这篇SAP社区博客里详细介绍过Postman的编程&＃xff1a;

Just a single click to test SAP OData Service which needs CSRF token validation
https://blogs.sap.com/2019/06/10/sap-just-a-single-click-to-test-sap-odata-service-which-needs-csrf-token-valid/

Jerry还在成都C4C开发团队时&＃xff0c;组内同事就告诉过我&＃xff0c;jMeter是另一个功能强大的基于Java的API压力测试工具。所以这次我选择用jMeter来对API做压力测试。

下文介绍的内容需要大家对jMeter的使用有最基本的了解&＃xff0c;如果还不太熟悉的朋友&＃xff0c;可以先查阅jMeter的官方文档。

总的思路就是使用jMeter提供的Thread Group(线程组)和控制器这两个工具。Thread Group帮助工具使用者实现了通过多线程发送HTTP请求的功能&＃xff0c;比如下图设定的100&＃xff0c;意思是通过100个线程同时发送请求。

而涉及到对系统进行写操作的SAP API&＃xff0c;比如新建&＃xff0c;修改或者删除数据的SAP OData服务&＃xff0c;在请求的HTTP头部必须附带防止跨域请求伪造攻击的CSRF token(有时又称XSRF token:Cross-site request forgery). 我们可以将从服务器获取CSRF token的请求和真正调用contact API的请求放到同一控制器里&＃xff0c;这样能确保同一线程内&＃xff0c;拿token和创建contact这两个请求依次执行。

SAP云平台的官网上有一个帮助文档&＃xff0c;对用户访问SAP云平台上的服务的Authentication流程做了清晰的阐述&＃xff1a;

https://cloudplatform.sap.com/scenarios/usecases/authentication.html

这张图描述了在Authentication场景下&＃xff0c;几个名词User(有时称为Client), Service Provider和Identity Provider(途中简写成IdP)的相互作用关系。

虽然Jerry本文介绍的场景&＃xff0c;我用jMeter消费的是Marketing Cloud上的服务&＃xff0c;而非SAP云平台上的服务&＃xff0c;不过这些服务对应的Idp都是SAP ID service&＃xff0c;即accounts.sap.com, 因此Authentication原理仍然相同。

我们牢牢记住这张图的几个步骤&＃xff0c;因为我们接下来用jMeter消费Marketing Cloud API时&＃xff0c;同样要遵循这种Authentication流。

我们先用Chrome访问SAP Marketing Cloud Fiori Launchpad&＃xff0c;来深入理解图中介绍的Authentication流程。

1. 浏览器打开SAP Marketing Cloud Fiori Launchpad链接&＃xff0c;HTTP请求发送到了Marketing Cloud系统&＃xff0c;后者可以视为Service Provider。
2. Marketing Cloud把请求通过HTTP 302重定向了它预先配置好的IdP上去&＃xff0c;即SAP ID service(也就是http://account.sap.com).

关于什么是SAP ID service&＃xff0c;可以查看SAP官方帮助文档&＃xff1a;

https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/d6a8db70bdde459f92f2837349f95090.html

1. IdP的职责是完成实际的用户认证工作&＃xff0c;它给用户返回一个登录页面&＃xff0c;要求其输入用户名和密码。

上图显示的是SAP ID Service的登录页面&＃xff0c;UI虽然简单&＃xff0c;但是这个页面的源代码里存在很多隐藏字段。

用Chrome开发者工具能够发现这些隐藏字段&＃xff1a;

xsrfProtection
spId
spName
authenticity_token
idpSSOEndpoint

这些字段都是在SAP ID Service的服务器端生成&＃xff0c;然后返回给客户端。

1. 用户输入密码点击登录按钮后&＃xff0c;用户输入的用户名和密码&＃xff0c;同第三步介绍的登录页面的隐藏字段&＃xff0c;会一齐返回给SAP ID Service服务端。可以在Chrome开发者工具里观察到这些字段位于HTTP请求头部。

1. IdP完成用户认证&＃xff0c;颁发一个"assertion"响应&＃xff0c;值存储于HTTP响应头部的SAMLResponse字段里。

这个字段的SAML表明这是一个基于SAML协议的认证过程&＃xff0c;把上图Chrome开发者工具里观察到的SAMLResponse字段值通过BASE64解码&＃xff0c;得到下图的XML格式的assertion内容&＃xff1a;

上图第一处用红色矩形框高亮的字段是assertion的状态&＃xff0c;值为success. 因为SAP ID Service和Marketing Cloud系统配置为互相信任&＃xff0c;所以这意味着SAP ID Service通知Marketing Cloud&＃xff0c;这个用户的认证已经通过了。

SAML协议规范的官方文档&＃xff1a;

http://saml.xml.org/saml-specifications

有了上述的理论基础后&＃xff0c;进行jMeter项目的配置工作思路也就清楚了。

我把jMeter项目的工程文件放到我的Github上了&＃xff0c;方便大家重用&＃xff1a;

https://github.com/i042416/KnowlegeRepository/blob/master/ABAP/C4COData/jMeter/01-contact-creation.jmx

在jMeter里&＃xff0c;我们按照SAP官网认证架构图的6个步骤来配置&＃xff1a;

1. 使用jMeter提供的正则表达式提取器&＃xff0c;将认证流程第3个步骤&＃xff0c;IdP返回的登录页面的5个隐藏字段的值提取出来&＃xff0c;存储成jMeter变量&＃xff1a;

下图显示了这些隐藏字段的值被成功提取出来并存储成jMeter变量&＃xff1a;

1. 把第一步提取出并存储在jMeter变量中的五个字段的值(下图红色)的值&＃xff0c;再加上用户手动输入的用户名和密码(下图蓝色), 作为请求的头部字段&＃xff0c;一齐提交给SAP ID service&＃xff1a;

登录成功后&＃xff0c;收到了服务器端返回的COOKIE值&＃xff1a;

1. 发送新的请求给服务器&＃xff0c;获取CSRF token. 这个请求的响应里包含了两个下图高亮的COOKIE&＃xff0c;需要同样存储成jMeter变量&＃xff0c;以供最后一个请求使用。

1. 最后一个步骤&＃xff0c;将前一步获取到的CSRF token附加到HTTP请求字段中&＃xff0c;同时带上前一步服务器返回的两个COOKIE字段&＃xff1a;

至此这个jMeter项目的配置工作就完成了&＃xff0c;其优于Java编程和Postman之处在于我们不需要编写一行代码&＃xff0c;我们对API进行并发测试这个需求的相关功能点全部能够通过jMeter里的配置完成。

最后简单测试一下并发请求的响应时间&＃xff1a;

我在使用jMeter调用contact API创建工作时用到了简单的随机数生成器&＃xff0c;在contact的姓后面加上了简单的随机数&＃xff0c;这是最后通过jMeter生成的contact在Marketing Cloud里的显示&＃xff1a;

最后一步就是把SAP Marketing Cloud Launchpad里的contact tile的计数器刷新间隔设置成10秒刷新一次&＃xff1a;

系统显示&＃xff0c;在2019年6月5日上海SAP云大会这个演示场景的展台上&＃xff0c;一共有276个嘉宾完成了人脸识别后的Marketing Cloud contact注册流程。

要获取更多Jerry的原创文章&＃xff0c;请关注公众号"汪子熙":