近期，我所在的手游项目要开展自动化测试框架的搭建工作，虽然以前做过一些端游的自动化测试工作，但手游的自动化还没有接触过，但心想应该会有一些共同之处。于是把以前端游的自动化代码review了下，并咨询了其他几个手游项目组的同事，站在巨人的肩旁上，大致确定了自己所在项目的自动化测试框架。在本文中，我将简单抽象的说明下游戏自动化测试的基本流程和原理。
首先我们将游戏简单的分为客户端和服务端，下面开始介绍游戏自动化测试的基本流程和原理。
第一步：
从Client发一个RPC到Server，告诉Server，我要开始自动化测试了，并把自己的客户端Id传给Server，然后Client可以什么都不用管了，静静等待Server的安排。
ps，这里需要有2个知识储备。
1.客户端Id。可以简单的理解为，Server和Client通讯的凭证，因为Server一般是一个，而链接Server的Client有很多，Server怎么知道和哪个Client通信呢，就是靠这个客户端Id。
2.RPC。这个不是本文讨论的重点，网上资料较多，可以自行查找。
第二步：
服务端收到请求后，加载自动化测试代码。
如果自动化测试代码是在客户端层面实现的，那么Server先将这些自动化测试代码按需传递给Client，由Client加载并执行。
如果自动化测试代码是在服务端层面实现的，那么Sever就不需要将这些测试代码转发 到Client，直接按需执行就可以了。
那么问题来了，自动化测试代码在客户端层面实现好呢？还是在服务端层面实现好呢？一般来说，我们为了更接近真实用户的操作，会选择自动化测试代码在Client端层面上实现。怎么理解呢？就比如说，我们要实现释放技能的自动化测试，释放技能的一般逻辑是这样下：
1.玩家点击技能图标
2.客户端通知服务器释放技能
3.服务器判定是否能够释放技能
4.如果通过判定，则服务器释放技能，并通知客户端响应技能的表现
那么我如果要实现刚才说的释放技能的自动化测试，我即可以在Server端直接调用UseSkill的函数接口，也可以在Client端调用ClickButton的函数接口。正如我们前面说的，为了更加靠近真实用户的操作，我们会选择调用ClickButton去实现自动化测试。
既然一般我们选择在Client层面去实现自动化测试代码，那么为什么不把自动化测试代码直接放在Client端呢？这样就省去了前面提到了，由Server将自动化测试代码推送到Client的操作了。
理论上来说，放在哪里都是可以的。都不影响自动化测试的执行。
但是在手游自动化测试中，特别是在ios平台，很难存储和加载独立于包体的代码，所以为了通用性和一致性，我们将自动化测试代码放在服务端，并由Server推送给Client。
第三步：
当所有自动化测试用例执行完毕后，整理测试log，产生测试报告，进行后续的跟踪处理。
基本的流程和原理已经简单介绍过了，下面再介绍下，我们一直提到的自动化测试代码，这货到底包含了些什么东西呢？
首先，它会包含一个所有已经实现了的自动化测试用例清单，比如说，我实现了A副本的自动化测试和B任务的自动化测试，那么在这个清单上，就会标注A和B，自动化框架会读取这个清单，一个个去执行，当所有的用例被执行完成后，则开始生成测试报告。
其次，对应于具体的一个测试用例，比如前面提到的A副本的自动化测试用例，会有一个对应的自动化测试脚本，这个脚本你可以简单的理解为一系列的函数接口调用和状态判断。
函数接口的话，就类似于前面提到的ClickButton这种，实现A副本的自动化测试，就是将进入副本、施放技能打怪、拾取掉落、退出副本等一系列的函数接口依次去调用。然后在执行完这些接口后，通过状态判断去断定这些操作是否成功，如果没有成功，则说明游戏出现了问题。
本文来自网易实践者社区，经作者朱洁授权发布。
【声明】文章来源于网上采集整理，如有侵权，请邮件反馈yidunmarket@126.com，我们将尽快核实修改。
相关阅读：