我的测试入门——缺陷管理

软件测试的目的是验证程序的正确性，一个新开发出来的功能几乎是不可能没有 bug 的，而有bug 就需要记录并对bug 进行追踪。

Bug管理工具有很多，如JIRA，Bugzilla，禅道等。各个公司对于工具的使用，缺陷的规范也不尽相同，下面是我对于缺陷规范的认识。

标题

缺陷的标题应该简洁明了，让人一眼就可以定位到缺陷位置，所以在标题里面首先要写明测试环境，是在 web 端还是 app 端，是 chrome 浏览器还是火狐，是 Android 还是 iOS。其次要写出bug所在的功能模块，是登录功能，还是搜索功能。再然后需要尽量简短的概括缺陷场景，比如xx地方查询条件不生效；点击xx地方提示系统异常。

内容描述

这个模块即是对缺陷的详细描述，将标题里面的概括细化，需要列出每一步的详细操作步骤（开发人员对于应用的操作不如测试人员熟悉，没有详细操作步骤他们可能无法复现问题）。例如上面的“xx地方查询条件不生效”，具体操作可以记录如下：

1）登录xx网站，进入xx模块xx页面

2）在xx查询条件中输入xxx，点击查询

接下来便是操作的预期和实际结果，例如：

预期结果：查询到xxxxx

实际结果：提示系统异常

必要时可以附上截图、日志，以及对应的账号信息

重要程度

重要程序即是bug解决的优先级，这个优先级整个项目所有人员应该事先统一，例如影响主流程的bug，优先级最高，可定为1级，普通的bug，可定为2级，无关紧要的如页面展示类的bug，可定为3级。这样开发可以按照优先级来解决bug，避免测试进度落后。

版本

在迭代开发的过程中，一个产品会出现多个版本，V1.0，V2.0等，在提交bug时，需要记录缺陷产生的版本号或时间，便于日后统计与回顾。

缺陷的生命周期

以JIRA为例，常见的缺陷状态有以下几种。

new：新创建的缺陷，初始状态为new

Open：由测试人员操作打开

Fixed：已修复，由开发人员操作

Closed：已关闭（回归通过），由测试人员操作

Reopened：重新打开（回归不通过），由测试人员操作

Apply for Reject：申请拒绝（开发人员认为不是缺陷），由开发人员操作

Rejected：已拒绝（测试人员检查后发现不是缺陷），由测试人员操作

其中new是阶段的开始状态，Closed或Rejected是缺陷的最终状态。各状态间的转换关系如下。