软件测试找游戏bug,游戏测试用例及游戏测试bug详解

测试用例设计步骤

一、需求文档分析

1、文档阅读

切忌不阅读需求文档，上来直接写用例，至少读3遍文档。

细致理解功能设计意图和设计思路。

避免粗略理解带来的用例遗漏。

一些重要数据可能隐藏在不起眼的语句中。

加深对功能的理解，否则随着时间推移，可能会遗忘很多内容。

2、功能细节沟通探讨

不明白的地方需要及时确认，切忌脑补想当然。

尽早确认细节，最好在开始写之前就确认完毕。

关注需求变更，需求变更后，一定要跟程序和策划确认。

3、逻辑梳理

文档不一定是按照流程顺序写的，而且经常存在功能交叉的地方。

梳理出框架后，逐步细化。

4、功能拓展思考

· 设计缺陷思考

· 测试难点思考(领取奖励后刷新)

· 关联度思考(领取道具存储位置、道具重复问题)

· 特殊情况思考(领取道具过程中断网断电情况)

5、兼容相关思考

· 版本兼容(一种服务器两种版本中的交互)

· 功能兼容(老功能基础上增加新的内容)

· 操作系统版本兼容

· 分辨率兼容

二、功能模块划分

1、功能模块划分原则

· 高内聚、低耦合

· 重整体、清局部

2、模块划分方法

功能流程法：将功能的基本流程画出来，根据流程的每个大的环节进行模块划分，然后再细化和查漏补缺。

层次划分法：按照逻辑层次逐层细化出模块的过程，比较适用于UI划分，大的系统模块划分等。

类型划分法：按照功能包含内容的不同类型进行划分。

注：

· 不同的划分法适用不同的场景，要具体问题具体分析 有时候一个功能需要结合多种方法进行划分。

· 划分方法不重要，划分原则更重要一些。

· 划分完毕后，要结合需求文档重新梳理，确保模块清晰、覆盖完整。

三、测试用例编写

1、格式

清晰的格式为何如此重要：

让用例的脉络更清晰明了 。

方便需求变化后的更新维护 。

方便执行人员快速入手。

首页内容

· 用例名称

· 用例对应的游戏版本

· 编写人、修改日期、修改备注

· 需求文档的链接或地址

正文页内容

· 功能逻辑图(如果有)

· 用例id

· 模块功能名称

· 测试先决条件

· 输入信息

· 输出结果

· 备注信息

注：

尽量保证逻辑清晰。

尽量保证一个输入只对应一个输出。

保证每次更新用例后都有明确的记录标注。

尽量保证一个用例内格式统一。

2、常用的测试用例编写方法

(1)等价类

等价类：指的是一个输入集合内，任何输入数据对于输出的验证来讲都是等效的，此刻我们就可以选取少量代表性的测试数据来代表整体数据。

有效等价类：是对输出来讲有意义的输入集合，可以验证程序的正常功能和流程。

无效等价类：是对输出无意义的输入组合，用于验证非正常流程输入对输出的影响。

(2)边界值

边界值：对输入或输出的边界值进行分析的一种方法。

边界值的确定：一般选取正好等于，刚刚小于和刚刚大于3种情况作为测试数据。

通常适用的范畴：数值测试、字符串测试、数据类型测试等。

(3)因果图&判定表

因果图：简单的来说就是输入与输出之间因果关系的一种关系图。

判定表：可以通过因果图来生成的一种结果判定表。

因果图常常与判定表一起使用，通过因果图生成判定表，通过判定表来书写测试用例。

3、测试用例编写注意事项

输入条件要单一明确，尽量不用容易引起误解的词，比如：可能、大概等。

输出要判断且明确，最好不用“显示正确”这种词汇。

测试步骤要可执行。

保持尽量稿的覆盖度。

能抽象的尽量抽象出来，避免无意义的冗余。

四、测试用例整理与维护

需求变化后需要及时更新老的测试用例，并写清修改情况的备注(修改内容，产品和开发负责人。

测试用例应该尽量避免冗余，如果遇到重复的用例，需要根据实际情况进行修改。

注意测试用例的备份，写完后最好自己本地也备份一份，避免线上被人误删。

五、BUG的界定标准

1、与需求设计不符

2、违背常识

六、BUG的生命周期

· 发现bug

· 提交给开发

· 开发修复

· 测试验证

· 通过后关闭/不通过继续指派给开发

· 上线前回归

七、BUG的等级划分

P0：致命错误，需要立即修复，如宕机、重启性报错等。

P1：严重错误，需要紧急修复，如功能流程错误、数值错误等。

P2：一般错误，允许一段时间内修复，如功能的简单错误、界面错误等。

P3：无关紧要的错误，允许延期修复，如文字错误、某个像素点缺失等等。

八、BUG的提报标准

标题：【模块名称】+简短描述。

测试环境：表明测试用的版本，系统，服务器，账号等。

描述：bug的详细描述。

重新步骤：重现bug的详细流程步骤及复现概率。

期望结果：希望bug修复后的结果 。

备注：log，截图等。

九、BUG的提报标注——一个bug例子

标题：[士兵]打开士兵技能升级页面报错。

测试环境：内网测试服，v1.1.0版本，IOS系统，账号：zjf01。

详细描述：当我们在游戏中打开士兵升级页面时，系统提示报错信息。

重现步骤：(1)进入游戏；(2)打开士兵技能升级页面；(3)系统报错。

期望结果：能够正常升级士兵技能，打开升级页面不报错。

备注：报错信息见下面的截图

十、BUG的验证标准

严格按照复现步骤验证。

去除测试环境的影响。

验证标注：需要注明验证的版本、服务器等。

十一、BUG的验证标准

拓展：是否对其它功能有影响，做简单回归。

注意点：验证不能只看前端展现，更应关注后端数据。

十二、BUG的跟踪与推动

每个人都有责任跟踪自己的bug的修复状态。

及时与开发沟通，了解修复状态并提供修复过程中的支持。

久不修复的bug需要与开发和上级确认如何处理。

Bug修复后，需要及时验证。

十三、BUG的数据分析

本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理