对于目前的两大游戏引擎cocos-2dx、unity3D，其UI自动化测试的技术方案都已经实现。可以获取、设置UI对象的各个属性，并且可以调用UI对象及引擎的一些方法接口，实现基于引擎的UI驱动能力。有了这些能力之后，从技术上来说已经可以实现基于引擎的游戏UI自动化测试。但是单纯的UI驱动能力还不足以实施一个游戏的UI自动化测试。
UI自动化测试一般需要满足几个条件：UI相对稳定、操作过程及结果可预期、产品生命周期长。
UI相对稳定：
是指UI元素及布局在各个版本间变动不大，各个UI元素的关键属性（特别是用于唯一标识该UI元素的属性）保持稳定，其他属性可以根据需要发生变化。因为测试脚本是直接操作这些UI元素的，如果UI不够稳定，测试脚本就无法定位UI元素，也无法有效的操控UI元素。
操作过程及结果可预期：
是指交互的过程及预期结果是明确的，比如以QQ的发送文本消息功能为例，其交互过程及预期结果都是相对明确的，即使有操作分支也是有限的，可以很容易遍历。这样测试脚本的设计就比较简单，基本是线性往下执行。如果交互过程及预期结果不明确，有太多的随机性，会大大增加脚本的逻辑复杂度。过于复杂的脚本逻辑对于测试人员的能力要求高，而且会提高测试脚本的后期维护成本。
产品生命周期长：
因为UI自动化测试脚本的开发、维护成本都比较高，如果被测产品的生命周期太短，或者只发几个版本，就会导致自动化测试的投入产出比太低。
基于上述UI自动化测试的要求，我们来看看游戏的情况，一般的游戏往往不具备上述条件，常常是：
UI不稳定：UI酷炫，各种特效，每个版本都会更新UI。
操作过程及结果很难预期：
游戏战斗过程充斥着各种随机性和玩家操作的不确定性，导致预期结果需要复杂的实时计算才可以得出，无法提前预期。
生命周期短：
很多游戏只有短短几个月的生命周期。这些因素都导致了游戏的UI自动化测试成本太高。
确实很多游戏不适合做UI自动化测试，但是对于一些生命周期长、收入高的游戏投入人力做UI自动化测试还是很有价值的。而且随着测试人员技能及测试工具能力的提升，一些普通游戏也可以开展部分UI自动化测试。
下面就如何开展游戏UI自动化测试简单谈谈一些个人的想法。
做任何UI自动化测试都要考虑投入产出比，我们就按投入产出比来从高到低来探讨下游戏的UI自动化测试如何开展。
1、功能逻辑明确模块UI自动化
游戏中一般只有战斗模块的功能逻辑各种不确定，其他辅助模块的功能逻辑都是比较明确的，比如登录、商城、背包、设置、社区等都跟普通的商业软件没有什么区别。
针对这些模块可以很方便的实施UI自动化测试，而且这些辅助模块占游戏的全部UI功能的比例也很高，实现UI自动化测试具有很高价值。
对于这些相对功能逻辑明确的UI模块，实施自动化测试成本是最低的，几乎不需要改动游戏代码，只需要在引擎一级简单修改就可以实现UI自动化测试。
2、简单状态机实现兼容测试UI自动化
目前针对游戏的兼容性测试有：简单的monkey test、事件录制回放。但是这两种方式有明显的不足：
简单的monkey test：
只是随机的点击UI，没有UI元素属性获取能力，更没有UI驱动能力，无法做逻辑判断，覆盖的UI深度是有限的。连简单的登录都登录不了，更不要说更深的UI。
事件录制回放：
通过事件录制、回放来实现简单hardcode的UI自动化，也不具备UI元素属性获取能力，只要UI发生简单变化就会导致自动化失败。
针对这两种方式的不足，利用基于引擎的UI驱动能力，可以开启一个子线程实时检测当前UI状态，根据不同的UI状态在主线程中执行适用于当前状态的功能脚本即可实现相对稳定的UI兼容性测试。
举个简单的例子：以UI状态来划分一般游戏中会有登录、公告、主界面、对局、结算等UI状态。
如果子线程检测到当前UI是登录，则主线程执行登录相关脚本；
如果子线程检测到当前UI是公告，则主线程执行公告相关脚本；
如果子线程检测到当前UI是主界面，则执行启动对局相关脚本；
如果子线程检测到当前UI是对局，则执行对局相关脚本（或monkey test或回放录制的脚本）；
如果子线程检测到当前UI是结算，则执行结算相关脚本。
利用基于引擎的UI驱动能力，可以获取、操作UI元素，再结合一定的的逻辑判断就可以覆盖更多/更深的UI，非常适合兼容性测试。
通过简单状态级实现兼容测试UI自动化也几乎不需要改动游戏代码，只在引擎一级简单修改就可以实现。
3、结合接口实现实时性要求比较低的游戏的UI自动化
对于一些卡牌类游戏或者实时性要求不高的游戏，由于UI比较简单，战斗交互不复杂，实时性要求并不高。结合开发人员或者测试人员实现的一些接口，再加上基于引擎的UI驱动能力就可以实现功能测试的UI自动化。
如果有了关卡数据获取接口，通过该接口在进入战斗前获取到关卡数据，再结合战斗过程中的UI表现，通过一定的逻辑判断就可以实现战斗过程的UI自动化。
如果有了结算数据获取接口，通过该接口在战斗结束后获取该局的结算数据，再获取结算UI显示数据即可以验证结算结果UI显示是否正确。
这种方式只需要游戏提供接口，可能会需要改动游戏代码，如果通过协议截获的方式对游戏程序影响最小，那么对UI的驱动基本不需要改动游戏代码，只在引擎一级简单修改即可实现。
4、结合AI实现实时性要求很高的游戏的UI自动化
对于一些复杂的，对实时性要求很高的动作类游戏，比如格斗、射击类游戏，则建议结合AI来实现UI自动化测试。AI实现对实时性要求很高的战斗过程的自动化，并对外提供接口用以获取战斗数据。
利用基于引擎的UI驱动能力实现其他模块的自动化，结合AI实现战斗模块的自动化，从而实现整个游戏的UI自动化测试。
可能会有人认为：既然有了AI，就可以完全用AI实现自动化测试。
但是UI自动化测试不仅仅需要UI驱动能力，还需要自动化测试框架提供调度、执行、统计、展示等功能，这些功能显然不适合让AI来实现。AI最适合实现战斗的驱动及对外提供游戏数据获取接口。AI一般集成在游戏内部，显然不适合用来完成整个游戏的自动化测试功能。
结合AI实现的UI自动化成本是最高的，需要开发AI代码，好在一般具有一定规模的游戏开发团队也都会自己开发AI来做一些开发自测或者作为内挂提供游戏托管功能，所以只需要在这些已有的AI上扩展一些功能即可，成本也是可控的。
以上就是我对游戏UI自动化测试的一些想法，各个游戏可以根据各自项目的情况有选择性的实施投入产出比可控的UI自动化测试。
