没发过，方便提供下链接么

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

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

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

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

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

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

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

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

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

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

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

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

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