BUG详解

发现BUG仅仅是测试工作的开始

BUG的界定标准：与需求设计不符；违背常识

BUG的生命周期：发现bug；提交给开发；开发修复；测试验证（不通过继续指派给开发）；通过后关闭；上线前回归

BUG的等级划分：

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

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

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

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

bug的报错标准

标题：[模块名称]+简短描述

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

描述：BUG的详细描述

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

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

备注：log，截图等

bug举例：

标题：〔士兵〕打开士兵技能升级页面报错

测试环境:内网测试服，V1.1.0版本，iOS系统，账号：ykl02

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

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

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

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

BUG的验证标准：

严格按照复现步骤验证；

去除测试环境的影响，尽量使用提交BUG时的注明的环境；

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

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

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

（比如购买道具，花了100，但是只扣了50；如果修复之后，前端确实显示扣了100，但是数据库中只扣了50，这就是“BUG的伪修复”）

BUG的跟踪与推动：

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

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

久不修复的bug需要与开发和上级（需求人员）确认如何处理；

bug修复后，需要及时验证

BUG的数据分析：

根据bug优先级看各个优先级的bug数量；

根据项目人员看各个开发人员的bug数量；

根据功能模块看各个模块的bug数量

测试用例编写

格式：清晰的格式很重要

首页内容：（用例关键信息）用例名称；游戏版本；编写人，编写日期，备注；修改人，修改日期、修改备注；需求文档的链接或地址

正文页内容：功能逻辑图（若有，便于理解）、用例id、模块名称、测试先决条件（入口）、输入信息、输出结果、备注信息

注意事项：用例有清晰的逻辑、一个输入只对应一个输出、保证每次更新用例后都有明确的记录标注、保证格式一致

常用编写方法

等价类：一个输入集合内，任何输入数据对于输出的验证来讲都是等效的，所以选取少量代表性测试数据代表整个数据

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

无效等价类：是对输出来讲无意义的输入集合，验证特殊情况

边界值：对于输入或输出的边界值进行分析

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

适用：数值测试、字符串测试、数据类型测试等

因果图：输入与输出之间因果关系的一种关系图

适用于：输入条件较为复杂，存在多种可能组合（笛卡尔积）的情况

方法：识别出因（所有输入）、中间节点、果（所有输出），并且根据关系连接起来

判定表：可以通过因果图来生成的一种结果判定表格（因、中间节点、果，01表示是否存在）

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

注意事项

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

输出要可判断且明确，不用显示正确这种词汇

测试步骤要可执行

保证尽量高的覆盖度

能抽象合并的尽量抽象合并，避免无意义的冗余

测试用例整理与维护

需求变化后及时更新并备注修改情况（修改内容、产品和开发负责人）

遇到冗余的测试用例，根据实际情况及时修改

注意测试用例的备份，在公司服务器上写完后本地也备份一份，避免被人线上误删除

因果图与判定表 举例4

因果图与判定表 举例3

因果图与判定表 举例2

因果图与判定表 举例

边界值 举例

等价类举例

手游测试用例正文页内容 样例

测试用例首页内容样例