能支持动态 java、python 脚本、jmeter 脚本的执行

部分业务线自己有自己的造数脚本等

快速变化的业务和平台自身稳定性之间存在矛盾

这三段话感觉有点矛盾。工厂支持脚本执行，业务本身也是有自己的造数脚本，为何业务要用的话会需要造数工厂跟着业务进行变化？

我们之前的经验是，先统一接口测试脚本框架，等到大家都熟悉后，再基于框架扩展 web 界面，达到直接通过 web 界面调用流程型用例造数据的能力。业务组接入只需要加点各个造数功能的定义就可以，成本不高，实现直接复用本身的接口脚本。

不过要推广到多业务线，要看其他业务线的需求如何，以及接入是否能给他们带来收益（我们这里接入得到的收益是前端开发、客户端开发、产品都能直接自助使用，不用再找测试去执行脚本，减少沟通协作成本。有这方面痛点的还是比较愿意接入的）。如果本身大家就有一些现成的东西，前期选型调研可能就要考虑到大家现成的内容，尽可能减少大部分业务的接入成本。

谢大佬指点
这里我说的矛盾是指，假如造数工厂根据实际业务开发相应的功能（造数工厂的前后端），那么造数工厂就绑死在业务上，造数工厂平台负责人会不断应付业务的变化，若落后，则造数工厂无法符合业务要求；故当前造数工厂支持动态 java 脚本、python 脚本、jmeter 脚本，保持平台稳定性，业务测试只需要自己改自己的脚本即可；

当前我们的造数工厂有调用接口测试平台的业务场景相应功能，但是这块业务测试确实也用的不多；

真是难兄难弟啊，我跟你遇到一模一样的问题！

握手

哪些业务最需要造数据，他们现在现状如何，要用上造数平台成本如何？
已经有脚本造数据的业务（一般也说明他们对造数据需求很大），目前用脚本造数据有什么痛点，上了造数平台可以解决其中哪些？

可以想想这两个问题。个人理解关键点是这两个。

大佬，你的建议，我好好看看，谢谢

就是说你的造数脚本都需要用户自己提供到平台上，业务逻辑一变这些脚本就需要跟着变，人家用自己的脚本用的好好的，甚至在 CLI 里面更快捷，为什么要用你的平台，搁我我也不愿意用啊……
所以看起来你没有增值服务或者太少，比如

• 帮用户搞定了用户、权限接入问题从而减少了他们的重复性配置工作
• 提供了各种格式的数据结果导出格式
• 提供了用户使用习惯的分析，哪些是高频的、哪些是不常变的、哪些耗时比较长的，等等等等
• 适配对接用户造数之后的目标使用场景，比如测试平台、框架，提供一键对接灌入等
• 提供按照用户原有脚本可运行的容器，让用户直接平移而不需要重新开发，或者一键迁移等功能
• 你们自己的业务自己清楚，多找一下用户的痒点……

另外，找机会访谈一下用户，让他们象征性给点建议，汇报的时候把功劳分摊到用户头上，跟大大大 BOSS 汇报或者写邮件的时候就说 “在 XXX 的帮助下”，鸣谢一下，把他们绑到你的战车上，这是另一方面的小技巧。

别的业务线都有自己的造数工具，为什么要投入精力研发这样一个统一平台呢，背后有没有上级主管的支持？
如果有的话，可以尝试做个优势分析，可以稍微吹一点，拿着数据再让高层帮忙推动；如果没有，一般来说是没戏了。
做工具跟做产品的思路一样，前面几楼也说得很清楚了。

平台很久就存在，只不过开始没有他们要的功能吧，后来在去年年底才加了文中描述的那些功能（这块的功能确实来的比较晚），前面几位的意见确实很好，只能再跟测试 leader 多聊聊了

提供用户原有脚本可运行的容器，让用户直接平移而不需要重新开发，或者意见迁移

这个涉及到哪些技术，详细解释一下？

1、让别人低成本，甚至无成本的将现有业务迁移过来
2、能否有一些过硬的亮点功能可以吹？这样领导也好去推

提供平台，平台本身不含任何业务。