第 1 章 总则

为了加强部门管理工作， 建立规范的缺陷管理制度， 提高工作水平， 根据公司和部门的有关规定， 制定缺陷管理制度。

本缺陷管理制度适用于工程技术部。各测试， 研发人员应当依据本制度的规定， 规范工作， 保证软件质量。

软件缺陷又被叫做 Bug。所谓软件缺陷， 即为软件中存在的某种破坏正常运行能力的问题、 错误， 或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983 对缺陷有一个标准的定义：从产品内部看， 缺陷是软件产品开发或维护过程中存在的错误、 毛病等各种问题；从产品外部看， 缺陷是系统所需要实现的某种功能的失效或违背。

软件缺陷的管理分为四个阶段。包括：缺陷提交、 明确指明缺陷类型 、 缺陷修复、 缺陷回归验证。

第 2 章 职责

项目人员应对各阶段测试发现的缺陷进行跟踪管理， 以保证各级缺陷的修复率达到一定标准。包含内容如下：

2.1 测试人员在提供的缺陷模板中新建或重新打开缺陷。

2.2 测试人员提交的缺陷将反馈给项目负责人， 由项目负责人安排开发人员修复缺陷。

2.3 开发人员修复缺陷后， 记录处理时间及处理结果， 并将文档及时反馈给测试人员验证。

2.4 测试人员验证缺陷后， 记录验证时间及验证结果， 并提交给项目负责人。

第 3 章 缺陷类型

缺陷类型是指根据缺陷的自然属性划分的缺陷种类。共分为九类， 包括：文档缺陷、 设计缺陷、 配置缺陷、 界面交互缺陷、 数据校验缺陷、 查询统计缺陷、 功能缺陷、 性能缺陷、安全性缺陷。

3.1 文档缺陷

文档缺陷是指软件相关文档不满足其完整性、 正确性、 一致性、 易理解性、 易浏览性的要求。

满足以下一或多种情况：

（1） 影响发布和维护， 其中包括注释。

（2） 文档中术语不一致。

（3） 文档中词语、 语句表达不清晰， 产生歧义。

（4） 文档内容缺失， 结构不完整。

（5） 文档编制过程中产生的错误。

（6） 文档中发现的其他错误。

3.2设计缺陷

设计缺陷是指软件在最初设计时由于未考虑全面， 而使软件在使用中存在的一些潜在的缺陷。满足以下一或多种情况：

（1） 需求分析阶段没有考虑和挖掘到的隐式需求， 导致的需求缺失。

（2） 操作便捷性设计不符合大众操作习惯。

（3） 控件功能设计不符合大众使用习惯。

（4） 错误提示内容不符合大众阅读习惯。

（5） 其他设计不合理引发的缺陷。

3.3 配置缺陷

配置缺陷是指由于配置库、 变更管理或版本控制引起的错误。满足以下一或多种情况：

（1） 独立安装部署不成功。

（2） 配置文件或初始化数据错误。

（3） 不同运行环境产生的错误。

3.4 界面交互缺陷

界面交互缺陷是指接口通信和人机交互时产生的缺陷。满足以下一或多种情况：

（1） 组件、 模块之间数据通信错误。

（2） 程序接口错误。

（3） 硬件接口通信错误。

（4） 界面不存在， 界面不满足易用性要求， 界面难以被用户理解， 界面不协调不美观，提示信息没有使用用业务词汇或者容易被用户理解的词汇而是使用计算机专业术语。

（5） 界面风格不相对一致， 不符合操作习惯。

（6） 提示、 警告、 错误说明等友好信息表达模糊、 失当。

（7） 没有区别不同操作（增加、 删除、 修改、 查询） 对应界面的性质。

（8） 没有提供辅助输入手段。

3.5数据校验缺陷

数据校验缺陷是指提示的错误信息， 不适当的数据验证等缺陷。满足以下一或多种情况：

（1） 数据计算错误。

（2） 数据约束错误。

（3） 不同操作之间数据逻辑校验错误。

（4） 数据库发生死锁。

（5） 数据库的表、 缺省值未加完整性等约束条件。

（6） 数据库连接错误。

（7） 数据库中得表有过多空字段。

3.6 查询统计缺陷

查询统计缺陷是指条件设置不准确引起的查询统计结果不正确。满足以下一或多种情况：

（1） 查询条件设置不准确。

（2） 查询结果列表异常。

（3） 同一查询条件得到的结果不一致。

3.7 功能缺陷

功能缺陷是指影响软件要求或基本功能实现的缺陷。满足以下一或多种情况：

（1） 功能无法实现。

（2） 功能实现错误。

（3） 业务流程错误。

（4） 功能操作与数据库存储不一致。

（5） 功能与辅助帮助不吻合。

3.8 性能缺陷

性能缺陷是指产品性能不能满足需求规格说明书中对性能需求的要求。满足以下一或多种情况：

（1） 业务处理效率低。

（2） 查询统计效率低。

（3） 响应速度不能满足需求规格说明书中的要求。

3.9 安全性缺陷

安全性缺陷是指产品不能满足需求规格说明书中对安全性需求的要求。满足以下一或多种情况：

（1） 用户登录用户名/口令校验不正确。

（2） 口令没有掩码显示。

（3） 用户权限分配错误。

（4） 用户功能超权限。

第 4 章 缺陷管理流程

4.1新增（提交）

缺陷提交阶段需要提交缺陷报告， 测试人员必须保证登记的缺陷信息可以被处置负责人员理解， 因此缺陷报告必须详细描述缺陷内容。详细内容参见缺陷记录。

4.2 定位

缺陷分析定位阶段需要根据缺陷报告的内容对缺陷进行分析和定位。缺陷分析和定位是相关人员根据缺陷报告中对缺陷的详细描述查找重现缺陷， 确定缺陷产生的原因， 明确缺陷所处的位置， 以便修改缺陷。

4.4 解决

缺陷修复阶段需要对已经定位的缺陷进行修改。缺陷修复是开发人员对已经分析定位的缺陷进行修改并更改缺陷状态， 修改后的软件需要实现预期的结果（缺陷报告中的预期结果）。

4.5 否决

如果开发人员发现该缺陷不可再现、 重复、 不是问题等情况， 可以把缺陷状态设置成“否决”。

4.6 推迟处理

如果按照开发计划， 缺陷发生的功能不属于当前开发阶段必须的完成的， 可将缺陷状态设置为“推迟处理”。

4.7 回归验证

缺陷回归验证阶段需要对已经修改的缺陷进行验证和回归测试。缺陷回归验证是测试人人员对已经修改的缺陷进行回归测试， 根据缺陷报告中的操作步骤对缺陷重新进行测试， 并对缺陷修改过程中可能影响到的组件、 模块或功能进行重新测试， 验证修改后的缺陷可以实现预期结果并对其他组件、 模块或功能无影响。同时， 根据验证结果修改相应的缺陷状态，提交新产生的缺陷。

4.8 再打开

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

4.9 关闭

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

第 5 章 缺陷记录

5.1 编号

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

5.2 项目

5.3 发布版本

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

5.4 功能模块

5.5 缺陷描述

对该缺陷进行简短的描述， 尽量使负责人能够理解。

5.6 重现步骤

描述该缺陷出现的详细步骤， 尽量做到步骤清楚、 有实例、 可再现。

5.7 严重程度

缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。分为五类， 包括：致命、严重、 一般、 轻微、 提示。

（1） 致命：不能执行正常工作功能或重要功能。

（2） 严重：严重影响系统要求或基本功能的实现导致系统出错或关闭进程， 且没有办法更正。（重新安装或重新启动该软件不属于更正办法）

（3） 一般：严重影响系统要求或基本功能的实现导致系统提示错误， 但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法）

（4） 轻微：使操作者不方便或遇到麻烦， 但它不影响执行工作功能或重要功能。

（5） 提示：其他错误。

5.8 优先级

缺陷优先级指缺陷必须被修复的紧急程度。分为四类， 包括：紧急、 严重、 一般、 轻微。

（1） 紧急：缺陷不被修改将无法继续测试。

（2） 严重：缺陷必须被立即解决。

（3） 一般：缺陷需要正常排队等待修复或列入软件发布清单。

（4） 建议：缺陷可以在方便时被纠正。

5.9 状态

缺陷状态指缺陷在跟踪修复过程中的进展状态。分为五类， 包括：新建、 打开、 重现打开、 否决、 解决、 延迟、 关闭。

（1） 新建：已提交的缺陷。

（2） 打开：确认“提交的缺陷”， 等待处理。

（3） 重新打开：验证后发现未修复的缺陷。

（4） 否决：否决“提交的缺陷”， 不需要修复或不是缺陷。

（5） 解决：缺陷被修复。

（6） 延迟：缺陷暂缓修复。

（7） 关闭：确认被修复的缺陷， 将其关闭。

5.10 负责人

负责处置解决缺陷的负责人， 对于功能缺陷， 负责人应当具体开发人员；对于文档缺陷，负责人应当是具体文档的作者。缺陷登记者不明确责任人时， 可以指定项目负责人为责任人，由他重新分配负责人。

5.11 处理意见

处置意见是缺陷负责人对缺陷处置结果的简短描述。如“已修正”、“重复提交”、“不是问题” 等。

5.12 处理记录（解决的办法）

处置记录通常是解决方法， 其中包括不限于简要阐述缺陷产生原因、 解决方法， 是否会引起其他问题等。

第 6 章 附录

测试团队中的任何人都有权利和义务提出缺陷,并负责跟踪和关闭。如本人无法跟踪和关闭， 请委托上一级领导进行跟踪并关闭缺陷。

缺陷的严重程度、 优先级和状态均严格按照本制度执行。