软件缺陷管理制度

软件缺陷管理制度
1目的
缺陷是产品与规定要求不相符的部分。

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

软件缺陷的同义词有：bug，iue，defect，问题等，这里通称为缺陷。

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

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

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

不限于测试过程发现的缺陷。

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

3职责
3.1测试工程师：在这里主要是指发现和报告缺陷的测试人员。

在一
般流程中，他需要对这个缺陷后续相关的状态负责：包括相关人员对这个
缺陷相关信息的询问回答，以及验证测试。

3.2开发工程师：这里主要指对这个缺陷进行研究和修改的开发人员。

同时，他需要对修改后的缺陷在提交测试人员正式测试验证之前需要进行
验证测试。

3.3其他参与人：主要有项目负责人、测试经理、用户等组成。

他们对缺陷进行优先级划分，负责人进行确认并调解争议。

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

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

4.1登记
缺陷发现后，由测试人员登记到缺陷库。

具体项目也可以允许用户向缺陷库提交缺陷。

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

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

2
4.2提交
测试人员确认缺陷已经表述清楚，可以提交缺陷。

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

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

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

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

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

如果开发人员发现如下情况，可以把缺陷状态置成“否决”
测试人员对“已解决”状态的缺陷进行重新测试，测试步骤应当按照登记的可重现步骤进行。

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

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

4.7再打开
验证测试不通过的缺陷，应当重新打开，状态变为“重新打开”。

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

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

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

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

5.2所属项目5.3软件发布版本
即缺陷是在什么发布版本中发现。

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

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

4
5.6状态
即缺陷通过一个跟踪修复过程的进展情况新已经提交打开已解决新登
记的缺陷，这个时候缺陷记录内容可以不完整，可以继续补充缺陷信息完整，并分配责任人，负责人开始处理问题已经解决，负责人必须填写完整
的处置记录，内容包含对原因的分析和解决方法。

参见5.11否决责任人
呢不同意缺陷，或不处理缺陷参见4.4和5.11关闭重新打开验证测试通
过后没有通过验证测试，或不同意被否决。

已经关闭的缺陷再次出现的。

5.7严重程度
标志缺陷对整个软件产品功能的影响程度。

可以用数字表示，分为1到5档，可以用说明文字表示，具体项目可以根据自己的情况定义缺陷的严重程度标准，下表是一个常用的标准严重程度1致命导致软件无法使用问题，例如整个程序崩溃，导致无法使用，测试无法继续进行。

下面的问题应定义为严重度1级：问题会自发的影响整个系统。

用户使用正常的操作步骤，
就会影响整个系统提供的服务。

具有操作先后顺序的功能，一开始的步骤出现故障，导致后续步骤无法使用23严重某个功能未实现或导致一个特
性不能运行并且没有替代方案。

一般错误导致了一个特性不能运行但可有一个替代方案功能特征设计不符合系统的需求，不影响系统的业务，并且有相应的补救方法。

标示含义5
4轻微错误是表面化或微小的（提示信息不太准确友好、不准确、误导、错别字、界面布局或罕见故障等），对功能几乎没有影响，产品及属
性仍可使用。

5建议建设性的意见或建议。

需求文档没有规定的特性，如
果实现会对系统功能或者易用性有所提高。

5.8优先级
优先级和严重程度有一定关系，但是不同于严重程度。

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

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

1紧急如果障碍相关开发人员的进一步开发活动，应立即进行修复工作；如果阻止与此密切相关功能的进一步测试，应立即修复。

一般严重程
度是1的需要立刻处理。

2必须的3应该的4可选的5不需要必须修改，
发版前必须修正。

必须修改，不一定马上修改，但需确定在某个特定里版
本发布前须修正如果时间允许应该修改允许不修改测试人员和项目负责人
负责督促缺陷的修改进度。

测试人员、测试经理负责定期生成《测试报告》，统计该阶段缺陷的登记和处置情况。

不一致的表述开发异常处理不充分或不恰当结构不当逻辑判断不当对
攻击性的使用处理不足，例如无效数据，非法字符。

变量定义和使用不当，例如作用域不当多余的循环和分支测试流程错误功能没有完全测试补充规
范（有效，格式等）没有完全测试缺少工具和资源的使用规范使用了错误
的环境（比如数据库）其他文档建构需求，设计，测试用例，测试计划以
外其他文档建构过程导致的5.10缺陷描述
缺陷描述的要求为分类准确、叙述简洁、步骤清楚、有实例、可再现、复杂问题有据可查（截图或其它形式的附件）。

具体要求为：
单一：尽量一个报告只针对一个软件缺陷
简洁：每个步骤的描述应尽可能简洁明了。

只解释事实、演示和描
述软件缺陷必要的细节
再现：必须描述重现的步骤和条件，比如具体输入参数值，以便进
行回归验证。

如果能截图就应当提供截图。

截图文件不建议用BMP格式。

不能使用笼统的抽象词句：比如“有错误”之类问题描述一般格式：可重现的步骤:包括发生错误时的输入值期望结果实际结果
其它信息，可依实际情况增加
5.11处理意见
处置意见是缺陷负责人对缺陷处置结果的简短描述。

7
如果缺陷已经修正解决，处置意见是“已修正”，对于否决的缺陷，
处置意见参考4.4的表格
5.12处置记录
处置记录通常是解决方法。

缺陷解决办法的描述要求包括：
原因：说明缺陷产生的原因，比如：设计考虑不周，边界处理不严
密，逻辑判断不合理。

要求描述具体简洁，以便总结经验。

解决方法：修改涉及的文件，源代码，配置，脚本等。

概括：缺陷是否可能存在于其
他位置，或引起其他问题。

8。