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

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

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

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

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

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

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

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

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

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

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

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

学习路线的话，可以关注我的 CSDN 博客照着动手做，博客地址在文章开头。我的建议是，直接上手做点小东西，倒逼式学习，切忌看书看视频按部就班的学习，那样的话没有阶段性成果刺激，很难坚持下去。

这个平台呢，目前主要用在接口的全量回归上，优缺点都有。
先说说优点吧，
1、测试团队全体成员增删改查接口的测试数据非常方便，就像操作 excel 一样简单，而且提供了标准用例的功能，每个接口只要手动创建一个标准用例，后续再添加用例自动写入相关数据。
2、只要用例都准备好，测试集合的拼装非常便利，关联功能完全满足需求，而且成员间用例可复用，实现了数据共享

至于缺点呢，主要体现在无法支持个性化的需求，比如：
1、对结果进行复杂校验，比如对接口响应结果的逻辑运算校验和数据库校验等。
2、测试的场景做不到 JMeter 那么复杂，比如各种循环控制器、IF 控制器等。

通用性和个性化本来就难以调和，我思考良多，也没有好的办法。后续的思路是，将复杂的测试流程做成可视化的任务调用，但这样复杂度就高了，数据修改也很不方便了。