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调用自动化工具的库文件，将约束好的唯一窗体名写入到系统的共享内存当中，自动化工具会实时监测共享内存中标识位、如果标识位为“未读取”状态，自动化工具则读取此数据，并跟测试脚本的窗体名进行匹配，查看是否存在相同项：如果存在，则执行脚本中的相应操作并将标识位置为“已读取”状态。如果不存在相同项，则工具不进行任何操作，只将标识位置为“已读取”状态。

其次如果自动化工具只是为了能实现自动运行的话，估计有人会说那我使用按键精灵不也可以了吗，要对得起Flash游戏自动化测试工具这个响当当的名号，那么就需要考虑自动化工具能够协助测试人员测试到哪些手工不易测试的内容：

1）    基于工具能够摆脱人工操作而自动运行Flash游戏，所以首先就可以测试这个Flash游戏的稳定性，因此要求工具能实时监控Flash游戏的PID是否存在，另外还需要根据进程PID实时记录Flash游戏的cpu占用及内存消耗，因为测试人员很难通过手工记录CPU占用和内存消耗来知道Flash游戏长时间体验过程中其CPU占用和内存消耗（CPU占用太多或内存消耗太大会造成较低配置的用户无法较好体验游戏，而内存泄露则是严重性能缺陷）的变化情况；

2）    另外在Flash游戏测试过程中，会有一些概率出现的bug，如果让测试人员一直重复操作来重现这种Bug，无疑是一种人力的浪费，因此通过测试脚本的配置，让自动化工具代替测试人员自动执行这种概率性Bug的重现，然后自动化工具加入每次切换界面或鼠标点击时，就进行屏幕截图，并在日志中记录操作步骤、点击的屏幕坐标点位置，测试人员通过图片和日志来分析概率性bug是否已解决以及能否重现。通过每次点击的自动截图，测试人员还可以查看长时间运行Flash游戏时是否会有其他错误产生，功能测试的场景粒度主要在Flash游戏的各种界面按键、选择项点击触发的异常、还有各种界面跳转错误以及游戏场景中的随机操作可能引发的异常错误上面。

现在Flash自动化测试工具的实现方式和基本功能已经设定完毕，后续自动化工具的开发还需要框架结构、功能模块、测试脚本、日志文件的详细设计，如果大家想预知后事如何、且听下回分解。

言外感受：不要试图让自动化工具既有功能测试、又有性能测试、稳定测试、安全测试从而承载太多的功能，这样的设计意味着复杂的功能设计、更多人力和时间的花费、并且工具开发之后由于过于复杂还需要进行专门的培训、并需要对工具进行自身缺陷的检查。中小型公司的自动化方案，个人认为可以从数据的交互、协议数据的模拟来入手来考虑自动化方案。

转载于:https://www.cnblogs.com/xunmi/archive/2011/09/23/2185516.html