Bug跟踪流程
1. 目的
本文档主要是为了规范产品缺陷的跟踪解决、保证每个发现的缺陷都能有效跟踪，直到缺陷解决关闭。 2. 适用范围
本文档适用于公司所有产品的缺陷跟踪。 需要测试、软件开发人员、硬件开发人员协调执行。 3. 角色和职责 3.1 测试工程师
测试工程师负责问题提交、问题验证。
测试工程师不能把new状态、reopen状态的bug更改为fixed等其他状态。 测试工程师不能把没有修改的问题直接关闭。
测试工程师要及时验证问题，确保问题的及时关闭；如果验证不通过的问题要及时reopen，以便软件工程师能尽快了解情况，尽快解决问题。
3.2 开发工程师
软、硬件工程师负责修改问题，在问题修改完把问题状态修改为fixed状态。
如果软、硬件工程师认为是非问题的，要及时和测试工程师讨论决定，如果不能形成一致意见的，可以上报上一级主管讨论。 如果经过讨论后一致认为不是问题的可以置为 Invalid，或者确认是问题、讨论后决定不修改的问题可以置为wontfix, 然后由问题提交人关闭问题。 如果软、硬件工程师自己发现问题，原则上要求软、硬件工程师自己提交问题，把问题纳入跟踪。
软、硬件工程师不能关闭不是自己提交的问题。
3.3 缺陷库管理员
缺陷库管理员一般由测试主管兼任，负责缺陷库的日常管理、维护。在特殊情况下可以直接关闭部分问题（例如软件或硬件、测试一致同意关闭的问题）。
4. Bug跟踪流程
流程图：
过程说明：
A． New bug：测试人员、市场反馈的问题由测试人员填写bug。开发人员发现的问
题由开发人员填写。 Bug填写完成后提交给相应的软、硬件开发人员。Bug填写要求见“bug填写规范”。
B． Fix bug：开发人员修改自己负责的bug；修改完成并合入版本后把bug的状态
修改成fixed。
C． Close bug：问题验证通过后，由问题提交人关闭bug。
D． Reopen：问题验证没有通过，发现问题还存在，或者问题只修改了一部分，则
重新打开这个bug。 如果修改后造成了新的问题，请另外创建一个New bug。
5. Bug跟踪规范
5.1新建问题（New bug）填写规范
A． 正确选择产品名（Product）、模块名（Component）、产品版本号（Version）。 B． 正确选择问题严重程度（Severity）。 我们使用4个严重级别：
致命（Critical、A级）、严重（major、B级）、一般（Normal、C级）、建议（Enhancement、D级别）。
问题严重程度的定义见 “附录 Bug等级分类”。
C． 简述（Summary ）要求言简意赅、最好不要超过20个字。
D． 缺陷描述要求尽量详细。 内容要求包括问题出现所在菜单、测试操作过程、问
题出现条件、问题出现的规律、问题现象详细描述、问题出现概率等。 总之，觉得与问题相关的信息和设置都要尽量写清楚。 E． 以前有过的问题，尽量不要重复提交。
以前提交过，并且已经关闭或者处于fixed状态的问题，如果再次出现，请reopen，并再次说明问题现象等；如果以前提交过，还处于new或者reopen状态，请把这次发现的问题现象补充在原来提交问题的后面。
5.2处理缺陷（fix bug）填写规范
A． bug的状态必须在修改完成并合入版本后，才能把bug的状态置为fixed状态。 B．在处理说明栏描述清楚：修改后的功能流程、功能特征、功能实现，以及可能影响的模块等。解决版本中说明在哪个版本上修改。
建议格式（实例） 修改说明：
模块项目不需要这个功能，去掉这个菜单。 可能影响说明书，请核对。 必须填写项目。 说明问题是怎样修改的，修改后的功能流程、功能特征、功
能实现方式，可能影响的模块等。
验证版本：
请在4.0.6 以后的版本验证
必须填写项目，说明这个问题可以在那个版本开始验证。 问题形成原因：
可选项目。 可以写清楚问题出现原因，以便问题追溯，同时可以让相关人员
了解相关情况，评价问题修改思路是否正确等。
5.3问题关闭（close bug）填写规范
A．问题关闭时必须写清楚在那个版本验证通过. 建议格式（实例）：
在4.0.6 版本上验证通过。 或者 Verified on 4.0.6。
B．如果因为特殊原因要关闭问题，要求写清楚原因。
有些特殊情况，问题不是因为验证通过了而关闭的，这时要求写清楚问题关闭
的原因。
例如：此问题修改要导致软件更改体系结构、工作量特别大，软件开发、测试
商量决定问题关闭。
又例如：产品已经量产、问题不严重，客户可以接受；如果要修改，代码改动
比较大，风险比较大； 所以商量决定不修改，问题关闭。
5.4重新打开缺陷（Reopen）填写规范
A. 问题重新打开时要求填写清楚在哪个版本上（重新打开版本）验证不通过，如
果问题是有一部分没有验证通过，要求写清楚是哪部分没有验证通过。
建议格式（实例）：
例1：B130813-002版仍存在；
例2：B130813-002版上,界面刷新问题仍出现,几率降低
6. bug跟踪的监督
测试主管会定期抽查问题的跟踪情况，审核操作流程是否规范，缺陷的填写是否规范等。 测试工程师填写问题不规范，问题跟踪不规范的，将影响个人考评。
7. 关于Bug库
A．问题库地址。
公司管理跟踪问题库采用专业软件：bugzilla。
问题库位于公司内部网，地址：http://192.168.10.6/bugzilla/
B．问题库维护。
Bug库由测试主管定时备份。
Bug库的帐号、产品、版本等信息由测试人员共同维护。
8. 附录：Bug等级分类
Bug跟踪流程
1. 目的
本文档主要是为了规范产品缺陷的跟踪解决、保证每个发现的缺陷都能有效跟踪，直到缺陷解决关闭。 2. 适用范围
本文档适用于公司所有产品的缺陷跟踪。 需要测试、软件开发人员、硬件开发人员协调执行。 3. 角色和职责 3.1 测试工程师
测试工程师负责问题提交、问题验证。
测试工程师不能把new状态、reopen状态的bug更改为fixed等其他状态。 测试工程师不能把没有修改的问题直接关闭。
测试工程师要及时验证问题，确保问题的及时关闭；如果验证不通过的问题要及时reopen，以便软件工程师能尽快了解情况，尽快解决问题。
3.2 开发工程师
软、硬件工程师负责修改问题，在问题修改完把问题状态修改为fixed状态。
如果软、硬件工程师认为是非问题的，要及时和测试工程师讨论决定，如果不能形成一致意见的，可以上报上一级主管讨论。 如果经过讨论后一致认为不是问题的可以置为 Invalid，或者确认是问题、讨论后决定不修改的问题可以置为wontfix, 然后由问题提交人关闭问题。 如果软、硬件工程师自己发现问题，原则上要求软、硬件工程师自己提交问题，把问题纳入跟踪。
软、硬件工程师不能关闭不是自己提交的问题。
3.3 缺陷库管理员
缺陷库管理员一般由测试主管兼任，负责缺陷库的日常管理、维护。在特殊情况下可以直接关闭部分问题（例如软件或硬件、测试一致同意关闭的问题）。
4. Bug跟踪流程
流程图：
过程说明：
A． New bug：测试人员、市场反馈的问题由测试人员填写bug。开发人员发现的问
题由开发人员填写。 Bug填写完成后提交给相应的软、硬件开发人员。Bug填写要求见“bug填写规范”。
B． Fix bug：开发人员修改自己负责的bug；修改完成并合入版本后把bug的状态
修改成fixed。
C． Close bug：问题验证通过后，由问题提交人关闭bug。
D． Reopen：问题验证没有通过，发现问题还存在，或者问题只修改了一部分，则
重新打开这个bug。 如果修改后造成了新的问题，请另外创建一个New bug。
5. Bug跟踪规范
5.1新建问题（New bug）填写规范
A． 正确选择产品名（Product）、模块名（Component）、产品版本号（Version）。 B． 正确选择问题严重程度（Severity）。 我们使用4个严重级别：
致命（Critical、A级）、严重（major、B级）、一般（Normal、C级）、建议（Enhancement、D级别）。
问题严重程度的定义见 “附录 Bug等级分类”。
C． 简述（Summary ）要求言简意赅、最好不要超过20个字。
D． 缺陷描述要求尽量详细。 内容要求包括问题出现所在菜单、测试操作过程、问
题出现条件、问题出现的规律、问题现象详细描述、问题出现概率等。 总之，觉得与问题相关的信息和设置都要尽量写清楚。 E． 以前有过的问题，尽量不要重复提交。
以前提交过，并且已经关闭或者处于fixed状态的问题，如果再次出现，请reopen，并再次说明问题现象等；如果以前提交过，还处于new或者reopen状态，请把这次发现的问题现象补充在原来提交问题的后面。
5.2处理缺陷（fix bug）填写规范
A． bug的状态必须在修改完成并合入版本后，才能把bug的状态置为fixed状态。 B．在处理说明栏描述清楚：修改后的功能流程、功能特征、功能实现，以及可能影响的模块等。解决版本中说明在哪个版本上修改。
建议格式（实例） 修改说明：
模块项目不需要这个功能，去掉这个菜单。 可能影响说明书，请核对。 必须填写项目。 说明问题是怎样修改的，修改后的功能流程、功能特征、功
能实现方式，可能影响的模块等。
验证版本：
请在4.0.6 以后的版本验证
必须填写项目，说明这个问题可以在那个版本开始验证。 问题形成原因：
可选项目。 可以写清楚问题出现原因，以便问题追溯，同时可以让相关人员
了解相关情况，评价问题修改思路是否正确等。
5.3问题关闭（close bug）填写规范
A．问题关闭时必须写清楚在那个版本验证通过. 建议格式（实例）：
在4.0.6 版本上验证通过。 或者 Verified on 4.0.6。
B．如果因为特殊原因要关闭问题，要求写清楚原因。
有些特殊情况，问题不是因为验证通过了而关闭的，这时要求写清楚问题关闭
的原因。
例如：此问题修改要导致软件更改体系结构、工作量特别大，软件开发、测试
商量决定问题关闭。
又例如：产品已经量产、问题不严重，客户可以接受；如果要修改，代码改动
比较大，风险比较大； 所以商量决定不修改，问题关闭。
5.4重新打开缺陷（Reopen）填写规范
A. 问题重新打开时要求填写清楚在哪个版本上（重新打开版本）验证不通过，如
果问题是有一部分没有验证通过，要求写清楚是哪部分没有验证通过。
建议格式（实例）：
例1：B130813-002版仍存在；
例2：B130813-002版上,界面刷新问题仍出现,几率降低
6. bug跟踪的监督
测试主管会定期抽查问题的跟踪情况，审核操作流程是否规范，缺陷的填写是否规范等。 测试工程师填写问题不规范，问题跟踪不规范的，将影响个人考评。
7. 关于Bug库
A．问题库地址。
公司管理跟踪问题库采用专业软件：bugzilla。
问题库位于公司内部网，地址：http://192.168.10.6/bugzilla/
B．问题库维护。
Bug库由测试主管定时备份。
Bug库的帐号、产品、版本等信息由测试人员共同维护。
8. 附录：Bug等级分类