Flash游戏自动化的实现—自动化方案分析

xunmi

这是本人技术博客上的一篇原创文章（http://www.cnblogs.com/xunmi/），现在也在51testing论坛上分享出来（不能完整贴出，因为论坛帖子有字数限制），希望通过自己在Flash游戏自动化实施过程中累计的经验分享，让更多测试人员了解和分析如何更好的实现Flash游戏的自动化，希望自己抛出的砖，能够收获到大家回敬的玉，谢谢！

前端时间收到测试经理分配的任务：要求配合自动化组实现体感Flash游戏的自动化，因此根据自己对Flash游戏的测试了解以及其他自动化测试工具的使用经验，首先跟组员一起讨论确定体感Flash游戏的实现方案，Flash游戏的原理是通过ActionScript来控制帧动画的播放、暂停以及鼠标键盘在帧动画中的动作响应，但是体感Flash游戏由于有体感设备，因此与其他的Flash游戏交互上稍有不同：

体感Flash游戏的具体交互过程：1）首先玩家通过辅助识别设备和识别手柄，在体感设备前进行手臂挥动的动作，这些动作会被体感设备进行捕获，然后通过内置算法将玩家的动作分解为三维空间坐标数据和二维空间坐标数据；
2）体感设备引擎的动作识别模块会建立管道将三维空间坐标数据写入到指定目录下的管道文件中，而二维空间坐标数据则会被体感设备引擎坐标换算模块分解为横坐标数据、鼠标按键数据、键盘Esc按键数据分别写入Linux  input子系统中的系统Event、触摸屏Event、键盘Event中；
3）体感Flash游戏启动之后，会首先调用公共的3D动作模型库，将指定目录中的管道数据作为动作模型的输入进行解析，目的是将玩家的头部、双臂等关键部位通过球状、线形、带状识别点进行区分，并分析出各自的动作轨迹，这些不同的轨迹数据会被Scaleform播放器内置模拟器读取，并进行按键映射。
4）体感Flash游戏启动之后，还会从Linux input子系统中读取系统Event、触摸屏Event、键盘Event文件，由模拟器传给Flash的ActionScript执行游戏中的人物横坐标的移动、鼠标左键和右键触发的动作、键盘Esc按键操作。

按键映射的作用：如果是3D的Flash游戏，则会有人物角色或道具在3D场景的前后移动、道具的抛出、物体的旋转等动作，这些动作在Flash游戏中是通过不同的键盘按键来触发的，因此按键映射的作用就是将动作与键盘按键进行关联，模拟器通过键盘事件让Flash游戏知道应该进行怎样的三维动作。

要实现体感Flash游戏的自动化，可以以Flash游戏的数据获取来入手，Flash的播放器Scaleform是通过3D动作模型库的管道文件和Linux input子系的Event文件获取Flash执行的动作数据，因此自动化实现思路就是Flash自动化工具通过封装好的数据和测试脚本来替换体感设备引擎产生的动作数据，如下图所示：

接下来进行Flash自动化工具实现方案的具体分析：首先是操作模拟，要能够逼真地让自动化工具模拟玩家动作，需要考虑以下几个方面：

『单用户操作模拟』

Flash自动化工具对于游戏需要的三维动作数据可以用事先封装好的一系列动作数据来进行模拟，因为三维动作很难仅仅通过一系列坐标值来进行模拟，二维平面动作数据则通过解析测试脚本，然后将数据写入Linux input子系统的Event来进行模拟，但是体感设备引擎也会向交互数据文件写入数据，所以Flash自动化工具启动之后，通过脚本来停止体感设备的运行。

『玩家操作多样性』


实际当中用户的操作是多种多样的，没有既定的操作路线来模拟多个用户的不同操作，因此自动化测试工具的操作模拟功能还需考虑不同玩家在同一界面的随机性操作。这方面可以从工具的测试脚本设计中入手，实现思路是：在测试脚本中的位移、操作按键加入概率值，来让测试工具通过设置的0~100%之间的概率值增加对用户分支操作的覆盖。
『游戏界面的切换』

玩家在体验Flash游戏时会在主界面、选择界面、游戏中界面、成绩界面等界面进行切换，如果自动化工具不能区分多个游戏界面，并根据界面来执行不同的操作的话，那么自动化工具运行之后，可能就会在Flash游戏的某个界面上无法进入下一个界面操作。因此需要考虑自动化工具如何区分Flash游戏的不同界面，并自动执行相应的测试脚本。实现思路是：Flash游戏在播放器中进行界面切换时，Sacleform调用自动化工具的库文件，将约束好的唯一窗体名写入到系统的共享内存当中，自动化工具会实时监测共享内存中标识位、如果标识位为“未读取”状态，自动化工具则读取此数据，并跟测试脚本的窗体名进行匹配，查看是否存在相同项：如果存在，则执行脚本中的相应操作并将标识位置为“已读取”状态。如果不存在相同项，则工具不进行任何操作，只将标识位置为“已读取”状态。

xunmi

貌似都没人给出自己的建议~~~~~

xunmi

恩，很感谢小t给予的回馈，实际上Flash游戏的场景设计细度主要集中在每个关卡的过关条件、道具不同效果、游戏人物状态变化这些方面，这些地方的测试占游戏测试用例的大部分，而这部分通过我们的Flash自动化测试工具是没法很好测试的，因为会导致测试脚本需要设计的测试数据太复杂，每个测试面对应的3D数据也不太好封装，所以我们的Flash自动化测试工具的主要目的是进行稳定性测试，通过操作模拟来让Flash游戏长时间的运行，来做进程和资源监控，因为测试人员很难知道在长时间的Flash游戏重复体验过程中，游戏的CPU占用和内存消耗（CPU占用太多或内存太大会造成较低配置的用户无法较好体验游戏，内存泄露是性能缺陷）是怎么变化的，因为手工只能记录某个时间点的；通过每步操作的自动截图，测试人员可以查看长时间运行时是否会有错误产生，功能测试的场景设计粒度只能停留在Flash游戏各种界面按键、图片点击触发的异常、各种界面跳转以及游戏当中的随机操作可能引发的异常错误上面。

xunmi

回复 6# zlclclzl
你所说的复杂内容我想应该就是指Flash游戏的功能测试吧？Flash游戏的功能测试项比较多，而且不同的Flash游戏所需测试的功能差异也很大，所以市面很难有一种工具能够进行Flash游戏的通用测试。UI上的自动测试存在随机性问题，就拿祖玛这款游戏来说，除了每关关卡设置是固定的，每关出现的泡泡都是随机性的，自动测试无法判断随机情况的正确性。内存泄露是由于程序占用了内存空间，但最后没有正确释放或被系统回收掉而造成内存占用不断增大，比较严重的可以通过几次操作看出，但如果泄**不严重，Flash游戏没有加载所有的场景元素，没有长时间地运行，那么就无法保证内存不存在泄露问题，所以当我们可以实现Flash游戏的长时间自动运行时，就会考虑进行资源监控，并且让工具根据监控数据画出曲线图，供测试人员分析。模拟一个客户端消息，然后从服务器上获取最新的数据进行对比检查，这个有点类似我所做的平台服务器接口测试，测试的关注面主要集中在客户端与服务器交互上面，能够测试服务器接口是否正常运行，但客户端是否会根据各种触发条件来正确的发送数据给服务器这个是怎么保证的？

xunmi

回复 6# zlclclzl
你所说的复杂内容我想应该就是指Flash游戏的功能测试吧？Flash游戏的功能测试项比较多，而且不同的Flash游戏所需测试的功能差异也很大，所以市面很难有一种工具能够进行Flash游戏的通用测试。UI上的自动测试存在随机性问题，就拿祖玛这款游戏来说，只有每关关卡加载的场景是固定的，但每关出现的泡泡都是随机性的，自动测试无法判断随机情况的正确性。内存泄露是由于程序占用了内存空间，但最后没有正确释放或被系统回收掉而造成内存占用不断增大，比较严重的可以通过几次操作看出，但如果泄**不严重，Flash游戏没有加载所有的场景元素，没有长时间地运行，那么就无法保证内存不存在泄露问题，所以当我们可以实现Flash游戏的长时间自动运行时，就会考虑进行资源监控，并且让工具根据监控数据画出曲线图，供测试人员分析。模拟一个客户端消息，然后从服务器上获取最新的数据进行对比检查，这个有点类似我所做的平台服务器接口测试，测试的关注面主要集中在客户端与服务器交互上面，能够测试服务器接口是否正常运行，但客户端是否会根据各种触发条件来正确的发送数据给服务器这个是怎么保证的？

xunmi

没有人回复了。。。