背景

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

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

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

解决方案

账号业务流程：

初始方案

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

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

主要问题

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

   • 例如：客服换绑环节中，采用了 HTTP 调用接口方式，需要额外入参 Cookie，且并不是所有人都具有操作客服后台的权限，导致使用时仍需要联系 QA 同学提供用户信息或者授权客服后台权限；

2. 现业务共 80+ 款游戏，每款游戏的入参模板不同，开发成本相对比较高，且后期维护成本比较大。

   • 账号品类构造如下图：

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

最终方案

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

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

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

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

3. 交易模式组件化开发

4. 确认下单服务项枚举

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

总结

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

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