一、背景
背景是小公司，测试 10 来人左右，大部分人都没有代码基础，领导从我入职时，开始推行接口和 UI 自动化，目标是年底看到成果后开始投入更多资源（使用 httprunner 类的 python 框架）。现在的情况是，接口自动化是用测试平台做的，我和另一个人负责维护。
二、现状
我目前的想法是平台不好用
，造测试数据和写条用例都太慢了，所以想法是曲线救国，flask 做造数脚本，加平台执行用例，减少测试平台的使用，让平台更专注于接口测试的执行和报表啥的，且造数脚本在平常测试过程中也能使用，让接口自动化也能有点产出；另一个人的想法是，使用测试平台的话，其他人维护也好接手一点，如果以代码 + 平台的方式，后续其他人不好维护，且如果测试数据都用造数脚本了，那测试平台也就没意义了。
三、疑问
所以想问下社区内各位大佬，对于小公司而言，造数脚本 + 测试平台的方式是否是一条能走的路线？
用 flask 是起一个服务使造数功能以 http 接口形式输出？如果是这样的话，在 flask 上这些 “造数脚本”，可以在测试平台配置页面或者直接跳转支持调用就行了
使用服务来造数据的优点是？能举例说个场景吗
我就是这样搞的，造数 + 平台 结合
挥霍。
回复
接口测试的前置数据准备，图形化平台的 for 循环，变量的提取调用，数据库连接的封装，会感觉比用代码实现复杂度还高，不够灵活。用造数脚本的话，感觉会好很多，且造数脚本也可以平常手工测试时使用。
从提升平台使用率的角度看，造数的这种改造没什么帮助的吧。我们现在也面临这种尴尬处境，框架改成平台后，使用率反而降低了。了解下来，主要是以下几点：
1、框架的自由度高，而且还能看到框架的实现，调试也方便，使用者是有一定收获的；
2、使用平台限制比较多，而且写一条用例要操作几个表单才能完成，便捷性差很多；
tester
回复
我这边的理解是，平台或框架都是为了业务而服务，所以能高效完成业务测试目标就行。所以造数脚本如果能提高效率，那也可以尝试下哇，至于平台使用率，感觉不是特别重要，菜鸡的理解哈，可能存在错误
