因为接口的前置数据准备，无法用接口完成，只能跑 UI 来准备，这样一搞，再搞个类似于 postman 的 itest，就显得有点多余
还不如直接用代码搞定。。
纠结
正版 接口自动化测试项目实战：Python 3.8 Requests PyMySQL pytest 正版
本书采用项目驱动模式，并通过Python库建立起一套基础的、实用的接口自动化测试框架。 本书共分为两部分，第一部分为接口自动化测试基础，包括第1～6章，先带读者部署被测系统， 然后分别讲解 HTTP 请求的发送（Requests 库）、目录及文件的操作（os 库）、日志信息的 记录与输出（logging 库）、数据库的操纵（PyMySQL 库）、pytest 框架的使用等，所用的库 都是设计接口自动化测试框架常用的基础库。
￥59
app软件测试本文转自于TesterHome，如有侵权请联系（2523030730@qq.com）删除。文章源自玩技e族-https://www.playezu.com/217199.html 文章源自玩技e族-https://www.playezu.com/217199.html
玩技站长微信
添加好友自动发送入群邀请
rainbow-shownow
玩技官方公众号
官方微信公众号
PLAYEZU
未知地区 1F
这个就看实际情况了，如果大家能力够，且觉得写代码效率还可以，那就写代码呗。否则可能引入 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 没关系