• 没发过,方便提供下链接么

  • 复杂场景就不要用平台覆盖了,可以把平台理解为数据归集管理和共享的工具,用来做回归测试还是很便利的。

  • 哈哈,看来是同道中人,确实是券商

  • 还需要整理一下,会开源,请持续关注

  • 接口依赖和token处理,借鉴了JMeter的处理方式,
    以登录为例,先从登录接口响应结果中提取后续接口需要关联的值,即token,并保存:

    在同一个测试集合里,需要使用这个token的,以${token}的方式即可引用。

    这种方式是动态关联,指关联变量在一个测试集合里生成和使用,测试集合跑完后就失效。还可以考虑,设置专门的全局变量,这个我还没做,不过实现起来很容易。

  • 关联的话,借鉴了JMeter的处理方式,
    以登录为例,先从登录接口响应结果中提取后续接口需要关联的值,即token,并保存:

    在同一个测试集合里,需要使用这个token的,以${token}的方式即可引用。

    这种方式是动态关联,指关联变量在一个测试集合里生成和使用,测试集合跑完后就失效。还可以考虑,设置专门的全局变量,这个我还没做,不过实现起来很容易。

  • JSONPath断言是支持的,你可再仔细看用例详情那部分,是可以选择JSON断言,通过填写路径表达式和预期值来做JSON校验的。我所说的复杂校验是指业务逻辑的校验,关于这方面,也集成了Beanshell断言,但并不是很好调试。不过你说得很对,这些校验也不适合放在这个平台里,而是要在录入平台前就保证了接口业务逻辑的正确性。

  • 这种复杂的校验,就得写专门的代码了。我的想法是把这些校验写成特定的方法,恐怕要用到反射了,实现起来还是比较复杂的。

  • 恐怕没人有那么充足的时间,还是集中精力把一门语言学好吧,会而不精是大忌。

  • 还是那句话,平台是武器,能不能落地在于公司需求力度。而且,我初衷只是分享,可以看我CSDN博客,在货真价实地写文章。