软件缺陷管理制度Word格式.docx

1、这里主要指对这个缺陷进行研究和修改的开发人员。 同时， 他需要对修改后的缺陷在提交测试人员正式测试验证之前需要进行验证测试。3.3其他参与人：主要有项目负责人、测试经理、用户等组成。他们对缺陷 进行优先级划分，负责人进行确认并调解争议。3.4配置管理员：负责缺陷库的创建和权限管理， 并监督指导缺陷库的定制4缺陷管理流程4.1登记缺陷发现后， 由测试人员登记到缺陷库。 具体项目也可以允许用户向缺陷库 提交缺陷。缺陷登记后，提交前可以反复编辑，补充缺陷记录的信息。测试人员必须保证登记的缺陷信息可以被处置负责人员理解， 具体要求参见5.10登记后的缺陷状态是“新”。4.2提交测试人员确认缺陷已经表述

2、清楚，可以提交缺陷。提交后的缺陷状态是“已提交” 缺陷提交前必须分配一个具体的开发人员负责，如果测试人员不确定谁负 责，可以把缺陷分配给测试经理或项目负责人，再由他们重新分配负责人。4.3处置开发人员确认缺陷是自己负责后，开始着手处理，并修改缺陷的状态为“打 开”，表示缺陷正在处理中。已经打开的缺陷也可以修改负责人。4.4解决问题解决后， 填写解决处置记录， 写明造成缺陷的原因和解决方案， 改变缺陷状态为“已解决。”处置记录必须符合 5.12 规定的要求。 如果开发人员发现如下情况，可以把缺陷状态置成“否决”条件处置意见处置记录缺陷不可再现不可再现无与先前登记的缺陷重复重复问题先前登记缺陷的编

3、号不是缺陷，是测试人员理解错误不是问题说明需求和设计中对应的内容，以证明 软件行文符合预期要求。缺陷轻微， 且修改困难， 或修改易 导致更大的潜在问题不处理说明缺陷和需求不相抵触，且轻微说明处理的困难和风险如果按照开发计划， 缺陷发生的功能不属于当前开发阶段必须的完推迟处理引用开发计划，写明何时处理。需要项目负责人确认成的4.5验证测试人员对“已解决”状态的缺陷进行重新测试，测试步骤应当按照登记的可 重现步骤进行。4.6关闭测试人员确认缺陷已经解决后，关闭缺陷。项目负责人同意的可以对于否决的缺陷， 测试人员需要和项目负责人讨论， 关闭，项目负责人不同意的需要“重新打开”。4.7再打开验证测试不

4、通过的缺陷，应当重新打开，状态变为“重新打开” 。关闭了的缺陷再次出现时 （通常因为解决缺陷的方法导致相同位置出现不同 形式的缺陷时 ），测试人员重新打开缺陷，开发人员需要继续解决。项目负责人应当关注“重新打开”的缺陷。5缺陷记录缺陷记录应当包含但不限于如下属性。5.1编号缺陷的唯一标示，可以方便对特定缺陷记录的引用5.2所属项目5.3软件发布版本即缺陷是在什么发布版本中发现。对于文档缺陷，这里使用文档在配置库里的版本号5.4所属功能5.5负责人负责处置解决缺陷的负责人， 对于程序缺陷， 负责人应当具体开发人员； 对于文档缺陷，负责人应当是具体文档的作者缺陷登记者不明确责任人时， 可以指定项目

5、负责人为责任人， 由他重新分配 负责人。5.6状态即缺陷通过一个跟踪修复过程的进展情况新新登记的缺陷，这个时候缺陷记录内容可以不完整，可以继续补充已经提交缺陷信息完整，并分配责任人，打开负责人开始处理已解决问题已经解决，负责人必须填写完整的处置记录，内容包含对原因的分析和解决方法。参见5.11否决责任人呢不同意缺陷，或不处理缺陷 参见 4.4 和 5.11关闭验证测试通过后重新打开没有通过验证测试，或不同意被否决。已经关闭的缺陷再次出现的。5.7严重程度标志缺陷对整个软件产品功能的影响程度。可以用数字表示，分为 1 到 5 档，可以用说明文字表示， 具体项目可以根据自己的情况定义缺陷的严重程度

6、标 准，下表是一个常用的标准严重程度标示含义1致命导致软件无法使用问题，例如整个程序崩溃，导致无法使用，测试无法继 续进行。下面的问题应定义为严重度 1 级： 问题会自发的影响整个系统。 用户使用正常的操作步骤，就会影响整个系统提供的服务。 具有操作先后顺序的功能，一开始的步骤出现故障，导致后续步骤无 法使用2某个功能未实现或导致一个特性不能运行并且没有替代方案。3一般错误导致了一个特性不能运行但可有一个替代方案 功能特征设计不符合系统的需求，不影响系统的业务，并且有相应的补救 方法。4轻微错误是表面化或微小的（提示信息不太准确友好、不准确、误导、错别字、 界面布局或罕见故障等） ，对功能几乎

7、没有影响，产品及属性仍可使用。5建议建设性的意见或建议。需求文档没有规定的特性，如果实现会对系统功能或者易用性有所提高。5.8优先级优先级和严重程度有一定关系， 但是不同于严重程度。 严重程度表示对软件 系统功能的影响程度， 而优先级表明哪些缺陷应当尽早处理， 反映了处置缺陷的 时间安排。优先级一般由测试人员建议，项目负责人确定1 紧急如果障碍相关开发人员的进一步开发活动，应立即进行修复工作； 如果阻止与此密切相关功能的进一步测试，应立即修复。 一般严重程度是 1 的需要立刻处理。2 必须的必须修改，发版前必须修正。3 应该的必须修改，不一定马上修改，但需确定在某个特定里版本发布前须修正4 可

8、选的如果时间允许应该修改5 不需要允许不修改测试人员和项目负责人负责督促缺陷的修改进度。 测试人员、 测试经理负责 定期生成测试报告 ，统计该阶段缺陷的登记和处置情况。5.9缺陷来源来源说明需求需求描述不充分 需求有歧义 业务规则不完整 流程环节描述不完整 不合理的流程设计不正确的流程不恰当的角色不正确的前后条件（输入，输出） 功能描述不完整，不匹配 补充规范描述不完整 不一致的表述开发异常处理不充分或不恰当结构不当 逻辑判断不当 对攻击性的使用处理不足，例如无效数据，非法字符。 变量定义和使用不当，例如作用域不当 多余的循环和分支测试流程错误功能没有完全测试 补充规范（有效，格式等）没有完全

9、测试 缺少工具和资源的使用规范 使用了错误的环境（比如数据库）其他文档需求，设计，测试用例，测试计划以外其他文档建构建构过程导致的5.10缺陷描述缺陷描述的要求为分类准确、叙述简洁、步骤清楚、有实例、可再现、复杂 问题有据可查（截图或其它形式的附件） 。具体要求为： 单一：尽量一个报告只针对一个软件缺陷 简洁：每个步骤的描述应尽可能简洁明了。只解释事实、演示和描 述软件缺陷必要的细节 再现：必须描述重现的步骤和条件，比如具体输入参数值，以便进 行回归验证。如果能截图就应当提供截图。截图文件不建议用 BMP 格式。不能使用笼统的抽象词句：比如“有错误”之类 问题描述一般格式：可重现的步骤 : 包括发生错误时的输入值 期望结果实际结果 其它信息，可依实际情况增加5.11处理意见处置意见是缺陷负责人对缺陷处置结果的简短描述。 如果缺陷已经修正解决，处置意见是“已修正”，对于否决的缺陷，处置意见 参考 4.4 的表格5.12处置记录处置记录通常是解决方法。缺陷解决办法的描述要求包括：原因：说明缺陷产生的原因，比如：设计考虑不周，边界处理不严 密，逻辑判断不合理。要求描述具体简洁，以便总结经验。 解决方法：修改涉及的文件，源代码，配置，脚本等。 概括：缺陷是否可能存在于其他位置，或引起其他问题。