胡侃游戏自动化测试

http://www.51testing.com/?uid-138935-action-viewspace-itemid-95511

申明一下，只是在这里抛砖引玉，各位如果有好的方法和建议，欢迎指正。

首先，据我了解，国内的游戏（ MMORPG）行业（国外的我不知道哈），几乎还没有比较成功的游戏 自动化测试体系，或许是我孤陋寡闻吧！有少数公司在做，但是效果都不很明显，结合我自己的做的一些经历和实际操作，小小的说说自己的想法。

1.目前市面上的一些测试工具如：lr，wr，qtp什么的不适合做游戏自动化测试，至少我没找到合适方法。个人理解是因为这个工具实际是通过简单录制或定制一些行为来实现自动化测试的，做游戏自动化测试，这些工具有几个重大缺点：

     部署成本高：

     自动化体系在server端很难部署，定制行为的时候几乎不能调用到游戏的接口，无法获得游戏实际运行的信息，预期结果不方便定制。如果是通过简单录制回放的话，效率不如手动操作好，对一些繁琐的行为，几乎是不现实的，而且这些工具对tcp/ip协议支持不如http协议好，有兴趣的同学可以去研究研究。

     效果差强人意：

     我之前用lr做了一下游戏自动化，不到一周我就放弃了，后来招了一个lr的新人，我在百般劝说下，他都没放弃游戏lr的自动化测试，结果3天不到，他也放弃了！游戏自动化测试本质目的是提高测试效率，用lr反而降低了测试效率，那么我们还用lr来干什么呢？这里我也不多说原因了，到后面我会提一下另一种方法的，主要说另一种方法的优势，而这种方法的优势恰好是这些工具的劣势。

2.几乎所有的游戏在前期架构设计上就没考虑到游戏自动化测试的需求，所以在游戏后期介入自动化测试几乎是不现实的。

3.公司没有足够的人力物力，或者说项目组就没有意识到自动化测试的意义，所以也无法开展。

4.测试自身的能力，很多（现在不是几乎了，有的游戏公司的测试还是很nb的）测试自身能力不足，或者接触不到游戏代码或 其他需求无法满足，导致无法进行自动化测试。

写完一后就被人严重的bs了一下，说我界面不友好.....我只好说，这就是我的风格！嘿嘿，对于这个界面确实因为能力有限，编辑起来特别麻烦，所以在我没有找到好方法前，我决定不改这个风格了！

这一篇，我主要说说游戏 自动化测试对游戏架构的需求：

首先，如果在一款成熟运营的游戏中，试图让测试自动化起来，几乎是不大现实的。原因不外有二：

     1.我要想在游戏世界里刷出一个怪或要取得一个player的信息，如果我们的开发人员没有暴露接口出来，请问，我们该怎么办？

     2.我们要做一个自动化体系，是我们自己再去开发一个新的系统呢？还是用原来的系统？如果开发一个新系统，那么我可以告诉你，国内几乎没有那个项目老大允许你这么做，运营期的游戏，最重要是一个持续稳定，如果你插入你的开发量进去，我可以明确的告诉你，你会完全打乱你老大的计划。那好，那我们在原来的系统上改吧？对这一点，我相信有经验的同学都知道，去改别人的代码的效率远远低于自己开发的效率（如果是小改动，可能是达不到自动化的效果的）。

这2个原因是阻碍游戏自动化的主要因素，当然还有 其他因素，比如对项目组对测试认识方面等等的问题，这些我不在这里讨论，这里只说说 技术上的需求。

这一篇，我将会从游戏架构设计上大概谈谈，游戏自动化对架构的需求，下一篇会说说，成熟运营的游戏自动化可以做些什么。

在项目风格基本确定后，就是程序架构的设计了，如果在这个时候不考虑到测试的一些需求的话，那后期做起来就会很难。

一般来说，游戏设计分3大块：1.数据库设计。2游戏逻辑server。3 游戏的逻辑client。这里的server是广义的server，不同公司的设计是不一样的，不细分。游戏client就是指平时我们运行的，可以实际“玩”的游戏，运行在我们玩家的pc机上的可执行程序。

对于我们测试来说，其实可以把 数据库独立出来，数据库和游戏的交互无非就是存取修改操作。在不考虑的性能情况下，自动化测试可以不考虑数据库，当然对于数据安全性等的操作其实属于策略问题。

其实我们实际做的自动化测试主要是游戏server的实际运行和与client的交互。这里再强调一下，自动化的本质是为了提高测试效率，所以我们只让计算机做他适合做的事情，而不是把所有的测试都交给计算机，那可能就本末倒置了，反而是为了自动化而自动化，没意义。

设计上要求务必达到：

    1低耦合，高内聚

        这个能简化我们实现测试的过程，又能让我们更准确的定位问题和回归问题。具体原因这里就不说了，可以去看看软件设计和测试的一些资料。

    2.游戏运行要高透明，游戏运行的对象是可以给定条件获得，并且运行条件是可编辑的。

        这个问题不能太深入，太深入可能公司就要找我麻烦了哈，大家原谅一下。这样设计的目的就是为了，我们可以定制我们的测试过程和预期结果。

    3.通信是是可以设置和编辑的。

       其实client与server的交互的本质是通过发送数据包来实现的。我们游戏人员通常说的协议其实是制的一个一个的数据结构，而不是tcp/ip之类的协议。实现这个的目的是我们在部署大量client与server交互的时候不需要运行我们的client，只需要一个发包client就可以了，而不需要弄上几千几万个物理client。

    4.所有的接口在发布版本是关闭的。

       这个是鉴于某公司之前出现了一次严重事故而增加的，之前某公司由于发布失误，导致外网玩家可以直接编辑游戏运行的一些数据，这个做起来也非常简单，在server上加一个宏就可以实现：ifdef _Debug define  Test endif 就可以了。在编译发布版本的时候，就不会暴露这些高危数据出来，当然方式有很多，根据自己情况定是最好的。

今天主要就这么多内容了哈，不能太深入，深入会涉及到公司的一些机密，但是思想还是可以分享的。

预告一下：下一篇 胡侃游戏自动化测试（三） 主要说一下哪些可以用来做自动化测试。

广告一下哈：有兴趣的可加群17827576，主要是讨论游戏测试 生活的

感觉三还写不完，四接着写！

我们将我们的测试任务大概分解成了（三）的8步吧。

接下来，我大概说说测试思路哈：

player = GetPlayerByName('xxx') 首先获得一个player对象，这里前面就是谈到的对象概念了。

player.SetLevel(10)             设置player对象等级

player.AddItem(b,n)               设置角色身上道具b

player.SetPkValue(5)            设置pk值

player.ChangePos(x,y,z)         将player传送到npc那

player.GetMenu(npc,choice)      选择和npc对话和具体选项。

if player.GetItemNum(b)!=n-1 or player.task[taskid].status:判断是否正确接到任务和扣除道具

    Error(player)   如果错误，则返回player的数据（包含任务等数据）

    return false

好了，这里说个思路就是了，我们实现 自动化测试的思路大概就是这样的。当然其实这个还可以进一步做的，相信大家见过一些地图编辑器和任务编辑器，我现在可以说一个，其实我们自动化测试的时候可以做测试编辑器。思路还是和上面说的一样。

只是要做这个测试编辑器，就需要更好的设计优化我们的测试平台，将我们测试行为分离成指令+数据的形式。比如上面说的找npc对话接任务，我们平台可以设计一个接口：GetNpcOption(npcid,choice，player)实现把player传送到npcid那并选择某个选项。这个接口首先需要能找到这个npcid的npc，然后吧player传送到这里来，然后player选择这个choice。好了，我们假设我们这个也已经做过优化了。接下来，我们设计用例吧：

操作过程                  

player.level=10

player.SetItem(b,n)  

player.pkValue=5

GetNpcOption(npcid,choice，player)

预期结果：

player.GetItemNum(b)==n-1 and player.task[taskid].status

测试结果就拿来和预期结果比较就可以了。相信这样说大家已经明白了这个测试编辑器怎么做了，就是将我们行为和数据简化成指令+数据，我们可以通过这个编辑器来编辑测试行为，而我们的测试平台需要能解释这些行为。这里测试平台要吧这些行为翻译成游戏能理解的数据。这个最初我以为开发量会很大，但实际做下来，这个翻译行为比预想的轻松得多（当然，前提还是架构充分考虑到这些问题哈）。

好了，我们现在可以把精力充分花在设计用例上了，我们可以把最擅长设计用例的人充分利用起来，让少部分人去维护吧，这样，我们就可以把最合适的人放到最合适的岗位上去了。

为了测试更全面，我们还可以更进一步，让我们测试编辑器，可以设计一些随机行为，这里随机行为一个是数据的随机，一个是操作顺序和操作的随机（前提是这些操作随机后是游戏平台能识别并翻译的）。我们还可以定义只要不满足什么条件就是测试不通过的。这样只要我们的测试覆盖率就直接受我们设计测试影响了。一些人无法实现的大量，重复的，偶然的也可以做了。

一些朋友问我：能不能再具体点？其实已经很具体了，自动化是一种思想，就像lr，qtp一样，其实工具并不重要，关键是你的思路，有了思路，一切就都有头绪了。当然有的东西可能不适合你们。毕竟不同公司条件或做法都有区别。

好了，大概思路就这样，今天爆发了

预告：胡侃游戏自动化测试（五）会说说游戏架构未考虑测试的时候，可以做些什么。