游戏测试-测试用例编写规范

用例标准： 所有的测试用例，不单单是自己需要明确其中的测试点，最重要的一点就是，将你的测试用例给到一个刚毕业入职的新人，他可以按照你的用例内容去完成相关黑盒的测试。那么写好测试用例，标注出用例中的各个模块，各种情况就很有必要了。希望这篇文章可以帮助到有需要的同学们。我是17，一个游戏测试工程师。wink~

一、前言
1.1 背景    为保证测试用例对需求的覆盖率，即对一个系统从整体功能到单个功能，都尽可能的高的覆盖。而单个功能点主要强调的是不同的输入及其组合所带来的各种输入动作，是否都做了处理；测试用例设计首先要明确该系统存在多少功能点，要通过各种常用的测试方法来保证用例的完整性，然后再对各功能点的边界范围进行考虑。所以要保证测试用例的设计按照一种合理的结构组织进行，这样才能够更有效的保证系统所有功能点的覆盖率。
1.2 目的为测试用例的质量负责，使测试工作能有序、合理化的进行，从而提高实施测试时对所测玩法、系统或者活动的测试质量，也是作为各测试人员在设计用例时的一种规范，使之设计的用例能有效的被管理。 
二、 用例规范
2.1 测试用例用途l  指导测试工作有序进行，使实施测试的数据有据可依  l  确保所实现的功能与策划预期的需求相符合 l  跟踪测试进度，确定测试重点  l  评估测试结果的度量标准 l  分析缺陷的标准。 
2.2. 测试用例设计依据l  策划文档  l  项目内总结的用例编写关注点  l  外网玩家的操作习惯 l  测试工程师本人的理解程度（个人经验）
 2.3 用例内容及相应标准功能模块名称：要求检查模块划分清晰，必须包含有：玩法开启、功能主体、数据保存、协议测试、配表检查、关联模块检查等 功能子模块名称：对测试功能模块进行更进一步的拆分，如把玩法开启模块细分为：开启条件、关闭条件、GM指令开启关闭等。用例标题：对所测试逻辑点简短的描述，在前置条件处用【】说明。 用例类别：用标注功能主流程对应的预期结果，明确冒烟及回归需要执行步骤。
 前提条件：执行用例时需要的前置条件，前置条件需要额外构造时，需要说明清楚构造步骤。操作步骤：  执行该动作需要完成的操作，步骤明确，输入输出要素清晰，操作步骤的各个分支都要覆盖到，
分支划分需要用逻辑判断作为划分依据，具体步骤需要写到无法再进行检查。如获得奖励，需要考虑奖励发放的不同情况（背包or邮件），并检查获得奖励后奖励的正确性。
 预期结果：  执行完该操作后的表现结果，需要说明清楚一个操作对应的客户端表现检查，和服务器结果验证，比如进行强化操作，强化成功后的预期结果有：强化成功飘字，强化等级提升，材料消耗正确，获得强化属性等。
实际结果： 实际结果为失败时，在预期结果后增加子主题并标为X。具体示例如图： 2.4. 用例设计步骤l  测试需求分析：从策划文档分析结果中，找出待测功能的需求，通过自己的分析、理解，整理成为测试需求，
要清楚被测对象具体包含哪些功能点，将测功能的业务流程要进行全盘的整理出来（可画简单的流程图作为参考），主要包含该功能流程的主流程、分支流程、关联功能流程、关键判断条件以及完成该操作的条件。
（具体标准及方法见用例分析） l  
 测试用例设计：测试用例设计的类型主要包括功能测试、边界测试、异常测试、性能测试（非必须，存在新增动画等可能影响客户端性能时增加）、压力测试（非必须，存在多人匹配等可能影响服务器性能时增加）等，
在设计用例时要尽量考虑边界、异常等情况 l   测试用例评审：由测试用例设计者发起，参加的人员需包括测试负责人、功能负责人、开发人员及其他相关的测试人员 l  
 测试用例完善：测试用例编写完成之后需不断完善，功能负责人新增功能或更新需求后，测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；
在功能上线后玩家反馈的bug，而bug又是因测试用例存在漏洞造成，也需要对测试用例进行完善。 
三、用例评审
3.1、评审原因测试用例是执行测试的原则，但由于编写人员对在需求理解、设计等理解程度不同等因素的影响，首次产生的测试用例质量难以避免会有不同程度的差异，故对编写的测试用例进行评审是很有必要的，
其作用是测试用例的评审过程能够起到用例结构清晰化、场景覆盖全面化以及优先用例的合理化安排等。 

3.2、评审内容l  用例设计的结构安排是否清晰合理，是否高效的需求进行覆盖，用例的优先级别是否安排合理 l  
是否覆盖了测试需求的所有功能点，包括需求中的玩法规则、玩家可能进行的流程或操作等 l   用例是否有很好的可执行性。例如用例的前提条件、执行步骤和期待结果是否清晰、正确 l   
是否已经删除了冗余的测试用例，是否包含充分的负面测试用例 
3.3、评审过程基于文档需求分析的测试计划完成之后，进行初审，主要是对测试范围和测试要点进行审查 ；在测试用例的设计完成之后进行复审，主要是对测试用例的结构、覆盖率，具体描述是否有很好的可执行性，是否有冗余用例的存在进行评审 
3.4、评审人员l  部门评审：测试部全体成员参与的评审 l  项目评审：项目组全体测试人员与部分开发人员、策划人员等组成的小组  l 内部评审：全部参与测试的人员
3.5、评审方式l  会议评审（包括内部评审及客户评审）。由设计该用例的人员进行讲解，参与会议评审的相关人员给出意见或建议，并由专人记录评审的意见和建议 
3.6、评审结束标准经评审的用例由用例设计者根据评审的建议或意见进行修改，更新用例，再次发起评审、修改、更新用例，反复评审后，直至用例达到要求。（反复评审时存在时间问题）
 四、用例执行流程
4.1、建立测试计划 
4.2、分派测试用例给制定的测试人员 
4.3、逐条执行测试用例，并及时更改用例状态，通过时，标记通过，当用例执行失败时，需要通过表单系统提bug，并把测试用例和bug进行关联。
当用例阻塞无法正常进行时，标记为阻塞。并在备注中添加阻塞原因。
4.4、回归测试，阻塞和失败用例重新执行后，及时更改用例状态。