Bug状态流程图Word文件下载.docx
《Bug状态流程图Word文件下载.docx》由会员分享,可在线阅读,更多相关《Bug状态流程图Word文件下载.docx(11页珍藏版)》请在冰豆网上搜索。
对没有进入此状态的Bug,程序员不用管。
Reopen
为测试人员对修改问题进行验证后没有通过所标志的状态;
或者已经修改正确的问题,又重新岀现错误。
由测试人员改变。
Fixed
为开发人员修改问题后所标志的状态,修改后还未测试。
Closed
为测试人员对修改问题进行验证后通过所标志的状态。
由测试人员改变。
Rejected
开发人员认为不是Bug、描述不清、重复、不能复现、不采纳所提意见建议、或虽然是个错误但还没到非改不可的地步故可忽略不计、或者测试人员提错,从而拒绝的问题。
由Bug分配人或者开发人员来设
Bug严重级别(Severity,Bug级别):
是指因缺陷引起的故障对软件产品的影响程度。
由测试人员指
A-Crash
错误导致了死机、产品失败(“崩溃”)、系统悬挂无法操作;
B-Major
功能未实现或导致一彳、特性不能运行并且不口J能有替代方案;
C-Minor
错误导致了一个特性不能运行但可有一个替代方案;
D-Trivial
错误是表面化或微小的(提示信息不太准确友好、错别字、UI布局
或罕见故障等),对功能几乎没有影响,产品及属性仍可使用;
E-NicetoHave(建议)
建设性的意见或建议。
Bug分配者(开发组长/经理)指定
Bug优先级(Priority):
指缺陷必须被修复的紧急程度。
由
5-Urgent
阻止相矢开发人员的进一步开发活动,立即进行修复工作;
阻止与此密切相矢功能的进一步测试
4-VeryHigh
必须修改,发版前必须修正
3-High
必须修改,不一定马上修改,但需确定在某个特定里程碑结束刖须修正
2-Medium
如果时间允许应该修改
1-Low
允许不修改
功能模块(Subject):
TD中需在TestPlan页中定义好Subject,才能在Defects页中使用
问题描述、附件附图请参见后面第四部分’Bug描述要求’的有矢内容。
处理意见:
开发组长/经理(或具体Bug分配人员)在审核新Bug时、将Bug分配给开发人员解决前,需要给岀该Bug的处理意
见。
Fixable
可修改。
表示Bug可以被修复或更正
Duplicated
重复。
表不该Bug已经被其它测试人员找岀来J('
纯粹’重复),或者开发认为原因是相冋的(但从测试来看,认为岀现的地方有所不冋、表现有所不冋等)
Postponed
延后。
由于时间、进度、重要程度或者技术/需求等方面的原因,认
为不能解决、须延期解决、或者本版不做留待到后续版本解决的
Bug。
(注:
因’Bug状态’字段中也有该值,根据各组各自使用情况,可以只保留一个,或者开发/测试各有侧重地使用这两个Postponed)
ByDesign
因设计结构问题无法修改。
测试人员认为是Bug,不符合逻辑,也不
符合用户的要求,但开发人员则认为是按照设计做的、只能如此处理,否则修改代价太大
Car?
tReproduce
不口j复现。
不能重现(如因Bug岀现的环境重现不了了),或以刖岀现的某个Bug自动消失了(可能是在处理其他Bug的时候把这个Bug一并修复掉了)。
因TD本身亦带有是否复现(Reproducible),字段,根据各组各自使用情况,可以用它来标识,或者不用它而在’处理意见’字段中用该值标识出)
DisagreeWithSuggestion
不同意所提意见或建议,不采纳
NotError
不是问题。
测试人员提错了
WontFix
这个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-0K2-PD3-DV4-NB5-NR6-AF。
0K
正确
PD
此问题悬而不决
DV
有错误可以暂时不考虑
NB
不是错误
NR
不能复现的错误
AR
需求不明确
问题定位:
Calculateerror
计算错误,指计算过程中、计算结果错误。
Dataerror
数据错误,指非计算结果类的数据错误。
Graphicserror
图形错误,指绘图、图形显示、图形编辑时发生的错误。
Interfaceerror
界面错误
Requirementerror
需求错误
Functionerror
功能错误
Unknownerror
未知错误
缺陷来源(Source):
指弓I起缺陷的起因
Requirement
由于需求的问题引起的缺陷
Architecture
由于构架的问题引起的缺陷
Design
由于设计的问题引起的缺陷
Code
由于编码的问题引起的缺陷
Test
由于测试的问题引起的缺陷
Integration
由于集成的问题引起的缺陷
类型仃ype):
是根据缺陷的自然属性划分的缺陷种类。
F-Function
影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。
并且设计文档需要正式的变更。
如逻辑,指针,循环,递归,功能等缺陷
A・Assignment
需要修改少量代码,如初始化或控制块。
如声明、重复命名,范围、限定等缺陷
1-1nterface
与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。
C-Checking
提示的错误信息,不适当的数据验证等缺陷。
Bui1d/package/merge
由于配置库、变更管理或版本控制引起的错误
D・Documentation
影响发布和维护,包括注释。
G-Algorithm
算法错误。
U・UserInterface
人机交互特性:
屏幕格式,确认用户输入,功能有效性,页面排版等方面的缺陷
P・Performsnee
不满足系统可测量的属性值,如:
执行时间,事务处理速率等。
N-Norms
不符合各种标准的要求,如编码标准、设计符号等。
(以上依各组实际情况可以作适当调整)
项目组各角色在Bug库中的权限
管理员:
全部权限
测试组长/经理:
测试人员:
可添加Bug、不能删除Bug可添加注释评论(R&
DComments)不可修改他人所提Bug可调整:
Bug概要(题目,Summary)问题描述、附件附图(Attachmen⑸、Bug状态、Bug级别、测试版本、测试产品、功能模块、测试状态、问题定位、复测状态、注释评论(R&
DComments)复测
人、复测日期、修改人
Bug概要(题目,
开发人员/需求人员:
不能刪除Bug、可添加注释评论(R&
DCommen⑸可调整:
注释评论(R&
DComments)是否复现、Bug状态(不过无法直接标为closed)、问题描述、处理意见、待测版本、修改人、修改日期。
可添加Bug。
开发组长/经理/需求经理:
除了开发人员的权限,还可调整:
优先级别、责任人、
Summary)附件附图(Attachments)
项目经理:
可添加Bug、可添加注释评论(R&
DComments)可修改字段:
Bug概要(题目,Summary)、问题描述、附件附图(Attachments)、Bug状态(不过无法直接标为closed)、修改人、优先级别、问题定位、处理意见、注释评论
(R&
DComments)、是否复现、责任人、待测版本。
TD库的话,可分配给其帐号及查
也可刪除Bug,但要与测试组长/经理协商。
不属于项目组成员的其他人如研发中心经理组成员等,有必要查看看的权限°
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不处于编辑态切换
则正常
5因此对于
所有项目采用TestDirector逬行Bug管理,该工具能从测试步骤自动生成Bug报告
Bug描述要求在测试方案用例设计(在TestPlan页中)阶段就可以进行控制。
附:
好的Bug报告应满足以下几方面的要求:
«
结构清晰
・复现故障再写报告
*隔离Bug:
更改条件复测
・归纳:
是否其他模块也有相同的Bug
4比较:
其他测试用例是否使用到此Bug
*总结:
报告的开头有Bug的总结
•精简:
不要有多余的步骤和语言
・无歧义:
语言明确
*中立:
无批评性语言
・讨论:
将要发岀的报告送其他测试人员讨论
小结
・通过专业的技术测试岀精确的Bug;
!
通过准确的文档报告Bug;
・通过良好的沟通使Bug尽快解决。