游戏测试流程

需求评审会（策划主导，关于系统设计、关卡设计、玩法设计、数值设计、剧情设计、职业设定、）

需求分析（以测试的观点分析待测对象的软件需求，相当于制作软件的详细设计），对象主要来源于各种文档资料，入软件需求规格，Use case，界面设计，项目会议或与客户沟通时有关于需求信息的会议记录，其他技术文档等等。

                 完成一个测试项目首先必须了解测试规模、复杂程度与可能存在的风险，这些都需要经过详细的测试需求来了解。测试需求越详细准确，表明了对待测对象的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试饿质量与进度。

                 分析类别：1.常用的或规定的业务流程；2.各业务流程分支的遍历；3.明确规定不可使用的业务流程；4.没有明确规定但应该是不可以执行的业务流程；5.其他异常或者不符合规定的操作。以此理清业务的常规逻辑，一项一项列出各种可能的测试场景，同事借助于软件的需求以及其他需求，来确定应该导致的结果，彼岸星沉了软件业务流的基本测试需求。

用例编写A.理清思路，避免遗漏，将测试系统的操作步骤按照一定的格式用文字描述出来。测试方法主要包括：1.等价类比法（有效等价类和无效等价类）；2.边界值法；3.因果图（生成判定表，）；4.错误推测法（基于经验和直觉推测出系统可能存在的错误，从而有着针对性的设计测试用例）；5.其他如正交验证法、状态迁移图、流程分析法

             B.测试用例的格式与要素：编号、标题、测试场景、测试步骤、预期结果（测试步骤不可有混合）

用例评审1.先讲解整个业务逻辑图，需要保证评审人员对于整个业务逻辑图都非常清楚，并且能够理解为什么这么做；

               2.分析整个业务逻辑图是否有没有覆盖到的场景或者分支情况，采用头脑风暴；

               3.分析业务逻辑的异常处理情况，是否每个业务逻辑都有对应的异常情况处理，也采用头脑风暴；

               4.是否将逻辑的用例分类比较合理，让大家通过逻辑很容易就找到对应的用例；

测试执行

缺陷回归

封版提审（Android/IOS）

版本过审

灰度测试

正式更新

线上版本跟进