BUG库管理要点.docx
《BUG库管理要点.docx》由会员分享，可在线阅读，更多相关《BUG库管理要点.docx（14页珍藏版）》请在冰豆网上搜索。
BUG库管理要点
目录
1简介3
1.1目的3
1.2适用范围3
1.3参考文件&资料3
1.4术语表&缩写3
2Bug状态流程图4
3各角色对Bug的处理4
4Bug状态（Status）及描述5
5Bug严重级别（Severity）5
6Bug优先级（Priority）6
7缺陷来源（Source）7
8缺陷类型（Issuetype）7
9项目组各角色在Bug库中的权限9
10Bug描述要求9
11小结11
简介
1.1目的
为了规范Bug管理，明确项目经理、开发人员、测试人员各自的角色和职责特制定本文档。
1.2适用范围
本文档适用于TD中对于Bug的管理。
1.3参考文件&资料
TD中对于Bug生命周期的描述
1.4术语表&缩写
●缺陷与Bug：
系统开发过程中发现的问题统称为缺陷，包括测试及评审过程发现的所有问题。
Bug是“缺陷”的英文描述，本文档中不做Bug与缺陷的区分，但优先使用缺陷的概念。
●TD：
测试管理工具TestDirect的简写
2Bug状态流程图
3各角色对Bug的处理
项目经理（开发组长/经理）
每天对Bug进行分配，标注处理意见，给定优先级（发版前必须三方：
需求、开发、产品共同确定）。
问题分配时，应尽可能将咨询类、理解错误类等问题处理掉，而不是留给开发人员。
有可能是需求的问题，分配给需求人员。
定期对Bug库分析，找出常出错的模块，进行代码审查
开发人员
分析Bug，写出问题原因，修改Bug；实行Bug优先原则。
严重程度B-Major类或紧急程度3-High类以上（包含）bug5个或5个以上，停止新功能的开发。
测试人员
不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度；验证Bug是否已被解决。
测试主管/经理
审核测试人员提交的Bug；定期对Bug库进行分析，报告现状、预测趋势。
在测试总结报告中给出意见。
产品人员
可以对优先级和处理意见等进行审核，如果有意见，和项目组商量定夺
4Bug状态（Status）及描述
Bug状态（Status）：
指缺陷通过一个跟踪修复过程的进展情况。
包括New、Open、Reopen、Fixed、Closed、Rejected、Delay
ØNew：
为测试人员新bug提交所标志的状态。
ØOpen：
为任务分配人（开发组长/经理）对该问题准备进行修改并对该问题分配修改人员所标志的状态。
Bug解决中的状态，由任务分配人改变。
对没有进入此状态的Bug，程序员不用管。
ØReopen：
为测试人员对修改问题进行验证后没有通过所标志的状态。
由测试人员改变。
ØFixed：
为开发人员修改问题后所标志的状态，修改后还未测试。
由开发人员设置。
ØClosed：
为测试人员对修改问题进行验证后通过所标志的状态。
由测试人员改变。
ØRejected：
开发人员或项目经理认为不是Bug、描述不清、重复、不能复现、不采纳所提意见建议或虽然是个错误但还没到非改不可的地步故可忽略不计或者测试人员提错，从而拒绝的问题。
由项目经理来设置。
ØDelay：
开发人员或项目经理认为因开发进度等原因，当前无法解决，需留到以后版本解决的Bug。
由项目经理来设置。
Bug状态（Status）：
指缺陷通过一个跟踪修复过程的进展情况。
包括New、Open、Reopen、Fixed、Closed及Rejected等
New
为测试人员新问题提交所标志的状态。
Open
为任务分配人（开发组长/经理）对该问题准备进行修改并对该问题分配修改人员所标志的状态。
Bug解决中的状态，由任务分配人改变。
对没有进入此状态的Bug，程序员不用管。
Reopen
为测试人员对修改问题进行验证后没有通过所标志的状态；或者已经修改正确的问题，又重新出现错误。
由测试人员改变。
Fixed
为开发人员修改问题后所标志的状态，修改后还未测试。
Closed
为测试人员对修改问题进行验证后通过所标志的状态。
由测试人员改变。
Rejected
开发人员认为不是Bug、描述不清、重复、不能复现、不采纳所提意见建议、或虽然是个错误但还没到非改不可的地步故可忽略不计、或者测试人员提错，从而拒绝的问题。
由Bug分配人或者开发人员来设置。
5Bug严重级别（Severity）
ØA类——严重，包括：
1.由于程序所引起的死机，非法退出；
2.死循环；
3.导致数据库发生死锁；
4.操作系统崩溃、死机；
5严重的数值计算错误。
ØB类——高，包括：
1.主要功能未实现或不符；
2.数据通讯错误；
3.严重的数值计算错误；
4.数据流错误；
5.程序接口错误。
ØC类——中，包括：
1.次要功能未实现或错误；
2.轻微的数值计算错误；
3.打印内容、格式错误；
4.简单的输入限制未放在前台进行控制；
5.删除操作未给出提示。
ØD类——低，包括：
1.辅助说明描述不清楚；
2.界面错误；
3.显示格式不规范；
4.长时间操作未给用户进度提示；
5.提示窗口文字未采用行业术语；
6.可输入区域和只读区域没有明显的区分标志；
7.系统处理未优化。
ØE类——测试建议（非缺陷）
Bug严重级别（Severity，Bug级别）：
是指因缺陷引起的故障对软件产品的影响程度。
由测试人员指定。
A-Crash
错误导致了死机、产品失败（“崩溃”）、系统悬挂无法操作；
B-Major
功能未实现或导致一个特性不能运行并且不可能有替代方案；
C-Minor
错误导致了一个特性不能运行但可有一个替代方案；
D-Trivial
错误是表面化或微小的（提示信息不太准确友好、错别字、UI布局或罕见故障等），对功能几乎没有影响，产品及属性仍可使用；
E-NicetoHave（建议）
建设性的意见或建议。
6Bug优先级（Priority）
ØLow：
允许不修改。
ØMedium：
如果时间允许应该修改。
ØHigh：
必须修改，不一定马上修改，但需确定在某个特定里程碑结束前须修正。
ØVeryHigh：
必须修改，发版前必须修正。
ØUrgent：
阻止相关开发人员的进一步开发活动，立即进行修复工作；阻止与此密切相关功能的进一步测试。
Bug优先级（Priority）：
指缺陷必须被修复的紧急程度。
由Bug分配者（开发组长/经理）指定。
5-Urgent
阻止相关开发人员的进一步开发活动，立即进行修复工作；阻止与此密切相关功能的进一步测试
4-VeryHigh
必须修改，发版前必须修正
3-High
必须修改，不一定马上修改，但需确定在某个特定里程碑结束前须修正
2-Medium
如果时间允许应该修改
1-Low
允许不修改
功能模块（Subject）：
TD中需在TestPlan页中定义好Subject，才能在Defects页中使用。
问题描述、附件附图请参见后面第四部分‘Bug描述要求’的有关内容。
处理意见:
开发组长/经理（或具体Bug分配人员）在审核新Bug时、将Bug分配给开发人员解决前，需要给出该Bug的处理意见。
Fixable
可修改。
表示Bug可以被修复或更正
Duplicated
重复。
表示该Bug已经被其它测试人员找出来了（‘纯粹’重复），或者开发认为原因是相同的（但从测试来看，认为出现的地方有所不同、表现有所不同等）
Postponed
延后。
由于时间、进度、重要程度或者技术/需求等方面的原因，认为不能解决、须延期解决、或者本版不做留待到后续版本解决的Bug。
（注：
因‘Bug状态’字段中也有该值，根据各组各自使用情况，可以只保留一个，或者开发/测试各有侧重地使用这两个Postponed）
ByDesign
因设计结构问题无法修改。
测试人员认为是Bug，不符合逻辑，也不符合用户的要求，但开发人员则认为是按照设计做的、只能如此处理，否则修改代价太大
Can’tReproduce
不可复现。
不能重现（如因Bug出现的环境重现不了了），或以前出现的某个Bug自动消失了（可能是在处理其他Bug的时候把这个Bug一并修复掉了）。
（注：
因TD本身亦带有‘是否复现（Reproducible）’字段，根据各组各自使用情况，可以用它来标识，或者不用它而在‘处理意见’字段中用该值标识出）
DisagreeWithSuggestion
不同意所提意见或建议，不采纳
NotError
不是问题。
测试人员提错了
Won’tFix
这个Bug是一个错误，但还没有重要到非要更正不可的地步，可以忽略不计
说明：
1.定为Duplicated的Bug，必须注明和XXXbug重复
2.测试人员对标明为Duplicated的Bug复测，需要XXXBug修改后方可进行
3.定期回顾Can'tReproduce,Postponed
4.定期整理ByDesign
其它一些字段（及所定义的枚举值）的定义解释，供有需要用到的组参考：
测试状态（TestState）：
新提交的Bug定位标准。
由测试人员指定。
一般有8个（提交Bug时给出）
1－NewDefects（或写成Defect）
新Bug
2－SecondDefects（或写成SB）
复测时新出现的Bug
3－Faculative
偶发性
4－Reappear
原来修改过的问题又重新出现
5－ByRequirement
需求要求但没有做的功能
6－Suggestion
需求需要完善
7－DifferWithRequirement
与需求不一致
8－ByDesign
设计要求但没有做的功能
复测状态（ReTestState）：
复测时给出的状态，测试人员对于经过验证的Bug应按以下几种标准进行定位。
由测试人员指定。
一般有1－OK、2－PD、3－DV、4－NB、5－NR、6－AR。
OK
正确
PD
此问题悬而不决
DV
有错误可以暂时不考虑
NB
不是错误
NR
不能复现的错误
AR
需求不明确
问题定位：
Calculate_error
计算错误，指计算过程中、计算结果错误。
Data_error
数据错误，指非计算结果类的数据错误。
Graphics_error
图形错误，指绘图、图形显示、图形编辑时发生的错误。
Interface_error
界面错误
Requirement_error
需求错误
Function_error
功能错误
Unknown_error
未知错误
缺陷来源（Source）
Ø需求：
由于需求问题引起的缺陷。
Ø架构：
由于架构问题引起的缺陷。
Ø设计：
由于设计问题引起的缺陷。
Ø编码：
由于编码问题引起的缺陷。
Ø集成：
由于集成问题引起的缺陷。
Ø测试：
由于测试问题引起的缺陷。
缺陷类型（Issuetype）
Ø功能类
A.重复的功能；
B.多余的功能；
C.功能实现与设计要求不相符。
Ø易用性类
A.功能使用性、方便性、易用性不够。
Ø界面类
A.界面不美观；
B.控件排列、格式不统一；
C.焦点控制不合理或不全面。
Ø数据处理类
A.数据有效性检测不合理；
B.数据来源不正确；
C.数据处理过程不正确；
D.数据处理结果不正确。
Ø提示信息类
A.提示信息重复或出现时机不合理；
B.提示信息格式不符和要求；
C.提示框返回后焦点停留位置不合理。
Ø建议类
A.功能性建议；
B.操作建议；
C.检校建议；
D.说明建议。
Ø性能类
A.并发量；
B.数据量；
C.压缩率；
D.响应时间。
Ø兼容性类
A.系统软件不兼容（例如IE，操作系统等）；
B.系统硬件不兼容。
Ø偶发性类
A.偶然发生的，不可再现的bug。
Ø常识类
ØA.违背正常习俗习惯的，比如日期/节日等。
Ø特殊类
A.不符合OEM版本或DEMO版本特殊要求的。
类型（Type）：
是根据缺陷的自然属性划分的缺陷种类。
F-Function
影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。
并且设计文档需要正式的变更。
如逻辑，指针，循环，递归，功能等缺陷
A-Assignment
需要修改少量代码，如初始化或控制块。
如声明、重复命名，范围、限定等缺陷
I-Interface
与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。
C-Checking
提示的错误信息，不适当的数据验证等缺陷。
B-Build/package/merge
由于配置库、变更管理或版本控制引起的错误
D-Documentation
影响发布和维护，包括注释。
G-Algorithm
算法错误。
U-UserInterface
人机交互特性：
屏幕格式，确认用户输入，功能有效性，页面排版等方面的缺陷
P-Performance
不满足系统可测量的属性值，如：
执行时间，事务处理速率等。
N-Norms
不符合各种标准的要求，如编码标准、设计符号等。
7项目组各角色在Bug库中的权限
测试主管/经理：
全部权限。
测试人员：
可添加Bug，不可删除Bug；可添加注释评论（R&DComments）；不可修改他人所提Bug；可调整：
Bug概要（题目，Summary）、问题描述、附件附图（Attachments）、Bug状态（New置为Open或Fixed置为Reopen或Fixed置为Closed）、Bug级别、测试版本、测试产品，功能模块（subject）、测试状态、问题定位、复测状态、注释评论（R&DComments）、复测人、复测日期、修改人，责任人等。
开发人员：
可添加Bug；不能删除Bug；可添加注释评论；可调整：
注释评论、Bug状态（由Open置为Fixed）、问题定位。
开发人员/需求人员：
不能删除Bug、可添加注释评论（R&DComments）、可调整：
注释评论（R&DComments）、是否复现、Bug状态（不过无法直接标为closed）、问题描述、处理意见、待测版本、修改人、修改日期。
可添加Bug。
开发组长/经理/需求经理：
除了开发人员的权限，还可调整：
优先级别、责任人、Bug概要（题目，Summary）、附件附图（Attachments）
项目经理：
可添加Bug；不能删除Bug；可添加注释评论；调整Bug状态（New置为Open或Open置为Fixed或Open置为Delay或Open置为Rejected或Delay置为Open）、优先级别、问题定位、责任人。
可添加Bug、可添加注释评论（R&DComments）、可修改字段：
Bug概要（题目，Summary）、问题描述、附件附图（Attachments）、Bug状态（不过无法直接标为closed）、修改人、优先级别、问题定位、处理意见、注释评论（R&DComments）、是否复现、责任人、待测版本。
也可删除Bug，但要与测试组长/经理协商。
不属于项目组成员的其他人：
如研发中心经理组成员等，有必要查看TD库的话，可分配给其用户ID及查看的权限。
8Bug描述要求
Bug描述的要求为：
分类准确、叙述简洁、步骤清楚、有实例、易再现、复杂问题有据可查（截图或其它形式的附件）。
测试主管/经理把关，以开发人员的角度来审查Bug描述，看其是否描述清楚了Bug，不好描述的把工程文件或截图作为附件提交。
具体要求为：
∙原则：
每个bug都有相应的测试用例与之对应；
∙问题描述一般格式：
问题描述时，建议分几步描述：
模块或功能点=>测试步骤=>期望结果=>实际结果=>其它信息，可依实际情况调整；
∙单一：
尽量一个报告只针对一个软件缺陷，报告形式应方便阅读。
需要合并的bug也要指明每个的具体位置，以方便回归；
∙简洁：
每个步骤的描述应尽可能简洁明了。
只解释事实、演示和描述软件缺陷必要的细节，不要写无关信息；
∙再现：
问题必须在自己机器上能复现方可入库（个别严重问题复现不了也可入库，但需标明）；
∙复杂的问题应附截图补充说明或直接通知指定的修改人；考虑到网络数据传输效率，截图的文件格式建议用JPG或GIF，不建议用BMP；抓图可用TD自带的功能，亦可用HyperSnap之类的专用抓图工具；
∙报告中不允许使用抽象词句：
比如“有错误”之类；
∙简明扼要地对Bug进行概述，让人看标题就知道大概出现了什么问题（写清楚什么地方出现了什么问题）；
∙详细描述要对Bug描述清晰准确，能让开发人员根据描述重现bug（最好描述出现bug的原因，至少也要说明出现bug的规律）；
∙Bug中的Severity、Issuetype及Source项按照‘缺陷严重程度定义’、‘缺陷类型定义’及‘缺陷来源’中的相关说明来填写；
∙有关操作系统特征问题：
应在不同操作系统上进行操作，看是否能重现，并在Bug报告中标识。
∙Bug描述示例：
例一
河北98土建标准换算
操作：
1.输入9-24
2.F8
3.在F8输入10
期望结果：
进行换算
实际结果：
提示“输入的厚度应大于20”
例二（模块或功能点也可在‘功能模块’字段中规定，则Bug描述中就不必写了）
操作：
1.打开新建向导；
2.在“新建”中的“项目名称”中输入>80个字符；
3.点击“下一步”
期望结果：
“项目名称”应<=80个字符，输入大于80个字符，点击“下一步”应有错误提示
实际结果：
进入“比重调整”界面
例三（程序员知道期望结果的情况下）
云南98土建
操作：
1.输入13-170
2.F5
3.在F5中修改3240008的名称,处于编辑状态
4.到人材机,再回来
实际结果：
F5中变白板
注：
若3不处于编辑态切换则正常
例四（建议、需求类）
功能：
预算页，子目排序后可恢复原顺序
用途：
用户误操作后可复原
注：
所有项目采用TD进行Bug管理，该工具能从测试步骤自动生成Bug报告，因此对于Bug描述要求在测试方案用例设计（在TestPlan页中）阶段就可以进行控制。
附：
好的Bug报告应满足以下几方面的要求：
∙结构清晰；
∙复现故障再写报告；
∙隔离Bug：
更改条件复测；
∙归纳：
是否其他模块也有相同的Bug；
∙比较：
其他测试用例是否使用到此Bug；
∙总结：
报告的开头有Bug的总结；
∙精简：
不要有多余的步骤和语言；
∙无歧义：
语言明确；
∙中立：
无批评性语言；
∙讨论：
将要发出的报告送其他测试人员讨论。
9小结
∙通过专业的技术测试出精确的Bug；
∙通过准确的文档报告Bug；
∙通过良好的沟通使Bug尽快解决。
升级会员 