背景:
想要实现部分业务流程通过执行接口生成测试数据。
业务流程
最终的目的:登录不同的账号并通过不同的账号去请求创建需求的接口,最后生成推荐不同商品的需求。
分析
- 共两个接口:登录接口、创建需求接口;
- 创建需求的接口需要登录接口中返回的authKey,这里需要做关联;
- 不同的账号、不同的商品需要做登录账号、商品的参数化;
- 不同的账号各自创建需求,需要做循环、提取不同账号的authKey。
实现方案
单账号登录并创建需求
先从最简单的流程来。获取到两个接口及其传参,并通过关联authKey实现接口串联。
-
新建一个测试计划。
-
在测试计划下添加一个请求默认值,用来配置协议、服务器名称或ip、端口号等信息。(这样就不用每个请求都去配置一遍,且相对来说更好维护一些。)
-
在测试计划下添加一个信息头管理器,用来定义整个测试计划下的接口的请求头。
-
添加一个线程组,线程组重命名为“单账号登录并创建需求”。
-
在线程组下添加一个http请求,修改请求名称为“login”,并填写接口信息以及接口传参。
-
再已同样的方法添加创建需求的接口,创建需求接口的传参可以先直接复制接口中的参数。
-
在这个线程组下添加一个察看结果树,用来查看接口执行信息。
-
此时可以点击执行按钮,初步看一下执行结果,登录接口的响应信息中已返回authkey。
…但是,创建需求的接口,因为没有authKey所以报用户未登录。 -
需要将login接口返回的authkey,在请求头中作为需求推荐接口的请求信息。就是要做authkey这个字段的关联,具体的步骤就是:把每一次登录后login接口返回的authkey取出来赋给一个变量,再将这个变量作为authkey在需求创建接口中的请求信息。
关联
-
提取authkey。在login接口上添加一个后置处理器-正则表达式提取器。
-
上图中的正则表达式为: “authKey”:“(.+?)”,
()内的部分就是要提取的值。
()前面和后面的内容是要提取的值的前后文,以便定位。
.:匹配任何字符串。
+:匹配一次或多次。
?:找到第一个目标值后停止。
-
检查是否提取到目标值。在线程组上添加取样器-debug sampler,或在login接口上添加后置处理器-debug postprocessor都可以辅助调试。
添加后,执行接口,在察看结果树中查看结果。tips:
如果在结果中出现了正则表达式中填写的变量名及其值,则说明已经提取到目标值;
如果没有提取到,需要检查一下正则表达式:比如匹配符是否正确,前后文填写是否正确,是否有多余的空格。
-
把提取到的authkey关联到创建需求的接口。在创建需求接口上添加配置元件-HTTP信息头管理器,添加一行数据,参数名称需要关联的字段名,参数值为${正则表达式填写的引用名称}。
tips:jmeter中引入的变量都是这个格式:${变量名称}。
-
执行接口,创建需求的接口返回200,已创建对应的数据。
tips:
如果jmeter请求接口后创建的数据是乱码,那就在请求的“内容编码”处,填写编码格式(一般是utf-8);
如果修改后还是乱码,建议再修改一下jmeter的配置文件(jmeter解压路径\bin\jmeter.properties)
断言
-
添加断言。通过每次去看接口的响应信息去确认有没有异常,在接口数量少时还好,接口数量多时,一个一个去查看就很麻烦了。因此,可以通过添加断言,给出接口异常的条件和自定义的报错。
已知,需求创建成果后,returnID会返 回1,因此可以结合响应状态码和返回信息进行断言。在创建需求的接口上添加断言-响应断言。
apply to:默认断言应用于主样本。
测试字段:一般勾选“响应文本”,url样本是对请求的url进行断言,一般在请求有重定向时使用,响应代码就是状态码(如:200、302、404、500等)。注意,当响应代码为400或500时,jmeter默认这个请求是失败的,此时可以勾选“ignore status”来忽略。
模式匹配规则:响应文本与测试模式内填写的断言条件的关系。比如选了包括,就是响应文本中有没有包括测试模式中填写的内容,如果包括就是请求成功、未包括就是请求失败。
自定义失败消息:可以自己设置请求失败后返回的内容。
请求成功
请求失败
总结
通过单账号登录并创建需求的业务流程,学习了通过后置处理器-正则表达式结合后置处理器-debug postprocessor关联参数、通过断言-响应断言验证请求是否成功。
但是这种场景走出来的数据很单一,固定了登录的账号、固定了需求的传参,且运行一次只能生成一条数据,不符合预期,所以需要再优化实现方案。