最近两个项目中游荡，首次接触facebook游戏的测试，感触还是很多的。与之前的web2.0的互联网应用相比，webgame的测试更多样，也更加的复杂。留下点Memory，对Webgame进行自动化测试是挑战新的开始。 根据游戏整体架构的不同，在协议测试方面还是可以有很大的发展余地的。比较流行的facebook游戏进行自动化测试的还是比较多的，不过由于游戏UI方面的修改比较的多，所以在一开始选取好的测试方法是很重要的。

　　在游戏测试中用的比较多的是类似于按键精灵的这样的方式hook，利用windows api进行屏幕点的操作，以下是比较简单的实现，是通过autoit3对游戏FARMVILLE进行的操作，点击这里下载。

　　自动化的实现主要是将FARM中的田地size化，通过在1280x800的屏幕中，进行模拟对屏幕点的操作。实际效果还是很棒的，测试时遇到修改的情况的话可以通过修改excel中FARM的田地参数进行修改。可以使用更多的API进行定时，定点的收割。

　　以上提到的是使用windows api半hook的方式进行的自动化测试。

　　我们还可以通过真实的tcp，http或者https的协议来进行相关的自动化测试。

　　主要看在facebook中的游戏整体架构，使用flash前台通过json或者amf协议进行协议发送的话可以利用python的pyamf或者 perl的amf3解析包解析后进行协议层的自动化测试，这样可以减轻前段UI测试的压力，一般游戏的UI测试用例非常的多，很多涉及购买等操作的可以利 用协议自动化测试进行。

　　flash的自动化测试可以分为UI层面的测试及协议层面的测试。

　　flash的UI层面的测试：

　　UI层面的测试建议在基本UI及核心玩法已经确定的情况下运用，这样比较有实效性，返工率比较低。

　　主要实现的手法之前的Jason已经介绍过了，windows hook技术及Browsers本身的特性。

　　关于Browers本身的特性，这里需要提下iMacros这个在FF中的插件，iMacros插件版不支持flash的自动化，pro版可以通过代码实现很多的逻辑性操作。

　　Pro版实现flash自动化的效果也可分为屏幕定位及元素定位的方法，在整体实现上还是很有效果的。

　　flash的协议层面测试：

　　协议层面的测试做自动化测试的效果比较好，使用性比较高。主要的做法为，通过各种编程手段及辅助工具（http watch或者charles）来共同实现。

　　简单介绍下python下的framework：

　　首先需要python的pyamf包，可以通过这里来安装。

　　之后我们需要Mechanize包，这是发送http及https包比较easy的类。

　　通过已有的python test framework框架将测试用例变量化，最后输出报告格式化，这样整体的测试框架就出来了。

　　做协议测试的另一个方面是验证UI无法放松的边界值对后台逻辑的影响，很多游戏的失败就是因为这个原因。

　　python的 Pyamf 解析包是对amf协议的解析利器，可以使你轻松的实现类似于对html-text的操作，我们也可以利用Mechanize来进行相应的协议自动化测试。

　　Pyamf在协议测试中我们主要需要用到的类有三类：

　　1、amf3协议包体类：

　　envelope = pyamf.remoting.Envelope(amfVersion=3)

　　产生的envelope对象就是之后对你需要传递数据的封装对象。

　　2、pyamf amf3协议的转换类：

　　message = pyamf.remoting.encode(envelope)

　　产生的message 就可以利用urllib2.Request进行传递了。

　　3、pyamf amf3协议的解码类：

　　res = urllib2.urlopen(req)；

　　content = res.read()；

　　content = pyamf.remoting.decode(content)

　　这里最后产生的content就是返回amf3整体解析好的数据，可以根据需要将返回值进行解析，返回值可能是list{list{……}，”jason”=jason}，可以根据需要最后做相应的assert。更多pyamf类相关信息，查询这里。

　　之前介绍了如何进行webgame自动化测试的 思路及针对flash进行的自动化测试的框架。在对游戏进行自动化测试的时候，总是会思考大部分的致命BUG都来源于随机的操作，那么我们如何进行这些方 面的自动化测试呢。这时FUZZ模糊的思想又体现到我们的面前，我们可以将需要生成的测试用例交给COMPUTER来自动生成，并且自动执行得到相应的报 告，整体FUZZ模糊测试的概念就比较清晰了。

　　我们主要使用的是模糊测试中的自动协议生成测试并与协议测试相结合进行自动化测试。

　　利用pairwise的思想进行模糊测试。

　　我们需要考虑的模糊因素有以下几点。

　　1、各种类型的对象的模糊参数设计，模糊参数默认值。

　　2、组合参数对象的顺序模糊。

　　3、非正常类型的参数模糊，针对XSS。

　　利用设计的用例组合进行穷举算法生成相应的用例。

　　以下以最简单的用例做个实例：假设需要参数：”id=12&Goodid=12300&name=jason”。

　　针对ID的设计可以为{-65536，-1，0，12，65536}，针对Goodid的设计可以为 {-65536，-1，0，12300，65536}，针对name的设计可以为{jason，null，None，”"，…………}，针对参数顺序 {（id，goodid，name），（id，name，goodid）……}

　　根据上面的测试用例集合自动产生相应的测试用例，然后进行相应的协议自动化测试。当然这里设计的用例不完善仅供参考思路。

　　模糊测试的使用可以借助很多已有的测试用例类，类似之前Jason介绍的sulley一样，它的用例库比较的全，这样测试覆盖率会比较高。

====================================分割线================================

最新内容请见作者的GitHub页：http://qaseven.github.io/