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 关闭。


↙↙↙阅读原文可查看相关链接,并与作者交流