转转QA 平台游戏业务数据构造解决方案

志阳、 for 转转QA · 2021年08月27日 · 616 次阅读

背景

  • 游戏业务定制化强,流程冗长复杂,辅助系统多等等因素

  • 在需求测试过程中,与第三方协作时,联调自测时,手工走正常的业务流程去构造数据,耗费的时间成本相对比较高

  • 同时,游戏业务的迭代速度很快,在专注测试时,需要测试助力联调自测构造数据,牵扯着测试同学的精力,需求的质量受到影响

解决方案

账号业务流程:

初始方案

主要目标是业务数据构造从 0 到 1,减轻手工构造数据带来的成本

  1. 游戏发布,为满足应用场景需要,游戏枚举,重复代码比较多
  2. 代码强耦合,对于迭代速度如此快的业务,变更后代码改动量大
  3. 构造入参复杂,后期对内对外推广差

主要问题

  1. 业务内部推广中,反馈数据构造不好用

    • 例如:客服换绑环节中,采用了 HTTP 调用接口方式,需要额外入参 Cookie,且并不是所有人都具有操作客服后台的权限,导致使用时仍需要联系 QA 同学提供用户信息或者授权客服后台权限;
  2. 现业务共 80+ 款游戏,每款游戏的入参模板不同,开发成本相对比较高,且后期维护成本比较大。

    • 账号品类构造如下图:

虽然可以暂时满足业务的诉求,但在内部推广及使用方面,并没有对效率提升有明显改变,慢慢的内部使用减少,失去了做数据构造的意义

最终方案

一切均是以解决业务痛点,提高效率,降低成本为目的;

根据对链路的回放抓包,再次分析论证,制定出最终解决方案

  1. 根据入参品类(账号,租号)+ 游戏(王者荣耀,和平精英等)调用平台侧接口获取发布模板,适配所有品类,所有游戏发布场景

  2. 针对二次售卖,自主发货,禁聊售卖账号售卖流程,抽离前置条件,完成数据初始化及数据后置处理;

  3. 交易模式组件化开发

  4. 确认下单服务项枚举

  5. 实现客服后台核心流程重编码,解决 HTTP 接口调用 Header 需传入 Cookie 信息,方便后续业务内部及外部推广

总结

游戏业务,降本增效迫在眉睫,数据构造作为一种重要的手段,完成方案的开发接下来还需要一段时间,未来可期。

=====================================
如果喜欢我们的文章,请 VX 搜索 “转转 QA”,专注我们吖~

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册