这个就看实际情况了，如果大家能力够，且觉得写代码效率还可以，那就写代码呗。否则可能引入 itest 会好一些，能避免写代码规范不一造成的额外理解成本。

至于造数据要用 UI 自动化这个，可以考虑把准备数据和接口测试解耦一下。准备数据搞个凌晨的定时任务自动造好（具体每个场景造多少个，可以根据实际情况自行评估下）并记录相关信息（如账号 id）到某个数据库表里，接口自动化直接从里面拿，并标记是否已使用。

极客时间 52 讲里，也有提过这种方式，详细的可以参照下这部分内容。

没太理解为什么只能用 UI 来准备数据，UI 调的不还是接口么？不太清楚有啥特殊的地方。

另外按题主的说法，可以尝试把这两部分解耦，数据准备和接口测试分开来处理。如楼上恒捷大大说的那种处理方式。

至于是引用工具，还是写代码，就看团队的整体能力啦。

因为系统比较古老，并不是像现在的前后端分离，不过也可以理解为接口，毕竟无非都是 GET POST 接口，只是工作量太大，字段稍微变动一下，接口维护工作量也大，所以还不如用 UI

嗯嗯，分离的话倒是可以考虑下

你说的 itest 不是 itest work 测试管理平台中的 itest

额，就是准备用你们开发的 itest work

那没明白你的问题， 写代码就好? 我这就不一一说了，我这贴子写得很清楚 https://testerhome.com/topics/30495 测试架构师如何解读测试平台的各种争议
另外，从公司的角度是要提效，不是让你写代码。

“ 接口测试的准备数据要用 UI 自动化来准备 ” 这一句我表示看不明白，且也支持数据驱动，有问题欢迎随时沟通也用 ITEST Q 群（22569636）

“接口测试的准备数据要用 UI 自动化来准备 ”
这句话的意思是 前置条件准备比较复杂，比如有一个用例，
用例：正常用户登录，输入用户名密码，能登入系统

但是在登录的时候，要校验 用户名背后管理的各种信息，比如
1.用户名没有被禁用
2.用户名在有效期以内
3.用户名对应的商家有上传营业执照，且营业执照在有效期以内
4.用户名有缴纳消费者保障费用
5.一些其它信息等。。

以上条件都符合才能正常登录，当然也可以通过接口来准备这一大坨预制条件，，只是比较麻烦，还不如走一遍 UI 自动化来的方便，不知道你们怎么准备这一大坨预置条件的？

这和 ITEST 有什么关系，你用别的接口工具， 这也要你处理呀。再说了，这在 ITEST 中，如果 A 接口有这些依赖，只要你的接口依赖别的接口的输出就行了，A 接口可以依赖一堆接口，只要存在参数引用 。你用 POST man 也要处理前置呀，

下图中，都不需要人为去管理前置，itest 自动帮你管理好，

公积积的待办撤销业务，你都不需要管前置的事，只要在撤销接口中引用其他接口的输出参数
不会用还说是 itest 的事

我寻思他也没说是 itest 有问题啊，只不过说如果接口测试也用代码，那么就可以把前置处理这部分必须使用 UI 自动化的部分跟后面的接口测试整合在一起，当然一楼所说的两者解耦也是个很好思路；至于为什么非要用 UI 自动化来做前置处理，我觉得人家的业务场景，还是相信别人的判断比较好

嗯嗯，你完全理解了我的意思，哈哈
我确实没说 itest 有问题

但这标题，会让人误解，和 itest 没关系

可以尝试使用洞见自动化测试平台，洞见自动化测试平台支持这种应用场景