胡侃游戏自动化测试

发表于:2011-09-08来源:未知作者:领测软件测试网采编点击数: 标签:
申明一下,只是在这里抛砖引玉,各位如果有好的方法和建议,欢迎指正。 首先,据我了解,国内的游戏(MMORPG)行业(国外的我不知道哈),几乎还没有比较成功的游戏自动化测试体系,或许是我孤陋寡闻吧!有少数公司在做,但是效果都不很明显,结合我自己的

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

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

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

  部署成本高:

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

  效果差强人意:

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

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

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

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

  接着,我主要说说游戏自动化测试对游戏架构的需求:

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

  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 就可以了。在编译发布版本的时候,就不会暴露这些高危数据出来,当然方式有很多,根据自己情况定是最好的。

  接着,主要说一下哪些可以用来做自动化测试。

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

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

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