1 文档目的
本文档目的在于编写 bug 的定义，如何判断 bug，bug 类型的划分，bug 的状态等进行定义，bug 被报告后，如何跟踪 bug，如何关闭 bug，如何针对每一更新包做该测试包的测试总结（包括邮件和 bug 分析报告）进行规则约定。以便进一步知道我们的软件测试工作。

2 bug 定义与内容要求
一个好的缺陷跟踪系统包括了错误的必要信息，如果做得不好，会造成迷惑，并误导读者。

好的缺陷描述主要包括以下 6 个基本部分：bug 标题、错误类型、严重程度、优先级、解决方案和附件。

2.1 bug 标题
使用一两句话来描述错误，告诉项目经理、产品经理、开发人员以及其他读者为什么应该关心该问题。好的标题应该着重于出现的 bug 现象。但是过于简洁易引起误导，使得原本重要的问题被忽视。因此必须应该采用简洁、切中要害的概要，这样才能引起读者的重视。

2.1.1 内容定义
出错描述应简单概要，用简洁、切中要害的语言去描述，描述的语言中应尽量用 “不应 XXX”，“应该要 XXX，而不是 XXX” 等描述；

2.1.2 实例
列表标签名称显示不正确，名称 “投资列表” 应改为 “投资记录”，与该模块的名称要一致。

2.2 严重程度
指因缺陷引起的故障对软件产品的影响程度。

2.2.1 内容定义

2.3 优先级
指缺陷必须被修复的紧急程度。“优先级” 的衡量抓住了在严重性中没有考虑的重要程度因素。

2.3.1 内容定义

2.4 错误类型
根据缺陷的自然属性来划分。

2.4.1 内容定义



2.6 附件
附图以帮助读者加深对 bug 的理解，提高工作效率，减少不必要的沟通工作 。

3 跟踪 bug
缺陷跟踪流程图：

新增 bug：QC（测试人员）发现 bug 后新增，并将 bug 指向对应的开发人员；
接受\处理 bug：测试人员提交 bug 后，由开发组长或开发工程师对 bug 进行审核，审核 bug 的优先度，bug 修正，修改意见等；
已解决：开发人员修改问题之后，将 bug 回复给对应的测试人员。测试人员进行验证后，如果问题还没解决，则将 bug 重新回复给开发人员，bug 的状态不被关闭；bug 的记录不能被删除；
已验证：测试工程师回归 bug，通过则关闭处理，反之则重新打开；
已关闭：测试人员验证问题通过后，问题得到解决，则该 bug 关闭。