软件缺陷管理制度Word格式.docx
《软件缺陷管理制度Word格式.docx》由会员分享,可在线阅读,更多相关《软件缺陷管理制度Word格式.docx(8页珍藏版)》请在冰豆网上搜索。
![软件缺陷管理制度Word格式.docx](https://file1.bdocx.com/fileroot1/2022-10/20/d3aad25b-203e-4555-af63-21524f1ca1ab/d3aad25b-203e-4555-af63-21524f1ca1ab1.gif)
这里主要指对这个缺陷进行研究和修改的开发人员。
同时,他需要对修改后的缺陷在提交测试人员正式测试验证之前需要进行验证测试。
3.3其他参与人:
主要有项目负责人、测试经理、用户等组成。
他们对缺陷进行优先级划分,负责人进行确认并调解争议。
3.4配置管理员:
负责缺陷库的创建和权限管理,并监督指导缺陷库的定制
4缺陷管理流程
4.1登记
缺陷发现后,由测试人员登记到缺陷库。
具体项目也可以允许用户向缺陷库提交缺陷。
缺陷登记后,提交前可以反复编辑,补充缺陷记录的信息。
测试人员必须保证登记的缺陷信息可以被处置负责人员理解,具体要求参见
5.10
登记后的缺陷状态是“新”。
4.2提交
测试人员确认缺陷已经表述清楚,可以提交缺陷。
提交后的缺陷状态是“已提交”缺陷提交前必须分配一个具体的开发人员负责,如果测试人员不确定谁负责,可以把缺陷分配给测试经理或项目负责人,再由他们重新分配负责人。
4.3处置
开发人员确认缺陷是自己负责后,开始着手处理,并修改缺陷的状态为“打开”,表示缺陷正在处理中。
已经打开的缺陷也可以修改负责人。
4.4解决
问题解决后,填写解决处置记录,写明造成缺陷的原因和解决方案,改变缺
陷状态为“已解决。
”
处置记录必须符合5.12规定的要求。
如果开发人员发现如下情况,可以把缺陷状态置成“否决”
条件
处置意见
处置记录
缺陷不可再现
不可再现
无
与先前登记的缺陷重复
重复问题
先前登记缺陷的编号
不是缺陷,是测试人员理解错误
不是问题
说明需求和设计中对应的内容,以证明软件行文符合预期要求。
缺陷轻微,且修改困难,或修改易导致更大的潜在问题
不处理
说明缺陷和需求不相抵触,且轻微
说明处理的困难和风险
如果按照开发计划,缺陷发生的功
能不属于当前开发阶段必须的完
推迟处理
引用开发计划,写明何时处理。
需要项目负责人确认
成的
4.5验证
测试人员对“已解决”状态的缺陷进行重新测试,测试步骤应当按照登记的可重现步骤进行。
4.6关闭
测试人员确认缺陷已经解决后,关闭缺陷。
项目负责人同意的可以
对于否决的缺陷,测试人员需要和项目负责人讨论,关闭,项目负责人不同意的需要“重新打开”。
4.7再打开
验证测试不通过的缺陷,应当重新打开,状态变为“重新打开”。
关闭了的缺陷再次出现时(通常因为解决缺陷的方法导致相同位置出现不同形式的缺陷时),测试人员重新打开缺陷,开发人员需要继续解决。
项目负责人应当关注“重新打开”的缺陷。
5缺陷记录
缺陷记录应当包含但不限于如下属性。
5.1编号
缺陷的唯一标示,可以方便对特定缺陷记录的引用
5.2所属项目
5.3软件发布版本
即缺陷是在什么发布版本中发现。
对于文档缺陷,这里使用文档在配置库里的版本号
5.4所属功能
5.5负责人
负责处置解决缺陷的负责人,对于程序缺陷,负责人应当具体开发人员;
对
于文档缺陷,负责人应当是具体文档的作者
缺陷登记者不明确责任人时,可以指定项目负责人为责任人,由他重新分配负责人。
5.6状态
即缺陷通过一个跟踪修复过程的进展情况
新
新登记的缺陷,这个时候缺陷记录内容可以不完整,可以继续补充
已经提交
缺陷信息完整,并分配责任人,
打开
负责人开始处理
已解决
问题已经解决,
负责人必须填写完整的处置记录,内容包含对原因的分析和解决方法。
参见
5.11
否决
责任人呢不同意缺陷,或不处理缺陷参见4.4和5.11
关闭
验证测试通过后
重新打开
没有通过验证测试,或不同意被否决。
已经关闭的缺陷再次出现的。
5.7严重程度
标志缺陷对整个软件产品功能的影响程度。
可以用数字表示,分为1到5档,可以用说明文字表示,具体项目可以根据自己的情况定义缺陷的严重程度标准,下表是一个常用的标准
严重
程度
标示
含义
1
致命
导致软件无法使用问题,例如整个程序崩溃,导致无法使用,测试无法继续进行。
下面的问题应定义为严重度1级:
问题会自发的影响整个系统。
用户使用正常的操作步骤,就会影响整个系统提供的服务。
具有操作先后顺序的功能,一开始的步骤出现故障,导致后续步骤无法使用
2
某个功能未实现或导致一个特性不能运行并且没有替代方案。
3
一般
错误导致了一个特性不能运行但可有一个替代方案功能特征设计不符合系统的需求,不影响系统的业务,并且有相应的补救方法。
4
轻微
错误是表面化或微小的(提示信息不太准确友好、不准确、误导、错别字、界面布局或罕见故障等),对功能几乎没有影响,产品及属性仍可使用。
5
建议
建设性的意见或建议。
需求文档没有规定的特性,如果实现会对系统功能或者易用性有所提高。
5.8优先级
优先级和严重程度有一定关系,但是不同于严重程度。
严重程度表示对软件系统功能的影响程度,而优先级表明哪些缺陷应当尽早处理,反映了处置缺陷的时间安排。
优先级一般由测试人员建议,项目负责人确定
1紧急
如果障碍相关开发人员的进一步开发活动,应立即进行修复工作;
如果阻止与此密切相关功能的进一步测试,应立即修复。
一般严重程度是1的需要立刻处理。
2必须的
必须修改,发版前必须修正。
3应该的
必须修改,不一定马上修改,但需确定在某个特定里版本发布前须修正
4可选的
如果时间允许应该修改
5不需要
允许不修改
测试人员和项目负责人负责督促缺陷的修改进度。
测试人员、测试经理负责定期生成《测试报告》,统计该阶段缺陷的登记和处置情况。
5.9缺陷来源
来源
说明
需求
需求描述不充分需求有歧义业务规则不完整流程环节描述不完整不合理的流程
设计
不正确的流程
不恰当的角色
不正确的前后条件(输入,输出)功能描述不完整,不匹配补充规范描述不完整不一致的表述
开发
异常处理不充分或不恰当
结构不当逻辑判断不当对攻击性的使用处理不足,例如无效数据,非法字符。
变量定义和使用不当,例如作用域不当多余的循环和分支
测试
流程错误
功能没有完全测试补充规范(有效,格式等)没有完全测试缺少工具和资源的使用规范使用了错误的环境(比如数据库)
其他文档
需求,设计,测试用例,测试计划以外其他文档
建构
建构过程导致的
5.10缺陷描述
缺陷描述的要求为分类准确、叙述简洁、步骤清楚、有实例、可再现、复杂问题有据可查(截图或其它形式的附件)。
具体要求为:
单一:
尽量一个报告只针对一个软件缺陷简洁:
每个步骤的描述应尽可能简洁明了。
只解释事实、演示和描述软件缺陷必要的细节再现:
必须描述重现的步骤和条件,比如具体输入参数值,以便进行回归验证。
如果能截图就应当提供截图。
截图文件不建议用BMP格式。
不能使用笼统的抽象词句:
比如“有错误”之类问题描述一般格式:
可重现的步骤:
包括发生错误时的输入值期望结果
实际结果其它信息,可依实际情况增加
5.11处理意见
处置意见是缺陷负责人对缺陷处置结果的简短描述。
如果缺陷已经修正解决,处置意见是“已修正”,对于否决的缺陷,处置意见参考4.4的表格
5.12处置记录
处置记录通常是解决方法。
缺陷解决办法的描述要求包括:
原因:
说明缺陷产生的原因,比如:
设计考虑不周,边界处理不严密,逻辑判断不合理。
要求描述具体简洁,以便总结经验。
解决方法:
修改涉及的文件,源代码,配置,脚本等。
概括:
缺陷是否可能存在于其他位置,或引起其他问题。