接下来进行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自动化测试工具的实现方式和基本功能已经设定完毕，后续自动化工具的开发还需要框架结构、功能模块、测试脚本、日志文件的详细设计，如果大家想预知后事如何、且听下回分解（单田芳此刻灵魂附体了）。

　　言外感受：

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