游戏自动化该怎么做？这是一个值得探讨的问题。在中国，用手游自动化来描述，可能更为贴切。游戏自动化技术并不难以上手，有许多现成的工具提供使用。但是，要想做好游戏自动化，让其真正服务于游戏研发/运营期业务，并不是一件容易的事情。
自动化测试技术上的实质是通过代码模拟玩家的行为，本意是用来补足真人测试工作。游戏测试通常分为功能测试与专项测试，游戏自动化同样也需要适应这两种场景。专项测试分很多种，普遍来讲客户端性能测试、后台压力测试等等。后台压力测试可以采用机器人的方式连接后台专用的测试接口，可以直接调用后台的逻辑执行已经预定义的GM；客户端性能测试一般采用直接操作游戏客户端的方式，比如利用Airtest的UI自动化，或者是以GAutomator（Unity）为代表的接口自动化方法。如果是业务专项，比如数值测试、PVP平衡性、异常图像检测方面，可以采用AI自动化的方法。而自动化作为功能测试的用途，则一般采用UI自动化、接口自动化的方法，较为方便，能够控制逻辑。
游戏自动化测试执行的有效时间（除去用例的不稳定与环境因素），决定了其质量的下限。比如用于功能测试的场景，游戏自动化不可能代替黑盒测试人员去将所有的用例覆盖一边，但能够作为冒烟的作用去跑黑盒测试人员没有空余时间去遍历的场景，从而确保尽可能更多的功能是正常的。功能自动化很难跑出缺陷，但一旦跑出来的缺陷基本性质都较为严重，因此如果不充分覆盖更多的功能玩法，不在更多的机器上运行，功能自动化是没有意义的。同理，业务/性能专项也是如此，没有在更多的机器上去运行，那还不如增加人力去覆盖相应的场景。
纯粹的UI自动化不适合做大规模的游戏自动化，因为UI自动化本质上是将游戏控件viewport坐标映射到手机上的绝对坐标去执行的，一定会存在适配的问题，而且很多游戏内部的判断逻辑，用UI自动化是无法实现的。因此，UI自动化必须有接口自动化或者AI训练输入的方式，使得测试用例更加稳定。接口自动化相对于AI训练输入，逻辑上会更加稳定一些，理论上也会适用于更多的场景（尤其是跑流程的类型），但会对代码有一定的侵入，因此接口自动化对代码设计模式有一定的要求。从笔者的经验上来看，接口自动化需要做如下几个事情：
- 确保主机（客户端）与手游（服务端）之间的通信
- 游戏代码侵入：定义自动化关心的接口，模块不与业务代码耦合
- 在客户端上，抽象一层自动化关心的接口
- 对于每个自动化用例，尽可能用抽象出来的一层自动化关心的接口实现
其中，定义自动化关心的接口是很重要的一环，它不仅决定了自动化用例是否能够方便地实现以及维护，而且决定了者一套框架能否方便复用到其它游戏项目中。这是从自动化业务本身特性出发，所必须的一个环节。
AI自动化相对于接口自动化，侵入的程度会更加少，但需要更为优厚的基础条件（不论是游戏原本的代码实现支持，还是用于训练AI的基础设施）。行为树是最基础的AI，但支撑行为树的内部逻辑仍然属于接口自动化的范畴，因此这里的AI自动化偏向于“模拟玩家输入”的AI。这一块笔者了解不深，但从AI本身的特性（向一个数学目标逼近）上来讲，最适用于竞技型以及图像识别相关的场景。这些都是光靠接口自动化难以做到的东西。
当然，不论是AI、UI还是靠接口，除了跑自动化用例之外，都需要对日志、截图、录屏等信息进行收集，形成对用例流程的闭环，保留更为丰富的信息用于后续定位问题。
如何支持自动化大规模的使用，是除自动化实现本身之外的另外一个问题，也就是在做一个云真机平台的基础上，赋予自动化测试所特殊需求的功能。云真机平台的实现网上有很多类似的说明，此处不再赘述，但要支持多样自动化用例的运行，还需要一定的规范。最理想、标准的方案是docker image + configmap的形式，母镜像是用户的自动化用例框架，configmap映射用户在这个框架之下的用例配置。这样除去游戏本身的约束之外，在主机（客户端）层面，就能够让用户采用自己的方案去实现了。
总而言之，游戏自动化做到60分很容易，要往100分冲刺，还需要一番精心的设计。