手机游戏测试规范

1. 文档介绍

1.1 测试目的及原则

测试的目的就是为了尽可能多地找出错误，也就是说测试工程师必须千方百计的、尽最大努力去找隐藏在产品中的Bug。

测试的原则就是从用户的角度去看待自己手中的产品，通过自己的测试能够为用户提供放心的产品。

要达到上述的原则，要注意以下几点:

（1）应当把“尽早和不断的测试”作为开发者的座右铭。

（2）设计测试用例时应该考虑合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。（3）制定严格的测试计划，并把测试时间尽量放的宽松一点，不要希望在极短的时间内完成一个高水平的测试。（4）回归测试的关联性一点要引起充分的注意，因为往往修改了一个Bug会导致其他Bug 的产生。

（5）要妥善的保存测试文档，并记好笔记。

1.2 测试范围

1.3 用户对象

1.4 参考文献

1.5 术语与缩写的解释

2. 测试的分类

游戏产品测试就是在产品未出货前，对产品需求、设计规格说明等进行最终的复查，是质量保证的关键步骤；始终贯穿于整个软件的生命周期之中。

2.1 测试技术分类

按测试用例设计方法(或者测试技术）来分，测试包括黑盒测试和白盒测试。黑盒测试：也称功能测试或基于规格说明的测试，它是通过测试来检测每个功能是否都能正常使用；白盒测试：也称结构测试或逻辑驱动测试，是按照程序内部的结构来测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行。

二者的区别：黑盒测试是把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序的接口进行测试；而白盒测试是把测试对象看作一个开打的盒子，依据程序的内部逻辑结构相关的信息，设计或选择测试用例，对程序所有逻辑路径进行测试。

2.2 测试策略分类

测试分为单元测试、集成测试和系统测试。具体区别如下：

类型对象目的测试依据测试方法

单元测试模块内部程序消除局部模块的逻辑和功能上的错误和缺陷模块逻辑设计及外部说明

采用白盒测试方法

集成测试模块间的集成与调用关系

找出与软件设计相关的程序结构，模块调用关系及模块间接口方面的问题

程序结构设计

结合使用黑盒和白盒测试方法（灰盒）

系统测试整个系统，包括系统中的软硬件等

对整个系统进行一系列的整体、有效性的测试

系统结构设计、目标说明书、需求说明书等

黑盒测试

（游戏主要测试手段）

2.3 测试方式分类

测试包括手工测试和自动化测试（即依靠一定的测试工具来测试）。

3. 游戏系统测试流程

游戏测试流程包括：游戏程序详细设计文档、编写测试计划、测试用例执行、测试评审、评审测试工具、提交Bug报告、测试总结审核、返回开发修改。

3.1 详细步骤

（1）根据游戏程序详细设计文档，测试组长制定测试计划。

（2）审核制定的测试计划。

（3）根据测试计划设计，设计测试用例,编写测试用例。

（4）相关开发人员和测试人员审核测试用例。

（5）开发人员提供测试版本，以及相应版本所作修改的文档描述。

（6）测试人员根据测试用例和测试工具执行测试。

（7）记录测试结果，提交BUG报告。

（8）测试组长审核后，将BUG反馈给开发人员进行修改。

（9）开发人员修改后，提供新的测试版本,测试人员重新测试。

3.2 系统测试流程图

3.3 测试计划与策略

1.《编写测试计划》文档具体应指明测试的范围、方法、资源，以及相应测试活动的时间进度安排表。其应该包含如下内容：①开发文档需求(即目标）②测试需求说明（明确测试对象）③测试任务安排及人员分配④测试资源配置⑤计划表⑥问题跟踪报告⑦测试的度量

2.《编写测试策略》文档具体描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试以及每个阶段内在进行的测试种类（功能测试，性能测试，压力测试等）。具体包括：①测试策略项②测试阶段（单元测试，集成测试，系统测试）③测试类型④测试技术（例如参照80-20原则，即80% 的软件缺陷常常生存在软件20% 的空间里）⑤完成标准（例如：95％测试用例通过并且最高级缺陷全部解决）

3.4 制定有效测试用例

有效的测试用例不但可以提高测试效率而且便于对测试结果进行评估。以下从几个方面来说明：1.产品的名称、版本号及Tester；2.测试用例编号（Function的编号）；3.需要测试的模块；4.测试用例，其大致分类为基本功能测试用例（Basic Function Test Case)、全面测试用例（Full Test Case）和支撑测试用例（Sustaining Test Case）；5.测试的操作步骤；6.预期的结果；

7.实测结果（Pass/Fail）；8. Bug的优先等级（Priority1，2，3）；9.发现Bug的具体描述；10.附件（抓取到的有助于RD解决Bug的程序）。

3.5 游戏测试工作及数据统计

在产品开发过程中，测试人员应该做到如下几个方面：

1. 根据新项目的计划及该研发游戏产品的功能写出大概的Test Case（一般为简单的功能测试用例）出来以便后期的测试。

2. 在开始设计的初期，测试人员应该从客户的角度提出一些好的建议（该建议由PM来决定是否作为新功能添加到新产品中）（A-Test)。

3.当产品初具模型时，测试人员应该根据RD软件工程师的要求做必要的功能性和稳定性的测试（当然此时也可以提出自己新的见解，此见解由PM根据产品的性价比来决定是否作相应的更改或添加）(B-Test)。

4.当产品已经基本上实现其预期的功能时，测试人员应该做一次Full Test（其中包括：基本功能测试，大量测试，压力测试，边界测试等等）来找出Bug（C-Test）。

5.对于找出的Bug,测试人员应该每天向Project leader汇报当天找到的Bug,并标识出P1,P2,P3 Bug（P1，P2是Bug的优先级）所占的比例，以便Leader的复查和判断到底是不是Bug。

6.测试人员要立即将这些Bug及时的反映到Buglist的数据库中，以便RD软件组人员对软件的修改。

7.当发现的Bug被修改后，测试人员还要对此进行大量的重复测试(即回归测试），以确保Bug 不在存在，最后由测试人员来Close Bug。

8.对于新的版本出现后，测试人员应该根据自己的经验进行快速的功能测试或者先对数据库中Old Bug进行验证，以便快速发现新版本中的Bug。

9.产品出货后，用户在真正使用时可能会产生一些问题，所以在出货后，测试人员应该在适当的时间内做一次Sustaining Test或者进行一次回归测试，以便为用户提供版本的升级或问题的回复。

3.6 测试信息流程图

规范化的测试流程能够很好的提高测试效率，保证产品的质量。下面是简单的测试信息流程：

4.测试报告

《测试报告》文档是执行测试阶段的测试文档，指明执行测试结果的文档，它包括如下内容：

1.概述：说明本报告是哪一个测试活动的总结（版本号及主要测试的模块）

2.测试的时间、人员及地点（要说明地点是实验室还是其他环境）

3.Bug总结一栏表（Issue Summary）

4.测试结果的统计，包括总项数通过多少项，失败多少项，部分通过项及各百分比(用直观的图形表示比较好）；该版本无法测试的用N/A表示

5.测试总结和改进建议。即总结主要的测试活动和事件，所耗费的资源，如：所需的人员，时间等；同时应该提出良好的建议（从客户的角度）

测试报告表

项目名称程序版本

功能模块名

编制人编制时间

功能特性

测试目的

预置条件

参考信息特殊规程说明

用例编号用例说明测试步骤预期结果测试结果缺陷编号备注

1