🎉 🎂 🍰 TesterHome 创立 9 周年纪念日 🍰 🎂 🎉

研发效能 造数工厂的一些疑问

杨杰 · 2021年03月05日 · 最后由 eryi 回复于 2021年03月09日 · 1016 次阅读

当前我们这遇到这样的一个问题,当前已经有一个造数平台,能支持动态 java、python 脚本、jmeter 脚本的执行,但是在向业务测试部门推广时遇到一些阻力,部分业务线自己有自己的造数脚本等,迁移到造数工厂对于他们来说收益不大。从本质上来说,这里还存在另外个问题:快速变化的业务和平台自身稳定性之间存在矛盾(固定一人跟着业务进行变化?)

咨询在 BAT 大厂的朋友,都是各业务线自己维护自己的造数工厂。

诚心求教:大家对于造数工厂这块有什么好的建议吗?

共收到 11 条回复 时间 点赞

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

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

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

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

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

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

陈恒捷 回复

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

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

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

Samercc 回复

握手😀

杨杰 回复

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

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

陈恒捷 回复

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

杨杰 回复

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

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

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

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

MarvinWu 回复

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

槽神 回复

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

这个涉及到哪些技术,详细解释一下?

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

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册