多线程跑

只包含了静态分析吧，远程调用（RPC）的影响呢？

现在看来，纯测开不是好的选择，必须有较重要的业务握在手里

随着行业形势变差，学习的收益也越来越低

命名能不能统一风格啊，看得强迫症犯了

一如外包深似海！

有开源计划么？

十几年前，掌握 selenium 都算测试界技术好的了，那么几年后掌握 Docker/K8S 也许只是平常事了。

写得很接地气，希望能继续更新

皮之不存毛将焉附，行业下行，原来那些夸夸其谈的人顿时成了裸泳者

参考脉脉的设计

有什么用吗？

有什么解决方案了吗

太强了

有北京岗位么

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

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

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

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

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

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

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

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

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

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

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

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

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