【IT168 技术文章】

    前面我大概说了一下游戏自动化测试的一些现状需求，这一篇主要谈谈游戏里面哪些可以做，哪些好做，哪些难做，哪些没必要做以及一些原因。欢迎拍砖哈，希望大家也谈谈你们的做法和优点。

    我们在做游戏自动化测试之前，我们先假设我们的架构已经设计的足够好，允许我们能够通过我们的测试工具，获取游戏的运行状态并且修改游戏的状态。原本打算写到五就差不多了，后来应一些朋友的要求，我会大概说说游戏架构没有考虑到自动化测试的时候，自动化测试可以做的一些事情。

    据我了解的情况，目前国内所有的网络游戏都是采用面向对象的方法设计和实现的，如果有不是的，我没接触过，也不知道用什么办法去做，所以再一次假设，我们的游戏都是使用的面向对象的方法设计和实现的，请记住，这里我再三提到对象这个概念。后面讲的一些东西将会围绕这个概念展开。

    还是先说一下哪些东西不建议采用自动化测试吧：

    1.表现类，以主观感受为主为测试目的测试对象。

    大家都知道，计算机最喜欢做的是逻辑性计算，而不是人性计算。之所以不做，原因就是这类测试几乎无法定义预期结果，所以更不要谈测试结果了，如果没有测试结果，那么计算机做了什么呢？这种问题主要集中在client上，比如画面，音效，操作性，当然还有设计的游戏平衡性等等。这里标准其实就是：当人无法用逻辑语言表达出预期结果的东西，不要试图自动化。

    2.性价比低，一次性劳动且开发量大的测试对象。

    自动化的目的是为了提高效率，而不是为了自动化而自动化，也不是为了来表演某个人的技术能力。我见过某公司的一个朋友，曾经花了几大天的时间做了一个测试工具，仅仅是为了节省一个人半天工作量的测试工作。这种主要是需要做一个评估：这个测试工作是经常的吗？这个的自动化测试的开发成本是多少？我以前才开始做的时候，一个同事给我提了一个需求，让我单独给他做一个工具，用来检查策划新提的一个数据文件，这个数据文件只是他们的一个设计文件，而且文件内数据的关系只是有这个策划的心情来决定的，我当时傻不拉叽的给她做了（我估计我当时是色迷心窍）。而我花2天做的东西，她就点了一下鼠标，从此以后这个东西就永久的存储在工具库里了，不知道何年何月这个工具才能重见天日。因为我不知道将来是否有一天，还会有策划会按这个规则去设计他们的数据表。说明一下，这类数据文件之间的关系完全是通过数据来对应，一旦对应关系发生改变，测试代码也需要改变，所以重用性不高，而且这个仅仅是他们拍脑袋的结果，并不是我们实际运行在游戏中的数据文件。

    说了这么多，现在开始说哪写东西适合做自动化测试：

    计算机喜欢干重复性逻辑活动，那我们就让他干这种事情吧。

    简单算一下效率，假设某个测试工作需要5人*2小时/天的工作量，而且每天都是重复的工作，比如我们做游戏的，一般游戏发布前都需要对版本质量进行review，这个事情如果我们可以在我们下班后，让计算机去做，会是多么幸福的一件事情啊！假设游戏生命期3年，每周发布一次版本，每次发布前需要10个小时的绝对工作量，那么3年就是10*52*3/7=223,也就是要花费一个人223天的工作量，这其实是一个人一年的工作量了，而我们开发这个东西只需要10天！

    我们做自动化测试的时候，一般做通用性的东西，也可以叫做平台类的工具，在这个平台上，我们再设计自己的行为，通过这个平台作用于游戏，再通过平台将结果返回给我们的测试代码。

    而这个平台就要回归到前面所说的对象概念了，我们运行在游戏种的一些逻辑其实都是一些对象的行为。结合我们的测试可以说其实我们测试就是侧某一个对象在某一个状态下，是否产生了某种行为和没有产生不应该的行为。有了这个概念，我们设计自动化测试思路就清晰了。

    首先，这个平台我在二里面没提出这个说法，但是其实就是这个概念。这个平台主要是实现：实现测试代码和游戏的通信，通过这个平台，我们测试代码可以获得和修改游戏运行的环境。

    这个平台是长期维护的，当游戏一些逻辑发生变化的时候，平台可能需要相应的变化，否则可能会阻碍测试。平台是通用的，测试代码是针对具体的测试对象而设计的。

    我们假设现在需要测试一个任务（下列是我将这个任务分解了一下，为条件和步骤哈）：

    1.找a npc能接取到 a1任务。

    2.找其他npc不能接到a1任务。

    3.角色等级>=10级。

    4.角色有道具b。

    5.角色pk值大于5.

    6.扣除b道具后，角色接得a1任务。

    7.角色杀20个怪后，可以交任务。

    8.任务不能重复做。

    预告：胡侃游戏自动化测试（四）将接着讨论