随着智能设备的普及和移动互联网的兴起，各家互联网巨头纷纷在往移动端布局和转型，同时初创的移动互联网公司也都盯着这个市场希望分一杯羹。在这个大环境下，互联网的重心已经慢慢从Web端转向了移动端，而移动端的软件测试也变得越来越重要了。今天就说说移动测试中最重要的两个方向。  

APP自动化测试完全不同于手游自动化测试

手机App和手游的开发技术不同，这导致了两者的自动化测试技术是截然不同的。以安卓开发举例，手机App一般使用Android SDK开发，使用Java编写。通过Android提供的服务，我们可以获取App当前窗口的视图信息，进而查找和操作按钮等控件，以完成自动化测试，如Uiautomator。这个过程是标准化的，从技术上来说没有任何难度，因此各个公司各个App自动化测试的方法都大同小异。

但手游的开发却不是这样。手游一般使用引擎开发，现在著名的有cocos2d和unity3d。两者都是使用引擎自带的语言进行开发，主流的分别是c++和c#，虽然在开发过程中也有按钮等控件的概念。手游测试的自动化很难实现，现在也TestBird这种专门做测试公司能深入游戏引擎来进行自动化测试。  

接下来具体说说不同之处 　　

玩法不同导致功能测试更复杂

随机性。游戏的场景和过程是动态并且伴有随机要素的，这体现在两点。 　　

1、你重复玩一个游戏关卡，很可能两次出现敌人以及游戏过程是不同的。

2、你玩一个手游的时候不进行操作，敌人和周围的场景也在时刻发生改变。 　　

这两点对自动化测试带来了极大的挑战，如果测试脚本写的不够灵活，很容易导致上一次运行成功的脚本这一次就无法运行了。我们需要在测试脚本里适当的加入探索和自适应的功能。

App测试就没有这个问题，大部分App的使用方式都是静态且可以重复的。因此自动化测试可以完全按照测试脚本进行编写并执行。  

探索性。手游和App的第二个玩法不同在于探索性。App一般都是功能性的，好的App需要把它的功能简单明了地告诉用户。而游戏重在娱乐性，需要给玩家一定的探索要素。因此在做手游测试的时候，我们需要测试游戏的用户帮助说明是否清晰，同时后续的游玩和探索过程和前面给出的说明之间是否有合理联系，规则的指示是否有足够的提示性。  

难度测试。App希望做的越简单，用户的使用成本越低越好。而手游是有难度设置的。我们在做手游功能测试的时候，会把资源和等级调到最大以方便后期功能的执行，但当所有的功能测试都做完后，我们需要把自己的资源初始化，以"回归"一个普通玩家的水平，通过普通玩家的视角来查看游戏的难度提升是否合理，资源分配是否均匀。

关卡测试。App的使用是功能性的，一个功能的重复使用总是一样的。而手游具有关卡的概念，即便是同一种玩法，关卡和关卡之间也有细微的差别，前面的关卡测试正确了，并不表示后面的关卡一定是正确的。作者曾经碰到过一个手游的Bug，当游戏进行到某个后期关卡时，游戏一定会崩溃。而导致这个Bug的原因也很简单：这个关卡的图片资源在打包客户端的时候没有加入。因此当我们玩前面的关卡时并不会触发这个Bug，但一到后面的关卡就出错了。 　　

这类Bug虽然原因简单，但确实非常难测试到。因为各个关卡的玩法虽然都一致，但一个游戏的关卡数却是非常多。如果我们要遍历所有的关卡走一遍，那耗费的人力成本将是非常大的。对于这类重复性的关卡测试，建议使用自动化脚本进行遍历。

PvP测试。App的使用普遍是单人的，而手游往往有玩家对战的PvP模式，好的手游更是具有实时的PvP模式。由于两个玩家实时进行游戏合作或者对战，因此网络延迟的测试就变得非常关键了。我们在测试中需要模拟不同的网络对游戏延迟的影响，观察两个玩家的状态和数据是否一致，同时体验网络延迟对游戏手感的影响，这在传统的App测试中是完全不需要的。

TestBird

移动测试中游戏和应用的不同之处