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