软件缺陷管理制度

软件缺陷管理规定

1 目的

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

软件缺陷的同义词有：bug，issue，defect，问题等，这里通称为缺陷。 缺陷会存在于软件产品的整个生命周期中：可以是软件代码的问题、系统文档（开发文档和测试文档等）存在的问题，或者是用户的帮助文档和使用指南方面的问题等。

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

2 范围

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

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

3 职责

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

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

3.3 其他参与人：主要有项目负责人、测试经理、用户等组成。他们对缺陷进行优先级划分，负责人进行确认并调解争议。

3.4 配置管理员：负责缺陷库的创建和权限管理，并监督指导缺陷库的定制。

4 缺陷管理流程

缺陷管理流程图，下图描述缺陷管理的工作程序，缺陷的生命周期状态。

1

4.1 登记

缺陷发现后，由测试人员登记到缺陷库。具体项目也可以允许用户向缺陷库提交缺陷。

缺陷登记后，提交前可以反复编辑，补充缺陷记录的信息。

测试人员必须保证登记的缺陷信息可以被处置负责人员理解，具体要求参见 5.10

登记后的缺陷状态是“新”。

2

4.2 提交

测试人员确认缺陷已经表述清楚，可以提交缺陷。 提交后的缺陷状态是“已提交”

缺陷提交前必须分配一个具体的开发人员负责，如果测试人员不确定谁负责，可以把缺陷分配给测试经理或项目负责人，再由他们重新分配负责人。

4.3 处置

开发人员确认缺陷是自己负责后，开始着手处理，并修改缺陷的状态为“打开”，表示缺陷正在处理中。

已经打开的缺陷也可以修改负责人。

4.4 解决

问题解决后，填写解决处置记录，写明造成缺陷的原因和解决方案，改变缺陷状态为“已解决”。

处置记录必须符合 5.12 规定的要求。

如果开发人员发现如下情况，可以把缺陷状态置成“否决”

条件 缺陷不可再现 与先前登记的缺陷重复 不是缺陷，是测试人员理解错误 处置意见 不可再现 重复问题 不是问题 处置记录 无 先前登记缺陷的编号 说明需求和设计中对应的内容，以证明软件行文符合预期要求。 缺陷轻微，且修改困难，或修改易导致更大的潜在问题 如果按照开发计划，缺陷发生的功能不属于当前开发阶段必须的完成的 推迟处理 不处理 说明缺陷和需求不相抵触，且轻微 说明处理的困难和风险 引用开发计划，写明何时处理。 需要项目负责人确认 4.5 验证

测试人员对“已解决”状态的缺陷进行重新测试，测试步骤应当按照登记的可重现步骤进行。

3

4.6 关闭

测试人员确认缺陷已经解决后，关闭缺陷。

对于否决的缺陷，测试人员需要和项目负责人讨论，项目负责人同意的可以关闭，项目负责人不同意的需要“重新打开”。

4.7 再打开

验证测试不通过的缺陷，应当重新打开，状态变为“重新打开”。 关闭了的缺陷再次出现时(通常因为解决缺陷的方法导致相同位置出现不同形式的缺陷时)，测试人员重新打开缺陷，开发人员需要继续解决。

项目负责人应当关注“重新打开”的缺陷。

5 缺陷记录

缺陷记录应当包含但不限于如下属性。

5.1 编号

缺陷的唯一标示，可以方便对特定缺陷记录的引用。

5.2 所属项目 5.3 软件发布版本

即缺陷是在什么发布版本中发现。

对于文档缺陷，这里使用文档在配置库里的版本号。

5.4 所属功能 5.5 负责人

负责处置解决缺陷的负责人，对于程序缺陷，负责人应当具体开发人员；对于文档缺陷，负责人应当是具体文档的作者。

缺陷登记者不明确责任人时，可以指定项目负责人为责任人，由他重新分配负责人。

4

5.6 状态

即缺陷通过一个跟踪修复过程的进展情况 新 已经提交 打开 已解决 新登记的缺陷，这个时候缺陷记录内容可以不完整，可以继续补充 缺陷信息完整，并分配责任人， 负责人开始处理 问题已经解决， 负责人必须填写完整的处置记录，内容包含对原因的分析和解决方法。参见5.11 否决 责任人呢不同意缺陷，或不处理缺陷 参见4.4 和 5.11 关闭 重新打开 验证测试通过后 没有通过验证测试，或不同意被否决。 已经关闭的缺陷再次出现的。 5.7 严重程度

标志缺陷对整个软件产品功能的影响程度。可以用数字表示，分为1到5档，可以用说明文字表示，具体项目可以根据自己的情况定义缺陷的严重程度标准，下表是一个常用的标准 严重程度 1 致命 导致软件无法使用问题，例如整个程序崩溃，导致无法使用，测试无法继续进行。 下面的问题应定义为严重度1级： ? 问题会自发的影响整个系统。 ? 用户使用正常的操作步骤，就会影响整个系统提供的服务。 ? 具有操作先后顺序的功能，一开始的步骤出现故障，导致后续步骤无法使用 2 3 严重 某个功能未实现或导致一个特性不能运行并且没有替代方案。 一般 错误导致了一个特性不能运行但可有一个替代方案 功能特征设计不符合系统的需求，不影响系统的业务，并且有相应的补救方法。 标示 含义 5

4 轻微 错误是表面化或微小的（提示信息不太准确友好、不准确、误导、错别字、界面布局或罕见故障等），对功能几乎没有影响，产品及属性仍可使用。 5 建议 建设性的意见或建议。 需求文档没有规定的特性，如果实现会对系统功能或者易用性有所提高。 5.8 优先级

优先级和严重程度有一定关系，但是不同于严重程度。严重程度表示对软件系统功能的影响程度，而优先级表明哪些缺陷应当尽早处理，反映了处置缺陷的时间安排。

优先级一般由测试人员建议，项目负责人确定。

1紧急 如果障碍相关开发人员的进一步开发活动，应立即进行修复工作； 如果阻止与此密切相关功能的进一步测试，应立即修复。 一般严重程度是1的需要立刻处理。 2必须的 3应该的 4可选的 5不需要 必须修改，发版前必须修正。 必须修改，不一定马上修改，但需确定在某个特定里版本发布前须修正 如果时间允许应该修改 允许不修改 测试人员和项目负责人负责督促缺陷的修改进度。测试人员、测试经理负责定期生成《测试报告》，统计该阶段缺陷的登记和处置情况。

5.9 缺陷来源

来源 需求 说明 需求描述不充分 需求有歧义 业务规则不完整 流程环节描述不完整 不合理的流程 设计 不正确的流程 不恰当的角色 不正确的前后条件（输入，输出） 功能描述不完整，不匹配 补充规范描述不完整 6

不一致的表述 开发 异常处理不充分或不恰当 结构不当 逻辑判断不当 对攻击性的使用处理不足，例如无效数据，非法字符。 变量定义和使用不当，例如作用域不当 多余的循环和分支 测试 流程错误 功能没有完全测试 补充规范（有效，格式等）没有完全测试 缺少工具和资源的使用规范 使用了错误的环境（比如数据库） 其他文档 建构 需求，设计，测试用例，测试计划以外其他文档 建构过程导致的 5.10 缺陷描述

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

具体要求为：

? 单一：尽量一个报告只针对一个软件缺陷

? 简洁：每个步骤的描述应尽可能简洁明了。只解释事实、演示和描

述软件缺陷必要的细节

? 再现：必须描述重现的步骤和条件，比如具体输入参数值，以便进

行回归验证。如果能截图就应当提供截图。截图文件不建议用BMP格式。

? 不能使用笼统的抽象词句：比如“有错误”之类 ? 问题描述一般格式：

? 可重现的步骤: 包括发生错误时的输入值 ? 期望结果 ? 实际结果

? 其它信息，可依实际情况增加

5.11 处理意见

处置意见是缺陷负责人对缺陷处置结果的简短描述。

7

如果缺陷已经修正解决，处置意见是“已修正”，对于否决的缺陷，处置意见参考4.4 的表格

5.12 处置记录

处置记录通常是解决方法。 缺陷解决办法的描述要求包括：

? 原因：说明缺陷产生的原因，比如：设计考虑不周，边界处理不严

密，逻辑判断不合理。要求描述具体简洁，以便总结经验。 ? 解决方法：修改涉及的文件，源代码，配置，脚本等。 ? 概括：缺陷是否可能存在于其他位置，或引起其他问题。

8

本文来源：https://www.bwwdw.com/article/0axv.html