1、概要

本报告旨在总结手游测试的流程，主要从黑盒功能测试方面出发，以手游测试为中心作出的一份工作总结报告。

2、QA测试的定义和工作职责

我所理解的QA（QualityAssurance），中文为“质量保证”，在整个项目产品的生命周期中，QA将与项目中的其他所有部门进行协助合作，跟踪和分析产品中的问题，督促问题的解决，同时尽可能从用户玩家的角度分析游戏的不足及不合理之处，以保证游戏质量达到项目需求。

QA工作职责是对游戏进行测试和建议，在项目生命周期内游戏各阶段正常运行为工作重点。合格的QA在进行测试工作的同时会逐步成为对项目产品最了解的人员，应当对游戏的各个方面和项目的工作有充分的了解，从而及时发现游戏中的缺席和项目管理中的缺陷，并提出专业性建议。

QA所着重做的三件事：

①发现并跟踪游戏的BUG。

②指出游戏中存在的瑕疵。

③从用户角度提出游戏的不足和对游戏的建议。

3、游戏测试的流程

游戏测试流程依附于游戏开发的流程，一个正确，正规，合理且科学的测试流程对测试的效率和工作质量有至关重要的作用，这里不再赘述。

下图是我个人对游戏测试流程的理解，这份报告也将围绕我所理解的测试流程展开。

4、测试

准备期

测试准备期是测试工作的酝酿奠基期，为整个测试的工作打好基础。

4.0 项目计划

测试应当尽早介入项目，从测试的专业角度为项目提出意见。根据项目计划分析出测试需求，从而为测试计划做铺垫。

4.1 测试计划

4.1.0测试计划定义

测试计划依附于项目计划，同时又应该有自己的独立性，对项目计划有监督催促的作用。当测试计划与项目计划发生冲突，断档时，应及时向PM反应，以检查项目或测试计划哪个部分出了问题，作出相应的调整，保证之后的流程能正常正确的进行。

测试计划制定应依据测试需求，将测试工作进行合理有效的划分，为下一阶段的测试做好准备和规划，使测试人员清晰的了解项目测试情况以及每个测试阶段该做什么，也可以让项目的其他人员了解测试人员工作内容，以便配合测试工作。测试计划分为总体测试计划和详细测试计划。

4.1.1测试计划的目的

测试计划的制定应明确：

（1）为什么做这些测试。

（2）不同工作阶段的测试内容。

（3）不同测试阶段的起止时间。

（4）测试环境，测试文档存放位置，BUG的管理方法。

（5）测试人员安排。

（6）如何测试，测试的方法。

（7）测试的风险评估

（8）游戏所要达到的质量标准

测试计划编写完成后，需所有测试和开发人员进行评审，对测试计划进行完善修复，直至大家达成一致。然后根据测试计划制定详细的测试方案，测试计划和测试方案最大的区别在于前者重点在于“做什么”，而后者重点在于“怎么做”。

4.2测试用例

测试用例是对测试任务的细化描述，包含具体的测试方案，测试方法，测试技术，测试策略等的一个文档。

理论上测试用例应包括以下几个要素：

①编号：同一份用例中编号应具有唯一性。

②模块：用例对应的功能模块。如：背包的一键整理功能

③重要性：用例的重要程度。

④预置条件：执行用例的前置条件。如：游戏版本号，运行环境等等

⑤测试输入：执行用例所需的输入。

⑥操作步骤：执行用例详细的步骤。

⑦预期结果：执行操作步骤后预期所得到的结果。

⑧测试结果：PASS/NG/NT

⑨备注：补充说明。

4.2.1编写用例的准备

首先，详细阅读策划文档，拆分策划文档中的功能点。然后，根据功能模块进行划分，细化每个模块的用例。然后，根据功能模块的逻辑，关联设计用例。最后，依据测试用例的设计方法，保证测试用例的规范，有效。

4.2.2测试用例的设计方法

测试用例的设计方法有很多，网上也有很多总结，适合自己的方法才是最好的方法，下面我写几个自己常用的用例设计方法，有的是自己总结的，有的是较常使用的。

（1）需求文档拆分转化法

所见即所得，策划文档是我们设计用例的基础，将我们在策划文档中所见到的都转化成我们的测试用例。包括但不限于：所有策划文档需求描述的文字信息，所有策划文档中的流程图，示意图，状态图等，所有和策划进行交流所达成的需求信息等等。都可以转化成测试用例。

这是我写测试用例的第一步，也是我最开始写用例的基础。这个过程应当充满着愉快（？）的交流，一定要耐心询问策划自己的每一个对需求的质疑和不确定的地方。

（2）错误推测法

基于上述所得用例，及自己的经验直觉，推测出游戏中所可能存在的错误，从而针对性的写出测试用例。

包括但不限于：正确操作过程的不正确操作，容易发生错误的情况，在以前测试中发现的相同或相似错误，相同逻辑下其他用例发现的错误等等。

（3）边界值法

边界值法是很重要的一个用例设计方法，也是问题出现较多的地方。边界值法就是对输入和输出的边界进行测试。边界值的例子有很多，比如：购买物品的最小值和最大值，UI界面的边缘，活动的开始和结束时间等等。

需注意凡是文档中规定了有取值范围（值不一定就是具体的“数”，重点在于范围）的都需要进行边界值测试；凡是有次数和时间相关的，都需进行边界值测试；凡其他有边界的情况（单项边界，双向边界），需进行边界测试。

边界测试的取值应注意：

①给定了取值范围，应选取恰好在边界，在边界外，在边界内三种来测试。

②给定了个数或次数，应选取对应个数，最大个数，最小个数，比最大最小个数恰好大1或小1等几种值来测试。

③其他各种边界情况。

（4）等价类划分法

如果穷举来写用例的话，用例是无穷无尽的，不仅浪费了大量的用例编写时间，而且非常影响用例执行的效率，做了无用功。等价类划分法通常与边界值法相联系来写用例。等价类通常划分为有效等价类和无效等价类。

等价类法可以提高测试用例编写的速度和用例执行的效率。

举几个例子来说下有效等价类和无效等价类：

①比如购买物品，数量最小为1，最大为20。那么购买1-20个物品就是有效等价类，也就是1-20是等价的。小于1或大于20的就是无效等价类。当然边界情况要根据边界值来进行用例编写，这也是为什么我说等价类划分和边界值通常要联系着来写用例。

②再比如购买物品输入数字，只能输入数字，其他都不能输入，那么所有数字算是一个有效等价类，其他如汉字，符号，字母等是无效等价类。

等价类还有很多例子，不再一一列举。

（5）穷举法

穷举法用在等价类不能作用在的情况。比如，玩家起名字不能用特殊符号，此时需对特殊符号进行穷举测试。

（6）逻辑图法

画出文档实现的逻辑关系图，或询问程序功能所实现的逻辑，对功能的逻辑结构有所了解然后遍历逻辑图中的各个路径。通常有：判定逻辑的真值和假值（可看做if··else··，true or false，如果为真，则怎么怎么样，如果不为真，怎么怎么样，），条件逻辑的分支覆盖（可看做swich  case1 case2··），还有上面两种的组合逻辑，等等。这种方法我不太常用，很多情况是在出现BUG后像程序或策划询问分析BUG时，深入询问实现逻辑才会做。

（7）其他的用例设计方法

用例的设计方法还有很多，上面是我经常所用到的方法，除此外还有因果图法，正交实验设计法等等。留待以后作深入研究再补上。

4.2.3编写用例所需要注意的地方

（1）尽量根据用例的执行顺序编写用例，从而提高用例的执行效率。

（2）编写用例前一定要熟知功能系统的需求。

（3）编写用例时要根据测试功能项目进行分类，便于之后的分析和阅读。

（4）编写用例时要着重主要功能需求的重点，以及功能需求和流程中风险较高的地方。

（5）用例条数的多少不能说明用例质量的好坏，做到不多不少，覆盖全面最好。

（6）测试用例写完后应在项目组内进行评审，评审通过后方可执行。

4.3 测试环境

这里所说的测试环境是广义的测试环境，包括测试工作所需的软件和硬件。硬件环境如测试所需服务器，客户端，网络设备，各种测试机等等。软件如测试工作所需操作系统，数据库，BUG管理软件，版本管理控制软件（SVN）以及其他所需用到的软件。

测试环境的要求：

①应符合游戏或服务器正常流畅运行的最低要求。

②所选软件应较普及便利，方便工作进行。

③测试环境应尽量独立，纯净。

④虚拟测试环境应尽量接近真实环境。

测试环境的搭建了解并不深入，此处不做深入讨论。

兵马未动，粮草先行。测试准备期的工作做好了，方能为之后的工作顺利进行做好保障。在测试准备期通常具体的工作流程如下：

①提交策划文档

策划提交策划文档，通过SVN上传到策划文档目录下，并通知测试人员。

②策划文档的分配

测试拿到测试文档后，由测试组长进行工作分配，测试人员进行策划文档的测试。

③策划文档测试

测试人员应对策划文档中游戏玩法功能的合理性，可玩性等作出分析，是否存在问题，并对存在的问题作出相应反馈，反馈到相应策划。

④测试用例编写

策划文档测试进行之后，进行对应文档的测试用例编写。

⑤用例审查

用例编写完成之后在测试组内进行用例审查，互相检查用例，进行用例的补全和修正，通过审查的用例进入执行。

⑥策划案修改

这是不可避免的流程，策划对策划案进行修改后，必须通知相关测试人员，重新进入步骤③。