为什么不直接像 jmeter 那样，直接在断言中写 SQL 呢，写是把 SQL 变为一个服务 (接口),主要是为了重用

itest 如果你需要到数据中验证，你可以通过 itest 的 api 生成功能。建好数据源后，写 SQL 就行，sql 变为服务 (接口)。然后在你需要在接口测试中， 写一个接口用例，然后不管是执行完要验证数据，还是执行前，从 DB 中提取数据 都 OK ，引用这个 接口用例的数据就行了

我们都实现了，自己实现的 。之前也是找开源的，没找到，所以自己写，搞了一年，现在基本上完事了。在最后的测试阶段

先写用例，在写用例的时候，你只要存在参数引用，就是存在依赖关系，如 A 接口，引用了 B 接口提取的参数，或是 A 接口引用了 C 接口取到的 token 也算是存在 依赖 。然后我反推出来，和调用链不太一样的

不管如何同步，还是没解决，怎么接口又变了，这里的同步，只是同步了接口的变更，前端要是按之前的返回数据做的响应，如果数据结构变了，前端能不改?

fixed

谢谢指正，确实是，马上改

你好！ 你这问题和本贴要表达的没一分钱关系。 如果你硬要曲解 一站式为一统江湖，只能表示无话可说！汽车的 4S 都有丰田家的，本田家的且还有众多的专修店的存在，就算有 6S ,10S 专修店也一样会存在。一统江湖我认为是狂妄的想法，且很不现实。

"目前 itest 上面集成接口测试之后，就把自己限制在很小的一个 web 接口测试范围了 " 人是活的，工具是死的，从来没有人被工具限定

实际不乱，建项目时，选择的是一站式模板，可以改的，接口测试，就看不到手工测试的东东了，后续我们可以让用户制制显示的页面 ，他关注什么，显示什么，不关注的功能，他看不到。
关于接口测试，免费版就只做 HTTP 的，后续可能有 RPC 的，GUI 现在及将来也不会碰，性价比低。后续 CD CI 集成以及代码扫描都要实现
什么都想干反而可能搞不好，就算想都做，最好把自己的平台做成一个工具集，可选的插入式集成。这个建议非常好，免费版这个不改的，正在实现的商版是这样做的

我就欢迎这种平台，乐见百花齐放

调用接口时，制造混乱，也是混沌的概念呀，叫接口混沌测试有何不妥

造据数据是强业务，没法做成通用的

之前也可以用，只是后置插件你要自己实现，这前手册没写这 如何用，后续手册中我们写详细 点，下周的版本，你就不用写只要写 SQL 就行，我们自动把他当成一个插件（但是你一行 JAVA 代码不用写），然后调完接口 A，再调这个服务就行，后续通过这个服务来检查，如果你想在 A 接中后就检查，还是要写插件，在插件中，调用这个服务

DevTestOps

打错了是说 我们实现方式和 其他不同，上面不是能

这个刚开发完，下周就 OK 了，我们实现方式和 其他不能，数据库校验做成一个服务,SQL 你自己写，以插件形式，插进来，我们后置来调用

非常中肯的评论，共识多多

您提的调试提醒了我，后面我在上传插件后，加一个测试 ，输入相关数据，可以测试插件本身， 在测试时，单独把这个测试线程的日志写为一个独立文件，可下下来看。

插件化后，调试确实是一个问题。后续，这块我们文档补充全，只要按文档来，我们来回调，对使用者来说就是个回调函数，目前这块文档还没写得很细。

这个回复打 100 分 哈哈

维护慢就是平台维护的问题了，而不是平台没有用 。本质上还是投入产出，看哪个合算

我就是感于之前的讨论，觉得我要说些什么

没太明白你的意思，itest work 中，A 接口提取了响应数据中的 某个值取名为 A ，这个 A 是不能重或的，，别的接口只是引用，和 key 没关系呀， 不同的接口,KEY 可能是 name ,等，我们不关记他的 Key ，只关心，他引用的变量。如下图，第一个图和第二个图都引用了 packageId 这个变量，和 key 无关呀。不知你说的 key 是参数名不，且我们支持 XXX.XX.XX 这种对向属性的 key

接口间只要存在参数引用 事实上就存在依赖关系，然后就可以推导出来了