😂 感觉这样的话弄着弄着后面就真的没法维护了

谢谢，目前我也打算这样弄

了解了，谢谢

插个耳机？

针对你的几个问题我的理解是：

2.没有设计合理的测试用例，只能通过用户行为驱动去覆盖 app 的功能。

依据用户行为覆盖功能也算是一种场景测试方法吧，这个也算合理呀

3.在上线新功能的时候，测试人员已经把所有的功能都测试完了，自动化测试方面都还没有进行或者进展很慢，跟不上发版计划。

这个是指脚本还没运行还是脚本还没开发完成呢

4.在实际使用过程中，很容易出现一些异常情况，例如：单个测试用例运行毫无问题，一旦串行多个测试用例或多或少的会出现一些异常现象。 该怎么来规避？

异常现象是指的是脚本出错还是程序出错呢？脚本出错的话就要具体原因具体解决；程序出错的话，是不是说明出现 BUG 了呢

赞同，这种图形化式平台真的不好用

想了解下，你们那对 “造数 + 平台” 这种方式的用户和领导反馈是咋样的呢？

我这边的理解是，平台或框架都是为了业务而服务，所以能高效完成业务测试目标就行。所以造数脚本如果能提高效率，那也可以尝试下哇，至于平台使用率，感觉不是特别重要，菜鸡的理解哈，可能存在错误

接口测试的前置数据准备，图形化平台的 for 循环，变量的提取调用，数据库连接的封装，会感觉比用代码实现复杂度还高，不够灵活。用造数脚本的话，感觉会好很多，且造数脚本也可以平常手工测试时使用。

是的，接口测试平台直接以 http 方式调用 flask 的造数服务就行了