软件缺陷管理制度.docVIP

  1. 1、本文档共7页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多

软件缺陷管理规定

1目的

缺陷是产品与规定要求不相符的局部。软件缺陷是开发、评审、测试和使用的过程中,发现的软件产品与用户需求,设计要求不符的局部,这些局部造成使用不方便或在某种程度上不能满足用户的要求。

软件缺陷的同义词有:bug,issue,defect,问题等,这里通称为缺陷。

缺陷会存在于软件产品的整个生命周期中:可以是软件代码的问题、系统文档〔开发文档和测试文档等〕存在的问题,或者是用户的帮助文档和使用指南方面的问题等。

本文规定了软件缺陷登记跟踪处理的完整过程标准。

2范围

适用于软件的整个生命周期。

不限于测试过程发现的缺陷。评审,用户使用等过程中发现的缺陷都是应当按照本流程进行登记跟踪管理。

3职责

3.1测试工程师:在这里主要是指发现和报告缺陷的测试人员。在一般流程中,他需要对这个缺陷后续相关的状态负责:包括相关人员对这个缺陷相关信息的询问答复,以及验证测试。

3.2开发工程师:这里主要指对这个缺陷进行研究和修改的开发人员。同时,他需要对修改后的缺陷在提交测试人员正式测试验证之前需要进行验证测试。

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档,可以用说明文字表示,具体工程可以根据自己的情况定义

文档评论(0)

199****4744 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

版权声明书
用户编号:7002121022000045

1亿VIP精品文档

相关文档