胡侃游戏自动化测试(2)

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

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

　　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.任务不能重复做。

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

　　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

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

原文转自：http://www.ltesting.net