挑战类Flash游戏测试用例设计 [转]
前段时间参与了Flash游戏的功能测试，发现游戏测试的内容比较的繁多，因此总结一下测试用例的编写思路，便于以后能快速进行同类游戏的用例设计。
所测试的Flash游戏类似<雪地漂移上百层>这款游戏，先简介一下这款游戏的需求：这是一款考验快速反应的益智游戏，游戏的过程就是通过控制角色在空中左右平移吃掉屏幕中的上升道具来保证自己一直向上升，如果角色速度减到0然后滞空掉落，将显示角色所达到的最大高度以及得分。
1）首先是游戏初始界面
2）随后进入道具说明界面
3）游戏开始先滑入跑道获取起飞初速度
4）游戏当中左右平移操作
5）挑战失败后的成绩统计
〖备注〗
游戏的安装、卸载、升级的功能不划为本次功能测试的讨论内容。
此款游戏的需求不算太复杂，既没有多种模式的选择（水果忍者游戏），也没有多种关卡设计（祖玛游戏），在测试时偏重操作性及数据正确性。进行功能测试用例编写之前，首先进行测试用例设计：
『首先是基本功能的验证』
测试用例首先应该对基本功能进行覆盖，基本功能就是能保证玩家能够进行一个完整的流程操作，即启动—开始—退出三个基本步骤，然后再根据每一步进行测试项分解：
每个测试项有相应的测试点，比如游戏启动测试项，其测试点根据图标、显示方式、启动时间、按键操作分类后进行测试内容细化：
|
测试项 |
测试内容 |
|
游戏图标 |
图标的大小符合需求中的设计 |
|
图案跟需求说明书的原型一致 |
|
|
界面显示 |
在不同的分辨率下显示全屏 |
|
启动成功后，光标模型显示正确 |
|
|
启动项检查 |
启动时间不超过需求中规定的约束值 |
|
启动成功后，游戏的进程名没有错误 |
|
|
按键操作 |
启动过程中通过功能键强制中断 |
其他的测试点的细则不一一列举，根据游戏中的实际情况进行细化。
『每个界面的测试』
基本功能虽然能保证游戏的操作流程正常，但对于游戏内容的正确性是无法保证的，界面也是玩家在体验过程中会关注的内容，因此对于游戏内容的检查首先应该根据各个界面进行下手，其中每个界面的跳转路径测试，也保证除基本流程之外的分支流程能够正确，其测试项有：
『游戏元素的细分』
界面只是游戏内容的一小部分，实际上游戏内容远不止繁多的界面，通常还有角色人物、道具、音效、成绩、奖惩规则等元素。此款游戏没有生命值的需求，所以奖惩规则没有在测试设计中考虑，根据游戏元素整理的测试项如下：
『占用资源的关注』
游戏的资源占用也属于功能测试的重要内容，测试结果需要在测试报告中记录，通常都是记录游戏的CPU占用及内存消耗，需要注意的是这两项数值都是实时变化的，因此需要记录的数据需要进行筛选，选择重要的初始值和峰值进行记录。
如何才能得到这两类数据的峰值？这需要设计合理的测试场景：1）CPU占用理论上是游戏线程越多，读写数据操作越频繁，则CPU占用的数值就越高，因此CPU占用的峰值测试场景为玩家操作频繁的界面中。2）内存消耗则是根据游戏在运行时加载的资源多少来决定的，因此理论上玩家玩的时间越长，加载的界面、元素越多，内存的消耗就越大，因此峰值的测试场景需要尽量遍历所有界面、接触到所有道具，测试时间也需要在4个小时以上。
『异常场景设计』
异常场景的是对测试用例覆盖率最有效的补充，往往最容易暴露问题的就是异常的操作或环境。用例的设计需要考虑游戏与系统如何进行数据交互、游戏采用框架以及哪些数据需要跟其他软件进行传递的。
测试的Flash游戏运行在Linux环境，与底层系统的交互涉及到操作数据和玩家成绩：操作数据（角色在游戏中的左右移动）是通过pipe管道与底层系统进行交互，玩家成绩（最高高度和最大得分）的则是通过scroe.xml文件进行保存。因此异常场景的测试项有：
此款游戏的测试用例设计思路已经基本完成，然后就需要对每个测试项进行测试点的细化，最后执行测试进行功能验证了。
后记：是否完成了功能验证，就意味着游戏没有严重问题？实际上这款游戏上线之后，根据服务器的一段时间日志统计，并没有多少玩家去玩，虽然游戏不存在影响运行问题，但此款游戏在市场上表现并不成功，我们忽视了游戏开发环节中一项重要的工作，那就是用户体验测试，在完成游戏功能测试之后，应该在公司内部或现网试运行阶段进行游戏体验，收集和筛选反馈建议，查看游戏哪些内容需要丰富以增加用户粘度、是否存在捷径可以刻意降低游戏难度、哪些元素缺少吸引需要去掉等。游戏不像商业软件，有特定的用户和明确的需求，游戏应该注重用户粘性，这样就需要考虑用户体验、游戏平衡、玩家成就感等内容，因此测试时也需要重点考虑这些。
