变量替换漏了body字段

[InnSea]

这里不加上body的话没法正确替换参数

[wuranxu]

已加上

[wuranxu]

可以试试还有什么别的问题么？唯一的改动是 xx.0.xx需要改成xx[0].xx，其他应该都是兼容的

[InnSea]

1、xx[0].xx这种方式替换也是不成功的 2、发送请求AsyncRequest类里的get_resp方法似乎做了改动，原本逻辑在body中设置一个json类型的全局变量，例如登录数据，然后在body中可以直接使用${login_user}，现逻辑不会把body转json，请求时会报类型不是json。 3、断言还没仔细看。。尝试${response.code}或者${code}都不能替换成功

感谢回复，后续有问题我继续反馈

[InnSea]

断言的部分我看了一下，这边传入的应该是返回数据才对？原本传入的是case_params（case主变量）了

原逻辑：

[wuranxu]

1、xx[0].xx这种方式替换也是不成功的 2、发送请求AsyncRequest类里的get_resp方法似乎做了改动，原本逻辑在body中设置一个json类型的全局变量，例如登录数据，然后在body中可以直接使用${login_user}，现逻辑不会把body转json，请求时会报类型不是json。 3、断言还没仔细看。。尝试${response.code}或者${code}都不能替换成功

感谢回复，后续有问题我继续反馈

没有${response}这种用法了，该逻辑暂时去掉了，都需要进行参数提取，问题2里面如果是前置条件里面的response，可以用前置条件的${变量值.response}来获取登录的response，以前有自动转JSON逻辑，现在没有，而且现在默认就是JSON的。

[InnSea]

但是my_asserts传入的参数改成response_info后现在断言是正常的了，通过${response.code}也能正确替换。

[wuranxu]

但是my_asserts传入的参数改成response_info后现在断言是正常的了，通过${response.code}也能正确替换。

那肯定是因为你有一个response的变量，目前不会默认添加这样的变量。

[InnSea]

问题2我可能没有描述清楚，单纯一条用例这样使用是不行的了，原逻辑是可以的

[InnSea]

response变量是请求的invoke方法里返回的呀

[wuranxu]

问题2我可能没有描述清楚，单纯一条用例这样使用是不行的了，原逻辑是可以的

你如果需要这么使用，请把全局变量的类型改成String。否则会转成JSON，导致你无法使用

[wuranxu]

response变量是请求的invoke方法里返回的呀

那是因为你改动了代码，这里需要你把response提取出来，而不是改成response_info

[InnSea]

理解了，这样的话确实不需要response了，上个问题转成string后可以正常使用，那json类型什么情况下使用呢？还是说新逻辑应该用不到json类型的变量了呢

[wuranxu]

理解了，这样的话确实不需要response了，上个问题转成string确实可以了，那json类型什么情况下使用呢？还是说新逻辑应该用不到json类型的变量了呢

可以局部使用啊，比如${login_user.phone}这种，不是让你作为整体去用的

[InnSea]

好的，谢谢。 1、xx[0].xx这种方式替换也是不成功的 这个问题还请帮忙确认一下

[wuranxu]

好的，谢谢。 1、xx[0].xx这种方式替换也是不成功的 这个问题还请帮忙确认一下

这个应该没问题，还是那句话，你需要提取你的变量。接着用${xx[0].xx}是可以的，你可以打印一下case_params, 里面是一个字典。应该会有{"xx": {}}这样的数据

[InnSea]

这是用例的前置步骤，我通过course_id接收

使用的时候是这样使用的，最后提取出来的结果是空

[wuranxu]

这是用例的前置步骤，我通过course_id接收

使用的时候是这样使用的，最后提取出来的结果是空

修复好了，和原来逻辑冲突导致。原来的sql返回结果默认转为str了，很影响效率，现在不会做这种频繁序列化、反序列化。

[InnSea]

好的，我试试

[InnSea]

用例数据管理里的变量替换有问题

[wuranxu]

用例数据管理里的变量替换有问题

已将2者变量合并，case变量 > 请求变量 = 全局变量

[InnSea]

就是后续用全局变量代替了？

[wuranxu]

没有请求参数的概念了，以后，只有初始化有，会合并到用例参数，全局变量也是

------------------ 原始邮件 ------------------ 发件人: In Sea @.> 发送时间: 2024年1月31日 22:16 收件人: wuranxu/pity @.> 抄送: 米洛 @.>, State change @.> 主题: Re: [wuranxu/pity] 变量替换漏了body字段 (Issue #140)

就是后续用全局变量代替了？

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>

[InnSea]

还要打扰一下了，目前使用又遇到一个问题，比如我前置用例是登录，提取了$.data.token，出参名为token，另一个用例中把这条用例作为前置用例，然后在header中使用${token}。但是最终替换的结果token被套了两层字符串""xxxxxxxx"，变成了这样的格式。

[wuranxu]

那是因为header里面有强转，我调整一下

------------------ 原始邮件 ------------------ 发件人: In Sea @.> 发送时间: 2024年1月31日 22:43 收件人: wuranxu/pity @.> 抄送: 米洛 @.>, State change @.> 主题: Re: [wuranxu/pity] 变量替换漏了body字段 (Issue #140)

还要打扰一下了，目前使用又遇到一个问题，比如我前置用例是登录，提取了$.data.token，出参名为token，另一个用例中把这条用例作为前置用例，然后在header中使用${token}。但是最终替换的结果token被套了两层字符串""xxxxxxxx"，变成了这样的格式。

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: @.***>

[InnSea]

[2024-01-31 23:21:12]: 步骤开始 -> 执行用例失败: 主case->login 第1个前置条件执行失败: dictionary update sequence element #0 has length 1; 2 is required 然后刚才拉了最新代码后发现有新的报错。

[wuranxu]

update

再试试吧，token那个好了，这个如果还有问题可以告诉我是哪行代码报的错，错误堆栈给我下

[InnSea]

token的问题解决了，谢谢昨天这么晚还回复。

[InnSea]

昨晚那个问题，准确说是当前用例在数据管理中加入了多个场景，直接测试是没有问题的，但是给这条用例加上一条前置用例的话就会报错。 报错是这个方法里报的，不确定是不是这块代码的问题。 @wuranxu

[InnSea]

前面说的不对。应该是这里case_params挂载req_params时有问题，挂载数据不对

[wuranxu]

前面说的不对。应该是这里case_params挂载req_params时有问题，挂载数据不对

已修复，参数顺序问题，后面应该没多大问题了。

[InnSea]

可以了，感谢

[InnSea]

还有一个问题想请教下，之前看到过有issue提到变量名重复的问题。新版本还会有类似的问题吗？

[InnSea]

还有这个地方不能用这个写法，某些情况下会有问题。还是需要用回原来的写法才行。

[InnSea]

断言参数这里有一个问题： 我尝试提取接口返回的json类型的数据时，比如$.data。然后在断言的时候预期结果填入json数据，实际结果为提取的${data}。 但是在这里的translate时，报错了:Expecting property name enclosed in double quotes: line 1 column 2 (char 1)。原因是act传入的是一个字典，而不是json。

补充： 不仅仅是上述场景。如果提取出来是个列表等也会报错，是不是可以去掉translate这一步。

[wuranxu]

断言参数这里有一个问题： 我尝试提取接口返回的json类型的数据时，比如$.data。然后在断言的时候预期结果填入json数据，实际结果为提取的${data}。 但是在这里的translate时，报错了:Expecting property name enclosed in double quotes: line 1 column 2 (char 1)。原因是act传入的是一个字典，而不是json。

补充： 不仅仅是上述场景。如果提取出来是个列表等也会报错，是不是可以去掉translate这一步。

首先，你不能直接${data}这么去做断言，而应该分开按字段去断言，其次，这个原因是，模板引擎把你的json返回解析成了字典，导致不能反序列化。如果你一定需要这么做的话，你可以${data|tojson} 去做到这个事情。至于你上面说的参数那里，好像没看出来有什么问题。

[wuranxu]

断言参数这里有一个问题： 我尝试提取接口返回的json类型的数据时，比如$.data。然后在断言的时候预期结果填入json数据，实际结果为提取的${data}。 但是在这里的translate时，报错了:Expecting property name enclosed in double quotes: line 1 column 2 (char 1)。原因是act传入的是一个字典，而不是json。

补充： 不仅仅是上述场景。如果提取出来是个列表等也会报错，是不是可以去掉translate这一步。

translate操作是不能去掉的，因为我们的断言预期/实际结果，经过${变量}处理后，它始终是一个字符串，如果想要进行一些大于/小于/数组包含等操作，那必须转换为Python里面的对象，如int，数组，字典等。

[InnSea]

好的。现在还遇到一些新问题。

第一个问题：执行测试计划时，写入数据库报错。看起来是写入类型错误：error: (pymysql.err.ProgrammingError) (1064, 'You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near \'\'code\': \'18009\', \'msg\': "\'数据未找到\'"}, \'{}\', 0)\' at line 1')。

第二个问题：/run/multiple接口执行用例的时候会报错error: sequence item 0: expected str instance, dict found，报错信息如下：

[wuranxu]

好的。现在还遇到一些新问题。

第一个问题：执行测试计划时，写入数据库报错。看起来是写入类型错误：error: (pymysql.err.ProgrammingError) (1064, 'You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''code': '18009', 'msg': "'数据未找到'"}, '{}', 0)' at line 1')。

第二个问题：/run/multiple接口执行用例的时候会报错error: sequence item 0: expected str instance, dict found，报错信息如下：

问题2我试了，没有复现。请检查一下你的请求参数~ url: http://127.0.0.1:7777/request/run/multiple?env=1 json: [186,185]

问题1应该是response变成Python对象（以前是str）导致，已修复

[InnSea]

好的。感谢，问题2目前也没出现过了