游戏的UI自动化测试的开展新姿势
对于目前的两大游戏引擎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自动化也几乎不需要改动游戏代码，只在引擎一级简单修改可以实现。
