Bug生命周期及其管理.docx

Bug生命周期及其管理.docx

《Bug生命周期及其管理.docx》由会员分享，可在线阅读，更多相关《Bug生命周期及其管理.docx（11页珍藏版）》请在冰点文库上搜索。

Bug生命周期及其管理

Bug生命周期

对Bug的处理

开发组长/经理

每天对Bug进行分配，标注处理意见，给定优先级（发版前必须三方：

需求、开发、产品共同确定）。

问题分配时，应尽可能将咨询类、理解错误类等问题处理掉，而不是留给开发人员。

有可能是需求的问题，分配给需求人员。

定期对Bug库分析，找出常出错的模块，进行代码审查

开发人员

分析Bug，写出问题原因，修改Bug；实行Bug优先原则，严重程度B-Major类或紧急程度3-High类以上（包含）bug5个或5个以上，停止新功能的开发。

需求人员

解释需求，给出处理意见，将Bug库中的建议整理成需求文档。

评审确定后列入开发计划

测试人员

不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度。

验证Bug是否已被解决

测试组长/经理

审核测试人员提交的Bug。

定期对Bug库进行分析，描绘出曲线图等，报告现状、预测趋势。

在测试总结报告中给出意见

产品人员

可以对优先级和处理意见等进行审核，如果有意见，和项目组商量定夺

Bug状态（Status）：

指缺陷通过一个跟踪修复过程的进展情况。

包括New、Open、Reopen、Fixed、Closed及Rejected等

New

为测试人员新问题提交所标志的状态。

Open

为任务分配人（开发组长/经理）对该问题准备进行修改并对该问题分配修改人员所标志的状态。

Bug解决中的状态，由任务分配人改变。

对没有进入此状态的Bug，程序员不用管。

Reopen

为测试人员对修改问题进行验证后没有通过所标志的状态；或者已经修改正确的问题，又重新出现错误。

由测试人员改变。

Fixed

为开发人员修改问题后所标志的状态，修改后还未测试。

Closed

为测试人员对修改问题进行验证后通过所标志的状态。

由测试人员改变。

Rejected

开发人员认为不是Bug、描述不清、重复、不能复现、不采纳所提意见建议、或虽然是个错误但还没到非改不可的地步故可忽略不计、或者测试人员提错，从而拒绝的问题。

由Bug分配人或者开发人员来设置。

Bug严重级别（Severity，Bug级别）：

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

由测试人员指定。

A-Crash

错误导致了死机、产品失败（“崩溃”）、系统悬挂无法操作；

B-Major

功能未实现或导致一个特性不能运行并且不可能有替代方案；

C-Minor

错误导致了一个特性不能运行但可有一个替代方案；

D-Trivial

错误是表面化或微小的（提示信息不太准确友好、错别字、UI布局或罕见故障等），对功能几乎没有影响，产品及属性仍可使用；

E-NicetoHave（建议）

建设性的意见或建议。

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）：

指引起缺陷的起因。

Requirement

由于需求的问题引起的缺陷

Architecture

由于构架的问题引起的缺陷

Design

由于设计的问题引起的缺陷

Code

由于编码的问题引起的缺陷

Test

由于测试的问题引起的缺陷

Integration

由于集成的问题引起的缺陷

类型（Type）：

是根据缺陷的自然属性划分的缺陷种类。

F-Function

影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。

并且设计文档需要正式的变更。

如逻辑，指针，循环，递归，功能等缺陷

A-Assignment 

需要修改少量代码，如初始化或控制块。

如声明、重复命名，范围、限定等缺陷

I-Interface 

与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。

C-Checking

提示的错误信息，不适当的数据验证等缺陷。

B-Build/package/merge

由于配置库、变更管理或版本控制引起的错误

D-Documentation 

影响发布和维护，包括注释。

G-Algorithm 

算法错误。

U-UserInterface

人机交互特性：

屏幕格式，确认用户输入，功能有效性，页面排版等方面的缺陷

P-Performance

不满足系统可测量的属性值，如：

执行时间，事务处理速率等。

N-Norms

不符合各种标准的要求，如编码标准、设计符号等。

（以上依各组实际情况可以作适当调整）

项目组各角色在Bug库中的权限

管理员：

全部权限

测试组长/经理：

全部权限

测试人员：

可添加Bug、不能删除Bug、可添加注释评论（R&DComments）、不可修改他人所提Bug、可调整：

Bug概要（题目，Summary）、问题描述、附件附图（Attachments）、Bug状态、Bug级别、测试版本、测试产品、功能模块、测试状态、问题定位、复测状态、注释评论（R&DComments）、复测人、复测日期、修改人

开发人员/需求人员：

不能删除Bug、可添加注释评论（R&DComments）、可调整：

注释评论（R&DComments）、是否复现、Bug状态（不过无法直接标为closed）、问题描述、处理意见、待测版本、修改人、修改日期。

可添加Bug。

开发组长/经理/需求经理：

除了开发人员的权限，还可调整：

优先级别、责任人、Bug概要（题目，Summary）、附件附图（Attachments）

项目经理：

可添加Bug、可添加注释评论（R&DComments）、可修改字段：

Bug概要（题目，Summary）、问题描述、附件附图（Attachments）、Bug状态（不过无法直接标为closed）、修改人、优先级别、问题定位、处理意见、注释评论（R&DComments）、是否复现、责任人、待测版本。

也可删除Bug，但要与测试组长/经理协商。

不属于项目组成员的其他人如研发中心经理组成员等，有必要查看TD库的话，可分配给其帐号及查看的权限。

Bug描述要求

Bug描述的要求为分类准确、叙述简洁、步骤清楚、有实例、易再现、复杂问题有据可查（截图或其它形式的附件）。

测试组长/经理把关，以开发人员的角度来审查Bug描述，看其是否描述清楚了Bug，不好描述的把工程文件或截图作为附件提交。

具体要求为：

∙问题描述一般格式：

问题描述时，建议分几步描述：

模块或功能点=>测试步骤=>期望结果=>实际结果=>其它信息，可依实际情况调整；

∙单一：

尽量一个报告只针对一个软件缺陷，报告形式应方便阅读。

在主报告之后应注明不同的条件；

∙简洁：

每个步骤的描述应尽可能简洁明了。

只解释事实、演示和描述软件缺陷必要的细节，不要写无关信息；

∙再现：

问题必须在自己机器上能复现方可入库（个别严重问题复现不了也可入库，但需标明）；

∙复杂的问题应附截图补充说明或直接通知指定的修改人；考虑到网络数据传输效率，截图的文件格式建议用JPG或GIF，不建议用BMP；抓图可用TestDirector自带的功能，亦可用HyperSnap之类的专用抓图工具。

∙报告中不允许使用抽象词句：

比如“有错误”之类；

∙有关操作系统特征问题：

应在不同操作系统上进行操作，看是否能重现，并在Bug报告中标识；

∙Bug描述示例：

例一

河北98土建标准换算

操作：

1.输入9-24

2.F8

3.在F8输入10

期望结果：

进行换算

实际结果：

提示“输入的厚度应大于20”

例二（模块或功能点也可在‘功能模块’字段中规定，则Bug描述中就不必写了）

操作：

1.打开新建向导；

2.在“新建”中的“项目名称”中输入>80个字符；

3.点击“下一步”

例三（程序员知道期望结果的情况下）

云南98土建

操作：

1.输入13-170

2.F5

3.在F5中修改3240008的名称,处于编辑状态

4.到人材机,再回来

实际结果：

F5中变白板

例四（建议、需求类）

功能：

预算页，子目排序后可恢复原顺序

用途：

用户误操作后可复原

期望结果：

“项目名称”应<=80个字符，输入大于80个字符，点击“下一步”应有错误提示

实际结果：

进入“比重调整”界面

注：

若3不处于编辑态切换则正常

注：

所有项目采用TestDirector进行Bug管理，该工具能从测试步骤自动生成Bug报告，因此对于Bug描述要求在测试方案用例设计（在TestPlan页中）阶段就可以进行控制。

附：

好的Bug报告应满足以下几方面的要求：

∙结构清晰

∙复现故障再写报告

∙隔离Bug：

更改条件复测

∙归纳：

是否其他模块也有相同的Bug

∙比较：

其他测试用例是否使用到此Bug

∙总结：

报告的开头有Bug的总结

∙精简：

不要有多余的步骤和语言

∙无歧义：

语言明确

∙中立：

无批评性语言

∙讨论：

将要发出的报告送其他测试人员讨论

小结

∙通过专业的技术测试出精确的Bug；

∙通过准确的文档报告Bug；

∙通过良好的沟通使Bug尽快解决。

（注：

可编辑下载，若有不当之处，请指正，谢谢!

）