Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

动态参数输入源的使用场景需求分析 #29

Closed
gumutianqi opened this issue Oct 26, 2017 · 6 comments
Closed

动态参数输入源的使用场景需求分析 #29

gumutianqi opened this issue Oct 26, 2017 · 6 comments
Labels
Feature Request Request focused on developing a specific part of a larger feature.

Comments

@gumutianqi
Copy link

gumutianqi commented Oct 26, 2017

@brookshi

第一个需求场景:

比如登录,我们准备很多帐号ID和密码,一行一个的txt,body里面就是动态的,有两种场景

第一种:单个动态参数,从文件一次取一个, 如果多个动态参数可能需要对应多个txt文件

{
"account": {{getAcount}}
}

第二种情况是整个参数体JSON都是动态从文件读取的一次读取一个

//body 里面就是一个从文件获取的函数
{{loginData}}

对了,有时候需要将返回结果导出,希望可以提供多个请求的send的时候,返回结果读取解析后导出到文件;下次再上传作为动态参数使用

第二个场景:

接口请求返回的结果应该存下来或者下载下来作为其他请求的动态参数使用,比如登录的token就是这种场景,我可以使用一批帐号请求得到一批token,然后将返回结果存下来(可以读取返回结果来组装需要存的结构),并提供一个获取数据的函数;在别的接口里面可以调用这个函数获取动态参数;

{
"token": {{getToken}}
}

现在只能**$variables$**还是太弱了点

实现了上面的两种需求场景,就可以满足所有的接口连续链式调用和压力测试获取参数的问题;

对了,需要解决一个Collection内的接口串行和并行的问题;

很好的值得推广起来的项目,而且看好Go的HTTP/IO性能优势,提了几个建议,望采纳

如果能完美实现动态数据的问题,我觉得能接受付费购买授权,能解决很多中小企业自动化测试的问题;

@brookshi
Copy link
Owner

brookshi commented Oct 26, 2017

非常好的需求,非常感谢,我也有些这方面的想法,打算是让每个项目在server可以有个自己的文件夹,功能上加 一个pre request script,然后可以在这里或test里保存返回的结果到文件夹也可以打开这个文件夹里的结果,还可以人工上传一些初始参数文件到这个文件夹,然后在脚本里打开取值,做到这点的话,上面的这些需求应该就可以做到了

@brookshi brookshi added the Feature Request Request focused on developing a specific part of a larger feature. label Oct 26, 2017
@gumutianqi
Copy link
Author

gumutianqi commented Oct 27, 2017

@brookshi
完美的理解,做到这点那 hitchhiker 就真的健壮了,期待动态参数功能的到来;
可惜我不会Node和Go,我主要做Java架构和交互设计,不然可以提交一些pull request,不过可以一起讨论数据结构存储获取等等设计和提供交互体验优化建议;

@brookshi
Copy link
Owner

嗯,争取尽快能做出来,非常感谢你的建议

@gumutianqi
Copy link
Author

gumutianqi commented Oct 28, 2017

今天又想到一个点,在 Send 某个 API 接口的时候,其中的动态参数,应该可以直接读取该 Collection 下的另外一个接口的返回结果中的数据;

这样接口与接口直接就形成自动的调用链路了,不需要特殊干预;


举个实用场景:获取用户信息的 API,参数里面需要登录成功之后的 Token 参数;

两种实现方式

  1. 先点击调用 /login 来获取 token,在 Test 里面写脚本将 token 存下来,提供获取函数;然后再去调用/user/info 这是可以使用已经有的函数直接获取三个接口存下来的 token;

  2. 当然还有另一种更加便捷的方式,直接调用/user/info,发现参数里面有依赖另一个接口的结果,自动去调用依赖的接口,取得返回结果,读取结果直接给当前接口使用;


我觉得两种方式后面都需要考虑实现,场景不同:

第一种实现方式主要用在需要先初始化一些必要的数据到内存,或者大量动态参数存储文件的情况,然后在其他接口里面直接调用函数获取文件内容进行使用;主要是压测的场景和自动化测试里面边界测试的场景会用到;

第二种实现方式就是平时使用,我添加一个新接口,直接在script里面写这个接口的哪个参数依赖其他哪个接口;


这两种方式分别支持了 平时接口验证和测试使用单一接口压测全链路依赖压测三种自动化测试的需求,perfect !!!

@brookshi
Copy link
Owner

动态参数,应该可以直接读取该 Collection 下的另外一个接口的返回结果中的数据

这一点也就是第一种实现方式用上面说的应该是可以做到的吧
挺有想法的是第2种实现方式,自动调用依赖接口,不过有个问题:

在script里面写这个接口的哪个参数依赖其他哪个接口

这个其实比较难指定依赖的接口的,毕竟接口的名字可以是一样的,唯一标识符是guid,这个可读性太差。
不过倒是可以把这个功能做到UI上,直接选择已有的接口,这样做的好处大概是本来要点两次send,现在点一次就可以

@brookshi brookshi added the v0.4 label Oct 29, 2017
@brookshi
Copy link
Owner

@gumutianqi
兄弟,这个在0.4版本已经做好,可以查看下,文档

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Request Request focused on developing a specific part of a larger feature.
Projects
None yet
Development

No branches or pull requests

2 participants