原文发表于2009-02-01 12:04:11
在前面的四篇文章泛泛而谈bug相关的一些问题，只能迟到这篇文章中开始介绍bug本身相关比较实用的知识。先从bug报告开始，Bug报告的洋名似乎比中文名来的顺耳——Bug Report。
一般意义上的bug Report即是将所发现的bug整理归纳起来，随着缺陷管理工具的盛行，这种报告类型的报告已经渐渐失去了意义，但是笔者还是要从这种类型的bug report谈起——一开始，我们先来了解一下单个bug的组成要素。先来看一个bug的简单示例：
|
Bug ID |
Bug 783 |
|
标题 |
编辑用户信息功能 “用户职位”字段未保存 |
|
状态 |
Active |
|
原因 |
New |
|
严重级别 |
2 |
|
描述 |
[Test Cases] AAA_UserProfile_0003 [Precondition] <在此填写预置条件> [Descrīption] <在此填写详细描述信息> [Expected] <在此填写期望结果> [Actual] <在此填写实际结果> |
上表中并不是一个完整的bug的实例，但是基本上已经囊括了bug的基本要素。对于这些基本要素，接下来作简要说明：
1. Bug ID是bug的唯一标识符，类似于公民身份证号码，每个bug有且仅有唯一的一个ID序号。如： 示例中的“Bug 783”
2. 标题 是对bug的一个简要概括。如： 示例中 编辑用户信息功能 “用户职位”字段未保存
3. 状态 是指bug当前所处的状态。如：示例中 Active是指bug现在是活动的，即没有尚未被开发人员修复。bug的状态一般分为三种，即Active, Resolved, Closed，分别对应于活动的（开发人员未解决掉的），被解决的(开发人员声明已解决但尚未通过回归测试验证的)，关闭的(已经被开发人员修复并通过回归测试的)。关于bug的三种状态的转换将在后续文章中专门讨论。
4. 原因 是指将bug调整到某个状态的原因。如：示例中的New是指测试者新发现了一个bug，所以把状态调整为Active。Bug状态调整可能有多种原因，即使是对于同一个状态在不同的情况下也会有不同的原因。关于这部分的讨论也将在后续文章中提出。
5. 指派给 是指将bug指派给对应的负责人进行处理。如：实例中的 Q Chen是指项目相关人员处理bug之后将bug提供给下一步处理人员Q Chen。对于指派给的具体人选，不同的bug状态下有不同的要求：测试人员测试发现的bug指派给开发相关模块的开发人员或者开发组负责bug处理的人员，开发组处理后的bug会指派给发现bug的测试人员。
6. 优先级 目前在测试组实际工作中使用时同时包含有严重级别的意义，严重级别是指bug对应用程序或者操作系统的影响程度，严重界别越高的bug等待解决的优先级越高。如： 实例中的 1是指优先级(严重级别)最高的一类bug，这类bug需要尽快解决掉。关于Bug的优先级划分将在本系列文章中的后续篇章专门讨论。
7. 描述 部分是bug提交中最重要的部分，是对bug信息的一个详细的描述。如： 示例中 [Test Cases] APS_SheetJop_0003 ……我们可以发现“描述”被划分为几个子模块，以详细且清晰地描述bug相关的信息，以便bug相关人员处理bug和其他人员了解bug的各个阶段的各类信息。在下一篇文章中我们将详细讨论“描述”中的内容。
以上为个人观点，如有意见建议或者交流需要，请联系unique.wuchaodong@hotmail.com
