背景
在社区上看到了挺多优秀的测试平台，但大多都是以接口为核心的平台，比较困惑的是，为啥类似的造数据平台都没有？造数据也是业务测试的痛点啊，有一些流程挺长的，涉及上下游的，为了验证一个功能，需要花时间造数据去验证；有时候开发在开发功能的时候，也是需要测试进行造数据。
原由
先说明一下我的原由，我是个业务测试的，想着看一下社区的帖子，找一下造数据相关平台的思路，但是搜索无果，很无奈~我在组内维护了一个小平台，没有前端页面，用的是 fastapi 框架，因为 fastapi 可以一键生成 swagger 文档，写完造数脚本之后，直接在上面一键执行造数服务。
说一下困惑
一些业务造数的脚本，实现了 API 化嘛，通过代码写的，但是会有一些问题：
- 只有写这个造数脚本/代码的人才知道相关的造数逻辑，给其他人维护或者小伙伴离职了都比较难维护下来
- 因为是造数嘛，通过 post 开发的接口去实现造数，版本迭代接口变了，那造数相关的代码也得跟着变
- 因为组内每个人的代码风格都不一样，较难统一下来，整体看起来参差不齐
个人臆想
如果引入平台，将造数脚本抽出来，譬如说第一步做什么，第二步做什么，第三步做什么，将步骤关联起来，将整个流程生成外部调用链接，开发拿到链接直接通过 get 或者 post(post 的话，通过约定的 key-value 进行入参) 进行调用，这样子维护起来是不是比较方便？
小伙伴们，有没有开源的数据工厂可以提供一下思路~感激不尽~
我记得之前某个银行分享过
我们之前内部有做，思路和你的类似，但有些地方不大一样。
我们当时的背景：业务是借贷业务，流程比较长（注册 - 登录 - 授信 - 风控审核 - 放款 - 还款 - 催收），有些时候测后面环节的变更，需要刚好到这个环节的账号，所以造数据需求比较强，很早就开始做了。
第一阶段，用的最简单的办法，web 前端根据提供的账号名，直接去改数据库某些数据的状态类型字段，比如一键注册、一键风控审核通过等。好处是实现简单，一个熟悉业务的测试同学就基本能 hold 住。缺点是容易改漏产生脏数据，而且从零造还得一步一步来。
第二阶段，结合接口自动化，用流程自动化用例来造数据。有几个能到上面提到流程点的自动化用例，并且把账号一些基础信息（如手机号）抽离成了配置项。好处是已经基本满足测试需要了，随时从零生成到某个节点的数据。缺点是客户端、前端开发以及产品还是不大会用（他们技术栈不一定是 java，所以不熟悉甚至本地都没有 java 环境），而且不同组用的不同的仓库，跨组使用还得了解哪个用例对应哪个东西，使用成本略高。
第三阶段，基于流程自动化用例，增加一些 controller+dto，变成 http 服务，并加入 swagger 做到每个接口自描述。同时也用 antd 做了一个前端，可以配置接入不同组的 http 服务，并基于 swagger 提供的内容，生成对应的界面。这样左侧是业务描述，右侧是这个业务下的各个造数据功能（也可以分组，一个 controller 在前端会放到一个 tab ）。执行失败前端会展示完整日志，方便用户提供给测试同学去定位解决。
除了我们的实践外，19 年的 MTSC 大会，工程效率专场，陆金所有一个议题特别分享了他们的造数服务，你可以到社区公众号底部的 MTSC 找到当时的视频和 ppt。
针对你这 3 个困惑，也相应说下我们之前对应的情况和解决：
只有写这个造数脚本/代码的人才知道相关的造数逻辑，给其他人维护或者小伙伴离职了都比较难维护下来
我们在第一阶段的时候这个问题遇到得比较明显，因为维护的人太少了，知识掌握在少数人手上。第二阶段就好了很多，毕竟大家都在写，而且能清晰说明这个流程，被定为了试用期通过的必要条件，也能保障不至于大多数人不清楚。
因为是造数嘛，通过 post 开发的接口去实现造数，版本迭代接口变了，那造数相关的代码也得跟着变
首先，服务端接口大多都是向下兼容的，所以接口变了很少会造数脚本也必须马上改，不改用不了。大多数情况是新产品接口加了参数，需要写心得脚本才能造新产品的数据。
因为组内每个人的代码风格都不一样，较难统一下来，整体看起来参差不齐
这个就需要培训和规范了。我们其实也有遇到，一开始考虑到水平不一，没限定写法，所以百花齐放，甚至有的组的写法只有自己组才能看得懂（主要是整体设计比较特别 + 各种奇妙的命名），而且大家都处于 “知道自己写得不好，但不知道怎么才能写得好” 的状态。后面整体做了一次重构，重新统一了写法，并且初期所有改动强 review ，由熟悉规范的人 review 通过才合并，保障大家姿势正确。后面就会好很多。
也补充下对标题这句 社区里满大街的测试平台都是接口类型的，为啥没有数据工厂的平台？ 的理解
1、做数据工厂或者这方面持续投入的，我目前接触除了金融类业务，好像其他业务需求都不强（大部分业务流程都是短且简单，中间态不多），所以可能做得也不多？
2、造数据很多都涉及到领域业务知识，分享出来度不好把握，脱敏太厉害就虚，写得太具体有风险。所以分享的也不多。
3、这方面更多还是体力活（一个一个脚本写下来），能做创新的点不多，受众相比接口测试这些也不广，所以大家可能分享欲望也不是太强。
所以，如果是领域相关，通用性相对不那么长的，可能你直接找同业务领域的同行交流，会比在外面找分享文章效果好很多。
我们公司有在做数据工厂，就是造数据给测试和研发做测试的，其实这些已经脱离了一般的测试平台本质，等于一个应用平台，功能就是造数据，但数据都是跟业务强关联的，做成开源的肯定不适合所有公司，还是要改，那还不如自己公司自己做一个定制化的，可能代码更简单，针对性更高，只是跟着版本迭代，需要人力去维护。
目前造数工具这块其实还是基于公司定制化的东西。并没有多少做成通用的，都是小众化的，无法独立。
造据数据是强业务，没法做成通用的
上面的都说的差不多了。
1·自动化每日定时构建。造一些各个环节需要的数据，打好 tag
2·暴力插库 (非常熟悉数据库)
以上是我在金融领域测试造数据的经验
哥昨夜睡太晚，
数据造到三点半。
躺到床上闭上眼，
半秒不到就入眠。
谁知刚过一小时，
沉睡梦中惊坐起，
我去还是造数据，
惊悸！
谁知又过一小时，
沉睡梦中惊坐起，
啊哈哥要当 coach，
惊喜！
EDP 啊 EDP！
谢谢各位大佬的回复，小弟感激不尽，也想了一下如何处理以上的困惑
- 小伙伴在写造数脚本时，尽量写明注释，这里实现是什么的功能，最好把调用的接口文档地址也注明一下
- 组内推动规范性，我这边出遍指导文章，教导小伙伴如何规范，统一写法，因为自身不是领导级别的，可能也比较难推动，可能需要小组长进行规范
- 关于平台化的话，目前也不是十分需要，个人也对前端不是很熟悉，以后平台的话，可以做类似大佬这段话的功能 可以配置接入不同组的 http 服务，并基于 swagger 提供的内容，生成对应的界面。
我们正在做。
我有给团队做一个简单的造数和工具平台，主要是做其他自动化测试的副产物，在代码层面也可以根据注释自动生成前端页面。建议不要想太复杂，一切从解决实际用途出发
呵
回复
有其它办法，比如直接仿照系统的业务处理逻辑再写一遍，开发怎么产生数据的，造数平台也一样逻辑去产生，但这么做成本太高了。
相对而言，用接口等系统提供给外部调用的入口来造数，相对维护成本低不少。而且流程性接口用例本身就是自动化测试的产物，用来造数据属于水到渠成，也没有太多为了造数据而额外付出的成本。
或者你也可以先分享下你们的现状，以及你们现在人工造数据大概是怎么做的？
我就直接写代码，用代码先造部分可以用的数据，后面慢慢再抽离出来通用的工具