游戏测试流程
需求评审会(策划主导,关于系统设计、关卡设计、玩法设计、数值设计、剧情设计、职业设定、)
需求分析(以测试的观点分析待测对象的软件需求,相当于制作软件的详细设计),对象主要来源于各种文档资料,入软件需求规格,Use case,界面设计,项目会议或与客户沟通时有关于需求信息的会议记录,其他技术文档等等。
完成一个测试项目首先必须了解测试规模、复杂程度与可能存在的风险,这些都需要经过详细的测试需求来了解。测试需求越详细准确,表明了对待测对象的了解越深,对所要进行的任务内容就越清晰,就更有把握保证测试饿质量与进度。
分析类别:1.常用的或规定的业务流程;2.各业务流程分支的遍历;3.明确规定不可使用的业务流程;4.没有明确规定但应该是不可以执行的业务流程;5.其他异常或者不符合规定的操作。以此理清业务的常规逻辑,一项一项列出各种可能的测试场景,同事借助于软件的需求以及其他需求,来确定应该导致的结果,彼岸星沉了软件业务流的基本测试需求。
用例编写A.理清思路,避免遗漏,将测试系统的操作步骤按照一定的格式用文字描述出来。测试方法主要包括:1.等价类比法(有效等价类和无效等价类);2.边界值法;3.因果图(生成判定表,);4.错误推测法(基于经验和直觉推测出系统可能存在的错误,从而有着针对性的设计测试用例);5.其他如正交验证法、状态迁移图、流程分析法
B.测试用例的格式与要素:编号、标题、测试场景、测试步骤、预期结果(测试步骤不可有混合)
用例评审1.先讲解整个业务逻辑图,需要保证评审人员对于整个业务逻辑图都非常清楚,并且能够理解为什么这么做;
2.分析整个业务逻辑图是否有没有覆盖到的场景或者分支情况,采用头脑风暴;
3.分析业务逻辑的异常处理情况,是否每个业务逻辑都有对应的异常情况处理,也采用头脑风暴;
4.是否将逻辑的用例分类比较合理,让大家通过逻辑很容易就找到对应的用例;
测试执行
缺陷回归
封版提审(Android/IOS)
版本过审
灰度测试
正式更新
线上版本跟进